You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2017/01/08 08:36:06 UTC
Modeling annotations
[splitting annotations discussion in its own thread]
> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <bl...@gmail.com> wrote:
>> We had looked at overriding getters/setters for annotations, but we didn't
>> want to do that 1000s of times, so we gave up.
>> I see value in the
>> superclass being able to have annotations along with JavaDocs for various
>> attributes and relationships, plus the class itself. The superclass is
>> essentially maintained outside of the IDE currently, anyway (you may look
>> at the code, but you don't edit it), so I don't think it'll be too bad.
> But how does this save us work creating annotations? If you had to override 1000's of methods, then you will have to create 1000's of annotations in the Modeler as well to achieve the same effect. The only way to cut down on the number of (repeating) annotations is if they are are all applied to the same properties of different entities. Then they can be moved to a separate interface (or a superclass common to all entities), all outside the Modeler and within the IDE.
More on why annotations being on the IDE side is important ... Annotations do not have to be trivial. They may have a bunch of references to other code. So taking them out of reach of the IDE refactoring is really inconvenient. E.g.:
@MyA {
handler = com.foo.MyHandler,
types = {"a", "b", "c"},
name = "foo"
}
class MyClass {}
So here if you say rename "MyHandler", you have a good chance of missing it in the XML. We've seen this problem repeatedly with Listener classes mapped in the Modeler, which led us to remove Listener functionality from the Modeler completely. This generally made me extremely wary of keeping non-ORM pieces of code in the XML.
So perhaps there's another solution for annotations? Such as replacing the "generation gap" pattern in the future versions with smarter "merging" code generators (e.g. using @javax.annotation.Generated to tell the code generated by us from the code created by the user).
Andrus
Re: Modeling annotations
Posted by Michael Gentry <mg...@masslight.net>.
Well, I haven't made any XML changes yet. My first goal is to be able to
edit the currently supported model before adding to it. We'll have plenty
of time to noodle over XML changes/design for this effort.
Thanks,
mrg
On Tue, Jan 17, 2017 at 10:17 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> Fair enough. While I would likely still avoid annotations in the model
> myself, I see where you are coming from.
>
> It would be ideal if we could implement proper model extensions mechanism
> [1]. Then annotations, cdbimport specs, DB comments or any other arbitrary
> metadata can be done as independent optional modules.
>
> Andrus
>
> [1] https://lists.apache.org/thread.html/068029fd0197b1d55e2206bf666a84
> c5d24e20235fad3340901358de@%3Cdev.cayenne.apache.org%3E
>
>
>
> > On Jan 17, 2017, at 10:07 AM, Michael Gentry <mg...@masslight.net>
> wrote:
> >
> > I don't think that will allow enough granularity or control. For
> example,
> > there are certain fields we don't want exposed, etc. A custom template
> > would apply the same annotation everywhere. That's why in the new CM I
> was
> > adding annotation support on everything.
> >
> >
> > On Tue, Jan 17, 2017 at 9:58 AM, Andrus Adamchik <andrus@objectstyle.org
> >
> > wrote:
> >
> >> I wonder if "regular" things like JAXB annotations can be generated via
> a
> >> custom template?
> >>
> >> Andrus
> >>
> >>> On Jan 16, 2017, at 11:20 AM, Michael Gentry <bl...@gmail.com>
> >> wrote:
> >>>
> >>> My initial desire for annotation support was to allow for JAXB
> >> annotations (
> >>> http://www.techferry.com/articles/jaxb-annotations.html), but of
> course
> >> it
> >>> could be used for other purposes. I'm not sure how much IDE
> refactoring
> >>> would take place in this arena. I concede renaming "MyHandler" could
> be
> >>> problematic, or at least surprising -- hopefully you'd notice the _
> >>> superclasses had unexpected changes.
> >>>
> >>> I really want to be able to specify annotations, but I'd also hate to
> >> lose
> >>> the generation gap pattern and "uglify" the subclasses (if they even
> >>> existed at that point) with something like this:
> >>>
> >>> @MyA {
> >>> handler = com.foo.MyHandler,
> >>> types = {"a", "b", "c"},
> >>> name = "foo"
> >>> }
> >>> @Generated // By Cayenne - DO NOT EDIT
> >>> @XmlElement // I intentionally put this annotation after @Generated
> to
> >>> maybe cause problems...
> >>> public String getNotes() {
> >>> return (String)readProperty(NOTES_PROPERTY);
> >>> }
> >>> [repeat]
> >>>
> >>> You'd also need to "protect" NOTES_PROPERTY as well, all the
> relationship
> >>> methods, etc.
> >>>
> >>> I can see it being quite difficult to merge without causing problems,
> >> too.
> >>> You'd also need to properly parse the method to find the end -- people
> >> can
> >>> have custom templates where more logic is added into the generated
> >> methods,
> >>> so you can't just skip to the next }. Also, how do you track renames?
> >> If
> >>> someone changed "notes" in CM to "note" and regenerated classes, would
> it
> >>> create a new getter/setter for "note", delete "notes" and all
> annotations
> >>> on it, losing the annotations you had intended for "notes" (which is
> now
> >>> "note")? This would also be quite surprising for most users.
> >>>
> >>> Thanks,
> >>>
> >>> mrg
> >>>
> >>>
> >>> On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <
> andrus@objectstyle.org>
> >>> wrote:
> >>>
> >>>> [splitting annotations discussion in its own thread]
> >>>>
> >>>>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <andrus@objectstyle.org
> >
> >>>> wrote:
> >>>>>
> >>>>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <bl...@gmail.com>
> >> wrote:
> >>>>>> We had looked at overriding getters/setters for annotations, but we
> >>>> didn't
> >>>>>> want to do that 1000s of times, so we gave up.
> >>>>>> I see value in the
> >>>>>> superclass being able to have annotations along with JavaDocs for
> >>>> various
> >>>>>> attributes and relationships, plus the class itself. The superclass
> >> is
> >>>>>> essentially maintained outside of the IDE currently, anyway (you may
> >>>> look
> >>>>>> at the code, but you don't edit it), so I don't think it'll be too
> >> bad.
> >>>>
> >>>>> But how does this save us work creating annotations? If you had to
> >>>> override 1000's of methods, then you will have to create 1000's of
> >>>> annotations in the Modeler as well to achieve the same effect. The
> only
> >> way
> >>>> to cut down on the number of (repeating) annotations is if they are
> are
> >> all
> >>>> applied to the same properties of different entities. Then they can be
> >>>> moved to a separate interface (or a superclass common to all
> entities),
> >> all
> >>>> outside the Modeler and within the IDE.
> >>>>
> >>>> More on why annotations being on the IDE side is important ...
> >> Annotations
> >>>> do not have to be trivial. They may have a bunch of references to
> other
> >>>> code. So taking them out of reach of the IDE refactoring is really
> >>>> inconvenient. E.g.:
> >>>>
> >>>> @MyA {
> >>>> handler = com.foo.MyHandler,
> >>>> types = {"a", "b", "c"},
> >>>> name = "foo"
> >>>> }
> >>>> class MyClass {}
> >>>>
> >>>> So here if you say rename "MyHandler", you have a good chance of
> missing
> >>>> it in the XML. We've seen this problem repeatedly with Listener
> classes
> >>>> mapped in the Modeler, which led us to remove Listener functionality
> >> from
> >>>> the Modeler completely. This generally made me extremely wary of
> keeping
> >>>> non-ORM pieces of code in the XML.
> >>>>
> >>>> So perhaps there's another solution for annotations? Such as replacing
> >> the
> >>>> "generation gap" pattern in the future versions with smarter "merging"
> >> code
> >>>> generators (e.g. using @javax.annotation.Generated to tell the code
> >>>> generated by us from the code created by the user).
> >>>>
> >>>> Andrus
> >>>>
> >>>>
> >>
> >>
>
>
Re: Modeling annotations
Posted by Andrus Adamchik <an...@objectstyle.org>.
Fair enough. While I would likely still avoid annotations in the model myself, I see where you are coming from.
It would be ideal if we could implement proper model extensions mechanism [1]. Then annotations, cdbimport specs, DB comments or any other arbitrary metadata can be done as independent optional modules.
Andrus
[1] https://lists.apache.org/thread.html/068029fd0197b1d55e2206bf666a84c5d24e20235fad3340901358de@%3Cdev.cayenne.apache.org%3E
> On Jan 17, 2017, at 10:07 AM, Michael Gentry <mg...@masslight.net> wrote:
>
> I don't think that will allow enough granularity or control. For example,
> there are certain fields we don't want exposed, etc. A custom template
> would apply the same annotation everywhere. That's why in the new CM I was
> adding annotation support on everything.
>
>
> On Tue, Jan 17, 2017 at 9:58 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
>> I wonder if "regular" things like JAXB annotations can be generated via a
>> custom template?
>>
>> Andrus
>>
>>> On Jan 16, 2017, at 11:20 AM, Michael Gentry <bl...@gmail.com>
>> wrote:
>>>
>>> My initial desire for annotation support was to allow for JAXB
>> annotations (
>>> http://www.techferry.com/articles/jaxb-annotations.html), but of course
>> it
>>> could be used for other purposes. I'm not sure how much IDE refactoring
>>> would take place in this arena. I concede renaming "MyHandler" could be
>>> problematic, or at least surprising -- hopefully you'd notice the _
>>> superclasses had unexpected changes.
>>>
>>> I really want to be able to specify annotations, but I'd also hate to
>> lose
>>> the generation gap pattern and "uglify" the subclasses (if they even
>>> existed at that point) with something like this:
>>>
>>> @MyA {
>>> handler = com.foo.MyHandler,
>>> types = {"a", "b", "c"},
>>> name = "foo"
>>> }
>>> @Generated // By Cayenne - DO NOT EDIT
>>> @XmlElement // I intentionally put this annotation after @Generated to
>>> maybe cause problems...
>>> public String getNotes() {
>>> return (String)readProperty(NOTES_PROPERTY);
>>> }
>>> [repeat]
>>>
>>> You'd also need to "protect" NOTES_PROPERTY as well, all the relationship
>>> methods, etc.
>>>
>>> I can see it being quite difficult to merge without causing problems,
>> too.
>>> You'd also need to properly parse the method to find the end -- people
>> can
>>> have custom templates where more logic is added into the generated
>> methods,
>>> so you can't just skip to the next }. Also, how do you track renames?
>> If
>>> someone changed "notes" in CM to "note" and regenerated classes, would it
>>> create a new getter/setter for "note", delete "notes" and all annotations
>>> on it, losing the annotations you had intended for "notes" (which is now
>>> "note")? This would also be quite surprising for most users.
>>>
>>> Thanks,
>>>
>>> mrg
>>>
>>>
>>> On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <an...@objectstyle.org>
>>> wrote:
>>>
>>>> [splitting annotations discussion in its own thread]
>>>>
>>>>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <an...@objectstyle.org>
>>>> wrote:
>>>>>
>>>>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <bl...@gmail.com>
>> wrote:
>>>>>> We had looked at overriding getters/setters for annotations, but we
>>>> didn't
>>>>>> want to do that 1000s of times, so we gave up.
>>>>>> I see value in the
>>>>>> superclass being able to have annotations along with JavaDocs for
>>>> various
>>>>>> attributes and relationships, plus the class itself. The superclass
>> is
>>>>>> essentially maintained outside of the IDE currently, anyway (you may
>>>> look
>>>>>> at the code, but you don't edit it), so I don't think it'll be too
>> bad.
>>>>
>>>>> But how does this save us work creating annotations? If you had to
>>>> override 1000's of methods, then you will have to create 1000's of
>>>> annotations in the Modeler as well to achieve the same effect. The only
>> way
>>>> to cut down on the number of (repeating) annotations is if they are are
>> all
>>>> applied to the same properties of different entities. Then they can be
>>>> moved to a separate interface (or a superclass common to all entities),
>> all
>>>> outside the Modeler and within the IDE.
>>>>
>>>> More on why annotations being on the IDE side is important ...
>> Annotations
>>>> do not have to be trivial. They may have a bunch of references to other
>>>> code. So taking them out of reach of the IDE refactoring is really
>>>> inconvenient. E.g.:
>>>>
>>>> @MyA {
>>>> handler = com.foo.MyHandler,
>>>> types = {"a", "b", "c"},
>>>> name = "foo"
>>>> }
>>>> class MyClass {}
>>>>
>>>> So here if you say rename "MyHandler", you have a good chance of missing
>>>> it in the XML. We've seen this problem repeatedly with Listener classes
>>>> mapped in the Modeler, which led us to remove Listener functionality
>> from
>>>> the Modeler completely. This generally made me extremely wary of keeping
>>>> non-ORM pieces of code in the XML.
>>>>
>>>> So perhaps there's another solution for annotations? Such as replacing
>> the
>>>> "generation gap" pattern in the future versions with smarter "merging"
>> code
>>>> generators (e.g. using @javax.annotation.Generated to tell the code
>>>> generated by us from the code created by the user).
>>>>
>>>> Andrus
>>>>
>>>>
>>
>>
Re: Modeling annotations
Posted by Michael Gentry <mg...@masslight.net>.
I don't think that will allow enough granularity or control. For example,
there are certain fields we don't want exposed, etc. A custom template
would apply the same annotation everywhere. That's why in the new CM I was
adding annotation support on everything.
On Tue, Jan 17, 2017 at 9:58 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> I wonder if "regular" things like JAXB annotations can be generated via a
> custom template?
>
> Andrus
>
> > On Jan 16, 2017, at 11:20 AM, Michael Gentry <bl...@gmail.com>
> wrote:
> >
> > My initial desire for annotation support was to allow for JAXB
> annotations (
> > http://www.techferry.com/articles/jaxb-annotations.html), but of course
> it
> > could be used for other purposes. I'm not sure how much IDE refactoring
> > would take place in this arena. I concede renaming "MyHandler" could be
> > problematic, or at least surprising -- hopefully you'd notice the _
> > superclasses had unexpected changes.
> >
> > I really want to be able to specify annotations, but I'd also hate to
> lose
> > the generation gap pattern and "uglify" the subclasses (if they even
> > existed at that point) with something like this:
> >
> > @MyA {
> > handler = com.foo.MyHandler,
> > types = {"a", "b", "c"},
> > name = "foo"
> > }
> > @Generated // By Cayenne - DO NOT EDIT
> > @XmlElement // I intentionally put this annotation after @Generated to
> > maybe cause problems...
> > public String getNotes() {
> > return (String)readProperty(NOTES_PROPERTY);
> > }
> > [repeat]
> >
> > You'd also need to "protect" NOTES_PROPERTY as well, all the relationship
> > methods, etc.
> >
> > I can see it being quite difficult to merge without causing problems,
> too.
> > You'd also need to properly parse the method to find the end -- people
> can
> > have custom templates where more logic is added into the generated
> methods,
> > so you can't just skip to the next }. Also, how do you track renames?
> If
> > someone changed "notes" in CM to "note" and regenerated classes, would it
> > create a new getter/setter for "note", delete "notes" and all annotations
> > on it, losing the annotations you had intended for "notes" (which is now
> > "note")? This would also be quite surprising for most users.
> >
> > Thanks,
> >
> > mrg
> >
> >
> > On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <an...@objectstyle.org>
> > wrote:
> >
> >> [splitting annotations discussion in its own thread]
> >>
> >>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <an...@objectstyle.org>
> >> wrote:
> >>>
> >>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <bl...@gmail.com>
> wrote:
> >>>> We had looked at overriding getters/setters for annotations, but we
> >> didn't
> >>>> want to do that 1000s of times, so we gave up.
> >>>> I see value in the
> >>>> superclass being able to have annotations along with JavaDocs for
> >> various
> >>>> attributes and relationships, plus the class itself. The superclass
> is
> >>>> essentially maintained outside of the IDE currently, anyway (you may
> >> look
> >>>> at the code, but you don't edit it), so I don't think it'll be too
> bad.
> >>
> >>> But how does this save us work creating annotations? If you had to
> >> override 1000's of methods, then you will have to create 1000's of
> >> annotations in the Modeler as well to achieve the same effect. The only
> way
> >> to cut down on the number of (repeating) annotations is if they are are
> all
> >> applied to the same properties of different entities. Then they can be
> >> moved to a separate interface (or a superclass common to all entities),
> all
> >> outside the Modeler and within the IDE.
> >>
> >> More on why annotations being on the IDE side is important ...
> Annotations
> >> do not have to be trivial. They may have a bunch of references to other
> >> code. So taking them out of reach of the IDE refactoring is really
> >> inconvenient. E.g.:
> >>
> >> @MyA {
> >> handler = com.foo.MyHandler,
> >> types = {"a", "b", "c"},
> >> name = "foo"
> >> }
> >> class MyClass {}
> >>
> >> So here if you say rename "MyHandler", you have a good chance of missing
> >> it in the XML. We've seen this problem repeatedly with Listener classes
> >> mapped in the Modeler, which led us to remove Listener functionality
> from
> >> the Modeler completely. This generally made me extremely wary of keeping
> >> non-ORM pieces of code in the XML.
> >>
> >> So perhaps there's another solution for annotations? Such as replacing
> the
> >> "generation gap" pattern in the future versions with smarter "merging"
> code
> >> generators (e.g. using @javax.annotation.Generated to tell the code
> >> generated by us from the code created by the user).
> >>
> >> Andrus
> >>
> >>
>
>
Re: Modeling annotations
Posted by Andrus Adamchik <an...@objectstyle.org>.
I wonder if "regular" things like JAXB annotations can be generated via a custom template?
Andrus
> On Jan 16, 2017, at 11:20 AM, Michael Gentry <bl...@gmail.com> wrote:
>
> My initial desire for annotation support was to allow for JAXB annotations (
> http://www.techferry.com/articles/jaxb-annotations.html), but of course it
> could be used for other purposes. I'm not sure how much IDE refactoring
> would take place in this arena. I concede renaming "MyHandler" could be
> problematic, or at least surprising -- hopefully you'd notice the _
> superclasses had unexpected changes.
>
> I really want to be able to specify annotations, but I'd also hate to lose
> the generation gap pattern and "uglify" the subclasses (if they even
> existed at that point) with something like this:
>
> @MyA {
> handler = com.foo.MyHandler,
> types = {"a", "b", "c"},
> name = "foo"
> }
> @Generated // By Cayenne - DO NOT EDIT
> @XmlElement // I intentionally put this annotation after @Generated to
> maybe cause problems...
> public String getNotes() {
> return (String)readProperty(NOTES_PROPERTY);
> }
> [repeat]
>
> You'd also need to "protect" NOTES_PROPERTY as well, all the relationship
> methods, etc.
>
> I can see it being quite difficult to merge without causing problems, too.
> You'd also need to properly parse the method to find the end -- people can
> have custom templates where more logic is added into the generated methods,
> so you can't just skip to the next }. Also, how do you track renames? If
> someone changed "notes" in CM to "note" and regenerated classes, would it
> create a new getter/setter for "note", delete "notes" and all annotations
> on it, losing the annotations you had intended for "notes" (which is now
> "note")? This would also be quite surprising for most users.
>
> Thanks,
>
> mrg
>
>
> On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
>> [splitting annotations discussion in its own thread]
>>
>>> On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>>
>>>> On Jan 8, 2017, at 1:12 AM, Michael Gentry <bl...@gmail.com> wrote:
>>>> We had looked at overriding getters/setters for annotations, but we
>> didn't
>>>> want to do that 1000s of times, so we gave up.
>>>> I see value in the
>>>> superclass being able to have annotations along with JavaDocs for
>> various
>>>> attributes and relationships, plus the class itself. The superclass is
>>>> essentially maintained outside of the IDE currently, anyway (you may
>> look
>>>> at the code, but you don't edit it), so I don't think it'll be too bad.
>>
>>> But how does this save us work creating annotations? If you had to
>> override 1000's of methods, then you will have to create 1000's of
>> annotations in the Modeler as well to achieve the same effect. The only way
>> to cut down on the number of (repeating) annotations is if they are are all
>> applied to the same properties of different entities. Then they can be
>> moved to a separate interface (or a superclass common to all entities), all
>> outside the Modeler and within the IDE.
>>
>> More on why annotations being on the IDE side is important ... Annotations
>> do not have to be trivial. They may have a bunch of references to other
>> code. So taking them out of reach of the IDE refactoring is really
>> inconvenient. E.g.:
>>
>> @MyA {
>> handler = com.foo.MyHandler,
>> types = {"a", "b", "c"},
>> name = "foo"
>> }
>> class MyClass {}
>>
>> So here if you say rename "MyHandler", you have a good chance of missing
>> it in the XML. We've seen this problem repeatedly with Listener classes
>> mapped in the Modeler, which led us to remove Listener functionality from
>> the Modeler completely. This generally made me extremely wary of keeping
>> non-ORM pieces of code in the XML.
>>
>> So perhaps there's another solution for annotations? Such as replacing the
>> "generation gap" pattern in the future versions with smarter "merging" code
>> generators (e.g. using @javax.annotation.Generated to tell the code
>> generated by us from the code created by the user).
>>
>> Andrus
>>
>>
Re: Modeling annotations
Posted by Michael Gentry <bl...@gmail.com>.
My initial desire for annotation support was to allow for JAXB annotations (
http://www.techferry.com/articles/jaxb-annotations.html), but of course it
could be used for other purposes. I'm not sure how much IDE refactoring
would take place in this arena. I concede renaming "MyHandler" could be
problematic, or at least surprising -- hopefully you'd notice the _
superclasses had unexpected changes.
I really want to be able to specify annotations, but I'd also hate to lose
the generation gap pattern and "uglify" the subclasses (if they even
existed at that point) with something like this:
@MyA {
handler = com.foo.MyHandler,
types = {"a", "b", "c"},
name = "foo"
}
@Generated // By Cayenne - DO NOT EDIT
@XmlElement // I intentionally put this annotation after @Generated to
maybe cause problems...
public String getNotes() {
return (String)readProperty(NOTES_PROPERTY);
}
[repeat]
You'd also need to "protect" NOTES_PROPERTY as well, all the relationship
methods, etc.
I can see it being quite difficult to merge without causing problems, too.
You'd also need to properly parse the method to find the end -- people can
have custom templates where more logic is added into the generated methods,
so you can't just skip to the next }. Also, how do you track renames? If
someone changed "notes" in CM to "note" and regenerated classes, would it
create a new getter/setter for "note", delete "notes" and all annotations
on it, losing the annotations you had intended for "notes" (which is now
"note")? This would also be quite surprising for most users.
Thanks,
mrg
On Sun, Jan 8, 2017 at 3:36 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> [splitting annotations discussion in its own thread]
>
> > On Jan 8, 2017, at 10:40 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
> >
> >> On Jan 8, 2017, at 1:12 AM, Michael Gentry <bl...@gmail.com> wrote:
> >> We had looked at overriding getters/setters for annotations, but we
> didn't
> >> want to do that 1000s of times, so we gave up.
> >> I see value in the
> >> superclass being able to have annotations along with JavaDocs for
> various
> >> attributes and relationships, plus the class itself. The superclass is
> >> essentially maintained outside of the IDE currently, anyway (you may
> look
> >> at the code, but you don't edit it), so I don't think it'll be too bad.
>
> > But how does this save us work creating annotations? If you had to
> override 1000's of methods, then you will have to create 1000's of
> annotations in the Modeler as well to achieve the same effect. The only way
> to cut down on the number of (repeating) annotations is if they are are all
> applied to the same properties of different entities. Then they can be
> moved to a separate interface (or a superclass common to all entities), all
> outside the Modeler and within the IDE.
>
> More on why annotations being on the IDE side is important ... Annotations
> do not have to be trivial. They may have a bunch of references to other
> code. So taking them out of reach of the IDE refactoring is really
> inconvenient. E.g.:
>
> @MyA {
> handler = com.foo.MyHandler,
> types = {"a", "b", "c"},
> name = "foo"
> }
> class MyClass {}
>
> So here if you say rename "MyHandler", you have a good chance of missing
> it in the XML. We've seen this problem repeatedly with Listener classes
> mapped in the Modeler, which led us to remove Listener functionality from
> the Modeler completely. This generally made me extremely wary of keeping
> non-ORM pieces of code in the XML.
>
> So perhaps there's another solution for annotations? Such as replacing the
> "generation gap" pattern in the future versions with smarter "merging" code
> generators (e.g. using @javax.annotation.Generated to tell the code
> generated by us from the code created by the user).
>
> Andrus
>
>