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:
Is that correct?
Cheers,
Doru
On 12 Apr 2011, at 13:28, Nicolas Anquetil wrote:
----- 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:
>
>> 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
"Yesterday is a fact.
Tomorrow is a possibility.
Today is a challenge."
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch