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@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@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@tudorgirba.com wrote:
Hi,
Welcome back :)
On Aug 10, 2016, at 9:04 AM, Meinert Schwartau m.schwartau@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
Hi Meinert,
Thanks a lot for the input.
On Aug 12, 2016, at 10:10 PM, Meinert Schwartau m.schwartau@gmail.com wrote:
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?
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?
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
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@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@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@tudorgirba.com wrote:
Hi,
Welcome back :)
On Aug 10, 2016, at 9:04 AM, Meinert Schwartau m.schwartau@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"Not knowing how to do something is not an argument for how it cannot be done."
-- www.tudorgirba.com www.feenk.com
"Some battles are better lost than fought."
-
Meinert Schwartau -
Tudor Girba