This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 232018 - Maven JPA dependency issues
Summary: Maven JPA dependency issues
Status: VERIFIED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Persistence (show other bugs)
Version: 7.4
Hardware: All All
: P2 normal (vote)
Assignee: Sergey Petrov
URL:
Keywords: 7.4_WAIVER_APPROVED
Depends on:
Blocks: 235210 235649
  Show dependency tree
 
Reported: 2013-06-29 02:02 UTC by athompson
Modified: 2014-08-06 15:06 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description athompson 2013-06-29 02:02:57 UTC
Probable 7.4 stopper.

There are several issues with the automatic adding of JPA dependencies to Maven projects (triggered by adding a JPA persistence unit/entity/etc to a project). The first (SNAPSHOT versions) is pretty major and is probably a "must fix" for 7.4 and 7.3.2:

1. The dependencies added for JPA 2.1 are SNAPSHOT versions. JPA 2.1 has been released, so instead of adding the snapshot versions of the persistence libraries the final versions should now be used:

  org.eclipse.persistence:eclipselink:2.5.0
  org.eclipse.persistence:org.eclipse.persistence.jpa.modelgen.processor:2.5.0
  org.eclipse.persistence:javax.persistence:2.1.0 (see #3)

2. The JPA dependencies appear now to be in the "central" repository, therefore the "eclipselink" and "jpa20-persistence" (sic--see #5) repositories should no longer be added to the POM file and instead the URL [1] should be added to the repository blacklist.

3. The dependency "org.eclipse.persistence:javax.persistence" is now a transitive dependency of "eclipselink" (at least since version 2.4.0 which is JPA 2.0), so should not be explicitly included when adding eclipselink.

4. The repository entries with IDs "eclipselink" (added when creating a new PU) and "jpa20-persistence" (added when creating a new entity without a PU) refer to the same repository so should be combined (rendered moot by #2).

5. If you create a new entity class without a PU, the repository added is used for JPA 2.1 deps, has the name "Repository for library Persistence (JPA 2.1)", but has the contradictory ID "jpa20-persistence" (rendered moot by #2).


[1]: http://download.eclipse.org/rt/eclipselink/maven.repo/
Comment 1 Sergey Petrov 2013-07-01 07:32:50 UTC
If snapshot is the major part, it can't be fixed https://bugs.eclipse.org/bugs/show_bug.cgi?id=408212, so change to P3. 
Will evaluate other parts later, but it's much better to have set of issues rather then issue with a set of problems, otherwise "issue" may never be fixed completely.
Comment 2 Sergey Petrov 2013-07-01 14:39:33 UTC
For javax.persistence it seems to be valid and can be omitted.
I can't find eclipselink artifact in central repository, I see only separate jars here. Can you? I can't build a project without repository specification also.
As for repository names, I see very monor or no issues here as different set of jars means different libraries are added.
Comment 3 Quality Engineering 2013-07-02 02:13:58 UTC
Integrated into 'main-silver', will be available in build *201307012300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/e04f8ab0daa5
User: Sergey B. Petrov <sj-nb@netbeans.org>
Log: #232018 do not specify api jar in meven dependency
Comment 4 athompson 2013-07-02 18:12:41 UTC
(In reply to comment #2)

I've verified that it builds fine without specifying the eclipse repo here; I even deleted my local repo and rebuilt to be sure. I also can see it in the central repo here:

http://search.maven.org/#browse%7C1265486467
Comment 5 athompson 2013-07-02 18:17:58 UTC
(In reply to comment #1)

I can't get a build to fail using version 2.5.0 of eclipselink. Is there anything I need to do to reproduce this?
Comment 6 Sergey Petrov 2013-07-03 03:34:11 UTC
you need to use jdk6+ source level to get all dependencis necessary for a fail, i.e. eclipselik+modelgen.
Comment 7 Sergey Petrov 2013-07-03 03:36:29 UTC
it may be problem, is there snapshot version in central? I can't see.
Comment 8 athompson 2013-07-03 05:53:16 UTC
(In reply to comment #6)
> you need to use jdk6+ source level to get all dependencis necessary for a fail,
> i.e. eclipselik+modelgen.

I'm using JDK7 source level without problems. I'll try JDK6...
Comment 9 Milos Kleint 2013-07-03 06:02:27 UTC
(In reply to comment #7)
> it may be problem, is there snapshot version in central? I can't see.

no central, doesn't contain any snapshots by design.
Comment 10 Sergey Petrov 2013-07-03 06:25:25 UTC
jdk7 source level should fail too in my opinion, the problem is in signing of eclipslelink/modelgen jars, it's resolved in 2.5.1, I have no ideas why it's not reproducible for you. after update to 2.5.1 I'll try to move dependencies to central repository.
Comment 11 athompson 2013-07-03 15:48:33 UTC
IMHO any of the other workarounds mentioned in the bug would be preferable to using a snapshot version. Neophyte developers use the generated code as a blueprint for best practices. This is sending the message that it's acceptable to use snapshots in production-quality code, which subverts the whole purpose of using a build system like Maven which is to have reproducible builds.

More directly, code generated by Netbeans should be (and is assumed to be) production quality, and production quality code should not use snapshot versions.
Comment 12 Sergey Petrov 2013-07-03 15:59:23 UTC
What other workarounds do you mean?
I don't  see usage of downloaded jars as valid workaround for maven projects.
Also it's unclear what "Short-term the modelgen jar could be used with the signed core and jpa bundles for  pre-pocessing." means but it seems to be suggestion to use another jars combination instead of eclipselinlk+modelgen. It's not perfect also.
Comment 13 athompson 2013-07-03 16:05:10 UTC
...especially since using a snapshot version requires using a separate repository, which makes the POM more complex than it needs to be, creates the situation where one doesn't know which repository a dependency is coming from, and causes all of the other issues mentioned here.
Comment 14 athompson 2013-07-03 16:14:55 UTC
(In reply to comment #12)
> What other workarounds do you mean?
> I don't  see usage of downloaded jars as valid workaround for maven projects.
> Also it's unclear what "Short-term the modelgen jar could be used with the
> signed core and jpa bundles for  pre-pocessing." means but it seems to be
> suggestion to use another jars combination instead of eclipselinlk+modelgen.
> It's not perfect also.

What I took it to mean is just to create a new artifact which contains an unsigned version of the affected class file, and include it as a dependency as well. It's a bit kludgey since it relies on Maven adding one jar to the class path before another, and the JDK/JVM respecting that classpath order though.
Comment 15 Sergey Petrov 2013-07-03 16:27:26 UTC
having in mind it's possible to use central with release artifacts, it's one more point to update to 2.5.1 as soon as possible, in my opinion it should fit in 7.4 schedule. As it's a bit late to do in 7.3.1, 7.4 can use 2.5.1 instead of others workarounds.
Comment 16 Sergey Petrov 2013-07-03 16:30:44 UTC
latest suggested wa is far away from general libraries handling by nb. it's much better to change artifacts list to core+jpa bundle+modelgen, but it affect ant also if we want to match ant/maven and affect later management, so I prefer to wait for 2.5.1 in 7.4 schedule
Comment 17 athompson 2013-07-03 18:12:46 UTC
(In reply to comment #15)
> having in mind it's possible to use central with release artifacts, it's one
> more point to update to 2.5.1 as soon as possible, in my opinion it should fit
> in 7.4 schedule. As it's a bit late to do in 7.3.1, 7.4 can use 2.5.1 instead
> of others workarounds.

That's fine by me. It also may be a good reason to push out a patch to 7.3 after 2.5.1 is released.

Since my main issue is that learning programmers will often interpret the generated code as a "best practice", you may also want to note in any tutorials the reason for the use of a snapshot version, and that one normally shouldn't use them in production code. A small 7.3 plugin update which simply adds a similar comment to generated code may also be a good idea.
Comment 18 Sergey Petrov 2013-08-01 14:19:48 UTC
2.5.1 may be a bit later but  hope it will fit in 7.4
Comment 19 athompson 2013-08-26 12:41:19 UTC
I still think noting in the comments/tutorials the reason for the snapshot version is a good idea...
Comment 20 Sergey Petrov 2013-08-26 12:46:23 UTC
if 2.5.1 schedule will fail to meet 7.4 target, it may have sense to mention snapshot in release notes. I hope it should be possible, it's a bit late for 7.3.1 to update release notes.
Comment 21 Petr Jiricka 2013-09-05 12:21:33 UTC
Update: it may be too late to update the bundled EclipseLink to the new version (2.5.1) for NetBeans 7.4, but a sufficient fix may be to just update the pom URL and leave the bundled bits as they are. Need to try this out when EL 2.5.1 is out.
Comment 22 Sergey Petrov 2013-09-10 17:28:41 UTC
it may be important to update to 2.5.1 in patch(jars+poms), because of dependencies issue, and also issue 235649, issue 235210
Comment 23 Sergey Petrov 2013-09-11 03:26:43 UTC
waiving, can't update jars too late
Comment 24 athompson 2013-09-18 06:05:08 UTC
2.5.1-RC1 is in the central repository now. That's slightly better than a snapshot and the eclipselink repo can be removed...
Comment 25 Sergey Petrov 2013-09-18 06:19:01 UTC
yes, unfortunately it's still; rc1, and also rc2 is released(but may not be in maven). so it's late for 7.4, for 7.4 some information will be in release notes and also I hope to update to 2.5.1 in 7.4 patch
Comment 26 Sergey Petrov 2013-10-01 16:38:09 UTC
http://hg.netbeans.org/web-main/rev/2503cb719727 2.5.1
Comment 27 Sergey Petrov 2013-11-13 13:32:54 UTC
Can it be verified in trunk?
Comment 28 Stepan Zebra 2013-11-13 13:58:02 UTC
(In reply to Sergey Petrov from comment #27)
> Can it be verified in trunk?

verified, please proceed with integration into release74
Comment 29 Sergey Petrov 2013-11-13 17:31:45 UTC
graft - http://hg.netbeans.org/releases/rev/fee70e933219
(include spec versions update)

long desc http://hg.netbeans.org/releases/rev/e29c4926b6b9