[MNG-8254] Fix registration of DI-powered beans

[jonasrutishauser]

JIRA issue: https://issues.apache.org/jira/browse/MNG-8254
IT PR: apache/maven-integration-testing#358

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

[gnodet]

@jonasrutishauser the changes cause stack overflow errors:

Caused by: java.lang.StackOverflowError
	at java.base/java.lang.ReflectiveOperationException.<init>(ReflectiveOperationException.java:90)
	at java.base/java.lang.reflect.InvocationTargetException.<init>(InvocationTargetException.java:67)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)
	at jdk.proxy2/jdk.proxy2.$Proxy104.provides(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)
	at jdk.proxy2/jdk.proxy2.$Proxy104.provides(Unknown Source)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at com.google.inject.internal.DelegatingInvocationHandler.invoke(DelegatingInvocationHandler.java:50)

[jonasrutishauser]

There are a lot of changes regarding DI now on the master branch which cause this stack overflow.
I have to check again and see what is the current state.

[gnodet]

There are a lot of changes regarding DI now on the master branch which cause this stack overflow. I have to check again and see what is the current state.

I'm actually looking into the SisuBridge, so give me some the day to look at it...

[gnodet]

There are a lot of changes regarding DI now on the master branch which cause this stack overflow. I have to check again and see what is the current state.

I'm actually looking into the SisuBridge, so give me some the day to look at it...

This may be fixed with #1722

[jonasrutishauser]

I found the problem.

I'm not sure why the interfaces are registered in org.apache.maven.di.impl.InjectorImpl.bindImplicit() but I filter them out in the Sisu registration.

[gnodet]

@jonasrutishauser could have another look at the master branch, now that #1722 has been merged ?

Also, what's your use case for providing an alternative ModelBuilder ? I do intend to push more into the builder (and less in the project builder, see #1700), so it may become a bit complex, but maybe we can offer more SPI here ?

[jonasrutishauser]

@jonasrutishauser could have another look at the master branch, now that #1722 has been merged ?

I think my problem was resolved when I tested after your merge (with the current master branch my test will no longer work as there are to many changes in project building).

Also, what's your use case for providing an alternative ModelBuilder ? I do intend to push more into the builder (and less in the project builder, see #1700), so it may become a bit complex, but maybe we can offer more SPI here ?

Our use case is that we want to add additional subprojects using an extension maven plugin.
We have a code generate which generates several maven modules from a source file in a company specific dsl.

This was possible with maven 3 as most objects where mutable and by implementing AbstractMavenLifecycleParticipant.afterProjectsRead() which updates the project list in the maven session.

If I look at the current master branch there is a comment which would cover our use case:

maven/maven-api-impl/src/main/java/org/apache/maven/internal/impl/model/DefaultModelBuilder.java

Lines 1351 to 1357 in 5207475

	// subprojects discovery
	if (getSubprojects(model).isEmpty()
	// only discover subprojects if POM > 4.0.0
	&& !MODEL_VERSION_4_0_0.equals(model.getModelVersion())
	// and if packaging is POM (we check type, but the session is not yet available,
	// we would require the project realm if we want to support extensions
	&& Type.POM.equals(model.getPackaging())) {

[gnodet]

@jonasrutishauser could have another look at the master branch, now that #1722 has been merged ?

I think my problem was resolved when I tested after your merge (with the current master branch my test will no longer work as there are to many changes in project building).

Also, what's your use case for providing an alternative ModelBuilder ? I do intend to push more into the builder (and less in the project builder, see #1700), so it may become a bit complex, but maybe we can offer more SPI here ?

Our use case is that we want to add additional subprojects using an extension maven plugin.

We have a code generate which generates several maven modules from a source file in a company specific dsl.

This was possible with maven 3 as most objects where mutable and by implementing AbstractMavenLifecycleParticipant.afterProjectsRead() which updates the project list in the maven session.

If I look at the current master branch there is a comment which would cover our use case:

maven/maven-api-impl/src/main/java/org/apache/maven/internal/impl/model/DefaultModelBuilder.java

Lines 1351 to 1357 in 5207475

	// subprojects discovery
	if (getSubprojects(model).isEmpty()
	// only discover subprojects if POM > 4.0.0
	&& !MODEL_VERSION_4_0_0.equals(model.getModelVersion())
	// and if packaging is POM (we check type, but the session is not yet available,
	// we would require the project realm if we want to support extensions
	&& Type.POM.equals(model.getPackaging())) {

Right, if you generate files on the fly, that will work. But you still need a way to call your code, so maybe a better alternative would be to register a ModelTransformer, as those are called before validating the file, raw and effective models, and allow changing the models at those points.

[gnodet]

Duplicates MNG-8220 and #1683