[mbien]

draft until maven 3.10.1 is released + manual testing

• https://maven.apache.org/docs/3.10.0/release-notes.html
• https://github.com/apache/maven/milestone/130

todo:

• investigate MavenReloadImplementationTest#testUnresolvableArtifactAppears failure
  • caused by NbArtifactFixer assuming the thread doesn't change between collectPlaceholderArtifacts() and resolve()
  • mvn 3.10 uses now multiple threads for dep tree traversal
  • workaround: switch back to single threading via config property. Would be good to fix the cause though.
• investigate user property related tests failures, when embedded, user props are ignored (not reproducible standalone)
  • symptom: failures in
    • NbMavenProjectImplTest#testMavenConfig
    • MavenSourceLevelImplTest#testSystemPropertySourceLevel
    • MicronautPackagingArtifactImplTest#testProjectArtifactOptionalNativeAndAction
  • cause:
    • maven's model interpolation is now more defensive, but this can be switched off again
    • it is unclear though if the guards would influence the IDE itself outside of the tests. E.g overwriting properties via setings.xml profiles is recognized by the IDE even in "restricted mode". Couldn't find a usecase which would be affected by this. (possibly effective pom generator?)
    • opened 3.10.0: Model interpolation does not take property activated profiles into account maven#13347 mostly for clarification purposes
• investigate why local repo indexing is now significantly slower
  • its about 5x slower, have a POC which rewrites ArtifactDependencyIndexCreator without embedder which would resolve this issue but requires regression testing Update bundled maven to 3.10.1 #9642 (comment) (bonus: migrates away from deprecated API)
• paperwork will fail. will update the version occurrences once 3.10 is finalized
• bonus: get rid of more deprecations

[mbien]

local repo scan metrics atm, scanning my current .m2 folder (~500 mb):

    NB 31:
    INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexManager]: Indexing [scan] of local took 14.14s.
    mvn 3.10:
    INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexManager]: Indexing [scan] of local took 62.11s.
    mvn 3.10 wip rewrite without embedder:
    INFO [org.netbeans.modules.maven.indexer.NexusRepositoryIndexManager]: Indexing [scan] of local took 25.48s.

ideally we should verify that NB 31 and rewrite produce the same results, but it appears to work on first glance. Thinking about printing the whole dep list while its indexing to sout and diff it - probably the quickest smoke test.

[mbien]

testProjectArtifactOptionalNativeAndAction in MicronautPackagingArtifactImplTest is also failing.

main difference is the swallowed log line at:

netbeans/enterprise/micronaut/src/org/netbeans/modules/micronaut/maven/MicronautPackagingArtifactsImpl.java

Lines 195 to 197 in 2c328a1

	if (!explicitGraalvmGoal && !MicronautMavenConstants.PACKAGING_NATIVE.equals(model.getPackaging())) {
	LOG.log(Level.FINE, "Unsupported packaging: {0}", model.getPackaging());
	return Collections.emptyList();

the packaging is "jar" but should be "native-image". This could be failing for a similar reason as the user property related failures. The test project pom uses <packaging>${packaging}</packaging> -> which is set by the build action the test is executing.

User properties not being picked up might be the primary cause for the test failures, will take a look at that one first.

property overrides via setting.xml are correctly picked up by the model interpolator already.

[slachiewicz]

Some Maven-side notes, in case they help:

• The -Djava8 profile activation and the interpolation failures have one cause: 3.10 treats any model built below VALIDATION_LEVEL_MAVEN_2_0 as a repository POM, and NetBeans builds projects at MINIMAL. dependencyInterpolation.full only lifts the interpolation half, and globally, including dependency POMs. Details and a proposed Maven fix in 3.10.0: Model interpolation does not take property activated profiles into account maven#13347.
• Single-threaded collection: aether.dependencyCollector.bf.threads=1 in EmbedderFactory.cloneStaticProps() reaches every session the embedder creates (Maven copies system properties into the session config); setUpLegacySupport needs it set explicitly. That also covers Build the Maven dependency tree with Maven Resolver instead of maven-dependency-tree #9694's DependencyTreeFactory.
• ArtifactDependencyIndexCreator: the standalone session is online and has no settings.xml mirrors, proxies or credentials, unlike the offline project embedder it replaces. Taking the RepositorySystem and session from the project embedder would keep both.
• setUpLegacySupport: pass m.isBlocked() instead of false, so the default HTTP blocker mirror applies.

[mbien]

• Single-threaded collection: aether.dependencyCollector.bf.threads=1 in EmbedderFactory.cloneStaticProps() reaches every session the embedder creates (Maven copies system properties into the session config);

To add a little context, this is only needed so that the following call path doesn't fork more threads behind the scenes, since some hacks there use thread local storage for communication between method calls:

MavenProjectCache.loadOriginalMavenProjectInternal() calls NbArtifactFixer.collectPlaceholderArtifacts passing two lambdas as parameter. The first lambda calls projectEmbedder.readProjectWithDependencies() this triggers the downcall from resolver code into NbArtifactFixer.resolve()

For the hack inside NbArtifactFixer to continue working the thread is not allowed to change between collectPlaceholderArtifacts() and resolve(). So if resolver forks, this all breaks since all thread locals are empty.

Everything else can remain multithreaded -> if it doesn't its also fine. Hopefully this can be all cleaned up at some point so that it is maintainable again.

[mbien]

The -Djava8 profile activation and the interpolation failures have one cause: 3.10 treats any model built below VALIDATION_LEVEL_MAVEN_2_0 as a repository POM (....) + apache/maven#13347 (comment)

switched from VALIDATION_LEVEL_MINIMAL to VALIDATION_LEVEL_MAVEN_2_0 and enabled the junit asserts again. Checking CI before continuing.

edit: using VALIDATION_LEVEL_MAVEN_2_0 is going to have other side effects. E.g maven will give up on malformed poms much earlier - which is bad for IDEs. This found some issues in test data. Fixed it + running CI again.

[mbien]

paused until future maven 3.10 point release. We might be able to remove a workaround or two before integration. Since this targets now NB 33 there is no time pressure anymore.

We could get refactorings like #9694 in first since those apply to all versions and can be tested independently.

[mbien]

testing 3.10.1 snapshot with workarounds reverted

looks good. all green.