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.

Bug 141246 - Quick Run does not work on NBM project unit tests
Summary: Quick Run does not work on NBM project unit tests
Status: REOPENED
Alias: None
Product: apisupport
Classification: Unclassified
Component: Project (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker with 1 vote (vote)
Assignee: Martin Kozeny
URL:
Keywords: REGRESSION
Depends on: 111294
Blocks: 142763
  Show dependency tree
 
Reported: 2008-07-22 23:58 UTC by Jesse Glick
Modified: 2013-02-14 13:18 UTC (History)
5 users (show)

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments
Working CP (6.12 KB, text/plain)
2008-07-22 23:58 UTC, Jesse Glick
Details
Broken CP (2.52 KB, text/plain)
2008-07-22 23:59 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
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 1 Jesse Glick 2008-07-22 23:58:56 UTC
Created attachment 65295 [details]
Working CP
Comment 2 Jesse Glick 2008-07-22 23:59:05 UTC
Created attachment 65296 [details]
Broken CP
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 14 Jan Lahoda 2008-08-02 13:40:56 UTC
Done:
http://hg.netbeans.org/main/rev/171cfde69ddb
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 <jlahoda@netbeans.org>
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.