Sorry for that partial message. Accidentaly hit send. Our project is structured like this: mainProject subproject1 src main java <sources here> subproject2 src main java <sources here> etc VerveineJ only seems to parse one subproject and then stops. Is there a way to configure that it parses all subprojects? Cheers Matt On Tue, Apr 26, 2011 at 6:52 PM, Matthias Junker &lt;junker.matt(a)gmail.com&gt; wrote: morning). org.eclipse.jdt.core.dom.MethodBinding.isAnnotationMember(MethodBinding.java:55) fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(VerveineVisitor.java:554) fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:497) org.eclipse.jdt.core.dom.MethodInvocation.accept0(MethodInvocation.java:237) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) org.eclipse.jdt.core.dom.MethodInvocation.accept0(MethodInvocation.java:245) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) org.eclipse.jdt.core.dom.VariableDeclarationFragment.accept0(VariableDeclarationFragment.java:225) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) org.eclipse.jdt.core.dom.VariableDeclarationStatement.accept0(VariableDeclarationStatement.java:273) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) >>> at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) >>> at >>> org.eclipse.jdt.core.dom.TryStatement.accept0(TryStatement.java:195) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) >>> at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) >>> Disconnected from the target VM, address: '127.0.0.1:51367', >>> transport: 'socket' org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:504) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:484) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219) >>> at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) fr.inria.verveine.extractor.java.FamixRequestor.acceptAST(FamixRequestor.java:31) org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1016) org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:628) >>> at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:982) fr.inria.verveine.extractor.java.VerveineJParser.parse(VerveineJParser.java:169) fr.inria.verveine.extractor.java.VerveineJParser.main(VerveineJParser.java:153) {org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding@1808 }"public

Yes, i give mainProject as argument. It seems to finish normally. I can load the output.mse in Moose without problem, but i only have the classes from one subproject in it. Also in the output of verveinej.sh i can only see the classes from this subproject. It looks as if it wouldn't find the other classes. Unfortunately i can't give out the sources, but i'll try to build a small test project and see if it works there. Cheers, Matt On Wed, Apr 27, 2011 at 12:49 AM, Nicolas Anquetil < nicolas.anquetil(a)inria.fr&gt; wrote:

----- Mail original ----- You mean a .project that would not reference all the source that are in the path? I don't know. But I will do some tests nicolas

No it dsoes not use .project afaik. It looks for all the java files in the directory(ies) it is given nicolas

Hey, Will try this. I tried to parse the subprojects individually in the meantime and found another exception when parsing enums which override a method in an enum constant. Try parsing the following: public enum TestEnum { A{ @Override protected void foo() { super.foo(); }}, B, C; protected void foo(){ } } it throws the following Exception: Exception in thread "main" java.lang.ClassCastException: fr.inria.verveine.core.gen.famix.Enum cannot be cast to fr.inria.verveine.core.gen.famix.Class at fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:510) at org.eclipse.jdt.core.dom.SuperMethodInvocation.accept0(SuperMethodInvocation.java:237) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) at org.eclipse.jdt.core.dom.ExpressionStatement.accept0(ExpressionStatement.java:144) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:504) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) at org.eclipse.jdt.core.dom.AnonymousClassDeclaration.accept0(AnonymousClassDeclaration.java:143) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) at org.eclipse.jdt.core.dom.EnumConstantDeclaration.accept0(EnumConstantDeclaration.java:260) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) at org.eclipse.jdt.core.dom.EnumDeclaration.accept0(EnumDeclaration.java:280) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at fr.inria.verveine.extractor.java.FamixRequestor.acceptAST(FamixRequestor.java:31) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1016) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:628) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:982) at fr.inria.verveine.extractor.java.VerveineJParser.parse(VerveineJParser.java:169) at fr.inria.verveine.extractor.java.VerveineJParser.main(VerveineJParser.java:153) On Thu, Apr 28, 2011 at 8:35 AM, Tudor Girba &lt;tudor.girba(a)gmail.com&gt; wrote:

On Apr 28, 2011, at 10:46 PM, Nicolas Anquetil wrote: lol this is the same in pharo so this is good then.

When I first saw your email, I have doubt about the meaning of your example. For people who are not up-to-date with Java Enums here is a short explanation: TestEnum is an enumeration type. B, C are instances of TestEnum. A is an instance of an anonymous subclass of TestEnum in which foo is overridden. So, I have TestEnum.B.getClass() == TestEnum.class Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

When you write "public enum TestEnum", in fact, it defines the class TestEnum. So, enum TestEnum { A, B, C; } is equivalent of: class TestEnum { static final TestEnum A = new TestEnum(); static final TestEnum B = new TestEnum(); static final TestEnum C = new TestEnum(); } Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Hi Nicolas, Cool :). What was the problem? Cheers, Doru On 1 May 2011, at 21:14, Nicolas Anquetil wrote: -- www.tudorgirba.com "One cannot do more than one can do."

