VerveineJ problem
Locked
12
12
 
|
Hey,
i tried to load a project with verveinej.sh and get a NullPointerException. I only provided the path to the sources as an argument: Exception in thread "main" java.lang.NullPointerException at org.eclipse.jdt.core.dom.MethodBinding.isAnnotationMember(MethodBinding.java:55) at fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(VerveineVisitor.java:554) at fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:497) at 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) at 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) at 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) at 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' 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.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) 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) This is the MethodBinding where i get the NullPointer: • this = {org.eclipse.jdt.core.dom.MethodBinding@1077}"public java.lang.String getName() " • binding = {org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding@1808}"public java.lang.String getName() " • resolver = {org.eclipse.jdt.core.dom.DefaultBindingResolver@1809} • parameterTypes = null • exceptionTypes = null • name = null • declaringClass = null • returnType = null • key = null • typeParameters = null • typeArguments = null • annotations = null • parameterAnnotations = null Did anybody have similar problems? Cheers Matt _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi, Matthias,
apparently you invoked verveineJ the right way. would you mind testing again with the latest VerveineJ (as of this morning). I just finished correcting some bugs so maybe your's was covered. Otherwise, would it be possible to have access to the code parsed? So that I can reproduce the error? thanks for helping nicolas ----- Mail original ----- > De: "Matthias Junker" <[hidden email]> > À: "Moose-related development" <[hidden email]> > Envoyé: Dimanche 24 Avril 2011 14:51:51 > Objet: [Moose-dev] VerveineJ problem > Hey, > i tried to load a project with verveinej.sh and get a > NullPointerException. I only provided the path to the sources as an > argument: > > Exception in thread "main" java.lang.NullPointerException > at > org.eclipse.jdt.core.dom.MethodBinding.isAnnotationMember(MethodBinding.java:55) > at > fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(VerveineVisitor.java:554) > at > fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:497) > at > 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) > at > 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) > at > 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) > at > 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' > 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.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) > 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) > > This is the MethodBinding where i get the NullPointer: > > • this = {org.eclipse.jdt.core.dom.MethodBinding@1077}"public > java.lang.String getName() " > • binding = > {org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding@1808}"public > java.lang.String getName() " > • resolver = {org.eclipse.jdt.core.dom.DefaultBindingResolver@1809} > • parameterTypes = null > • exceptionTypes = null > • name = null > • declaringClass = null > • returnType = null > • key = null > • typeParameters = null > • typeArguments = null > • annotations = null > • parameterAnnotations = null > > Did anybody have similar problems? > > Cheers > Matt > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
I tested again and the loading works now. Thanks. Now i have another problem. I try to parse a maven multi-module project which is organized like this: mainProject On Tue, Apr 26, 2011 at 8:29 AM, Nicolas Anquetil <[hidden email]> wrote: > Hi, Matthias, > > apparently you invoked verveineJ the right way. > > would you mind testing again with the latest VerveineJ (as of this morning). > I just finished correcting some bugs so maybe your's was covered. > > Otherwise, would it be possible to have access to the code parsed? > So that I can reproduce the error? > > > thanks for helping > > nicolas > > ----- Mail original ----- >> De: "Matthias Junker" <[hidden email]> >> À: "Moose-related development" <[hidden email]> >> Envoyé: Dimanche 24 Avril 2011 14:51:51 >> Objet: [Moose-dev] VerveineJ problem >> Hey, >> i tried to load a project with verveinej.sh and get a >> NullPointerException. I only provided the path to the sources as an >> argument: >> >> Exception in thread "main" java.lang.NullPointerException >> at >> org.eclipse.jdt.core.dom.MethodBinding.isAnnotationMember(MethodBinding.java:55) >> at >> fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(VerveineVisitor.java:554) >> at >> fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:497) >> at >> 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) >> at >> 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) >> at >> 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) >> at >> 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' >> 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.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) >> 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) >> >> This is the MethodBinding where i get the NullPointer: >> >> • this = {org.eclipse.jdt.core.dom.MethodBinding@1077}"public >> java.lang.String getName() " >> • binding = >> {org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding@1808}"public >> java.lang.String getName() " >> • resolver = {org.eclipse.jdt.core.dom.DefaultBindingResolver@1809} >> • parameterTypes = null >> • exceptionTypes = null >> • name = null >> • declaringClass = null >> • returnType = null >> • key = null >> • typeParameters = null >> • typeArguments = null >> • annotations = null >> • parameterAnnotations = null >> >> Did anybody have similar problems? >> >> Cheers >> Matt >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote: > Hi, > > I tested again and the loading works now. Thanks. > > Now i have another problem. I try to parse a maven multi-module > project which is organized like this: > > mainProject > > > > > > On Tue, Apr 26, 2011 at 8:29 AM, Nicolas Anquetil >> Hi, Matthias, >> >> apparently you invoked verveineJ the right way. >> >> would you mind testing again with the latest VerveineJ (as of this morning). >> I just finished correcting some bugs so maybe your's was covered. >> >> Otherwise, would it be possible to have access to the code parsed? >> So that I can reproduce the error? >> >> >> thanks for helping >> >> nicolas >> >> ----- Mail original ----- >>> De: "Matthias Junker" <[hidden email]> >>> À: "Moose-related development" <[hidden email]> >>> Envoyé: Dimanche 24 Avril 2011 14:51:51 >>> Objet: [Moose-dev] VerveineJ problem >>> Hey, >>> i tried to load a project with verveinej.sh and get a >>> NullPointerException. I only provided the path to the sources as an >>> argument: >>> >>> Exception in thread "main" java.lang.NullPointerException >>> at >>> org.eclipse.jdt.core.dom.MethodBinding.isAnnotationMember(MethodBinding.java:55) >>> at >>> fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(VerveineVisitor.java:554) >>> at >>> fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:497) >>> at >>> 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) >>> at >>> 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) >>> at >>> 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) >>> at >>> 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' >>> 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.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) >>> 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) >>> >>> This is the MethodBinding where i get the NullPointer: >>> >>> • this = {org.eclipse.jdt.core.dom.MethodBinding@1077}"public >>> java.lang.String getName() " >>> • binding = >>> {org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding@1808}"public >>> java.lang.String getName() " >>> • resolver = {org.eclipse.jdt.core.dom.DefaultBindingResolver@1809} >>> • parameterTypes = null >>> • exceptionTypes = null >>> • name = null >>> • declaringClass = null >>> • returnType = null >>> • key = null >>> • typeParameters = null >>> • typeArguments = null >>> • annotations = null >>> • parameterAnnotations = null >>> >>> Did anybody have similar problems? >>> >>> Cheers >>> Matt >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> > _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
It should be able to parse everything. what do you give it as argument? "mainProject"? But basically, it should be called as a compiler: you tells it where the sources are and what class path it needs to parse these sources. When it stops does it crashes? Is it a memory problem as with Doru? nicolas De: "Matthias Junker" <[hidden email]> _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote:
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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? Cheers, Doru On 27 Apr 2011, at 07:47, Matthias Junker wrote: > 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 <[hidden email]> wrote: > It should be able to parse everything. > > what do you give it as argument? "mainProject"? > > But basically, it should be called as a compiler: you tells it where the sources are and what class path it needs to parse these sources. > When it stops does it crashes? > Is it a memory problem as with Doru? > > nicolas > > De: "Matthias Junker" <[hidden email]> > À: "Moose-related development" <[hidden email]> > Envoyé: Mardi 26 Avril 2011 18:59:29 > Objet: [Moose-dev] Re: VerveineJ problem > > > 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 <[hidden email]> wrote: > > Hi, > > > > I tested again and the loading works now. Thanks. > > > > Now i have another problem. I try to parse a maven multi-module > > project which is organized like this: > > > > mainProject > > > > > > > > > > > > On Tue, Apr 26, 2011 at 8:29 AM, Nicolas Anquetil > > <[hidden email]> wrote: > >> Hi, Matthias, > >> > >> apparently you invoked verveineJ the right way. > >> > >> would you mind testing again with the latest VerveineJ (as of this morning). > >> I just finished correcting some bugs so maybe your's was covered. > >> > >> Otherwise, would it be possible to have access to the code parsed? > >> So that I can reproduce the error? > >> > >> > >> thanks for helping > >> > >> nicolas > >> > >> ----- Mail original ----- > >>> De: "Matthias Junker" <[hidden email]> > >>> À: "Moose-related development" <[hidden email]> > >>> Envoyé: Dimanche 24 Avril 2011 14:51:51 > >>> Objet: [Moose-dev] VerveineJ problem > >>> Hey, > >>> i tried to load a project with verveinej.sh and get a > >>> NullPointerException. I only provided the path to the sources as an > >>> argument: > >>> > >>> Exception in thread "main" java.lang.NullPointerException > >>> at > >>> org.eclipse.jdt.core.dom.MethodBinding.isAnnotationMember(MethodBinding.java:55) > >>> at > >>> fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(VerveineVisitor.java:554) > >>> at > >>> fr.inria.verveine.extractor.java.VerveineVisitor.visit(VerveineVisitor.java:497) > >>> at > >>> 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) > >>> at > >>> 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) > >>> at > >>> 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) > >>> at > >>> 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' > >>> 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.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) > >>> 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) > >>> > >>> This is the MethodBinding where i get the NullPointer: > >>> > >>> • this = {org.eclipse.jdt.core.dom.MethodBinding@1077}"public > >>> java.lang.String getName() " > >>> • binding = > >>> {org.eclipse.jdt.internal.compiler.lookup.ParameterizedMethodBinding@1808}"public > >>> java.lang.String getName() " > >>> • resolver = {org.eclipse.jdt.core.dom.DefaultBindingResolver@1809} > >>> • parameterTypes = null > >>> • exceptionTypes = null > >>> • name = null > >>> • declaringClass = null > >>> • returnType = null > >>> • key = null > >>> • typeParameters = null > >>> • typeArguments = null > >>> • annotations = null > >>> • parameterAnnotations = null > >>> > >>> Did anybody have similar problems? > >>> > >>> Cheers > >>> Matt > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> [hidden email] > >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > >> _______________________________________________ > >> Moose-dev mailing list > >> [hidden email] > >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > >> > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "What we can governs what we wish." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
----- Mail original ----- > De: "Tudor Girba" <[hidden email]> > À: "Moose-related development" <[hidden email]> > 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 don't know. But I will do some tests nicolas _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi,
On 27 Apr 2011, at 18:33, Nicolas Anquetil wrote: > > > ----- Mail original ----- >> De: "Tudor Girba" <[hidden email]> >> À: "Moose-related development" <[hidden email]> >> 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 > I don't know. > But I will do some tests > > nicolas > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
> > ----- Mail original ----- > >> De: "Tudor Girba" <[hidden email]> > >> À: "Moose-related development" <[hidden email]> > >> 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 [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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" <[hidden email]> >>>> À: "Moose-related development" <[hidden email]> >>>> 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 > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "When people care, great things can happen." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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 <[hidden email]> wrote: Hi, _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Although each time I correct a problem, I find out you just generated a new one a few hours ago, I am still optimistic, because the number of open problems is constant, so it's seems that the whole process is under control. :-) Anyway, I did succeed in parsing silverpeas using separate parsing. The exact sequence I used is: verveinej.sh -Xmx2500m -- lib-core verveinej.sh -Xmx2500m -- web-core verveinej.sh -Xmx2500m -- war-core verveinej.sh -Xmx2500m -- ws-test-core test-core it-test-core config-core verveinej.sh -Xmx2500m -- ejb-core but I believe any other should work ... I also introduced initializer blocks as special methods "<Initializer>()" and I also greatly improved the speed, parsing ArgoUML takes 1 minute instead of 1 hour So, off I go, working on the new problem nicolas De: "Matthias Junker" <[hidden email]> _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
On Apr 28, 2011, at 10:46 PM, Nicolas Anquetil wrote: > > Although each time I correct a problem, I find out you just generated a new one a few hours ago, I am still optimistic, because the number of open problems is constant, so it's seems that the whole process is under control. > :-) lol this is the same in pharo so this is good then. > > Anyway, I did succeed in parsing silverpeas using separate parsing. > The exact sequence I used is: > verveinej.sh -Xmx2500m -- lib-core > verveinej.sh -Xmx2500m -- web-core > verveinej.sh -Xmx2500m -- war-core > verveinej.sh -Xmx2500m -- ws-test-core test-core it-test-core config-core > verveinej.sh -Xmx2500m -- ejb-core > > but I believe any other should work ... > > I also introduced initializer blocks as special methods "<Initializer>()" > and I also greatly improved the speed, parsing ArgoUML takes 1 minute instead of 1 hour > > So, off I go, working on the new problem > > nicolas > > De: "Matthias Junker" <[hidden email]> > À: "Moose-related development" <[hidden email]> > 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 <[hidden email]> wrote: > 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" <[hidden email]> > >>>> À: "Moose-related development" <[hidden email]> > >>>> 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 > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Matthias Junker-2
> public enum TestEnum {
> > A{ > @Override > protected void foo() { > super.foo(); > }}, > B, > C; > > protected void foo(){ > > } > } 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 > > 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 <[hidden email]> wrote: > 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" <[hidden email]> > >>>> À: "Moose-related development" <[hidden email]> > >>>> 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 > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
oh boy, java.... is getting as complex a C++
Now I not understand what it measn to be an instance of TestEnum where it is defined? elsewhere? >> public enum TestEnum { >> >> A{ >> @Override >> protected void foo() { >> super.foo(); >> }}, >> B, >> C; >> >> protected void foo(){ >> >> } >> } > > 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 > > > >> >> 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 <[hidden email]> wrote: >> 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" <[hidden email]> >>>>>> À: "Moose-related development" <[hidden email]> >>>>>> 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 >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "When people care, great things can happen." >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Nicolas Anquetil
Hi Nicolas,
You rock! On my old Mac (Intel Core 2 Duo 2.8 GHz) I parsed ArgoUML 0.28.1 in less than 1 min (with -Xmx2000m) :). I found two problems: - the export is not UTF-8. I fixed this with this Mac script: iconv --from-code=MacRoman --to-code=UTF-8 $1 > $2 - the source anchors specify the full path, while they should specify the path relative to the input folder - it seems that the multiple instances of ParameterizableClass are duplicated. For example, I get 930 instances of java::lang::Class. I will open a issues for each of these. In any case, great progress. Cheers, Doru On 28 Apr 2011, at 22:46, Nicolas Anquetil wrote: > > Although each time I correct a problem, I find out you just generated a new one a few hours ago, I am still optimistic, because the number of open problems is constant, so it's seems that the whole process is under control. > :-) > > Anyway, I did succeed in parsing silverpeas using separate parsing. > The exact sequence I used is: > verveinej.sh -Xmx2500m -- lib-core > verveinej.sh -Xmx2500m -- web-core > verveinej.sh -Xmx2500m -- war-core > verveinej.sh -Xmx2500m -- ws-test-core test-core it-test-core config-core > verveinej.sh -Xmx2500m -- ejb-core > > but I believe any other should work ... > > I also introduced initializer blocks as special methods "<Initializer>()" > and I also greatly improved the speed, parsing ArgoUML takes 1 minute instead of 1 hour > > So, off I go, working on the new problem > > nicolas > > De: "Matthias Junker" <[hidden email]> > À: "Moose-related development" <[hidden email]> > 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 <[hidden email]> wrote: > 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" <[hidden email]> > >>>> À: "Moose-related development" <[hidden email]> > >>>> 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 > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Stéphane Ducasse
> Now I not understand what it measn to be an instance of TestEnum where it is defined? elsewhere?
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 >>> public enum TestEnum { >>> >>> A{ >>> @Override >>> protected void foo() { >>> super.foo(); >>> }}, >>> B, >>> C; >>> >>> protected void foo(){ >>> >>> } >>> } >> >> 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 >> >> >> >>> >>> 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 <[hidden email]> wrote: >>> 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" <[hidden email]> >>>>>>> À: "Moose-related development" <[hidden email]> >>>>>>> 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 >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "When people care, great things can happen." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
In reply to this post by Matthias Junker-2
OK I think I got it ... It is in the tests and it is green nicolas De: "Matthias Junker" <[hidden email]> _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
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" <[hidden email]> > À: "Moose-related development" <[hidden email]> > 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 <[hidden email]> wrote: > 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" <[hidden email]> > >>>> À: "Moose-related development" <[hidden email]> > >>>> 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 > > [hidden email] > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "One cannot do more than one can do." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |