sdedic opened a new pull request, #5998: URL: https://github.com/apache/netbeans/pull/5998
First of all, `log4j` is not a good example. The project is set up in a way that **requires** that JDK8 is **on the PATH** while maven `toolchains.xml` define JDK 9+. The project will not compile if (e.g.) JDK11 is on PATH or JDK8 is defined in toolchains. But the example surfaced several interesting things. Most importantly, maven processes for the parent *and subprojects* are launched in parallel. In reality, parent priming build is most likely to fetch all artifacts for all projects in the reactor - so running maven for a subproject is not necessary. So it is worth to wait for preceding priming builds to complete before trying another one. Next bug is that, after priming, the problem reporter does not refresh early - so `SanityBuildAction` could not even re-check the project is broken. This PR: - serializes maven priming builds. There will be at most 1 priming build running. It could be relaxed to allow 1 priming build for a reactor; we'll see from how this first change will affect perceived IDE performance. - each priming build first checks, if the _updated_ maven model still reports missing artifacts. If not, it won't execute maven. It may be still reported through Progress API, but at least the costly external process (+ maven project model evaluation) will not happen - an artifact might be reported as missing in the model, when it is, actually downloaded already. If this is detected - when the now-not-missing artifact is going to be reported, the current evaluation restarts. This is attempted 3 times at most so no endless loop should happen. During prototyping, I've tried to avoid Java compilation - since for IDE purposes, only dependencies are important, not correctness of the project's sources. That would allow speedup of the priming process - and also better detection if the priming build fails: currently there's no failure detection, as work-in-progress sources can easily fail "priming" compilation. We would need to only report artifact download failures. Sadly with Maven builtin goals, it does not seem possible - I tried to use `dependency` plugin, but that one treats even intra-reactor dependencies (e.g. snapshots) the same way as external ones and attempts to resolve them from an external repository (instead of the reactor contents). So I reverted back to `install`. There's important peculiarity: while `-SNAPSHOT` projects are `install`ed, nonsnapshot projects are just `package`d. This difference (based on top project) is applied to the whole reactor. In a case where the root project defines a non-snapshot version while the modules are actually snapshot versions, the priming fails. The difference is IMHO negligible - so I made the goals settable through `Preferences` (although this is not exposed in the UI) and `vscode` extension makes an experiment on its users to use `install` for both situations. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
