----- Mail original -----
De: "Tudor Girba" tudor.girba@gmail.com
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.
??? Did not get it? - AnnotationType is for declaration of annotations - AnnotationTypeInstance is for using annotation (when an entity is annotated)
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.
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 ...
Cheers, Doru
nicolas
De: "Simon Denier" simon.denier@gmail.com À: "Moose-related development" moose-dev@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev