On 18.08.24 13:11, Michael Bien wrote:
On 17.08.24 22:23, Svata Dedic wrote:
For maven, priming was historically implemented as a "Project
Problem" resolving action executing "package" or "install" goals. But
I think this is wrong way: for example, we do not _need_ to install
build plugins. The IDE will not use them -- it will just load the
Maven configuration model. No build plugins (and their dependencies)
-> less download -> less time.
I am not advocating to install everything but at the same time I also
highly doubt that this is the right attribute to optimize for. The
local repo is a cache - lets use the cache. Downloading (missing)
build plugins should not be something NB should worry about - those
are required to build the project.
Lets ask the user if the pom is trusted, then let maven download the
plugins, refresh the project and call it a day.
And optimizing this is still possible, even go-offline can be
configured to ignore transitive dependencies and various other things.
I could even imagine running it in multiple rounds if we want the
first results as early as possible.
lets be less theoretical:
i benchmarked priming a bit (while debugging a mvnd issue) with a single
module maven project. The project was set up to have several netbeans
editor dependencies and uses the nbm-maven-plugin (this ensures that it
can't be easily loaded by NB without building it first).
UX while having "trust project build script" checked on the open-project
window is not ideal right now. The user has to look at the maven log
output until NB finished priming the project - which can take a while.
This could be easily improved by splitting it into a two stage approach:
1) run "mvn validate" (downloads plugins and a few pom dependencies)
2) open/load project (this will work ok now since this allows initial
model creation - this worked for all projects I tried so far)
3) run "mvn compile" (or something comparable)
Validate finished in ~5s, while regular NB priming took ~25s.
("validate" on followup projects would be even faster since the chances
that some of the "core" artifacts overlap is quite high)
-> instant 5x "time-to-project-open" reduction and this uses only
generic maven lifecycle phases (no magic)
(benchmarking nw tasks will always be inaccurate outside of lab setups,
so take it with a grain of salt. Counting downloads or comparing local
repo file size might be a better metric - I did run it twice though)
I personally still prefer the UX of not trusting the script (default)
and then hitting a build goal since this lets me decide on a
case-by-case basis what is needed (tests? recursive? install?). i don't
gain anything by looking at a log while NB does something before I can
run a goal myself.
regarding go-offline:
This could be a candidate for the global-goal-presets
(https://github.com/apache/netbeans/pull/7537). Something to consider
for NB 24+.
best regards,
-mbien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org
For additional commands, e-mail: dev-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
