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.
While checking the behavior of CosChecker, I found a warning that NB-generated classes would be left in target/classes/. This is not true for j2seproject's, and I thought it should not be true for Maven projects either. In fact checkRunConfig calls cleanGeneratedClassfiles for exactly this reason. Unfortunately it does not work - QUICK_CLEAN exits early (in BuildArtifactMapperImpl.clean) when .netbeans_automatic_build is not present. And checkRunConfig specifically deletes this file right before calling cleanGeneratedClassfiles, guaranteeing that it will be a no-op! The obvious patch would just be to move the calls to deleteCoSTimeStamp below the call to cleanGeneratedClassfiles. This works to clean up target/classes/ when BUILD is run after CoS has been used. Unfortunately COSExChecker then _readds_ this file at the end of the build... meaning that if you run BUILD again immediately afterward, which ought to be a quick incremental build, .netbeans_automatic_build and **/*.class get deleted again, so the whole project is recompiled. I would fix this myself if I understood the purpose of COSExChecker but I do not.
what I understood from a chat with jlahoda: the default behaviour is after clean build keep the external build's classes around until Run is triggered, then all extrnally built classfiles are deleted and replaced by IDE's own. A marker is placed into the output directory and any subsequent file save just copies the IDE's class file. The purpose of the COSChecker appears to be to suppress this behaviour and attempt to skip the "delete external, copy all IDE's classfiles" step and always just copy the single class files. That might be because of the resource files we copy on our own..
at least one of the reason why it's like that is to support external CoS dependent things, like jrebel or javeleon
works as intended within the current constraints.
Why not delete the call to cleanGeneratedClassfiles, given that it does nothing in this context?
http://hg.netbeans.org/core-main/rev/5b1815adfcfb
Integrated into 'main-golden', will be available in build *201210120002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/5b1815adfcfb User: Milos Kleint <mkleint@netbeans.org> Log: #209814 comment out noop code and fix handling when project is closed