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.
NB 7.0 copies persistence.xml to build/test/classes/META-INF/persistence.xml Another dependent project fails if it depends on build/test/classes of the main project and if it has its own persistence unit with the same name. This was not the case with NB 6.9, where build/test/classes/META-INF is not created. My use case is a project that performs database initialisation for a main project that it depends on. It depends on some test classes that are useful in both projects. I don't know how to resolve this in a clean way. The error stops the build of the initialization project: Caused by: Exception [EclipseLink-30017] (Eclipse Persistence Services - 2.2.0.v20101020-r8375): org.eclipse.persistence.exceptions.PersistenceUnitLoadingException Exception Description: Persistence unit blabla is defined in both URL:file:blabla/build/test/classes/ and URL:blabla/build/web/WEB-INF/classes/. Cannot have several persistence units with the same name loaded by the same classloader. at org.eclipse.persistence.exceptions.PersistenceUnitLoadingException.persistenceUnitNameAlreadyInUse(PersistenceUnitLoadingException.java:210) at org.eclipse.persistence.internal.jpa.deployment.JavaSECMPInitializer.initPersistenceUnits(JavaSECMPInitializer.java:258) at org.eclipse.persistence.internal.jpa.deployment.JavaSECMPInitializer.initialize(JavaSECMPInitializer.java:218) at org.eclipse.persistence.internal.jpa.deployment.JavaSECMPInitializer.initializeFromAgent(JavaSECMPInitializer.java:160) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) FATAL ERROR in native method: processing of -javaagent failed at org.eclipse.persistence.internal.jpa.deployment.JavaSECMPInitializerAgent.initializeFromAgent(JavaSECMPInitializerAgent.java:47) at org.eclipse.persistence.internal.jpa.deployment.JavaSECMPInitializerAgent.premain(JavaSECMPInitializerAgent.java:39) ... 6 more Exception in thread "main" Java Result: 1 In the initialization project, which is a plain Java app, I am using VM option -javaagent:blabla\eclipselink-2.2.0.jar -Xms512M -Xmx1G
The persistence units in the different projects do actually have different names. The problem appears to be that the main project's test classes depend on the main project's classes, and the clash is between the PU in the test classes and the main classes of the same main project, only if it is used by another project. The problem disappears if I delete the PU from the test classes dir.
As far as I know only single persistence.xml with given PU can be on the CP. The exception from eclipse link complains about 2 such files URL:file:blabla/build/test/classes/ and URL:blabla/build/web/WEB-INF/classes/. It's obvious that the unit test folder depends on the sources as it test them. Probably wantfix. You can remove the dependency among src and unit test sources in the project customizer (in the Libraries/Compile Tests remove the Compiled Sources).
Thanks very much Thomas. I tried your suggestion but NetBeans won't let me do it - "remove the dependency among src and unit test sources in the project customizer (in the Libraries/Compile Tests remove the Compiled Sources)" - the remove button is disabled. Besides I would not know how to restore this option, and what other features I would lose. Please let me re-phrase the issue. In NB 7.0, the PU of the main project is copied to the test classes of the main project. This did not happen in NB 6.9. The dependent project only needs the classes of the main project, including its test classes. It does not want any of both the conflicting PUs because it has its own PU with a different name. The other duplicated PU is useless in the context. Why should a PU from library resources be on the CP anyway? It is a configuration that should not be shared. May be the answer is in the fact that the tests run without this error even though they depend on the main classes which have their own PU with the same name. Why is that possible, and at the same time it is not possible that a dependent project does the same thing (having both main antd test classes in the CP)? It would be cleaner if even the test classes of the same project had no visibility of the persistence.xml of the main classes. In my case, I created a test PU in the main persistence.xml, but I would be just as happy to create a separate persistence.xml for the test classes. Would be much cleaner.
regarding visibility. nb do not recognize pu from archives but persistence support pu from archives so you can share it. and as I remember some users use single pu configuration (persistence.xml) for both - main classes and test classes. It still worth to look if the issue can be resolved.
Sergey, I agree with you - in fact I am also doing this. But please, please, don't copy persistence.xml, ever. I want to keep testing netbeans dev builds, while I am working, but I can't do that because of this bug. The sooner it is fixed the better.
may be related to issue 181459. Can you provide sample project?
also it's related https://bugs.eclipse.org/bugs/show_bug.cgi?id=302450 if there are some entities in 'tests' to process entities it's required to have persistence.xml, but it may not be necessary, at least it can be known limitation to have processed entities in main sources only but it requires more investigation.
there is easy workaround seems to work for me, you can disable compile on save in project properties for affected projects (i.e. project with extra persistence.xml in test/classes).
Created attachment 105267 [details] Testcase Thanks for the kind suggestion. If I try the suggested solution to disable compile on save, then I am hitting another bug 194605. Then I cannot build the project anymore and I can't find a way out of this at all. Part of the issue seems to be the VM argument of the J2SE project: -javaagent:"C:\Program Files\NetBeans Dev 201101190000\java\modules\ext\eclipselink\eclipselink-2.2.0.jar" -Xms512M -Xmx1G The testcase relies on a eclipselink-2.2.0 library that I created. The issue does not exist in NetBeans 6.9. To run this testcase, please deploy the web app first, then test ServletServiceTest (will fail) and then run the J2SE app, then test again. For me it makes a lot of sense to re-use code from test classes in an initialization module - the test classes are the primary assets that should be maintained properly. I have not yet added the VM options in the web project for running the test classes which I think I must do to match the behavior of the GlassFish container.
this another issue doesn't seems to be real issue, as it's just nb do not handle automatically case of multiple pu for same classes. still trying to find out how to avoid persistence.xml copy as I see there is not reason to copy, anyway no metamodel classes are generated for entities in tests and nothing else.
hope it works with this fix http://hg.netbeans.org/web-main/rev/ce2032b6dba7 please test after a few days, but you may need to remove netbeans cach from netbeans home, or recreate your project (to get fresh cache for sources). Old cache will cause problems as it may contain already copied persistence.xml
Integrated into 'main-golden', will be available in build *201101250001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/ce2032b6dba7 User: Sergey B. Petrov <sj-nb@netbeans.org> Log: #193828 - prevent copy persistence.xml to tests root cache
Sergey, Thank you very much! We are very pleased with the professional response of the NetBeans team - as usual. Enterprise Java support is great.