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 nicolas.anquetil@inria.fr 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" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch 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

----- Mail original -----

De: "Matthias Junker" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 < junker.matt@gmail.com > 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 < nicolas.anquetil@inria.fr > 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" < junker.matt@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch 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 nicolas.anquetil@inria.fr 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" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 junker.matt@gmail.com 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 nicolas.anquetil@inria.fr 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" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"What we can governs what we wish."

Hi,

On 27 Apr 2011, at 18:33, Nicolas Anquetil wrote:

----- Mail original -----

...

De: "Tudor Girba" tudor.girba@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 Moose-dev@iam.unibe.ch 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."

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" tudor.girba@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"When people care, great things can happen."

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

----- Mail original -----

De: "Matthias Junker" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 < tudor.girba@gmail.com > 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" < tudor.girba@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 tudor.girba@gmail.com 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" tudor.girba@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch 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."

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 tudor.girba@gmail.com 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" tudor.girba@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

OK

I think I got it ... It is in the tests and it is green

nicolas

----- Mail original -----

De: "Matthias Junker" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 < tudor.girba@gmail.com > 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" < tudor.girba@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

basically the problem was that I did not anticipate a complex construct like that :-)

nicolas

----- Mail original -----

De: "Tudor Girba" tudor.girba@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 tudor.girba@gmail.com 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" tudor.girba@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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 junker.matt@gmail.comwrote:

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@inria.fr> wrote:

...

basically the problem was that I did not anticipate a complex construct like that :-)

nicolas

----- Mail original -----

...

De: "Tudor Girba" tudor.girba@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 tudor.girba@gmail.com 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" tudor.girba@gmail.com >> À: "Moose-related development" moose-dev@iam.unibe.ch >> 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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

----- Mail original -----

De: "Matthias Junker" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch 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 < junker.matt@gmail.com > 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@inria.fr > wrote:

basically the problem was that I did not anticipate a complex construct like that :-)

nicolas

----- Mail original -----

De: "Tudor Girba" < tudor.girba@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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" < junker.matt@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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 < tudor.girba@gmail.com > 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" < tudor.girba@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

thanks for looking into it

It seems it is a problem with JDT parser. You can get the sources (or I can send them to you) to pin-point the problem

nicolas

----- Mail original -----

De: "Matthias Junker" junker.matt@gmail.com À: "Moose-related development" moose-dev@iam.unibe.ch Envoyé: Lundi 2 Mai 2011 10:25:14 Objet: [Moose-dev] Re: VerveineJ problem

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 < nicolas.anquetil@inria.fr > wrote:

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" < junker.matt@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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 < junker.matt@gmail.com > 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@inria.fr > wrote:

basically the problem was that I did not anticipate a complex construct like that :-)

nicolas

----- Mail original -----

De: "Tudor Girba" < tudor.girba@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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" < junker.matt@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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 < tudor.girba@gmail.com > 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" < tudor.girba@gmail.com > À: "Moose-related development" < moose-dev@iam.unibe.ch > 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev