----- Mail original -----
De: "Tudor Girba"
<tudor.girba(a)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(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