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: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  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).
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.
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.
Integrated into 'main-silver', will be available in build *201307012300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Sergey B. Petrov <firstname.lastname@example.org>
Log: #232018 do not specify api jar in meven dependency
(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:
(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?
you need to use jdk6+ source level to get all dependencis necessary for a fail, i.e. eclipselik+modelgen.
it may be problem, is there snapshot version in central? I can't see.
(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...
(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.
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.
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.
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.
...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.
(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.
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.
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
(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.
2.5.1 may be a bit later but hope it will fit in 7.4
I still think noting in the comments/tutorials the reason for the snapshot version is a good idea...
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.
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.
it may be important to update to 2.5.1 in patch(jars+poms), because of dependencies issue, and also issue 235649, issue 235210
waiving, can't update jars too late
2.5.1-RC1 is in the central repository now. That's slightly better than a snapshot and the eclipselink repo can be removed...
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
Can it be verified in trunk?
(In reply to Sergey Petrov from comment #27)
> Can it be verified in trunk?
verified, please proceed with integration into release74
graft - http://hg.netbeans.org/releases/rev/fee70e933219
(include spec versions update)
long desc http://hg.netbeans.org/releases/rev/e29c4926b6b9