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 -----
De: "Tudor Girba" tudor.girba@gmail.com À: "Moose-related development" moose-dev@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 -----
De: "Tudor Girba" tudor.girba@gmail.com À: "Moose-related development" moose-dev@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"In a world where everything is moving ever faster, one might have better chances to win by moving slower."