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.
Product Version = NetBeans IDE Dev (Build 20140414-18a1c1d2d22e) Operating System = Linux version 3.11.0-19-generic running on amd64 Java; VM; Vendor = 1.7.0_51 Runtime = Java HotSpot(TM) 64-Bit Server VM 24.51-b03 I have a unit test in a Maven project which I am trying to run repeatedly after making minor edits to sources and/or tests. Compile-on-Save mode is enabled, which is good because it skips most of the setup in the Maven process. Yet something like 20-30s elapse from the time when I press Ctrl-F6 to when “Scanning for projects...” actually appears in the Output Window! Some time elapses, then a wait cursor appears, then the wait cursor disappears and a process appears in the process list, and then eventually the Output Window opens and finally Maven starts running. A profiler snapshot shows that BeanRunConfig.getMavenProject is called twice—from CosChecker, and from JUnitOutputListenerProvider—and each time it calls NbMavenProjectImpl.loadMavenProject (even though the code would lead you to believe this value is cached), and each call takes around 9s! Since I am not setting any special properties (besides -Dtest=…) or profiles, it seems gratuitous to be doing a quite expensive recalculation of the project model (twice) every time.
Created attachment 146812 [details] .npss file attached from NetBeans .npss file
as part of issue 168036, we've replaced EmbedderFactory.getOnlineEmbedder() with createProjectLikeEmbedder(). Please note that we're not reusing the project embedder but creating a new one which has a significant container initialization penalty. As far as I can tell, since maven 3.0.x, the problems of issue 168036 should not be present and reusing the existing embedder container should be safe.
the two loadings of MavenProject are caused by subsequent calls to RunConfig.getMavenProject(). Unfortunately on different instances. Once on Runconfig passed to RunUtils.*, that instance is later "cloned" (an inheriting most properties from parent/source is used) in MavenCommandLineExecutor.run(). Unfortunately copying the MavenProject mp field from parent to clone doesn't fix the issue as multiple checkers set properties on the clone or original thus resetting the mp field. With the assumption that changed profiles/properties invalidate the model. How far the assumption is correct in these cases remains to be examined. However with the right combination of getMavenProject() + setProperty() calls, we could end up with more than the observed 2 reloads.
http://hg.netbeans.org/core-main/rev/b2d38ca6e540 please test with your project.
Integrated into 'main-silver', will be available in build *201404230001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/b2d38ca6e540 User: Milos Kleint <mkleint@netbeans.org> Log: #243897 reuse project embedder, don't recreate. Also within MavenCommandLIneExecutor reuse the already loaded MavenProject instances, don't reset on property/profile change to prevent multiple loadings right before the build is executed.
Much better.
Still seeing a significant delay in 20140630-368fe2537540, though perhaps not as long as before. CosChecker.checkRunConfig is still triggering a call to loadMavenProject.
Created attachment 147918 [details] .npss file attached from NetBeans .npss file
(In reply to Jesse Glick from comment #7) > Still seeing a significant delay in 20140630-368fe2537540, though perhaps > not as long as before. CosChecker.checkRunConfig is still triggering a call > to loadMavenProject. Yes, but there should be only one such call. And that's correct AFAIK. The model for execution can differ from the one for loading (different profiles, properties) and the pre-build checkers need the correct thing to act upon.
Unfortunately we are paying this price all the time even though it is rare for the aspects of the model which CosChecker would care about to actually be modified by things set in the run config (typically just -Dtest=…).
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss
Still valid in 8.2 dev Product Version: NetBeans IDE Dev (Build 201607100002)
FWIW I have not seen this recently.