Status of Java annotation import with infusion/VerveineJ?

> 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
> > [hidden email]
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> www.tudorgirba.com
>
> "Reasonable is what we are accustomed with."
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

>
>
> ----- Mail original -----
>> De: "Tudor Girba" <[hidden email]>
>> À: "Moose-related development" <[hidden email]>
>> 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
>>> [hidden email]
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>>
>> "Reasonable is what we are accustomed with."
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> De: "Tudor Girba" <[hidden email]>
> À: "Moose-related development" <[hidden email]>
> 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" <[hidden email]>
> >> À: "Moose-related development" <[hidden email]>
> >> 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
> >>> [hidden email]
> >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >>
> >> --
> >> www.tudorgirba.com
> >>
> >> "Reasonable is what we are accustomed with."
> >>
> >>
> >> _______________________________________________
> >> Moose-dev mailing list
> >> [hidden email]
> >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> >
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > 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
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

> 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" <[hidden email]>
>> À: "Moose-related development" <[hidden email]>
>> 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" <[hidden email]>
>>>> À: "Moose-related development" <[hidden email]>
>>>> 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
>>>>> [hidden email]
>>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Reasonable is what we are accustomed with."
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev