|
| Re: Thoughts on JPA 2.0 metamodel generation in Dali 3.0 [message #435553 is a reply to message #435552] |
Wed, 22 July 2009 21:38   |
 Neil Hauge
Messages: 475
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 #616667 is a reply to message #435552] |
Wed, 22 July 2009 21:38 |
Neil Hauge
Messages: 475
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.03482 seconds
] 
Search
Help
Register
Login
Home
