Quick Run on unit tests for NBM projects is broken. For org.netbeans.modules.autoproject.java.BuildSnifferTest, you get e.g.
java.lang.NullPointerException: Must pass non-null build script
for every test. It seems that FileUtil.toFileObject does not work. Not surprising, because there is no masterfs in the
classpath. I understand that the classpaths will not and should not be identical - Quick Run needs to use build folders
- but there seem to be other substantial differences. I will attach the classpath list for autoproject.java in the good
version (regular Ant test-single) and the bad version (Quick Run) for comparison.
Created attachment 65295 [details]
Created attachment 65296 [details]
The workaround is to never run a unit test without first making some change to a source file. (E.g. insert and delete a
space and then save.) For some reason I do not understand, the Quick Run is not used when there are any edits to main
*** Issue 142028 has been marked as a duplicate of this issue. ***
As another example, S-F6 on AntBasedProjectFactorySingletonTest.java fails unless you add
Even the generated test in New Data Loader fails with Quick Run. Correcting the classpath manually didn't help either -
well, the CPs are not 100% identical yet and there always be at least jars in one and class files in the other, but now
I suspect it's rather another consequence of the problem than the cause of it.
Also if repository and filesystem initialization code is stepped through rather than run, the test passes (at least for
me), maybe a race condition...? I'm not sure if this two-fold approach will ever be maintainable :(.
Oops, forget the last paragraph, stepping through the test works since it doesn't use Quick Run.
Looks there are two separate problems to be addressed:
1) System FS is empty because org.openide.filesystems.ExternalUtil.MainFS#MainFS() uses manifests to find XML layer
files, but the manifests for NB modules are not available during Quick Run. Looks like Quick Run will have to add
manifests manually (probably under build/classes?). Any other ideas how to find XML layers?
2) And there are the missing CP entries mentioned above. I investigate that now.
Ouch, I forgot about manifests. Yes, some code in NB expects to find META-INF/MANIFEST.MF resources corresponding to
modules, with at least OpenIDE-Module-Layer entries. MainImpl also looks for OpenIDE-Module-Build-Version but I think
this is not critical, and probably would never be run from a unit test anyway.
Copying manifest.mf to build/classes/META-INF/MANIFEST.MF is unsafe since 'ant jar' would then pick it up before it has
been given the proper dynamic substitutions from project.xml and elsewhere (OpenIDE-Module-Public-Packages etc. etc.).
I might suggest disabling Quick Run in NBM projects for 6.5; I think it will be difficult to make it really work
consistently with the Ant-based tests. There is just a lot of very specific functionality in the build harness that
existing tests may rely on.
re copying manifests: I probably don't understand all possible consequences, but just an idea: what about copying it
into some artificial folder (under 'build' folder) and add it to classpath only for Quick Run?
I'd agree with disabling Quick Run for NBM projects for now, IMHO there is not enough time to check sufficient number of
tests. Who should decide that? And Honzo, how could I turn it off in apisupport projects?
Maybe we could change it from "opt-out" (use CoS by default, disable it by a property) to "opt-in" (do not use CoS by
default, may be enabled using a property)? I will do it if everyone agrees.
Discussed with Tonda, Honzo pls change it to the "opt-in" default you suggested. We'll return to it after 6.5.
Copying manifest.mf to e.g. build/quickrun/META-INF/MANIFEST.MF might be a good solution. Will not help for any code
which expects to find harness-generated attributes (OIDE-M-Build-Version, OIDE-M-Pub-Pkgs etc.) but I think the primary
use case is for code looking for OIDE-M-Layer which is staticly present in manifest.mf.
Agreed that opt-in for Quick Run tests in NBM projects is probably best for 6.5; we can change it back to opt-out when
we have resolved the major problems.
Well, the opt-in makes it lower priority, but the problems with Quick Run enabled still need fixing.
Integrated into 'main-golden', available in build *200808030201* on http://bits.netbeans.org/dev/nightly/
User: Jan Lahoda <firstname.lastname@example.org>
Log: #141246: making the quick-run enabled only if the user explicitely requests it.
Now have annotation processing, an important step.
Need to get resources generated by APs in the CoS classpath, which I think java.source does not do yet.