Hi Tudor,
>
> Very interesting. This is the first time I heard of lombok, and I would
> have to look into it more closely. What I find strange is that you get to
> visit the method (this is where you get the unresolved method declaration
> from) even if the method does not exist. I am sure I do not understand
> something. Would you like to open an issue for this?
>
>
Actually the lombok issue resolved itself. I found out that lombok provides
a delombok functionality (https://projectlombok.org/features/delombok.html
):
"Delombok [...] allows you to use lombok with these tools by preprocessing
your java code into java code with all of lombok's transformations already
applied. [...] Delombok's standard mode of operation is that it copies an
entire directory into another directory, recursively, skipping class files,
and applying lombok transformations to any java source files it encounters."
So I just have analyse my delomboked source files instead of the original
source files and everything will be fine.
> > The cause of the next problem is that we have multiple smaller
> applications (e.g. backoffice and frontend) which are separate applications
> but share a common db. Some of these services have classes with the same
> class and packagename (e.g. an annotation WebController). This lead to the
> following error message:
> > unresolved annotation type declaration - WebController -
> c:\data\moose\....\WebController.java - line 12
> > I had to start the debugger to find the issue. I found it because
> AnnotationTypeDeclaration.parent.problems = "Pb(323) The type
> WebController is already defined"
> > If the package names are different the problems disappears. Then I only
> get the the lombok errors. As a solution I will create unique base package
> names for my projecfs (which makes sense anyway).
>
> Indeed. The only other solution for this problem is to analyze each
> sub-project separately. Also, perhaps I can manage to create a better log
> statement for this case. Would you like to open an issue on github for this?
>
>
> > Note that you could the following example to you README of jdt2famix to
> show how to download the dependencies for gradle projects:
> >
> > task copyDependencies(type: Copy) {
> > from configurations.compile
> > from configurations.testCompile
> > into 'dependencies’
> > }
>
> Thanks!
>
> Could you also tell me how to actually add this to a gradle script and
> invoke it? I tried a variation of this (without
> configurations.testCompile), but I did not manage to run it. I am likely
> missing something basic here, and perhaps if you would walk me through a
> concrete example, I could make some progress :). For example, what steps
> would you use for downloading the dependencies of
> https://github.com/spring-projects/spring-framework ?
>
> Cheers,
> Doru
>
>
Actually I tested it with the spring gradle file and it worked. The spring
build file is a little bit more complicated, because it is a multimodule
project. Basically an easy way to find the right place is to define it
directly after the dependencies of the java projects. I added it as follows
to the configure (allprojects) section:
configure(allprojects) { project ->
group = "org.springframework"
version = qualifyVersionIfNecessary(version)
// ....
task copyDependencies(type: Copy) {
from configurations.compile
into 'dependencies'
}
}
If you have a simple project (not a multi module one), there won't exist
such a configure method. Then you can define it directly (e.g. after the
dependencies). I attached my spring gradle build file to this mail. In my
company project, which is a multi module project too, I added it to a
configure method which is used for all java projects (we have some non java
projects too). If I added to a configure method which is called for all
projects due to the non java projects I would get an error. So it seems as
if you always have to change you build files and as if there doesn't exist
a general solution (like there exists one for maven). But I'm not a gradle
expert, so there might exist a better solution.
Best regards
Meinert
Hello everyone,
We are happy to announce version 6.0 of the Moose Suite, the platform for software and data analysis built in Pharo:
http://moosetechnology.org/#install
Description
---
The key highlights are:
- It is based on Pharo 5.0 including the latest version of the Glamorous Toolkit.
- It includes the SmaCC parsing framework together with parsers and abstract syntax trees for Java, JavaScript and Swift.
- Roassal2 comes with several enhancements.
- Famix features a new and generic query API engine.
- Moose Finder and GTInspector come with more custom presentations and visualizations.
- SmaCC comes with a dedicated debugger.
- The debuggers for Glamour, PetitParser and Announcements received a new update.
- DeepTraverser is an order of magnitude faster.
Extra highlights:
- Roassal2 is documented in a brand new book: http://agilevisualization.com
- jdt2famix is a new open-source importer for Java: https://github.com/girba/jdt2famix
Installation
---
The Moose Suite 6.0 comes for each platform as a separate bundle:
- For Mac: http://moosetechnology.org/res/download/moose_suite_6_0-mac.zip
- For Windows: http://moosetechnology.org/res/download/moose_suite_6_0-win.zip
- For Linux: http://moosetechnology.org/res/download/moose_suite_6_0-linux.zip
The Moose Suite 6.0 can also be loaded in a Pharo 5.0 image either from the Configuration Browser, or by executing the following script:
Metacello new
smalltalkhubUser: 'Moose' project: 'Moose';
configuration: 'Moose';
version: #stable;
load.
Enjoy,
The Moose team
Hi Tudor,
there are two types of problems in the jdt2famix-import.problems file.
My project uses Lombok to generate getter, setters and builders and so on
(which is quite commmon for java projects). Because of that, some methods
can't be found. Consider the following classes:
----------------------------------------
import lombok.Builder;
@Builder
public class Address {
private String postalCode;
}
----------------------------------------
import lombok.AccessLevel;
import lombok.NoArgsConstructor;
@NoArgsConstructor(access = AccessLevel.PRIVATE)
public class AddressBuilder extends Address.AddressBuilder {
public static AddressBuilder anAddressBuilder() {
return new AddressBuilder();
}
public Address.AddressBuilder withDefaultValues() {
return this.postalCode("23456");
}
}
-----------------------------------------
I get the following error:
unresolved method declaration - withDefaultValues -
c:\data\moose\...\AddressBuilder.java - line 12
This error message and its line number (line number 12 is the method header
"Address.AddressBuilder withDefaultValues ...") are misleading because at
first I thought that the hole method is missing. But it only means that in
this method an unresolved method is used. Furthermore I wonder if it were
possible to support lombok?
The cause of the next problem is that we have multiple smaller applications
(e.g. backoffice and frontend) which are separate applications but share a
common db. Some of these services have classes with the same class and
packagename (e.g. an annotation WebController). This lead to the following
error message:
unresolved annotation type declaration - WebController -
c:\data\moose\....\WebController.java
- line 12
I had to start the debugger to find the issue. I found it because
AnnotationTypeDeclaration.parent.problems = "Pb(323) The type WebController
is already defined"
If the package names are different the problems disappears. Then I only get
the the lombok errors. As a solution I will create unique base package
names for my projecfs (which makes sense anyway).
Note that you could the following example to you README of jdt2famix to
show how to download the dependencies for gradle projects:
task copyDependencies(type: Copy) {
from configurations.compile
from configurations.testCompile
into 'dependencies'
}
Best regards
Meinert
-----Original Message-----
From: Tudor Girba [mailto:tudor@tudorgirba.com]
Sent: Thursday, August 11, 2016 10:41 PM
To: Moose-related development
Subject: [Moose-dev] Re: Problems with mondorian
Hi,
Great. I am happy it works for you.
Still, could you tell me if you get any problems reported in
jdt2famix-import.problems when you parse your system?
Cheers,
Doru
> On Aug 11, 2016, at 6:12 PM, Meinert Schwartau <m.schwartau(a)gmail.com>
wrote:
>
> Thanks. After downloading the current Moose version and using the
> other method you suggested it works for me :-)
>
> Thank you for providing the Java parser.
>
> Best regards
> Meinert
>
> > Am 10.08.2016 um 16:36 schrieb Tudor Girba <tudor(a)tudorgirba.com>:
> >
> > Hi,
> >
> > I now fixed the providerTypes error (including a test). Please try with
the latest Moose 6.0 image.
> >
> > Cheers,
> > Doru
> >
> >
> >> On Aug 10, 2016, at 3:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
> >>
> >> Hi,
> >>
> >> Welcome back :)
> >>
> >>> On Aug 10, 2016, at 9:04 AM, Meinert Schwartau <m.schwartau(a)gmail.com>
wrote:
> >>>
> >>> Hi,
> >>>
> >>> I want to display the dependencies between my classes. I wonder why
the following code does not work, it displays the classes in a circle but
not the edges between them. I’m using Moose 6 und Pharo 5 (downloaded
yesterday) and evaluated the following code in the moose panel in the
evaluator:
> >>>
> >>> |view|
> >>> view := RTMondrian new.
> >>> view nodes: ArrayedCollection withAllSubclasses.
> >>> view edges: (ArrayedCollection withAllSubclasses) from: [ :cls | cls
yourself ] to: [ :cls | cls referencedClasses ].
> >>> view circleLayout.
> >>> view
> >>
> >> In your script, from:to: connects one source node with one target node
returned by evaluating the corresponding blocks. However, your to: blocks
return a collection, and the engine will try to find a node that has that
collection as a model.
> >>
> >> What you want is to iterate over all items in the collection and
connect the source node to each of the target nodes.
> >>
> >> To this end, you should use toAll:
> >>
> >> |view|
> >> view := RTMondrian new.
> >> view nodes: ArrayedCollection withAllSubclasses.
> >> view edges source: (ArrayedCollection withAllSubclasses) connectFrom:
[ :cls | cls yourself ] toAll: [ :cls | cls referencedClasses ].
> >> view circleLayout.
> >> view
> >>
> >>>
> >>> Then I tried to display the dependencies between my own classes
(parsed by jdt2famix) but got an exception. After clicking on All classes
in the moose panel I entered the following code in the evaluator:
> >>> |view allClasses|
> >>> view := RTMondrian new.
> >>> allClasses := self allClasses.
> >>> view nodes: allClasses.
> >>> view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls |
cls providerTypes].
> >>> view circleLayout.
> >>> view
> >>>
> >>> If I execute the code above, I get an “MessageNotUnderstood: reveiver
of “atScope:” is nil” exception. If I remove the “view edges: allClasses
from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes].” statement
I don’t get an exception, the RTMondorian view opens, but no classes are
displayed as dots in the view.
> >>
> >> Indeed, thanks for reporting.
> >>
> >> I also noticed a bug in MooseQuery during the computation of messages
like providerTypes. The problem appears when the opposite part of a
relationship is nil. For example, when you have an invocation and the
target cannot be resolved, the invocation will point to nil, and Moose gets
unhappy. This is a problem in Moose and we need to solve it.
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>> Any suggestions?
> >>>
> >>> Best regards
> >>> Meinert
> >>>
> >>>
> >>> _______________________________________________
> >>> Moose-dev mailing list
> >>> Moose-dev(a)list.inf.unibe.ch
> >>> https://www.list.inf.unibe.ch/listinfo/moose-dev
> >>
> >> --
> >> www.tudorgirba.com
> >> www.feenk.com
> >>
> >> "If you can't say why something is relevant, it probably isn't."
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "From an abstract enough point of view, any two things are similar."
> >
> >
> >
> >
> >
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
--
www.tudorgirba.comwww.feenk.com
"Not knowing how to do something is not an argument for how it cannot be
done."
Hi,
I want to display the dependencies between my classes. I wonder why the following code does not work, it displays the classes in a circle but not the edges between them. I’m using Moose 6 und Pharo 5 (downloaded yesterday) and evaluated the following code in the moose panel in the evaluator:
|view|
view := RTMondrian new.
view nodes: ArrayedCollection withAllSubclasses.
view edges: (ArrayedCollection withAllSubclasses) from: [ :cls | cls yourself ] to: [ :cls | cls referencedClasses ].
view circleLayout.
view
Then I tried to display the dependencies between my own classes (parsed by jdt2famix) but got an exception. After clicking on All classes in the moose panel I entered the following code in the evaluator:
|view allClasses|
view := RTMondrian new.
allClasses := self allClasses.
view nodes: allClasses.
view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes].
view circleLayout.
view
If I execute the code above, I get an “MessageNotUnderstood: reveiver of “atScope:” is nil” exception. If I remove the “view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes].” statement I don’t get an exception, the RTMondorian view opens, but no classes are displayed as dots in the view.
Any suggestions?
Best regards
Meinert
Thanks. After downloading the current Moose version and using the other
method you suggested it works for me :-)
Thank you for providing the Java parser.
Best regards
Meinert
> Am 10.08.2016 um 16:36 schrieb Tudor Girba <tudor(a)tudorgirba.com>:
>
> Hi,
>
> I now fixed the providerTypes error (including a test). Please try with
the latest Moose 6.0 image.
>
> Cheers,
> Doru
>
>
>> On Aug 10, 2016, at 3:49 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
>>
>> Hi,
>>
>> Welcome back :)
>>
>>> On Aug 10, 2016, at 9:04 AM, Meinert Schwartau <m.schwartau(a)gmail.com>
wrote:
>>>
>>> Hi,
>>>
>>> I want to display the dependencies between my classes. I wonder why the
following code does not work, it displays the classes in a circle but not
the edges between them. I’m using Moose 6 und Pharo 5 (downloaded
yesterday) and evaluated the following code in the moose panel in the
evaluator:
>>>
>>> |view|
>>> view := RTMondrian new.
>>> view nodes: ArrayedCollection withAllSubclasses.
>>> view edges: (ArrayedCollection withAllSubclasses) from: [ :cls | cls
yourself ] to: [ :cls | cls referencedClasses ].
>>> view circleLayout.
>>> view
>>
>> In your script, from:to: connects one source node with one target node
returned by evaluating the corresponding blocks. However, your to: blocks
return a collection, and the engine will try to find a node that has that
collection as a model.
>>
>> What you want is to iterate over all items in the collection and connect
the source node to each of the target nodes.
>>
>> To this end, you should use toAll:
>>
>> |view|
>> view := RTMondrian new.
>> view nodes: ArrayedCollection withAllSubclasses.
>> view edges source: (ArrayedCollection withAllSubclasses) connectFrom: [
:cls | cls yourself ] toAll: [ :cls | cls referencedClasses ].
>> view circleLayout.
>> view
>>
>>>
>>> Then I tried to display the dependencies between my own classes (parsed
by jdt2famix) but got an exception. After clicking on All classes in the
moose panel I entered the following code in the evaluator:
>>> |view allClasses|
>>> view := RTMondrian new.
>>> allClasses := self allClasses.
>>> view nodes: allClasses.
>>> view edges: allClasses from: [ :cls | cls yourself ] to: [ :cls | cls
providerTypes].
>>> view circleLayout.
>>> view
>>>
>>> If I execute the code above, I get an “MessageNotUnderstood: reveiver
of “atScope:” is nil” exception. If I remove the “view edges: allClasses
from: [ :cls | cls yourself ] to: [ :cls | cls providerTypes].” statement
I don’t get an exception, the RTMondorian view opens, but no classes are
displayed as dots in the view.
>>
>> Indeed, thanks for reporting.
>>
>> I also noticed a bug in MooseQuery during the computation of messages
like providerTypes. The problem appears when the opposite part of a
relationship is nil. For example, when you have an invocation and the
target cannot be resolved, the invocation will point to nil, and Moose gets
unhappy. This is a problem in Moose and we need to solve it.
>>
>> Cheers,
>> Doru
>>
>>
>>> Any suggestions?
>>>
>>> Best regards
>>> Meinert
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)list.inf.unibe.ch
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "If you can't say why something is relevant,
>> it probably isn't."
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "From an abstract enough point of view, any two things are similar."
>
>
>
>
>
Hi!
Currently I have three questions:
I want to declare my own methods like isJunitTest, isBookingClass, isMasterdataClass, isGeneratedClass and so on to filter and visualize my classes. As far as I read it these new methods should be added to existing classes. So in my case because they belong to a class to FamixClass. But these extensions should be stored in a separate package. How do you do it? Is there an example in the web how to do this in pharo?
How do you save your visualizations and queries? Using the moose panel is nice for prototyping. But in the end I would like to create a menu entry, or a new entry in the moose panel on which somebody can click and sees the result of the query I created.
Any suggestions for storing my code in a git repository. It seems not to be so easy like it should be (see http://stackoverflow.com/questions/25722280/pharo-project-on-git)
Best regards
Meinert
Hi,
I extended the excellent work of Cyril, and now all Famix related code (including tests) is in ConfigurationOfFamix. We now have 10 failures, but these were failing before as well.
Now, the ConfigurationOfMoose contains only 10 packages that are related to the UI and visualization (and one for Moose-Help). I would consider creating a separate configuration for those packages, and leave in the ConfigurationOfMoose only the Moose-Help.
Please take a look, and let me know if you see something broken (e.g., missing code).
For reference, here is how the configuration looks like now:
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"It's not what we do that matters most, it's how we do it."
Hi,
Since yesterday, all Moose-related jobs are failing. These are built on top of Pharo 5.0 stable, downloaded like this:
wget --quiet -O - http://get.pharo.org/50+vm | bash
We did not change anything in the projects that fail, and locally on Mac, I can load any of the code without problems. The jobs are running Linux.
So, I am wondering if anything else has changed in Pharo 5.0.
In particular, the error is quite strange. It looks like this:
[31mError: MessageNotUnderstood: receiver of "finish" is nil
[0mUndefinedObject(Object)>>error:
[ :err :rcvr |
| errCtx errMorph |
errCtx := thisContext.
[ errCtx := errCtx sender.
"Search the sender chain to find the morph causing the problem"
[ errCtx notNil and: [ errCtx receiver isMorph not ] ]
whileTrue: [ errCtx := errCtx sender ].
"If we're at the root of the context chain then we have a fatal drawing problem"
errCtx ifNil: [ ^ self handleFatalDrawingError: err ].
errMorph := errCtx receiver.
...
See more at: https://ci.inria.fr/moose/job/fame/1266/console
Any idea of what might be wrong?
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"We cannot reach the flow of things unless we let go."
