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.
|Summary:||Quick Run does not work on NBM project unit tests|
|Product:||apisupport||Reporter:||Jesse Glick <jglick>|
|Component:||Project||Assignee:||Martin Kozeny <mkozeny>|
|Severity:||blocker||CC:||anebuzelsky, brucechapman, jlahoda, mkrauskopf, musilt2|
|Issue Type:||ENHANCEMENT||Exception Reporter:|
|Bug Depends on:||111294|
Description Jesse Glick 2008-07-22 23:58:38 UTC
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 at org.netbeans.modules.autoproject.java.BuildSnifferTest.runAnt(BuildSnifferTest.java:197) at org.netbeans.modules.autoproject.java.BuildSnifferTest.testAntRuntimeCP(BuildSnifferTest.java:171) 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.
Comment 3 Jesse Glick 2008-07-23 00:00:18 UTC
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 sources.
Comment 4 rmichalsky 2008-07-29 13:54:16 UTC
*** Issue 142028 has been marked as a duplicate of this issue. ***
Comment 5 Jesse Glick 2008-07-30 20:21:01 UTC
As another example, S-F6 on AntBasedProjectFactorySingletonTest.java fails unless you add quick.test.single=false to project.ant/nbproject/private/private.properties.
Comment 6 rmichalsky 2008-07-31 09:20:01 UTC
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 :(.
Comment 7 rmichalsky 2008-07-31 09:25:34 UTC
Oops, forget the last paragraph, stepping through the test works since it doesn't use Quick Run.
Comment 8 rmichalsky 2008-07-31 13:27:26 UTC
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.
Comment 9 Jesse Glick 2008-07-31 21:16:46 UTC
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.
Comment 10 rmichalsky 2008-08-01 10:31:16 UTC
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?
Comment 11 Jan Lahoda 2008-08-01 10:35:36 UTC
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.
Comment 12 rmichalsky 2008-08-01 11:55:44 UTC
Discussed with Tonda, Honzo pls change it to the "opt-in" default you suggested. We'll return to it after 6.5.
Comment 13 Jesse Glick 2008-08-01 20:02:14 UTC
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.
Comment 15 Jesse Glick 2008-08-02 19:22:23 UTC
Well, the opt-in makes it lower priority, but the problems with Quick Run enabled still need fixing.
Comment 16 Quality Engineering 2008-08-03 03:41:37 UTC
Integrated into 'main-golden', available in build *200808030201* on http://bits.netbeans.org/dev/nightly/ Changeset: http://hg.netbeans.org/main/rev/b83fdf33e5cf User: Jan Lahoda <email@example.com> Log: #141246: making the quick-run enabled only if the user explicitely requests it.
Comment 17 Jesse Glick 2010-01-27 09:29:51 UTC
Now have annotation processing, an important step.
Comment 18 Jesse Glick 2010-03-11 15:17:42 UTC
Need to get resources generated by APs in the CoS classpath, which I think java.source does not do yet.