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 181861 - Metamodel generation for JPA entities in Maven projects
Summary: Metamodel generation for JPA entities in Maven projects
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: Maven (show other bugs)
Version: 7.0
Hardware: All All
: P2 normal (vote)
Assignee: Sergey Petrov
URL: http://wiki.eclipse.org/UserGuide/JPA...
Keywords:
Depends on: 187653
Blocks: 178108
  Show dependency tree
 
Reported: 2010-03-11 08:29 UTC by Petr Jiricka
Modified: 2010-09-02 14:58 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Initial (controversial) patch. (11.02 KB, text/plain)
2010-03-11 09:02 UTC, Petr Jiricka
Details
Patch for EclipseLink lib and Maven handling of processor classpath (3.62 KB, text/plain)
2010-05-31 08:00 UTC, Petr Jiricka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Jiricka 2010-03-11 08:29:55 UTC
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.
Comment 1 Sergey Petrov 2010-03-11 08:49:33 UTC
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.
Comment 2 Petr Jiricka 2010-03-11 09:02:55 UTC
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.
Comment 3 Petr Jiricka 2010-03-11 09:06:05 UTC
> 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.
Comment 4 Quality Engineering 2010-03-17 05:15:25 UTC
Integrated into 'main-golden', will be available in build *201003170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/b2d0bd16bf23
User: pjiricka@netbeans.org
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.
Comment 5 Petr Jiricka 2010-04-19 08:05:10 UTC
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:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.2</version>
                <executions>
                    <execution>
                        <id>default-compile</id>
                        <configuration>
                            <source>1.6</source>
                            <target>1.6</target>
                        </configuration>
                    </execution>
                    <execution>
                        <id>default-testCompile</id>
                        <configuration>
                            <compilerArgument>-proc:none</compilerArgument>
                            <source>1.6</source>
                            <target>1.6</target>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

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:
http://jira.codehaus.org/browse/MCOMPILER-97
and contains useful discussion + workarounds etc.
Comment 6 Petr Jiricka 2010-04-19 08:06:34 UTC
Also NetBeans bug 184378 is related (analogous to this problem, but for Ant projects).
Comment 7 Petr Jiricka 2010-04-20 15:34:30 UTC
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
Comment 8 Petr Jiricka 2010-05-03 08:33:16 UTC
> 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:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.2</version>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>

Declaring the EclipseLink Maven repository in the repositories section:

        <repository>
            <url>http://ftp.ing.umu.se/mirror/eclipse/rt/eclipselink/maven.repo</url>
            <id>eclipselink</id>
            <layout>default</layout>
            <name>Repository for library EclipseLink</name>
        </repository>

Declaring dependencies on the EclipseLink artefacts:

        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>eclipselink</artifactId>
            <version>2.1.0-SNAPSHOT</version>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>org.eclipse.persistence.jpa.modelgen.processor</artifactId>
            <version>2.1.0-SNAPSHOT</version>
            <scope>compile</scope>
        </dependency>
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>javax.persistence</artifactId>
            <version>2.0.0</version>
        </dependency>
Comment 9 Sergey Petrov 2010-05-04 15:59:30 UTC
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?
Comment 10 Petr Jiricka 2010-05-04 19:25:48 UTC
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.
Comment 11 rjdkolb 2010-05-10 09:40:57 UTC
add cc
Comment 12 rjdkolb 2010-05-10 11:20:31 UTC
Generating Canonical MetaModel classes in OpenJPA 2.0 (final)

http://openjpa.apache.org/builds/2.0.0/apache-openjpa-2.0.0/docs/manual/ch13s04.html
Comment 13 Petr Jiricka 2010-05-11 12:52:46 UTC
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?
http://repository.codehaus.org/org/codehaus/mojo/archetypes/ear-javaee6/
http://repository.codehaus.org/org/codehaus/mojo/archetypes/ejb-javaee6/
http://repository.codehaus.org/org/codehaus/mojo/archetypes/webapp-javaee6/

All references to maven-compiler-plugin 2.0.2 need to be replaced with version 2.3. Thanks.
Comment 14 David Simonek 2010-05-12 15:10:37 UTC
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...
Comment 15 Petr Jiricka 2010-05-12 15:41:40 UTC
> 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.
Comment 16 Petr Jiricka 2010-05-14 14:59:58 UTC
I verified that version 2.3 of the compiler works, for both JavaSE project and Web project.
Comment 17 David Simonek 2010-05-14 15:38:08 UTC
OK, great. I will release on Monday along with other Maven related releases.
Comment 18 Petr Jiricka 2010-05-31 08:00:53 UTC
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.
Comment 19 Sergey Petrov 2010-05-31 14:03:10 UTC
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?
Comment 20 Petr Jiricka 2010-05-31 14:46:21 UTC
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 
<compilerArgument>-proc:none</compilerArgument>
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)?
Comment 21 Sergey Petrov 2010-06-01 11:58:31 UTC
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.
Comment 22 David Simonek 2010-06-15 13:46:14 UTC
Hi,
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.
Comment 23 Quality Engineering 2010-06-16 03:30:17 UTC
Integrated into 'main-golden', will be available in build *201006160001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/2ed67a731a07
User: pjiricka@netbeans.org
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.
Comment 24 Petr Jiricka 2010-06-16 11:42:20 UTC
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).
Comment 25 Petr Jiricka 2010-06-29 23:18:14 UTC
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.
Comment 26 Quality Engineering 2010-06-30 03:19:34 UTC
Integrated into 'main-golden', will be available in build *201006300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/60caac6793cc
User: Dafe Simonek <dsimonek@netbeans.org>
Log: #181861, #186223 - update of archetype versions to newly releases archetypes that are addressing issues
Comment 27 Petr Jiricka 2010-09-01 21:35:38 UTC
This no longer works - the modelgen jar is not added to the dependencies now.

The workaround is to add the following to the pom:
        <dependency>
            <groupId>org.eclipse.persistence</groupId>
            <artifactId>org.eclipse.persistence.jpa.modelgen</artifactId>
            <version>2.1.0</version>
            <scope>provided</scope>
        </dependency>

Sergey, can you please fix?
Comment 28 Sergey Petrov 2010-09-02 14:08:24 UTC
next fix http://hg.netbeans.org/main-silver?cmd=changeset;node=a97a55355cff
may be related
Comment 29 Petr Jiricka 2010-09-02 14:58:34 UTC
You are right, I was trying an old build. In the latest build it works fine.