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
Operations

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}}.

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.

Andy Jefferson made changes - 17/Feb/13 02:36 PM
Field Original Value New Value
Status Open [ 1 ] Resolved [ 5 ]
Resolution Won't Fix [ 2 ]
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.

Andy Jefferson made changes - 20/Feb/13 12:05 PM
Status Resolved [ 5 ] Closed [ 6 ]
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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=360727 !!!