This is the Maven-specific part of the overall JPA metamodel generation problem, that is filed as bug 178108. Metamodel should be generated for Maven projects, too. Bug 188108 already contains some initial discussion related to Maven, the workaround, the possible solution, its advantages and disadvantages see:
solution: http://netbeans.org/bugzilla/show_bug.cgi?id=178108#c27 and the following comments.
maven projects may need to have the same annotation processors support as j2se/ant jee projects, then ther should be no problem with metamodel generation, or maven issue may be fixed in a way specific for this issue only, may be as suggested in the link below.
Created attachment 95052 [details]
Initial (controversial) patch.
I am attaching an initial patch that partially implements the approach outlined here:
http://netbeans.org/bugzilla/show_bug.cgi?id=178108#c27 (parts 1 and 2).
However, as pointed out by Milos Kleint in that issue, the dependency on the Google code repository is rather dangerous. Also, the "correct" approach would be to use the maven-compiler-plugin directly, once it properly supports annotation processors - currently it does not. So this patch is a short-term workaround at best.
One other problem is that the original workaround described in bug 178108 is not sufficient any more, after the addition of the jpa-modelgen jar file to the EclipseLink library: http://hg.netbeans.org/main-silver/rev/56c1e7b71626
The problem is that a project containing tests can not be built anymore, because the processor plugin will try to generate the metamodel also for tests, and will look for persistence.xml in test sources, where it does not exist:
Caused by: java.lang.RuntimeException: Unable to load persistence.xml : /Users/petrjiricka/NetBeansProjects/mavenproject13/target/test-classes/META-INF/persistence.xml (No such file or directory)
To work around that, I guess one would need to set up the maven-processor-plugin plugin also for the generate-test-sources phase.
> maven projects may need to have the same annotation processors support as
> j2se/ant jee projects
The "build" part will definitely be different. For the editor part, hopefully a lot can be reused.
Integrated into 'main-golden', will be available in build *201003170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Log: #180767, #181861 - partial fix for the dependency ordering aspect. Making sure that new libraries are added before the Java EE API stub jar files, so the stub classes are overridden on the compilation classpath.
maven-compiler-plugin version 2.2 was released recently, and it makes things work a bit better (I was testing with a plain Java SE project). Still, you can not just simply replace the compiler version with 2.2, because if the project has some tests, the processor will try to find persistence.xml in test sources, and fail. So if test sources do not have persistence.xml, the plugin has to be configured so processors are run during sources compilation, but not during test sources compilation:
This is still not quite clean, because what if the test sources do contain some other processor that you *do* want to run? This is similar to NetBeans bug 184372, which discusses the same issue for Maven-based APIsupport projects.
Also, the following Maven bug is related:
and contains useful discussion + workarounds etc.
Also NetBeans bug 184378 is related (analogous to this problem, but for Ant projects).
Some relevant links that should have been included in this report from the beginning:
http://wiki.eclipse.org/UserGuide/JPA/Using_the_Canonical_Model_Generator_(ELUG) - description of the generator
http://blog.gueck.com/2009/12/generating-jpa-20-criteria-canonical.html - blog describing how to make it work with Maven
> if the project has some tests, the processor will try to find persistence.xml in test sources, and fail.
This problem has now been fixed on the EclipseLink side in 2.0.3 and 2.1 development codelines. So it is now possible to fully make this work. Here are the instructions on how to configure metamodel generation with Maven:
Configuring and using within Maven
Use the following proceduce to configure the metamodel generation with Maven:
1. Use EclipseLink version 2.1.0-SNAPSHOT. Versions prior to this do not work well in some situations.
2. Add the modelgen jar to your project's dependencies.
3. Use maven-compiler-plugin version 2.2. Earlier versions do not work.
4. Make sure java source version is set to 1.6
Maven pom file example:
Declaring maven-compiler-plugin in the plugins section:
Declaring the EclipseLink Maven repository in the repositories section:
<name>Repository for library EclipseLink</name>
Declaring dependencies on the EclipseLink artefacts:
1 and 2 can be done on persistence side and I hope should work the same in ant and in maven.
4. for is user actions dependent and in my opinion should be controlled by users manually.
3. how I enforce usage of proper maven-compiler-plugin?
1 and 2 - agree.
4 - agree. And we already have a warning in place if the user has source level <1.6 (bug 181531).
3 - I don't think we should enforce it, but we should encourage it - for example by changing the default. For EE projects, there are archetypes which are used as templates for new projects: http://repository.codehaus.org/org/codehaus/mojo/archetypes/. Maybe we can update these archetypes to use a newer version of the maven-compiler-plugin?
For Java SE project I am not sure, because we don't control the archetypes. But Java SE may not be such a high priority.
Generating Canonical MetaModel classes in OpenJPA 2.0 (final)
Regarding item 3 - cc'ing Dafe as the owner of the Maven archetypes. Dafe, would you please release an updated version of the EE 6 archetypes?
All references to maven-compiler-plugin 2.0.2 need to be replaced with version 2.3. Thanks.
Yes I will, I just need to check the versions and decide on releasing strategy. Would you need any other updates to the archetypes, probably? I would like to assure that this will be the last update in 6.9 time frame, as I need to align with Maven release rules. Please check on your side, thank you.
Btw did you test with pom.xml modified to 2.3 version of compiler plugin? Just to be sure...
> Would you need any other updates to the archetypes, probably?
I am not aware of any other pending changes needed by NB 6.9.
> Btw did you test with pom.xml modified to 2.3 version of compiler plugin?
Not yet, will do.
I verified that version 2.3 of the compiler works, for both JavaSE project and Web project.
OK, great. I will release on Monday along with other Maven related releases.
Created attachment 99669 [details]
Patch for EclipseLink lib and Maven handling of processor classpath
I am trying now with trunk version, which already uses EclipseLink 2.1 RC1, which should eliminate manual steps 1 and 2 from comment #8. But there are still problems:
- EclipseLink library incorrectly declares the processor jar file - it should refer to org.eclipse.persistence.jpa.modelgen.processor, not org.eclipse.persistence.jpa.modelgen.
- For web projects, EclipseLink needs to be added to the processor classpath (for Java SE projects, EL is already in the compilation classpath, so this is not a problem). The Maven project currently does not handle processor classpath - it needs to be modified.
I am attaching a patch that fixes these two problems. Sergey and Dafe, can you please review it? Thanks.
thanks for resource fix, I see you introduce processor path usage, but I see no changes related to properties ui and processor path configuration, is it expected?
You are right, there is no UI, which creates inconsistency with Ant projects - thanks for raising this point.
What would the UI look like? I think the minimal possible UI is an enable/disable checbox. On the other hand, I think in Maven, having the UI is less critical than in Ant, because it is very easy to disable the processor e.g. by adding
to the compiler plugin. Also other configuration changes can be done easily by manually editing the pom file. So I think the UI does not need to be a part of this change, but we should create a separate issue to track it. The editing support (code completion etc.) is not implemented, so that too should be tracked separately. What do you think (both Sergey and Dafe)?
I'm not so good with maven, so only basic overview of your changeset was done.
If I got it right only services regstration of ap will work with your changet without ability to specify specific classes as in ant project, isn't it?
Regarding manual editing of pom, in ant based project it also possible to add proc:none to additional compiler options but also there is checkbox. Also ui related issue is where user will see processor classpath dependencies. But it can be a separate issue.
From Maven sources point of view, fix is fine, no complaints.
On UI side, I don't know the domain enough to be able to give an idea. Generally, our goal is to build Maven UI the same as Ant support UI where it is possible. But at the same time, there are several places where Maven supports lacks UI compared to Ant support. Such issues are typically tracked as Enh/Defects for future work.
Integrated into 'main-golden', will be available in build *201006160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Log: #181861 - metamodel generation for JPA entities in Maven projects. Correcting the URL of the EclipseLink modelgen pom, and adding support for processor path to Maven classpath modifier.
Another partial fix: http://hg.netbeans.org/web-main/rev/2ed67a731a07
Completely eliminates the need for manual step 2 from comment #8.
I also filed a new enhancement 187648 for the UI, and there is already a bug 184952 filed for the editing aspect (code completion etc).
Completely fixed by Dafe: http://hg.netbeans.org/main-silver/rev/60caac6793cc
I.e. the Maven archetypes for EE projects were updated to use version 2.3.1 of the compiler plugin.
Integrated into 'main-golden', will be available in build *201006300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Dafe Simonek <email@example.com>
Log: #181861, #186223 - update of archetype versions to newly releases archetypes that are addressing issues
This no longer works - the modelgen jar is not added to the dependencies now.
The workaround is to add the following to the pom:
Sergey, can you please fix?
next fix http://hg.netbeans.org/main-silver?cmd=changeset;node=a97a55355cff
may be related
You are right, I was trying an old build. In the latest build it works fine.