Hey, i tried again and it works now. Thanks a lot for solving this so fast. Cheers Matt On Sun, May 1, 2011 at 9:26 PM, Nicolas Anquetil &lt;nicolas.anquetil(a)inria.fr&gt;wrote;wrote:

Thanks, Matt. Cheers, Doru On 1 May 2011, at 22:51, Matthias Junker wrote: -- www.tudorgirba.com "Relationships are of two kinds: those we choose and those that happen. They both matter."

Hey, just tried that. The files are collected properly. However it seems i get a compilation error in one class which obviously stops the parsing. So this doesn't really have to do anything with the subprojects. I couldn't find out yet why it stops since in intellij the project compiles without problems. Will try to find out more. Thanks for your help. Cheers Matt On Mon, May 2, 2011 at 10:20 AM, Nicolas Anquetil &lt;nicolas.anquetil(a)inria.fr > > Hi, > > I solved it "fast" because I was on holidays :-) > Time's up, back to work :-( > > The first thing you could look at is whether it collects correctly all the > files to parse: > > - in > verveine.extractor.java/src/fr/inria/verveine/extrcator/java/VerveineJParser.java > [Eclipse: project verveine.extractor.java ; package > fr.inria.verveine.extrcator.java ] > > method > private void collectJavaFiles(Collection<String> paths, > Collection<String> files) { > for (String p : paths) { > collectJavaFiles(new File(p), files); > } > } > look at the values in 'files' in the end. > > If this is correct, > Then you can look inFamixRequestor, the class that prints the name of the > parsed files and calls the Verveine visitor > if it is not called for your other subproject, then the problem might be in > JDT itself :-( > > nicolas > > ------------------------------ > > *De: *"Matthias Junker" &lt;junker.matt(a)gmail.com&gt; > *À: *"Moose-related development" &lt;moose-dev(a)iam.unibe.ch&gt; > *Envoyé: *Dimanche 1 Mai 2011 22:51:37 > > *Objet: *[Moose-dev] Re: VerveineJ problem > > However i just realized my second problem still exists. It still only > parses two of the four subprojects now and stops then without exception. i > tried what doru suggested but that didn't help, so the .project files were > not the problem. i will try to debug a bit in order to find out what the > problem is. > > Cheers > Matt > > On Sun, May 1, 2011 at 10:49 PM, Matthias Junker &lt;junker.matt(a)gmail.com&gt;wrote;wrote: > >> Hey, >> i tried again and it works now. Thanks a lot for solving this so fast. >> >> Cheers >> Matt >> >> >> On Sun, May 1, 2011 at 9:26 PM, Nicolas Anquetil < >> nicolas.anquetil(a)inria.fr>> >>> >>> basically the problem was that I did not anticipate a complex construct >>> like that :-) >>> >>> nicolas >>> >>> ----- Mail original ----- >>> > De: "Tudor Girba" &lt;tudor.girba(a)gmail.com&gt; >>> > À: "Moose-related development" &lt;moose-dev(a)iam.unibe.ch&gt; >>> > Envoyé: Dimanche 1 Mai 2011 21:21:34 >>> > Objet: [Moose-dev] Re: VerveineJ problem >>> > Hi Nicolas, >>> > >>> > Cool :). What was the problem? >>> > >>> > Cheers, >>> > Doru >>> > >>> > >>> > On 1 May 2011, at 21:14, Nicolas Anquetil wrote: >>> > >>> > > OK >>> > > >>> > > I think I got it ... >>> > > It is in the tests and it is green >>> > > >>> > > nicolas >>> > > >>> > > De: "Matthias Junker" &lt;junker.matt(a)gmail.com&gt; >>> > > À: "Moose-related development" &lt;moose-dev(a)iam.unibe.ch&gt; >>> > > Envoyé: Jeudi 28 Avril 2011 19:20:58 >>> > > Objet: [Moose-dev] Re: VerveineJ problem >>> > > >>> > > Hey, >>> > > Will try this. I tried to parse the subprojects individually in the >>> > > meantime and found another exception when parsing enums which >>> > > override a method in an enum constant. Try parsing the following: >>> > > >>> > > public enum TestEnum { >>> > > >>> > > A{ >>> > > @Override >>> > > protected void foo() { >>> > > super.foo(); >>> > > }}, >>> > > B, >>> > > C; >>> > > >>> > > protected void foo(){ >>> > > >>> > > } >>> > > } >>> > > >>> > > it throws the following Exception: >>> > > >>> > > Exception in thread "main" java.lang.ClassCastException: >>> > > fr.inria.verveine.core.gen.famix.Enum cannot be cast to >>> > > fr.inria.verveine.core.gen.famix.Class >>> > > at >>> > > >>> fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:510) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.SuperMethodInvocation.accept0(SuperMethodInvocation.java:237) >>> > > at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> > > at >>> org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.ExpressionStatement.accept0(ExpressionStatement.java:144) >>> > > at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) >>> > > at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136) >>> > > at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> > > at >>> org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:504) >>> > > at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.AnonymousClassDeclaration.accept0(AnonymousClassDeclaration.java:143) >>> > > at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> > > at >>> org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.EnumConstantDeclaration.accept0(EnumConstantDeclaration.java:260) >>> > > at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.EnumDeclaration.accept0(EnumDeclaration.java:280) >>> > > at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219) >>> > > at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) >>> > > at >>> > > >>> fr.inria.verveine.extractor.java.FamixRequestor.acceptAST(FamixRequestor.java:31) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:1016) >>> > > at >>> > > >>> org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:628) >>> > > at >>> > > org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:982) >>> > > at >>> > > >>> fr.inria.verveine.extractor.java.VerveineJParser.parse(VerveineJParser.java:169) >>> > > at >>> > > >>> fr.inria.verveine.extractor.java.VerveineJParser.main(VerveineJParser.java:153) >>> > > >>> > > >>> > > >>> > > On Thu, Apr 28, 2011 at 8:35 AM, Tudor Girba &lt;tudor.girba(a)gmail.com&gt; >>> > >>> > > Hi, >>> > > >>> > > Nicolas, thanks for the clarification. >>> > > >>> > > Matthias, could you try copying all the java files to a new folder? >>> > > For convenience, here is a bash script that would copy all files >>> > > preserving the folder structure: >>> > > >>> > > for file in $(find . -name '*.java'); do mkdir -p >>> > > NEWFOLDER/$(dirname $file); cp $file NEWFOLDER/$(dirname $file); >>> > > done >>> > > >>> > > Cheers, >>> > > Doru >>> > > >>> > > >>> > > On 27 Apr 2011, at 23:49, Nicolas Anquetil wrote: >>> > > >>> > > > >>> > > > >>> > > >>> ----- Mail original ----- >>> > > >>>> De: "Tudor Girba" &lt;tudor.girba(a)gmail.com&gt; >>> > > >>>> À: "Moose-related development" &lt;moose-dev(a)iam.unibe.ch&gt; >>> > > >>>> Envoyé: Mercredi 27 Avril 2011 09:46:15 >>> > > >>>> Objet: [Moose-dev] Re: VerveineJ problem >>> > > >>>> Hi, >>> > > >>>> >>> > > >>>> I had a similar problem before with the new inFusion which is >>> > > >>>> also >>> > > >>>> based on JDT. In that case, the problem was due to inFusion >>> > > >>>> relying >>> > > >>>> on >>> > > >>>> an Eclipse project and it got confused because of the .project >>> > > >>>> file >>> > > >>>> from the root folder. >>> > > >>>> >>> > > >>>> Nicolas, would VerveineJ not be affected by a .project? >>> > > >>> >>> > > >>> You mean a .project that would not reference all the source that >>> > > >>> are >>> > > >>> in the path? >>> > > >> >>> > > >> I am just asking whether VerveineJ takes .project into account, >>> > > >> or if >>> > > >> it always traverses deep all the sources starting from the root >>> > > >> folder. If it does consider a possible .project, it could be that >>> > > >> the >>> > > >> problem stems from this. >>> > > >> >>> > > >> Cheers, >>> > > >> Doru >>> > > > >>> > > > >>> > > > No it dsoes not use .project afaik. >>> > > > It looks for all the java files in the directory(ies) it is given >>> > > > >>> > > > nicolas >>> > > > >>> > > > _______________________________________________ >>> > > > Moose-dev mailing list >>> > > > Moose-dev(a)iam.unibe.ch >>> > > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> > > >>> > > -- >>> > > www.tudorgirba.com >>> > > >>> > > "When people care, great things can happen." >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > Moose-dev mailing list >>> > > Moose-dev(a)iam.unibe.ch >>> > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > Moose-dev mailing list >>> > > Moose-dev(a)iam.unibe.ch >>> > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> > > >>> > > _______________________________________________ >>> > > Moose-dev mailing list >>> > > Moose-dev(a)iam.unibe.ch >>> > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> > >>> > -- >>> > www.tudorgirba.com >>> > >>> > "One cannot do more than one can do." >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Moose-dev mailing list >>> > Moose-dev(a)iam.unibe.ch >>> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >

Thanks a lot to both of you for working on this. Cheers, Doru On 2 May 2011, at 10:32, Nicolas Anquetil wrote: -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."