Priming build and reload improvements revisited

[sdedic]

This is a reiteration of #6514 early in the release cycle. Includes also NPE fix #6624. For detailed description, see the original issue #6514 - but comment here, please.

[mbien]

nice! I would like to help testing this (local smoke test). To avoid that we test it on the same projects, what testing was already done?

[matthiasblaesing]

For the following I regrettably can't provide numbers, but I think I can trace it back to the changes this is a followup for:

I noticed that NetBeans became to feel sluggish at work (Windows Laptop) when invoking "Run file" in a semi-big maven project and editing the pom.xml. The project is a dropwizard project and pull-in jersey, jetty, jackson, so a not to small number of modules. What I noticed is that the UI froze for a few seconds after each "Run file" invocation. UI freezes indicate something heavy blocking the EDT. Indeed, when you add assert !SwingUtilities.isEventDispatchThread(); to org.netbeans.modules.maven.NbMavenProjectImpl.getFreshOriginalMavenProject() (or a breakpoint there), this is hit when:

• you invoke "Run file"-Method
• you modify the pom.xml and save it

The source is here: MavenProjectNode#getShortDescription

netbeans/java/maven/src/org/netbeans/modules/maven/nodes/MavenProjectNode.java

Line 183 in ca7b58b

Collection<? extends ProjectProblem> problems = project.getLookup().lookup(ProjectProblemsProvider.class).getProblems();

Stacktrace:

java.lang.AssertionError
	at org.netbeans.modules.maven.NbMavenProjectImpl.getFreshOriginalMavenProject(NbMavenProjectImpl.java:479)
	at org.netbeans.modules.maven.problems.MavenModelProblemsProvider.doGetProblems1(MavenModelProblemsProvider.java:165)
	at org.netbeans.modules.maven.problems.MavenModelProblemsProvider.doGetProblems(MavenModelProblemsProvider.java:152)
	at org.netbeans.modules.maven.problems.MavenModelProblemsProvider.getProblems(MavenModelProblemsProvider.java:131)
	at org.netbeans.spi.project.ui.support.UILookupMergerSupport$ProjectProblemsProviderImpl.getProblems(UILookupMergerSupport.java:274)
	at org.netbeans.modules.maven.nodes.MavenProjectNode.getShortDescription(MavenProjectNode.java:183)
	at org.netbeans.modules.maven.nodes.MavenProjectNode$2$1.run(MavenProjectNode.java:92)
	at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
	at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:773)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:720)
	at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:714)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
	at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:742)
	at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:136)
[catch] at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:203)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:124)
	at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:113)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:109)
	at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:90)

The interesting bit is, that doGetProblems1 is called with sync = false in this case. The IMHO correct expectation would be, that the call immediately returns, but getFreshOriginalMavenProject seems to block.

[sdedic]

@matthiasblaesing good catch; even the getFreshOriginalMavenProject must be called async, it blocks naturally, as it waits (should wait) for a pending project load.

[sdedic]

@matthiasblaesing should be addressed in 6c1127f.

@mbien test plan:

• how to break a project: delete it's declared parent from the local repository
• Project > Project Information (BasicInfoPanel) -- both broken and not broken
• issue build on a broken (= with parent not in local repo) project (MavenCommandLineExecutor)
• issue build on a (broken) SUBproject (ReactorChecker)
• attempt to add dependency on a broken project
• attempt to create a new java file within a broken project (CreateProjectBuilder) -- you need to select the broken project's directory in the create dialog.

[lahodaj]

I think the direction is reasonable, although I am not a real expert on this code. Some very minor comments inline.

[sdedic]

Consolidated fixes before merge. If no objections are raised, I'll merge the PR today.

[mbien]

code looks good to me (the new tests did also run in CI this time)

[sdedic]

89faee1 logging fixes folded into the feature commit.

[mbien]

java/maven timed out - it usually doesn't do that
https://github.com/apache/netbeans/actions/runs/7178384394/job/19546924378

restarted job

[sdedic]

Hm ! So far tests run fine on local. So let's add some debugging if it fails again.

[matthiasblaesing]

@matthiasblaesing should be addressed in 6c1127f.

@sdedic thank you for the update. The interactive usage seems to be much better.

But I'm observing another problem now. My dropwizard projects user maven-shade. This in normally causes projects problem to be reported or warning level ("Project's main artifact is processed through maven-shade-plugin"). With the update after the IDE is loaded this warning is no longer there. I can get it back once I make a change to the pom. Then it comes back is reported again.

[matthiasblaesing]

@sdedic ignore my previous comment, it was a wrong observation. It is correct, that the problem report is not there when the project is opened, but that is not a regression as it was the same in NB19 and NB20 (just tested with clean userdir). You have to build the project or interact otherwise to get the problem report.

[sdedic]

@matthiasblaesing it should be sufficient to just "prime" the project - or open it provided that all build plugins + parent POM are in the local repository; otherwise Maven POM parsing fails miserably. But if primed or the artifacts are ready, it should display the error right on open.

[matthiasblaesing]

@sdedic you can test it trivially yourself. What I did was this:

1. Create the test project: mvn -DarchetypeGroupId=io.dropwizard.archetypes -DarchetypeArtifactId=java-simple -DarchetypeVersion=4.0.4 -DarchetypeRepository=https://repo.maven.apache.org/maven2/ -DgroupId=test -DartifactId=test -Dversion=0.1-SNAPSHOT -Dpackage=test.test -Dbasedir=BASEDIR -Dshaded=true -Dname=test -Ddescription=null -Darchetype.interactive=false -DarchetypeCatalog=local --batch-mode org.apache.maven.plugins:maven-archetype-plugin:3.2.1:generate (replace BASEDIR with the directory you want the project to be created in)
2. Fetch a copy of NB20 and start it with a clean user+cachedir bin/netbeans-20/bin/netbeans --userdir x --cachedir x
3. Activate the Java SE cluster
4. Open the project and wait for scanning to be finished: At that point I don't see a warning indicator on the project:
   
5. Choose "Reload POM" and it is there:
   

In step 4 all dependencies were present.

[sdedic]

@matthiasblaesing sorry, was busy on other part of Maven. Can I take it that the current situation is no worse than the with NB <=20 ? If so, I'd suggest to track that as an issue and try to fix it in NB21/22 separately.

[matthiasblaesing]

@matthiasblaesing sorry, was busy on other part of Maven. Can I take it that the current situation is no worse than the with NB <=20 ? If so, I'd suggest to track that as an issue and try to fix it in NB21/22 separately.

Yes, sorry about the wrong observation.

[sdedic]

Rebased onto newest master, will merge as soon as tests pass.