Note that if Compile on Save is disabled for the particular module with the layer.xml file in it, the problem goes away. Also note that the problem is not specific to branding modules.

Yet another addition to the instructions I gave to reproduce the bug: if the layer file is empty, a unit test will fail saying it's inefficient to have an empty layer file. Here's the layer file I used:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE filesystem PUBLIC "-//NetBeans//DTD Filesystem 1.2//EN" "http://www.netbeans.org/dtds/filesystem-1_2.dtd">
<filesystem>
    <folder name="Menu">
        <folder name="Tools">
            <file name="LibrariesCustomizerAction.shadow_hidden"/>
        </folder>
    </folder>
</filesystem>

jtulach: could this be related to -J-Dnetbeans.patches.CNB=<path> property that we use in Compile on Save mode?
We set <path> to ${basedir}/target/classes which will not only contain class files but also all the resources, including layers etc.

reassigning to module system

Making this P2.  Check out the sources to https://imagine.java.net/ - it built before, now you have to open almost all of the child projects and disable compile-on-save on each one to make it runnable.  Quite the regression.

Oddly, this is a problem even after a clean-and-build cycle on the parent project.  Does compile-on-save interfere even with that?

The assertion error is eliminated by ergonomics#d73e6477f7c4 

However I had a problem with relative paths. Had to comment out:

--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -158,7 +158,7 @@
     private String projectToOutputDir(Project p, File basedir) {
         //attempt to resolve a relative path to save space on the cmd line..
         File f = new File(new File(FileUtil.toFile(p.getProjectDirectory()), "target"), "classes");
-        String toRet = FileUtilities.relativizeFile(basedir, f);
+        String toRet = null;//FileUtilities.relativizeFile(basedir, f);
         if (toRet == null) {
             toRet = f.getAbsolutePath();
         }

in CoSApplicationLateBoundChecker. Passing back to Maven.

the problem with relative path is caused by fix for issue 231276. Apparently current directory of the running app is different on different OS. To see if -J-Dnetbeans.patches.CNB=<path> property is working (meaning if CoS is working) check in the output  of the app if the following line is present for your modules:

INFO [org.netbeans.core.startup.NbEvents]: Module patch or custom extension: /private/var/folders/46/zjq4yb7j4ml8gr6bkkfl94gm0000gn/T/mavenproject6/application/../mavenproject6-sample/target/classes


musilt2: can we have this tested on all the supported platforms? (currently on windows uses relative path but still)

http://hg.netbeans.org/core-main/rev/2a8ea251269d

jtulach: I suppose we can mark the issue as fixed?

> jtulach: I suppose we can mark the issue as fixed?

Yes, I believe the assert error problem is fixed now.

Integrated into 'main-silver', will be available in build *201307102300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/2a8ea251269d
User: Milos Kleint <mkleint@netbeans.org>
Log: #229353, #231276 use relative path to output dir on windows only, different OS have different current directory when running

I just tried the latest development build--the bug is fixed indeed on my MacOS installation. A build that threw the error on the previous NetBeans Dev version worked fine once I installed the new one.

Thanks, guys! Compile-on-Save for maven-based module projects has been a huge timesaver for me.

Hmm, the fix removed the build error, but now I'm getting an exception every time I try to edit or browse a layer file node: http://statistics.netbeans.org/analytics/exception.do?id=680979

The exception is confirmed on MacOS with NB build 201307122300, when creating a fresh new Maven-based platform application and adding/viewing a layer file to a module (e.g. the branding module).

that appears unrelated to the problem in this issue

(In reply to comment #11)
> Hmm, the fix removed the build error, but now I'm getting an exception every
> time I try to edit or browse a layer file node:
> http://statistics.netbeans.org/analytics/exception.do?id=680979
> 
> The exception is confirmed on MacOS with NB build 201307122300, when creating a
> fresh new Maven-based platform application and adding/viewing a layer file to a
> module (e.g. the branding module).

Integrated into 'main-silver', will be available in build *201307162300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/d73e6477f7c4
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #229353: In case of using patches, take just the first layer, and go on without raising any errors