[news.eclipse.technology.dali] Re: Thoughts on JPA 2.0 metamodel generat

[neil.hauge@xxxxxxxxxx (Neil Hauge)]

Hi Len,

I'll answer your questions inline.  Our direction on this front has 
changed a bit since the meetings, but of course things are not yet set in 
stone.


Leonard Theivendra wrote:

> Hi team, I missed the planning meeting but did see the minutes and this 
> item was listed.  Perhaps it is too early to get more details, but would 
> like to know your thoughts on how this is being planned to be addressed in 
> 3.0:

> 1) Will there be way to hook in provider specific annotation processors, 
> perhaps based on the platform set in the JPA facet?

We are actually moving in a non-APT direction for this at the moment.  The 
reason being that activating this type of processing could be a painful 
thing in the UI for large projects.  We can much more efficiently listen 
to our own JPA model and make more granular updates to the canonical 
meta-model, as opposed to doing wholesale generation on compilation.  We 
think the effort to do this is probably worth the possible performance 
depredation we would expect to see by including additional compile time 
processing.

This all assumes that we want an "automated" solution, as opposed to just 
a (generate once in a while) user directed solution, although there would 
still be problems with cleaning up deleted entities in this case.  The 
non-APT solution offers a number of advantages.


> 2) How should the generated metamodel classes be treated if the annotation 
> processor runs as part of a build (i.e. builder): as derived? If derived, 
> then what if the user wants to modify/add to the generated metamodel 
> classes during development (i.e. his changes will get overwritten).  If 
> not derived, there might be issues with source control constantly asking 
> to check in/out the files.

We currently don't see any use cases for the user modifying the generated 
canonical metamodel.  The classes will be marked @Generated and any user 
changes will be overwritten by our updates.

> 3) Will there be issues with Java 6's auto discovery mechanism of 
> annotation processors that happen to be on the build path? i.e. the 
> annotation processor running for JPA bean classes that do not need 
> metamodel generation.

Yes, this could be a problem, depending on how Eclipse handles this 
auto-discovery mechanism.  I'm not sure how this is handled so there will 
need to be more investigation done here.  I don't think this is 
necessarily a Dali issue, but one that could impact JPA Tooling.

> 4) Should there be an option to explicity run a metamodel generation 
> operation or is this best left for adopters to add if they choose to?

Based on our current design, the metamodel generation would either be on 
or off, so not sure having an explicit generation option would make sense.

> 5) Refactoring of jpa class elements and the re-generation of metamodel 
> classes and then refactoring the queries: guess this is an opportunity for 
> more tooling too.

Yep.  We are certainly looking at this refactoring as something to go 
along with this functionality.  It is in our tentative plans at the moment.

> Just some of the starter issues that pop into my head :), this whole 
> concept of generation of artifacts *during* the development cycle which 
> can possibly be modified by the user opens up a whole new can of worms :)

There are definitely several worm cans being opened with this new JPA 2.0 
requirement.  If you have any thoughts on user modification scenarios, 
that would be helpful.

Neil