#6525: maven execution should setup LegacySupport before running Maven

[sdedic]

During debugging of #6525, it turned out that during the project read, the execution sometimes avoided the call to setupLegacySupport in our MavenEmebdder before invoking Maven - and when the execution finally reached e.g. NbRepositoryModelResolver.resolveModel, the LegacySupport was already set up by maven core - and by default for online operation.
Futher calls to setupLegacySupport detected an existing session (from Maven) and did not create a NB-compatible setup.

The PR just ensures the LegacySupport is set up prior to maven call, so it is consistent with NB needs.

[mbien]

unfortunately this doesn't solve the issue for me. I am getting the same exception still, following the same steps from the issue. (I use the arrow keys to jump from diff to diff, I could reproduce this twice in a row with fresh config)

[sdedic]

Heh ... good, I'll give it more rounds of testing. Could you possibly test a diagnostic maven patch ? Someone is creating RepositorySession inside maven...

[mbien]

Could you possibly test a diagnostic maven patch ?

sure, no problem

[sdedic]

Hm. So not only unconfigured session. Maven's DefaultLegacySupport contains a thread-local variable that holds the current RepositorySession (through MavenSession). If the "offline" execution happened to be planned on a thread that formerly used "online" embedder, the online session remained in the thread local - and was used instead.

The new commit in this patch replaces the current value with the appropriate one, configured for the executing Embedder; this does not affect other threads (if they use also Maven libraries), as it is replaced in a thread-local variable.

@mbien -- Please test from this PR's branch. There's a Maven patch attached, against maven-3.9.5 tag. As a convenience, I've attached built binaries - to be replaced in java/maven/lib. All that is zipped into the attachment.

maven-patches.zip

[mbien]

ran a quick test and it appears to be working now (no exceptions), it produces a LOT of log output, so i hope that doesn't influence the timing.
I did what I usually did, opened that one commit with the many poms and went with arrow keys though all of them:
legacy-support.log (outdated)

have no time atm for more, but can test again this evening or tomorrow.

[sdedic]

Do not process the log, my bad - I had one more staged change on my local :( sorry ... replaced the last commit. I set up a value in System properties and check it inside maven libs to ensure that the repository session is 'correct'; the actual fix was already there, but the additional check was broken :)

If you can, try the updated branch in the next time slot -- thanks for your time.

[mbien]

log is now clean without thread dumps or exceptions

[mbien]

@sdedic if this is ready to merge, please squash / clean up (remove println) so that we can get this in before freeze.

[sdedic]

Cleaned up

[mbien]

thanks @sdedic!