8 Apr
2011
8 Apr
'11
12:08 a.m.
Hello
What's the status of Java annotation import with infusion/VerveineJ? I have seen some
mails in the past weeks but didn't take a close look.
Now I would like to use such information to draw dependencies linked to Spring annotations
(for dependency injection).
I tried both infusion and verveinej on the sample petclinic app for Spring but both
returned a minimalistic set of annotation types (Override, SuppressWarnings, XmlElement,
and XmlRootElement)
Any idea what is going wrong?
--
Simon Denier
8 Apr
8 Apr
12:19 a.m.
Hi Simon,
On 8 Apr 2011, at 00:08, Simon Denier wrote:
Hello
What's the status of Java annotation import with infusion/VerveineJ? I have seen some
mails in the past weeks but didn't take a close look.
Now I would like to use such information to draw dependencies linked to Spring
annotations (for dependency injection).
I tried both infusion and verveinej on the sample petclinic app for Spring but both
returned a minimalistic set of annotation types (Override, SuppressWarnings, XmlElement,
and XmlRootElement)
inFusion is not yet released. The one you are using is version 7.*. For this one you need
to add the jars where the annotations are defined (the jars should be in a folder
somewhere below the root folder you give as input).
However, VerveineJ should already provide this info. What version are you using? Nicolas,
did I understand this part wrong?
Cheers,
Doru
Any idea what is going wrong?
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
12:22 a.m.
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
Hi Simon,
On 8 Apr 2011, at 00:08, Simon Denier wrote:
--
www.tudorgirba.com
"Obvious things are difficult to teach."
Hello
What's the status of Java annotation import with infusion/VerveineJ? I have seen some
mails in the past weeks but didn't take a close look.
Now I would like to use such information to draw dependencies linked to Spring
annotations (for dependency injection).
I tried both infusion and verveinej on the sample petclinic app for Spring but both
returned a minimalistic set of annotation types (Override, SuppressWarnings, XmlElement,
and XmlRootElement)
inFusion is not yet released. The one you are using is version 7.*. For this one you need
to add the jars where the annotations are defined (the jars should be in a folder
somewhere below the root folder you give as input).
However, VerveineJ should already provide this info. What version are you using? Nicolas,
did I understand this part wrong?
Cheers,
Doru
Any idea what is going wrong?
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
12:35 a.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument value is always a
string).
What version did you test? I commited a running version yesterday evening (but it is still
not built on Hudson yet, any problem with that?).
The only two red tests, are things not implemented yet (e.g. enumeration access)
If it still does not work, can you send me an URL for your test case (I could search for
it but I am lazy)
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:22:12
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
Hi Simon,
On 8 Apr 2011, at 00:08, Simon Denier wrote:
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hello
What's the status of Java annotation import with
infusion/VerveineJ? I have seen some mails in the past weeks but
didn't take a close look.
Now I would like to use such information to draw dependencies
linked to Spring annotations (for dependency injection).
I tried both infusion and verveinej on the sample petclinic app for
Spring but both returned a minimalistic set of annotation types
(Override, SuppressWarnings, XmlElement, and XmlRootElement)
inFusion is not yet released. The one you are using is version 7.*.
For this one you need to add the jars where the annotations are
defined (the jars should be in a folder somewhere below the root
folder you give as input).
However, VerveineJ should already provide this info. What version
are you using? Nicolas, did I understand this part wrong?
Cheers,
Doru
Any idea what is going wrong?
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
12:47 a.m.
Hi,
I just redid the build on hudson, and there are still 17 tests.
I also tried with the latest version locally to parse:
svn co https://www.iam.unibe.ch/scg/svn_repos/Lectures/P2/Examples/Annotations/
But, I got an error:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.AnnotationTypeAttribute cannot be cast to
fr.inria.verveine.core.gen.famix.Method
at fr.inria.verveine.extractor.java.JavaDictionary.ensureFamixMethod(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown Source)
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.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.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(Unknown Source)
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(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown Source)
Cheers,
Doru
On 8 Apr 2011, at 00:35, Nicolas Anquetil wrote:
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument value is always a
string).
What version did you test? I commited a running version yesterday evening (but it is
still not built on Hudson yet, any problem with that?).
The only two red tests, are things not implemented yet (e.g. enumeration access)
If it still does not work, can you send me an URL for your test case (I could search for
it but I am lazy)
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Every thing should have the right to be different."
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:22:12
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Simon,
On 8 Apr 2011, at 00:08, Simon Denier wrote:
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hello
What's the status of Java annotation import with
infusion/VerveineJ? I have seen some mails in the past weeks but
didn't take a close look.
Now I would like to use such information to draw dependencies
linked to Spring annotations (for dependency injection).
I tried both infusion and verveinej on the sample petclinic app for
Spring but both returned a minimalistic set of annotation types
(Override, SuppressWarnings, XmlElement, and XmlRootElement)
inFusion is not yet released. The one you are using is version 7.*.
For this one you need to add the jars where the annotations are
defined (the jars should be in a folder somewhere below the root
folder you give as input).
However, VerveineJ should already provide this info. What version
are you using? Nicolas, did I understand this part wrong?
Cheers,
Doru
Any idea what is going wrong?
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
12:51 a.m.
Btw, the build on Hudson should be triggered after each commit.
Cheers,
Doru
On 8 Apr 2011, at 00:47, Tudor Girba wrote:
Hi,
I just redid the build on hudson, and there are still 17 tests.
I also tried with the latest version locally to parse:
svn co https://www.iam.unibe.ch/scg/svn_repos/Lectures/P2/Examples/Annotations/
But, I got an error:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.AnnotationTypeAttribute cannot be cast to
fr.inria.verveine.core.gen.famix.Method
at fr.inria.verveine.extractor.java.JavaDictionary.ensureFamixMethod(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown Source)
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.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.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(Unknown Source)
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(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown Source)
Cheers,
Doru
On 8 Apr 2011, at 00:35, Nicolas Anquetil wrote:
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument value is always a
string).
What version did you test? I commited a running version yesterday evening (but it is
still not built on Hudson yet, any problem with that?).
The only two red tests, are things not implemented yet (e.g. enumeration access)
If it still does not work, can you send me an URL for your test case (I could search for
it but I am lazy)
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Every thing should have the right to be different."
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:22:12
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Simon,
On 8 Apr 2011, at 00:08, Simon Denier wrote:
> Hello
>
> What's the status of Java annotation import with
> infusion/VerveineJ? I have seen some mails in the past weeks but
> didn't take a close look.
> Now I would like to use such information to draw dependencies
> linked to Spring annotations (for dependency injection).
>
> I tried both infusion and verveinej on the sample petclinic app for
> Spring but both returned a minimalistic set of annotation types
> (Override, SuppressWarnings, XmlElement, and XmlRootElement)
inFusion is not yet released. The one you are using is version 7.*.
For this one you need to add the jars where the annotations are
defined (the jars should be in a folder somewhere below the root
folder you give as input).
However, VerveineJ should already provide this info. What version
are you using? Nicolas, did I understand this part wrong?
Cheers,
Doru
> Any idea what is going wrong?
>
> --
> Simon Denier
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:39 a.m.
Errors in the Hudson job seem all related to a failure in test setup : getBelongsTo gets
called on a NamedEntity and fails. It should be easy to fix? Unfortunately I don't
have access to the source code for verveine.core and java famix. Please Nico release it!
On 8 avr. 2011, at 00:47, Tudor Girba wrote:
Hi,
I just redid the build on hudson, and there are still 17 tests.
I also tried with the latest version locally to parse:
svn co https://www.iam.unibe.ch/scg/svn_repos/Lectures/P2/Examples/Annotations/
But, I got an error:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.AnnotationTypeAttribute cannot be cast to
fr.inria.verveine.core.gen.famix.Method
at fr.inria.verveine.extractor.java.JavaDictionary.ensureFamixMethod(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown Source)
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.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.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(Unknown Source)
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(Unknown Source)
at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown Source)
Cheers,
Doru
On 8 Apr 2011, at 00:35, Nicolas Anquetil wrote:
--
Simon Denier
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument value is always a
string).
What version did you test? I commited a running version yesterday evening (but it is
still not built on Hudson yet, any problem with that?).
The only two red tests, are things not implemented yet (e.g. enumeration access)
If it still does not work, can you send me an URL for your test case (I could search for
it but I am lazy)
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Every thing should have the right to be different."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:22:12
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Simon,
On 8 Apr 2011, at 00:08, Simon Denier wrote:
> Hello
>
> What's the status of Java annotation import with
> infusion/VerveineJ? I have seen some mails in the past weeks but
> didn't take a close look.
> Now I would like to use such information to draw dependencies
> linked to Spring annotations (for dependency injection).
>
> I tried both infusion and verveinej on the sample petclinic app for
> Spring but both returned a minimalistic set of annotation types
> (Override, SuppressWarnings, XmlElement, and XmlRootElement)
inFusion is not yet released. The one you are using is version 7.*.
For this one you need to add the jars where the annotations are
defined (the jars should be in a folder somewhere below the root
folder you give as input).
However, VerveineJ should already provide this info. What version
are you using? Nicolas, did I understand this part wrong?
Cheers,
Doru
> Any idea what is going wrong?
>
> --
> Simon Denier
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:58 a.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
hummm, something is wrong, on my computer, 'ant junit' runs 34 tests and only two
fail ...
[junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 4.754 sec
[junit] Running tests.fr.inria.verveine.extractor.java.VerveineJTest_AdHoc
[junit] Tests run: 15, Failures: 2, Errors: 0, Time elapsed: 5.173 sec
[junit] Test tests.fr.inria.verveine.extractor.java.VerveineJTest_AdHoc FAILED
I might have found one problem in my ant script. The junit target recompiles everything
but does not build the jar file. I will add that.
Tudor, do you run 'ant jar' in verveine.core first and then 'ant junit' in
verveine.extarctor.java ?
Simon, verveineJ is on gforge.inria.fr
It is publicly available, and you are also one of the happy few that can commit.
svn checkout svn+ssh:/scm.gforge.inria.fr/svn/verveinej
But the problem may be somewhere else.
----- Mail original -----
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:47:24
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Hi,
I just redid the build on hudson, and there are still 17 tests.
I also tried with the latest version locally to parse:
svn co
https://www.iam.unibe.ch/scg/svn_repos/Lectures/P2/Examples/Annotations/
But, I got an error:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.AnnotationTypeAttribute cannot be
cast to fr.inria.verveine.core.gen.famix.Method
at
fr.inria.verveine.extractor.java.JavaDictionary.ensureFamixMethod(Unknown
Source)
at
fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown
Source)
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.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.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(Unknown
Source)
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(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown
Source)
Cheers,
Doru
On 8 Apr 2011, at 00:35, Nicolas Anquetil wrote:
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument
value is always a string).
What version did you test? I commited a running version yesterday
evening (but it is still not built on Hudson yet, any problem with
that?).
The only two red tests, are things not implemented yet (e.g.
enumeration access)
If it still does not work, can you send me an URL for your test case
(I could search for it but I am lazy)
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Every thing should have the right to be different."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:22:12
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Simon,
On 8 Apr 2011, at 00:08, Simon Denier wrote:
> Hello
>
> What's the status of Java annotation import with
> infusion/VerveineJ? I have seen some mails in the past weeks but
> didn't take a close look.
> Now I would like to use such information to draw dependencies
> linked to Spring annotations (for dependency injection).
>
> I tried both infusion and verveinej on the sample petclinic app
> for
> Spring but both returned a minimalistic set of annotation types
> (Override, SuppressWarnings, XmlElement, and XmlRootElement)
inFusion is not yet released. The one you are using is version
7.*.
For this one you need to add the jars where the annotations are
defined (the jars should be in a folder somewhere below the root
folder you give as input).
However, VerveineJ should already provide this info. What version
are you using? Nicolas, did I understand this part wrong?
Cheers,
Doru
> Any idea what is going wrong?
>
> --
> Simon Denier
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:07 a.m.
Hi,
On 8 Apr 2011, at 09:58, Nicolas Anquetil wrote:
hummm, something is wrong, on my computer, 'ant
junit' runs 34 tests and only two fail ...
[junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 4.754 sec
[junit] Running tests.fr.inria.verveine.extractor.java.VerveineJTest_AdHoc
[junit] Tests run: 15, Failures: 2, Errors: 0, Time elapsed: 5.173 sec
[junit] Test tests.fr.inria.verveine.extractor.java.VerveineJTest_AdHoc FAILED
I might have found one problem in my ant script. The junit target recompiles everything
but does not build the jar file. I will add that.
Tudor, do you run 'ant jar' in verveine.core first and then 'ant junit'
in verveine.extarctor.java ?
Yes.
Doru
Simon, verveineJ is on gforge.inria.fr
It is publicly available, and you are also one of the happy few that can commit.
svn checkout svn+ssh:/scm.gforge.inria.fr/svn/verveinej
But the problem may be somewhere else.
----- Mail original -----
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:47:24
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Hi,
I just redid the build on hudson, and there are still 17 tests.
I also tried with the latest version locally to parse:
svn co
https://www.iam.unibe.ch/scg/svn_repos/Lectures/P2/Examples/Annotations/
But, I got an error:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.AnnotationTypeAttribute cannot be
cast to fr.inria.verveine.core.gen.famix.Method
at
fr.inria.verveine.extractor.java.JavaDictionary.ensureFamixMethod(Unknown
Source)
at
fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown
Source)
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.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.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(Unknown
Source)
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(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown
Source)
Cheers,
Doru
On 8 Apr 2011, at 00:35, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument
value is always a string).
What version did you test? I commited a running version yesterday
evening (but it is still not built on Hudson yet, any problem with
that?).
The only two red tests, are things not implemented yet (e.g.
enumeration access)
If it still does not work, can you send me an URL for your test case
(I could search for it but I am lazy)
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Every thing should have the right to be different."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:22:12
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
> Hi Simon,
>
> On 8 Apr 2011, at 00:08, Simon Denier wrote:
>
>> Hello
>>
>> What's the status of Java annotation import with
>> infusion/VerveineJ? I have seen some mails in the past weeks but
>> didn't take a close look.
>> Now I would like to use such information to draw dependencies
>> linked to Spring annotations (for dependency injection).
>>
>> I tried both infusion and verveinej on the sample petclinic app
>> for
>> Spring but both returned a minimalistic set of annotation types
>> (Override, SuppressWarnings, XmlElement, and XmlRootElement)
>
> inFusion is not yet released. The one you are using is version
> 7.*.
> For this one you need to add the jars where the annotations are
> defined (the jars should be in a folder somewhere below the root
> folder you give as input).
>
> However, VerveineJ should already provide this info. What version
> are you using? Nicolas, did I understand this part wrong?
>
> Cheers,
> Doru
>
>
>> Any idea what is going wrong?
>>
>> --
>> Simon Denier
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Value is always contextual."
>
>
>
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:14 a.m.
I added a how to create the MSE file with VerveineJ here:
http://www.moosetechnology.org/docs/importers/importJavaWithVerveineJ
Cheers,
Doru
On 8 Apr 2011, at 10:07, Tudor Girba wrote:
Hi,
On 8 Apr 2011, at 09:58, Nicolas Anquetil wrote:
--
www.tudorgirba.com
"Every thing should have the right to be different."
hummm, something is wrong, on my computer,
'ant junit' runs 34 tests and only two fail ...
[junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 4.754 sec
[junit] Running tests.fr.inria.verveine.extractor.java.VerveineJTest_AdHoc
[junit] Tests run: 15, Failures: 2, Errors: 0, Time elapsed: 5.173 sec
[junit] Test tests.fr.inria.verveine.extractor.java.VerveineJTest_AdHoc FAILED
I might have found one problem in my ant script. The junit target recompiles everything
but does not build the jar file. I will add that.
Tudor, do you run 'ant jar' in verveine.core first and then 'ant junit'
in verveine.extarctor.java ?
Yes.
Doru
Simon, verveineJ is on gforge.inria.fr
It is publicly available, and you are also one of the happy few that can commit.
svn checkout svn+ssh:/scm.gforge.inria.fr/svn/verveinej
But the problem may be somewhere else.
----- Mail original -----
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:47:24
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Hi,
I just redid the build on hudson, and there are still 17 tests.
I also tried with the latest version locally to parse:
svn co
https://www.iam.unibe.ch/scg/svn_repos/Lectures/P2/Examples/Annotations/
But, I got an error:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.AnnotationTypeAttribute cannot be
cast to fr.inria.verveine.core.gen.famix.Method
at
fr.inria.verveine.extractor.java.JavaDictionary.ensureFamixMethod(Unknown
Source)
at
fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown
Source)
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.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.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(Unknown
Source)
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(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown
Source)
Cheers,
Doru
On 8 Apr 2011, at 00:35, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument
value is always a string).
What version did you test? I commited a running version yesterday
evening (but it is still not built on Hudson yet, any problem with
that?).
The only two red tests, are things not implemented yet (e.g.
enumeration access)
If it still does not work, can you send me an URL for your test case
(I could search for it but I am lazy)
nicolas
----- Mail original -----
> De: "Tudor Girba" <tudor.girba(a)gmail.com>
> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
> Envoyé: Vendredi 8 Avril 2011 00:22:12
> Objet: [Moose-dev] Re: Status of Java annotation import with
> infusion/VerveineJ?
> Actually, I think VerveineJ is broken now.
>
> Cheers,
> Doru
>
>
> On 8 Apr 2011, at 00:19, Tudor Girba wrote:
>
>> Hi Simon,
>>
>> On 8 Apr 2011, at 00:08, Simon Denier wrote:
>>
>>> Hello
>>>
>>> What's the status of Java annotation import with
>>> infusion/VerveineJ? I have seen some mails in the past weeks but
>>> didn't take a close look.
>>> Now I would like to use such information to draw dependencies
>>> linked to Spring annotations (for dependency injection).
>>>
>>> I tried both infusion and verveinej on the sample petclinic app
>>> for
>>> Spring but both returned a minimalistic set of annotation types
>>> (Override, SuppressWarnings, XmlElement, and XmlRootElement)
>>
>> inFusion is not yet released. The one you are using is version
>> 7.*.
>> For this one you need to add the jars where the annotations are
>> defined (the jars should be in a folder somewhere below the root
>> folder you give as input).
>>
>> However, VerveineJ should already provide this info. What version
>> are you using? Nicolas, did I understand this part wrong?
>>
>> Cheers,
>> Doru
>>
>>
>>> Any idea what is going wrong?
>>>
>>> --
>>> Simon Denier
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Value is always contextual."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Obvious things are difficult to teach."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing should have the right to be different."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:22 a.m.
On Fri, Apr 8, 2011 at 9:58 AM, Nicolas Anquetil
<nicolas.anquetil(a)inria.fr>wrote;wrote:
Simon, verveineJ is on gforge.inria.fr
It is publicly available, and you are also one of the happy few that can
commit.
svn checkout svn+ssh:/scm.gforge.inria.fr/svn/verveinej
Well, I know that, but the VerveineJ webpage was a bit unclear and just gave
the link to the verveine.extractor.java so I was under the false assumption
that core was still private (also verveine.extractor.java also contains the
jar of core and famix and can be run as a stand alone project).
I updated the page so that it gives the links to the two projects:
http://www.moosetechnology.org/tools/verveinej
Will try to check that tonight, I don't even have my mac here.
But the problem may be somewhere else.
----- Mail original -----
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:47:24
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
Hi,
I just redid the build on hudson, and there are still 17 tests.
I also tried with the latest version locally to parse:
svn co
https://www.iam.unibe.ch/scg/svn_repos/Lectures/P2/Examples/Annotations/
But, I got an error:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.AnnotationTypeAttribute cannot be
cast to fr.inria.verveine.core.gen.famix.Method
at
fr.inria.verveine.extractor.java.JavaDictionary.ensureFamixMethod(Unknown
Source)
at
fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown
Source)
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.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.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(Unknown
Source)
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(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown
Source)
Cheers,
Doru
On 8 Apr 2011, at 00:35, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument
value is always a string).
What version did you test? I commited a running version yesterday
evening (but it is still not built on Hudson yet, any problem with
that?).
The only two red tests, are things not implemented yet (e.g.
enumeration access)
If it still does not work, can you send me an URL for your test case
(I could search for it but I am lazy)
nicolas
----- Mail original -----
--
www.tudorgirba.com
"Every thing should have the right to be different."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:22:12
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
> Hi Simon,
>
> On 8 Apr 2011, at 00:08, Simon Denier wrote:
>
>> Hello
>>
>> What's the status of Java annotation import with
>> infusion/VerveineJ? I have seen some mails in the past weeks but
>> didn't take a close look.
>> Now I would like to use such information to draw dependencies
>> linked to Spring annotations (for dependency injection).
>>
>> I tried both infusion and verveinej on the sample petclinic app
>> for
>> Spring but both returned a minimalistic set of annotation types
>> (Override, SuppressWarnings, XmlElement, and XmlRootElement)
>
> inFusion is not yet released. The one you are using is version
> 7.*.
> For this one you need to add the jars where the annotations are
> defined (the jars should be in a folder somewhere below the root
> folder you give as input).
>
> However, VerveineJ should already provide this info. What version
> are you using? Nicolas, did I understand this part wrong?
>
> Cheers,
> Doru
>
>
>> Any idea what is going wrong?
>>
>> --
>> Simon Denier
>>
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Value is always contextual."
>
>
>
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
3:12 p.m.
On Fri, Apr 8, 2011 at 10:22 AM, Simon Denier <simon.denier(a)gmail.com>wrote;wrote:
On Fri, Apr 8, 2011 at 9:58 AM, Nicolas Anquetil <
nicolas.anquetil(a)inria.fr> wrote:
Poking around, I see that at least some annotation types are imported as
stub FamixNamespaces. Any idea where to look in the code which could lead to
such a behaviour?
Simon, verveineJ is on gforge.inria.fr
It is publicly available, and you are also one of the happy few that can
commit.
svn checkout svn+ssh:/scm.gforge.inria.fr/svn/verveinej
Well, I know that, but the VerveineJ webpage was a bit unclear and just
gave the link to the verveine.extractor.java so I was under the false
assumption that core was still private (also verveine.extractor.java also
contains the jar of core and famix and can be run as a stand alone project).
I updated the page so that it gives the links to the two projects:
http://www.moosetechnology.org/tools/verveinej
Will try to check that tonight, I don't even have my mac here.
But the problem may be somewhere else.
----- Mail original -----
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:47:24
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
Hi,
I just redid the build on hudson, and there are still 17 tests.
I also tried with the latest version locally to parse:
svn co
https://www.iam.unibe.ch/scg/svn_repos/Lectures/P2/Examples/Annotations/
But, I got an error:
Exception in thread "main" java.lang.ClassCastException:
fr.inria.verveine.core.gen.famix.AnnotationTypeAttribute cannot be
cast to fr.inria.verveine.core.gen.famix.Method
at
fr.inria.verveine.extractor.java.JavaDictionary.ensureFamixMethod(Unknown
Source)
at
fr.inria.verveine.extractor.java.VerveineVisitor.methodInvocation(Unknown
> Source)
> at fr.inria.verveine.extractor.java.VerveineVisitor.visit(Unknown
Source)
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.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.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(Unknown
Source)
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(Unknown
Source)
at fr.inria.verveine.extractor.java.VerveineJParser.main(Unknown
Source)
Cheers,
Doru
On 8 Apr 2011, at 00:35, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument
value is always a string).
What version did you test? I commited a running version yesterday
evening (but it is still not built on Hudson yet, any problem with
that?).
The only two red tests, are things not implemented yet (e.g.
enumeration access)
If it still does not work, can you send me an URL for your test case
(I could search for it but I am lazy)
nicolas
----- Mail original -----
> De: "Tudor Girba" <tudor.girba(a)gmail.com>
> À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
> Envoyé: Vendredi 8 Avril 2011 00:22:12
> Objet: [Moose-dev] Re: Status of Java annotation import with
> infusion/VerveineJ?
> Actually, I think VerveineJ is broken now.
>
> Cheers,
> Doru
>
>
> On 8 Apr 2011, at 00:19, Tudor Girba wrote:
>
>> Hi Simon,
>>
>> On 8 Apr 2011, at 00:08, Simon Denier wrote:
>>
>>> Hello
>>>
>>> What's the status of Java annotation import with
>>> infusion/VerveineJ? I have seen some mails in the past weeks but
>>> didn't take a close look.
>>> Now I would like to use such information to draw dependencies
>>> linked to Spring annotations (for dependency injection).
>>>
>>> I tried both infusion and verveinej on the sample petclinic app
>>> for
>>> Spring but both returned a minimalistic set of annotation types
>>> (Override, SuppressWarnings, XmlElement, and XmlRootElement)
>>
>> inFusion is not yet released. The one you are using is version
>> 7.*.
>> For this one you need to add the jars where the annotations are
>> defined (the jars should be in a folder somewhere below the root
>> folder you give as input).
>>
>> However, VerveineJ should already provide this info. What version
>> are you using? Nicolas, did I understand this part wrong?
>>
>> Cheers,
>> Doru
>>
>>
>>> Any idea what is going wrong?
>>>
>>> --
>>> Simon Denier
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Value is always contextual."
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Obvious things are difficult to teach."
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing should have the right to be different."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9 Apr
9 Apr
1:07 a.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
On 8 avr. 2011, at 00:35, Nicolas Anquetil wrote:
Howdy Simon,
Hummm, VerveineJ should not be broken.
At least, it is not on my computer :-)
And it should output annotation declaration and uses.
At least the subset defined in the metamodel (an annotation argument value is always a
string).
What version did you test? I commited a running version yesterday evening (but it is
still not built on Hudson yet, any problem with that?).
Tests are ok except for 2. It's now a fresh update from svn.
The only two red tests, are things not implemented yet (e.g. enumeration access)
If it still does not work, can you send me an URL for your test case (I could search for
it but I am lazy)
I use the petclinic sample project
https://src.springframework.org/svn/spring-samples/petclinic/trunk
To be compiled, you should run maven to download jar dependencies. However, it does not
seem like it changed a thing in my case.
Maybe the jars should be added to the classpath of the parser at runtime?
Sorry, I will be away from computer this week-end so no time to look at it until sunday
evening.
nicolas
----- Mail original -----
--
Simon Denier
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Vendredi 8 Avril 2011 00:22:12
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Actually, I think VerveineJ is broken now.
Cheers,
Doru
On 8 Apr 2011, at 00:19, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Simon,
On 8 Apr 2011, at 00:08, Simon Denier wrote:
--
www.tudorgirba.com
"Obvious things are difficult to teach."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hello
What's the status of Java annotation import with
infusion/VerveineJ? I have seen some mails in the past weeks but
didn't take a close look.
Now I would like to use such information to draw dependencies
linked to Spring annotations (for dependency injection).
I tried both infusion and verveinej on the sample petclinic app for
Spring but both returned a minimalistic set of annotation types
(Override, SuppressWarnings, XmlElement, and XmlRootElement)
inFusion is not yet released. The one you are using is version 7.*.
For this one you need to add the jars where the annotations are
defined (the jars should be in a folder somewhere below the root
folder you give as input).
However, VerveineJ should already provide this info. What version
are you using? Nicolas, did I understand this part wrong?
Cheers,
Doru
Any idea what is going wrong?
--
Simon Denier
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Value is always contextual."
11 Apr
11 Apr
10:19 a.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
first news on the bug with "SCG annotations examples"
I traced it to parsing :
"GetProperty getter = method.getAnnotation(GetProperty.class);"
where GetProperty is an annotation.
It would be a nice thing if Famix AnnotationType was actually a Famix Type (it's a
NamedEntity).
Actually, given their definition in Java (has some kind of interface), it could make sense
to define them as sub-class of Famix.Class ... ?
And AnnotationTypeAttribute should maybe relocated to.
I will think a bit over it. For information, JDT considers them to be somehow similar to
methods ...
nicolas
----- Mail original -----
De: "Simon Denier" <simon.denier(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Samedi 9 Avril 2011 01:07:30
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
[...]
Tests are ok except for 2. It's now a fresh update from svn.
That's the right behavior for now. The two faulty tests are things not yet
implemented.
I will start working on them ASAP
on the other hand, hudson verveine project exhibits a strange behaviour:
Twice already, the number of tests dropped to 0 on the summary page
(http://hudson.moosetechnology.org/job/verveinej/), and currently, there are still 17
failures when there should be only two.
The problem with 15 of these tests comes from a missing getBelongsTo() in famix.EnumValue.
A problem that has been corrected.
So either Hudson deos not have the corrected Famix model, or it does not recreate the
famix jar.
"NamedEntity.getBelongsTo() Not implemented in this class, use the proper subclass
(fr.inria.verveine.core.gen.famix.EnumValue)"
Can you look into that Tudor?
[...]
I use the petclinic sample project
https://src.springframework.org/svn/spring-samples/petclinic/trunk will look at it right
after correcting the bug with "SCG annotations examples"
To be compiled, you should run maven to download jar dependencies. However, it does not
seem like it changed a thing in my case.
Maybe the jars should be added to the classpath of the parser at runtime?
did not get it?
why do you need maven?
Jars are added to the classpath in the verveine.sh shell script.
nicolas
8:47 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
Hi Nicolas,
On 11 Apr 2011, at 10:19, Nicolas Anquetil wrote:
first news on the bug with "SCG annotations
examples"
I traced it to parsing :
"GetProperty getter = method.getAnnotation(GetProperty.class);"
where GetProperty is an annotation.
It would be a nice thing if Famix AnnotationType was actually a Famix Type (it's a
NamedEntity).
Actually, given their definition in Java (has some kind of interface), it could make
sense to define them as sub-class of Famix.Class ... ?
This does not sound good because an AnnotationType cannot be associated to a
declaredType.
But, why is it important?
And AnnotationTypeAttribute should maybe relocated
to.
I will think a bit over it. For information, JDT considers them to be somehow similar to
methods ...
Let us know what you find. This exercise is important.
Cheers,
Doru
nicolas
De: "Simon Denier" <simon.denier(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Samedi 9 Avril 2011 01:07:30
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
[...]
Tests are ok except for 2. It's now a fresh update from svn.
That's the right behavior for now. The two faulty tests are things not yet
implemented.
I will start working on them ASAP
on the other hand, hudson verveine project exhibits a strange behaviour:
Twice already, the number of tests dropped to 0 on the summary page
(http://hudson.moosetechnology.org/job/verveinej/), and currently, there are still 17
failures when there should be only two.
The problem with 15 of these tests comes from a missing getBelongsTo() in
famix.EnumValue. A problem that has been corrected.
So either Hudson deos not have the corrected Famix model, or it does not recreate the
famix jar.
"NamedEntity.getBelongsTo() Not implemented in this class, use the proper subclass
(fr.inria.verveine.core.gen.famix.EnumValue)"
Can you look into that Tudor?
[...]
I use the petclinic sample project
https://src.springframework.org/svn/spring-samples/petclinic/trunk
will look at it right after correcting the bug with "SCG annotations examples"
To be compiled, you should run maven to download jar dependencies. However, it does not
seem like it changed a thing in my case.
Maybe the jars should be added to the classpath of the parser at runtime?
did not get it?
why do you need maven?
Jars are added to the classpath in the verveine.sh shell script.
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We are all great at making mistakes."
11:15 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
----- Mail original -----
For some reason, Java does considers annotationType attributes as methods:
"@interface ClassPreamble {
String author();
String date();
int currentRevision() default 1;
String lastModified() default "N/A";
String lastModifiedBy() default "N/A";
String[] reviewers(); // Note use of array
}
The body of the annotation definition above contains annotation type element declarations,
which look a lot like methods. Note that they may define optional default values."
(http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html)
Maybe this is because annotations are similar to interfaces and interfaces don't have
attribute?
To me they look more like attributes, syntactically and semantically ...
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
Hi Nicolas,
On 11 Apr 2011, at 10:19, Nicolas Anquetil wrote:
???
Did not get it?
- AnnotationType is for declaration of annotations
- AnnotationTypeInstance is for using annotation (when an entity is annotated)
first news on the bug with "SCG annotations
examples"
I traced it to parsing :
"GetProperty getter = method.getAnnotation(GetProperty.class);"
where GetProperty is an annotation.
It would be a nice thing if Famix AnnotationType was actually a
Famix Type (it's a NamedEntity).
Actually, given their definition in Java (has some kind of
interface), it could make sense to define them as sub-class of
Famix.Class ... ?
This does not sound good because an AnnotationType cannot be
associated to a declaredType. But, why is it important?
well considering the code above, the localVariable getter has for type an annotation.
To record that, AnnotationType needs to be a type.
Similarly "GetProperty.class" requires that GetProperty be a Famix.Type
And also it is easier when the meta-model sticks to the definition of things.
AnnotationType is so much a Type that the name says it.
And
AnnotationTypeAttribute should maybe relocated to.
I will think a bit over it. For information, JDT considers them to
be somehow similar to methods ...
Let us know what you find. This exercise is important. Cheers,
Doru
nicolas
De: "Simon Denier" <simon.denier(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Samedi 9 Avril 2011 01:07:30
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
[...]
Tests are ok except for 2. It's now a fresh update from svn.
That's the right behavior for now. The two faulty tests are things
not yet implemented.
I will start working on them ASAP
on the other hand, hudson verveine project exhibits a strange
behaviour:
Twice already, the number of tests dropped to 0 on the summary page
(http://hudson.moosetechnology.org/job/verveinej/), and currently,
there are still 17 failures when there should be only two.
The problem with 15 of these tests comes from a missing
getBelongsTo() in famix.EnumValue. A problem that has been
corrected.
So either Hudson deos not have the corrected Famix model, or it does
not recreate the famix jar.
"NamedEntity.getBelongsTo() Not implemented in this class, use the
proper subclass (fr.inria.verveine.core.gen.famix.EnumValue)"
Can you look into that Tudor?
[...]
I use the petclinic sample project
https://src.springframework.org/svn/spring-samples/petclinic/trunk
will look at it right after correcting the bug with "SCG annotations
examples"
To be compiled, you should run maven to download jar dependencies.
However, it does not seem like it changed a thing in my case.
Maybe the jars should be added to the classpath of the parser at
runtime?
did not get it?
why do you need maven?
Jars are added to the classpath in the verveine.sh shell script.
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We are all great at making mistakes."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:25 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
Hi Nicolas,
On 11 Apr 2011, at 23:15, Nicolas Anquetil wrote:
Ok. So, this means that we should have AnnotationType as a subclass of FAMIXType.
For some reason, Java does considers annotationType attributes as methods:
"@interface ClassPreamble {
String author();
String date();
int currentRevision() default 1;
String lastModified() default "N/A";
String lastModifiedBy() default "N/A";
String[] reviewers(); // Note use of array
}
The body of the annotation definition above contains annotation type element
declarations, which look a lot like methods. Note that they may define optional default
values." (http://download.oracle.com/javase/tutorial/java/javaOO/annotations.html)
Maybe this is because annotations are similar to interfaces and interfaces don't have
attribute?
To me they look more like attributes, syntactically and semantically ...
This is odd, indeed. But, I am not sure I understand the implication. Would it not be
enough if we make AnnotationTypeAttribute a subclass of FAMIX.StructuralEntity?
Cheers,
Doru
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
----- Mail original -----
I meant to say that you cannot have a declaredType of a method to point to an
AnnotationType. But, I was clearly wrong :).
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
Hi Nicolas,
On 11 Apr 2011, at 10:19, Nicolas Anquetil wrote:
???
Did not get it?
- AnnotationType is for declaration of annotations
- AnnotationTypeInstance is for using annotation (when an entity is annotated) first news on the bug with "SCG annotations
examples"
I traced it to parsing :
"GetProperty getter = method.getAnnotation(GetProperty.class);"
where GetProperty is an annotation.
It would be a nice thing if Famix AnnotationType was actually a
Famix Type (it's a NamedEntity).
Actually, given their definition in Java (has some kind of
interface), it could make sense to define them as sub-class of
Famix.Class ... ?
This does not sound good because an AnnotationType cannot be
associated to a declaredType. But, why is it
important?
well considering the code above, the localVariable getter has for type an annotation.
To record that, AnnotationType needs to be a type.
Similarly "GetProperty.class" requires that GetProperty be a Famix.Type
And also it is easier when the meta-model sticks to the definition of things.
AnnotationType is so much a Type that the name says it. And
AnnotationTypeAttribute should maybe relocated to.
I will think a bit over it. For information, JDT considers them to
be somehow similar to methods ...
Let us know what you find. This exercise is important. Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev nicolas
De: "Simon Denier" <simon.denier(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Samedi 9 Avril 2011 01:07:30
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
[...]
Tests are ok except for 2. It's now a fresh update from svn.
That's the right behavior for now. The two faulty tests are things
not yet implemented.
I will start working on them ASAP
on the other hand, hudson verveine project exhibits a strange
behaviour:
Twice already, the number of tests dropped to 0 on the summary page
(http://hudson.moosetechnology.org/job/verveinej/), and currently,
there are still 17 failures when there should be only two.
The problem with 15 of these tests comes from a missing
getBelongsTo() in famix.EnumValue. A problem that has been
corrected.
So either Hudson deos not have the corrected Famix model, or it does
not recreate the famix jar.
"NamedEntity.getBelongsTo() Not implemented in this class, use the
proper subclass (fr.inria.verveine.core.gen.famix.EnumValue)"
Can you look into that Tudor?
[...]
I use the petclinic sample project
https://src.springframework.org/svn/spring-samples/petclinic/trunk
will look at it right after correcting the bug with "SCG annotations
examples"
To be compiled, you should run maven to download jar dependencies.
However, it does not seem like it changed a thing in my case.
Maybe the jars should be added to the classpath of the parser at
runtime?
did not get it?
why do you need maven?
Jars are added to the classpath in the verveine.sh shell script.
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"We are all great at making mistakes."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
12 Apr
12 Apr
10:03 a.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
Ok. So, this means that we should have AnnotationType
as a subclass of
FAMIXType.
yep
> For some reason, Java does considers
annotationType attributes as
> methods:
> Maybe this is because annotations are similar to
interfaces and
> interfaces don't have attribute?
> To me they look more like attributes,
syntactically and semantically
This is odd, indeed. But, I am not sure I understand
the implication.
Would it not be enough if we make AnnotationTypeAttribute a subclass
of FAMIX.StructuralEntity?
Yes it would. For the current use of AnnotationTypeAttribute, it actually does not really
matters, where they are.
However, agreeing that AnnotationType will be a Type, it would make sense to consider that
AnnotationTypeAttribute are attributes (i.e. FamixAttribute) of this new Type.
So this would advocate for AnnotationTypeAttribute being a special case of
FamixAttribute.
But, this is not a very strong argument, in fine, the only difference between a
FamixAttribute and a StrucuralEntity is 'parentType' which is just a renaming of
'belongsTo'. So both have the same information.
nicolas
PS: Any idea why verveineJ tests on Hudson play the yoyo? I don't remember commiting
anything fundamental since build #16. So why is the number of tests dropping to 0 now and
then?
Also, 15 of the 17 faulty tests in build #22 (and before) are due to a lacking
'getBelongsTo()' method in EnumValue:
---
java.lang.UnsupportedOperationException: NamedEntity.getBelongsTo() Not implemented in
this class, use the proper subclass (fr.inria.verveine.core.gen.famix.EnumValue)
---
Something that was correct last week. So either Hudson does not have the corrected
fr.inria.verveine.core.gen.famix code, or it is not generating the famix.jar file or it is
not using it it when it runs verveine.
Could you have a look at that?
tx
12:04 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
Hi Nicolas,
I fixed AnnotationType and AnnotationTypeAttribute in FAMIX, but I do not know how to
debug the hudson issue. What should I look at?
Cheers,
Doru
On 12 Apr 2011, at 10:03, Nicolas Anquetil wrote:
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
Ok. So, this means that we should have
AnnotationType as a subclass of
FAMIXType.
yep
> For some reason, Java does considers
annotationType attributes as
> methods:
> Maybe this is because annotations are similar
to interfaces and
> interfaces don't have attribute?
> To me they look more like attributes,
syntactically and semantically
This is odd, indeed. But, I am not sure I
understand the implication.
Would it not be enough if we make AnnotationTypeAttribute a subclass
of FAMIX.StructuralEntity?
Yes it would. For the current use of AnnotationTypeAttribute, it actually does not really
matters, where they are.
However, agreeing that AnnotationType will be a Type, it would make sense to consider
that AnnotationTypeAttribute are attributes (i.e. FamixAttribute) of this new Type.
So this would advocate for AnnotationTypeAttribute being a special case of
FamixAttribute.
But, this is not a very strong argument, in fine, the only difference between a
FamixAttribute and a StrucuralEntity is 'parentType' which is just a renaming of
'belongsTo'. So both have the same information.
nicolas
PS: Any idea why verveineJ tests on Hudson play the yoyo? I don't remember commiting
anything fundamental since build #16. So why is the number of tests dropping to 0 now and
then?
Also, 15 of the 17 faulty tests in build #22 (and before) are due to a lacking
'getBelongsTo()' method in EnumValue:
---
java.lang.UnsupportedOperationException: NamedEntity.getBelongsTo() Not implemented in
this class, use the proper subclass (fr.inria.verveine.core.gen.famix.EnumValue)
---
Something that was correct last week. So either Hudson does not have the corrected
fr.inria.verveine.core.gen.famix code, or it is not generating the famix.jar file or it is
not using it it when it runs verveine.
Could you have a look at that?
tx
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:28 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
----- Mail original -----
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Avril 2011 12:04:54
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Hi Nicolas,
I fixed AnnotationType and AnnotationTypeAttribute in FAMIX, but I do
not know how to debug the hudson issue. What should I look at?
For the "zero test" problem I have no idea
For EnumValue, you can first check whether there is a getBelongsTo() function in it.
If not, this is a problem of getting the SVN sources (or me pushing them to the
repository, but I can see them).
If you can open a console on the server, you could try to call ant manually in both
projects:
- verveine.core
ant jar
- verveine.extractor.java
ant junit
nicolas
Cheers,
Doru
On 12 Apr 2011, at 10:03, Nicolas Anquetil wrote:
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Ok. So, this means that we should have
AnnotationType as a subclass
of
FAMIXType.
yep
> For some reason, Java does considers
annotationType attributes as
> methods:
> Maybe this is because annotations are similar
to interfaces and
> interfaces don't have attribute?
> To me they look more like attributes,
syntactically and
> semantically
This is odd, indeed. But, I am not sure I
understand the
implication.
Would it not be enough if we make AnnotationTypeAttribute a
subclass
of FAMIX.StructuralEntity?
Yes it would. For the current use of AnnotationTypeAttribute, it
actually does not really matters, where they are.
However, agreeing that AnnotationType will be a Type, it would make
sense to consider that AnnotationTypeAttribute are attributes (i.e.
FamixAttribute) of this new Type.
So this would advocate for AnnotationTypeAttribute being a special
case of FamixAttribute.
But, this is not a very strong argument, in fine, the only
difference between a FamixAttribute and a StrucuralEntity is
'parentType' which is just a renaming of 'belongsTo'. So both have
the same information.
nicolas
PS: Any idea why verveineJ tests on Hudson play the yoyo? I don't
remember commiting anything fundamental since build #16. So why is
the number of tests dropping to 0 now and then?
Also, 15 of the 17 faulty tests in build #22 (and before) are due to
a lacking 'getBelongsTo()' method in EnumValue:
---
java.lang.UnsupportedOperationException: NamedEntity.getBelongsTo()
Not implemented in this class, use the proper subclass
(fr.inria.verveine.core.gen.famix.EnumValue)
---
Something that was correct last week. So either Hudson does not have
the corrected fr.inria.verveine.core.gen.famix code, or it is not
generating the famix.jar file or it is not using it it when it runs
verveine.
Could you have a look at that?
tx
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
1:56 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
I might have found the problem.
I executed the jar from verveine.extractor.java instead of verveine.core.
There are two tests that fail now:
http://hudson.moosetechnology.org/job/verveinej/27/
Is that correct?
Cheers,
Doru
On 12 Apr 2011, at 13:28, Nicolas Anquetil wrote:
----- Mail original -----
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Avril 2011 12:04:54
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
Hi Nicolas,
I fixed AnnotationType and AnnotationTypeAttribute in FAMIX, but I do
not know how to debug the hudson issue. What should I look at?
For the "zero test" problem I have no idea
For EnumValue, you can first check whether there is a getBelongsTo() function in it.
If not, this is a problem of getting the SVN sources (or me pushing them to the
repository, but I can see them).
If you can open a console on the server, you could try to call ant manually in both
projects:
- verveine.core
ant jar
- verveine.extractor.java
ant junit
nicolas
Cheers,
Doru
On 12 Apr 2011, at 10:03, Nicolas Anquetil wrote:
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Ok. So, this means that we should have
AnnotationType as a subclass
of
FAMIXType.
yep
> For some reason, Java does considers
annotationType attributes as
> methods:
> Maybe this is because annotations are similar
to interfaces and
> interfaces don't have attribute?
> To me they look more like attributes,
syntactically and
> semantically
This is odd, indeed. But, I am not sure I
understand the
implication.
Would it not be enough if we make AnnotationTypeAttribute a
subclass
of FAMIX.StructuralEntity?
Yes it would. For the current use of AnnotationTypeAttribute, it
actually does not really matters, where they are.
However, agreeing that AnnotationType will be a Type, it would make
sense to consider that AnnotationTypeAttribute are attributes (i.e.
FamixAttribute) of this new Type.
So this would advocate for AnnotationTypeAttribute being a special
case of FamixAttribute.
But, this is not a very strong argument, in fine, the only
difference between a FamixAttribute and a StrucuralEntity is
'parentType' which is just a renaming of 'belongsTo'. So both have
the same information.
nicolas
PS: Any idea why verveineJ tests on Hudson play the yoyo? I don't
remember commiting anything fundamental since build #16. So why is
the number of tests dropping to 0 now and then?
Also, 15 of the 17 faulty tests in build #22 (and before) are due to
a lacking 'getBelongsTo()' method in EnumValue:
---
java.lang.UnsupportedOperationException: NamedEntity.getBelongsTo()
Not implemented in this class, use the proper subclass
(fr.inria.verveine.core.gen.famix.EnumValue)
---
Something that was correct last week. So either Hudson does not have
the corrected fr.inria.verveine.core.gen.famix code, or it is not
generating the famix.jar file or it is not using it it when it runs
verveine.
Could you have a look at that?
tx
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:09 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
yep, that's it
I will resume work on VerveineJ in a few days hopefully.
1- to finish annotations and correct the problem with SCG Annotation example
2- to implement the things required by the two failing tests
thank you
nicolas
----- Mail original -----
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Avril 2011 13:56:58
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
I might have found the problem.
I executed the jar from verveine.extractor.java instead of
verveine.core.
There are two tests that fail now:
http://hudson.moosetechnology.org/job/verveinej/27/
Is that correct?
Cheers,
Doru
On 12 Apr 2011, at 13:28, Nicolas Anquetil wrote:
----- Mail original -----
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Avril 2011 12:04:54
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
Hi Nicolas,
I fixed AnnotationType and AnnotationTypeAttribute in FAMIX, but I
do
not know how to debug the hudson issue. What should I look at?
For the "zero test" problem I have no idea
For EnumValue, you can first check whether there is a getBelongsTo()
function in it.
If not, this is a problem of getting the SVN sources (or me pushing
them to the repository, but I can see them).
If you can open a console on the server, you could try to call ant
manually in both projects:
- verveine.core
ant jar
- verveine.extractor.java
ant junit
nicolas
Cheers,
Doru
On 12 Apr 2011, at 10:03, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> Ok. So, this means that we should have AnnotationType as a
> subclass
> of
> FAMIXType.
yep
>> For some reason, Java does considers annotationType attributes
>> as
>> methods:
>> Maybe this is because annotations are similar to interfaces and
>> interfaces don't have attribute?
>> To me they look more like attributes, syntactically and
>> semantically
> This is odd, indeed. But, I am not sure I understand the
> implication.
> Would it not be enough if we make AnnotationTypeAttribute a
> subclass
> of FAMIX.StructuralEntity?
Yes it would. For the current use of AnnotationTypeAttribute, it
actually does not really matters, where they are.
However, agreeing that AnnotationType will be a Type, it would
make
sense to consider that AnnotationTypeAttribute are attributes
(i.e.
FamixAttribute) of this new Type.
So this would advocate for AnnotationTypeAttribute being a special
case of FamixAttribute.
But, this is not a very strong argument, in fine, the only
difference between a FamixAttribute and a StrucuralEntity is
'parentType' which is just a renaming of 'belongsTo'. So both have
the same information.
nicolas
PS: Any idea why verveineJ tests on Hudson play the yoyo? I don't
remember commiting anything fundamental since build #16. So why is
the number of tests dropping to 0 now and then?
Also, 15 of the 17 faulty tests in build #22 (and before) are due
to
a lacking 'getBelongsTo()' method in EnumValue:
---
java.lang.UnsupportedOperationException:
NamedEntity.getBelongsTo()
Not implemented in this class, use the proper subclass
(fr.inria.verveine.core.gen.famix.EnumValue)
---
Something that was correct last week. So either Hudson does not
have
the corrected fr.inria.verveine.core.gen.famix code, or it is not
generating the famix.jar file or it is not using it it when it
runs
verveine.
Could you have a look at that?
tx
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:14 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
Great!
Doru
On 12 Apr 2011, at 14:09, Nicolas Anquetil wrote:
yep, that's it
I will resume work on VerveineJ in a few days hopefully.
1- to finish annotations and correct the problem with SCG Annotation example
2- to implement the things required by the two failing tests
thank you
nicolas
----- Mail original -----
--
www.tudorgirba.com
"In a world where everything is moving ever faster,
one might have better chances to win by moving slower."
De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Avril 2011 13:56:58
Objet: [Moose-dev] Re: Status of Java annotation import with infusion/VerveineJ?
I might have found the problem.
I executed the jar from verveine.extractor.java instead of
verveine.core.
There are two tests that fail now:
http://hudson.moosetechnology.org/job/verveinej/27/
Is that correct?
Cheers,
Doru
On 12 Apr 2011, at 13:28, Nicolas Anquetil wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
----- Mail original -----
--
www.tudorgirba.com
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev De: "Tudor Girba"
<tudor.girba(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Mardi 12 Avril 2011 12:04:54
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
Hi Nicolas,
I fixed AnnotationType and AnnotationTypeAttribute in FAMIX, but I
do
not know how to debug the hudson issue. What should I look at?
For the "zero test" problem I have no idea
For EnumValue, you can first check whether there is a getBelongsTo()
function in it.
If not, this is a problem of getting the SVN sources (or me pushing
them to the repository, but I can see them).
If you can open a console on the server, you could try to call ant
manually in both projects:
- verveine.core
ant jar
- verveine.extractor.java
ant junit
nicolas
Cheers,
Doru
On 12 Apr 2011, at 10:03, Nicolas Anquetil wrote:
>
>> Ok. So, this means that we should have AnnotationType as a
>> subclass
>> of
>> FAMIXType.
>
> yep
>
>
>>> For some reason, Java does considers annotationType attributes
>>> as
>>> methods:
>
>>> Maybe this is because annotations are similar to interfaces and
>>> interfaces don't have attribute?
>
>>> To me they look more like attributes, syntactically and
>>> semantically
>
>> This is odd, indeed. But, I am not sure I understand the
>> implication.
>> Would it not be enough if we make AnnotationTypeAttribute a
>> subclass
>> of FAMIX.StructuralEntity?
>
> Yes it would. For the current use of AnnotationTypeAttribute, it
> actually does not really matters, where they are.
> However, agreeing that AnnotationType will be a Type, it would
> make
> sense to consider that AnnotationTypeAttribute are attributes
> (i.e.
> FamixAttribute) of this new Type.
> So this would advocate for AnnotationTypeAttribute being a special
> case of FamixAttribute.
> But, this is not a very strong argument, in fine, the only
> difference between a FamixAttribute and a StrucuralEntity is
> 'parentType' which is just a renaming of 'belongsTo'. So both have
> the same information.
>
> nicolas
>
> PS: Any idea why verveineJ tests on Hudson play the yoyo? I don't
> remember commiting anything fundamental since build #16. So why is
> the number of tests dropping to 0 now and then?
>
> Also, 15 of the 17 faulty tests in build #22 (and before) are due
> to
> a lacking 'getBelongsTo()' method in EnumValue:
> ---
> java.lang.UnsupportedOperationException:
> NamedEntity.getBelongsTo()
> Not implemented in this class, use the proper subclass
> (fr.inria.verveine.core.gen.famix.EnumValue)
> ---
> Something that was correct last week. So either Hudson does not
> have
> the corrected fr.inria.verveine.core.gen.famix code, or it is not
> generating the famix.jar file or it is not using it it when it
> runs
> verveine.
>
> Could you have a look at that?
>
> tx
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Reasonable is what we are accustomed with."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11 Apr
11 Apr
10:49 p.m.
New subject: Status of Java annotation import with infusion/VerveineJ?
On 11 avr. 2011, at 10:19, Nicolas Anquetil wrote:
first news on the bug with "SCG annotations
examples"
I traced it to parsing :
"GetProperty getter = method.getAnnotation(GetProperty.class);"
where GetProperty is an annotation.
It would be a nice thing if Famix AnnotationType was actually a Famix Type (it's a
NamedEntity).
Actually, given their definition in Java (has some kind of interface), it could make
sense to define them as sub-class of Famix.Class ... ?
And AnnotationTypeAttribute should maybe relocated to.
I will think a bit over it. For information, JDT considers them to be somehow similar to
methods ...
Not sure I understand everything. Can you give me the line number(s) which are likely
involved in this problem? I just gave a look at the code and don't really know where
to start.
nicolas
De: "Simon Denier" <simon.denier(a)gmail.com>
À: "Moose-related development" <moose-dev(a)iam.unibe.ch>
Envoyé: Samedi 9 Avril 2011 01:07:30
Objet: [Moose-dev] Re: Status of Java annotation import with
infusion/VerveineJ?
[...]
Tests are ok except for 2. It's now a fresh update from svn.
That's the right behavior for now. The two faulty tests are things not yet
implemented.
I will start working on them ASAP
on the other hand, hudson verveine project exhibits a strange behaviour:
Twice already, the number of tests dropped to 0 on the summary page
(http://hudson.moosetechnology.org/job/verveinej/), and currently, there are still 17
failures when there should be only two.
The problem with 15 of these tests comes from a missing getBelongsTo() in
famix.EnumValue. A problem that has been corrected.
So either Hudson deos not have the corrected Famix model, or it does not recreate the
famix jar.
"NamedEntity.getBelongsTo() Not implemented in this class, use the proper subclass
(fr.inria.verveine.core.gen.famix.EnumValue)"
Can you look into that Tudor?
[...]
I use the petclinic sample project
https://src.springframework.org/svn/spring-samples/petclinic/trunk
will look at it right after correcting the bug with "SCG annotations examples"
To be compiled, you should run maven to download jar dependencies. However, it does not
seem like it changed a thing in my case.
Maybe the jars should be added to the classpath of the parser at runtime?
did not get it?
why do you need maven?
Jars are added to the classpath in the verveine.sh shell script.
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Simon Denier
4777
days inactive
4782
days old
23 comments
3 participants
participants (3)
-
Nicolas Anquetil -
Simon Denier -
Tudor Girba