Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Dali » Thoughts on JPA 2.0 metamodel generation in Dali 3.0
Thoughts on JPA 2.0 metamodel generation in Dali 3.0 [message #435552] Tue, 21 July 2009 11:28 Go to next message
Leonard Theivendra is currently offline Leonard Theivendra
Messages: 36
Registered: July 2009
Member
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?

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.

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.

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?

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.

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 :)
Re: Thoughts on JPA 2.0 metamodel generation in Dali 3.0 [message #435553 is a reply to message #435552] Wed, 22 July 2009 17:38 Go to previous messageGo to next message
Neil Hauge is currently offline Neil Hauge
Messages: 467
Registered: July 2009
Senior Member
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
Re: Thoughts on JPA 2.0 metamodel generation in Dali 3.0 [message #468441 is a reply to message #435553] Wed, 05 August 2009 10:30 Go to previous message
Leonard Theivendra is currently offline Leonard Theivendra
Messages: 36
Registered: July 2009
Member
Thanks for the info Neil, I will get back to this thread later with some
user modification scenarios
Re: Thoughts on JPA 2.0 metamodel generation in Dali 3.0 [message #616667 is a reply to message #435552] Wed, 22 July 2009 17:38 Go to previous message
Neil Hauge is currently offline Neil Hauge
Messages: 467
Registered: July 2009
Senior Member
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
Re: Thoughts on JPA 2.0 metamodel generation in Dali 3.0 [message #617456 is a reply to message #435553] Wed, 05 August 2009 10:30 Go to previous message
Leonard Theivendra is currently offline Leonard Theivendra
Messages: 36
Registered: July 2009
Member
Thanks for the info Neil, I will get back to this thread later with some
user modification scenarios
Previous Topic:How do I turn off JPA validation?
Next Topic:JPA implementation library warning
Goto Forum:
  


Current Time: Wed Jul 30 01:18:45 EDT 2014

Powered by FUDForum. Page generated in 0.35704 seconds