DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Key: NUCJPA-220
Type: Improvement Improvement
Status: Closed Closed
Resolution: Won't Fix
Priority: Major Major
Assignee: Unassigned
Reporter: Oliver Gierke
Votes: 0
Watchers: 1

If you were logged in you would be able to see more operations.
DataNucleus API JPA

Using JPA runtime enhancement should not require JDO related classes to be pulled into the project

Created: 17/Feb/13 01:39 PM   Updated: 23/Feb/13 07:14 AM   Resolved: 17/Feb/13 02:36 PM
Component/s: Dependency
Affects Version/s: 3.1.4
Fix Version/s: None

 Description  « Hide
I tried seeting up runtime enhancement specifying {{addClassTransformer}} which activates the {{JPAClassTransformer}} in the {{EntityManagerFactory}} implementation. If you're missing JDO API JAR on the classpath you'll run into a {{ClassNotFoundException}} for {{JDONullIdentityException}}.

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 17/Feb/13 02:36 PM
If "runtime enhancement" enhances things using the _public standard JDO specification bytecode enhancement contract_ then obviously yes it should require jdo-api.jar to be in the CLASSPATH, which is the current state of things.

Clearly we could provide DataNucleus-specific enhancement copying the JDO contract but then that would require a datanucleus jar to be in the CLASSPATH wherever those classes were used, so there is no benefit, and besides the JDO enhancement contract is well-defined and standardised (see NUCCORE-922 if you wish to contribute to such an issue).

FWIW DN 3.2 does away with separate enhancer and asm jars, and changes some internal exceptions (like when accessing a non-detached field) to use IllegalXXXException rather than JDO exceptions.

Oliver Gierke added a comment - 17/Feb/13 03:45 PM
While I can see this makes sense from an implementation point of view, I think it's exactly the wrong thing to do from a user's point of view. If I want to set up JPA, I set up JPA. I don't want any JAR files from another persistence mechanism lingering around in my classpath. You're essentially exposing implementation details to the user. But we might just agree to disagree here.

Matthew T. Adams added a comment - 23/Feb/13 07:14 AM
The only artifact being brought in is javax.jdo:jdo-api:3.0, but I'd recommend excluding 3.0 in favor of 3.0.1. 3.0.1's dependencies are manageable; basically, they're only the JTA jar, which you can exclude, and the JPA API itself**, but that uses provided scope, and you're surely going to have it around in the classpath. While I agree with you in principle, Oliver, it seems a small concession.

**: I'd sure like to see a standard javax.persistence:jpa-api artifact in Maven Central... Vote for !!!