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.
Please refer to the attached testcase. This appears to happen if in Project Properties|Build|Compiling|Compile on Save is swiched off. This testcase tests a standalone JPA project. Compile on Save must be turned off in JPA projects because of issue 178535 Please note that this project requires in project properties, Run|VM Options, -javaagent:<Your eclipselink distribution>\jlib\eclipselink.jar
Created attachment 110107 [details] Testcase
Another issue that requires turning off Compile on Save: Issue 201937
Caused by persistence CopyResourceIndexer. The problem is that the CRI copies the persistence.xml from src root into cache, then the persistence.xml is copied by CoS to build/classes. The Cos CP.RUNTIME contains both build/classes and src folder because of resources in it. So there are two persistence.xml which define the same PU and eclipse link's java agent fails.
There are two possible solutions: 1st) Special case for the persistence.xml (don't copy it from cache to build folder) 2nd) Don't put the source root to CP.RUNTIME and copy the resources from sources root to build/classes (similarly as the web project is doing). This slows down run a bit. After discussion with Honza L. we decided for second case.
Fixed jet-main 98acb457c727 The run (debug) file now works fine with attached project.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/98acb457c727 User: Tomas Zezula <tzezula@netbeans.org> Log: #201117:Option "Run focused Test", "Debug focused Test" are disabled in JUnit Test
*** Bug 188163 has been marked as a duplicate of this bug. ***
I am confused about the net effect of this change. Does it effectively revert the fix of bug #161085, as bug #188163 comment #8 vaguely implies, or is there now a third policy?
(In reply to comment #8) > I am confused about the net effect of this change. Does it effectively revert > the fix of bug #161085, as bug #188163 comment #8 vaguely implies, or is there > now a third policy? I do not think it reverts the fix for #161085 for the case reported there (although it might break some projects that use CoS in unsupported circumstances, e.g. resource processing in build.xml). Before #161085, when a (J2SE) project was invoked through CoS, it cleared everything from build/classes, put the "correct" classfiles there, and appended "src" to classpath. That way resources could have been loaded through ClassLoaders from the sources. But, the fix done for #161085 started to keep the resources in the build/classes, but did not care to update them when the resource was updated in the source folder. Which lead to various problems with not updated resources. The patch done for this bug fixes that - when a resource is updated in the source folder, it is copied to build/classes as well.