If you didn't like the JDO annotations in your source, you have one other option I can think of besides the xml metadata option.
NB: I think it's a pretty heavyweight solution for just a metadata location preference. You could also use AspectJ to introduce the annotations orthogonally. They would be there at runtime, but you wouldn't see them in source. It would take some changes to your build environment (I recommend just replacing javac with ajc), but you need to make sure that if you use AspectJ, do it before enhancing. Note that today, I'd say the best practice in JDO is to use annotations for logical metadata (like @PersistenceCapable -- those things that don't change as a function of your datastore type or vendor) and XML metadata for physical metadata (like OR mappings or other metadata that does change as a function of your datastore type & vendor). It's a fact of life that writing persistent objects is different than writing transient ones... Perhaps the Isis team could provide aspects or similar functionality that introduce the appropriate JDO metadata (annotations and/or XML) based on its own metadata. -matthew On Thu, Sep 6, 2012 at 12:31 PM, Dan Haywood <[email protected]>wrote: > Jeroen and I talked were also talking about this (he and I are using the > JDO object store in anger on a project we're working on together). I do > suspect that it would be possible to "teach" DataNucleus (the underlying > JDO implementation) about some of Isis' annotations and conventions, thus > reducing the amount of stuff. > > However, we both decided that would be a bad idea. After all, the JDO > community is that much larger (Google app engine, for example) and more > established than our own. And hopefully some of those users will come > across Isis and see its support for JDO, and think about trying it out. It > wouldn't be a good experience if they have to unlearn hard-learnt JDO > annotations/conventions and try to figure out how Isis interacts with JDO. > > On the other hand, if there are semantics that we can infer into Isis from > JDO annotations, then that direction is just fine. For example, > @javax.jdo.Embedded annotation is basically the same as the Isis > @Aggregated annotation, and so we infer the AggregatedFact from it. > > Dan > > On 6 September 2012 18:18, Kevin Meyer - KMZ <[email protected]> wrote: > > > Now you know why I like the sql-os so much! No annotations, just a > > few occaisional overrides in the properties file.. > > > > I'm slowly reconstrucing my build enviroment (I have recently moved > > into temporary accommodation).. should able to make some progress > > soon. > > > > Regards, > > Kevin > > > > On 6 Sep 2012 at 14:07, [email protected] wrote: > > > > > Do I really have to place all those JDO annotations in my model ? :( > > > > > > Regards, > > > > > > Minto > > > > > > Quoting Dan Haywood <[email protected]>: > > > > > > > Yes, it's on the Todo list to provide some docs. > > > > The quickstart app is configured for JDO, though, so you could stay > > there. > > > > > > > > More detail later today. > > > > Dan > > > > > > > > > -- mailto:[email protected] <[email protected]> skype:matthewadams12 googletalk:[email protected] http://matthewadams.me http://www.linkedin.com/in/matthewadams
