[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537196#comment-17537196
]
Andreas Loew edited comment on MNG-7475 at 5/15/22 1:24 PM:
------------------------------------------------------------
{color:#00875a}*OK, so the "riddle" is resolved*{color}, and I can give a
partly "{*}{color:#00875a}ALL CLEAR{color}{*}" sign (/), but am still
interested in your recommendations on how we (my customer/my team and myself)
should move forward in the best possible way... :)
First of all, here is a simple stripped-down reproducer project:
[^arquillian-reproducer.zip]
As stated in lines 48 and 49 of its pom.xml, it hurts when the
dependencyManagement section of the reproducer POM - or, in our original
real-world case, a parent POM's properties and dependencyManagement section -
imports "org.apache.maven:maven:pom:3.8.5" as a "compile" or even "test"
dependency. This will, as documented in the comments above, cause the
NoSuchMethodError due to the incompatible change in maven-model-builder public
API between 3.8.4 and 3.8.5... :(
It turned out that in our real-world scenario, indeed our mandatory parent POM
("db-superpom") does import "org.apache.maven:maven:pom:${version.maven}"
indirectly from its dependencyManagement section, with a property default value
of 3.8.5 for the "version.maven" property.
Resolution in our real-world scenario is - as {color:#de350b}*we are forced to
stay with inheriting from this mandatory parent POM*{color} - to either
globally override/downgrade ${version.maven} to 3.8.4 or to prepend/override
just "org.apache.maven:maven-model-builder:jar:3.8.4" to our test dependencies.
(on)
So if you ([~cstamas] and the Maven team) prefer to stay with breaking the
public API for the (partly valid) reasons you stated before, *what would be
your recommendation for "us" (my customer, my team and myself) to move forward
in the most future-proof way:*
a) globally override ${version.maven} to 3.8.4 on the long run (even when
Maven's current version is 4.0+) (?)
b) prepend "org.apache.maven:maven-model-builder:jar:3.8.4" on the long run to
our test dependencies (?)
c) *fork ShrinkWrap Resolver:* [https://github.com/shrinkwrap/resolver] and in
our private fork, change implementation of its
[https://github.com/shrinkwrap/resolver/blob/master/maven/impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/internal/SettingsXmlProfileSelector.java:]
c1) *use Maven's DefaultModelBuilderFactory* from the fork ** (?) ("A factory
to create model builder instances when no dependency injection is available"):
[https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilderFactory.java]
- will this be a *valid long term strategy* and stay around in Maven 4.0+? - or
c2) trying to *make ShrinkWrap use Eclipse Sisu* in the fork (?) and do a
"proper" resource injection - and if so, then the big question is: how?
>From my personal guts feeling, {+}*on the long run, only c1) and c2) are
>"truly" future-proof resolutions*{+}.... Do you agree?
Thanks a million for your kind help with this so far (y), I hope the above
arquillian-reproducer project might be helpful for this scenario in the
future...
Looking forward to your advice & kind regards
Andreas
was (Author: JIRAUSER289351):
{color:#00875a}*OK, so the "riddle" is resolved*{color}, and I can give a
partly "{*}{color:#00875a}ALL CLEAR{color}{*}" sign (/), but am still
interested in your recommendations on how we (my customer/my team and myself)
should move forward in the best possible way... :)
First of all, here is a simple stripped-down reproducer project:
[^arquillian-reproducer.zip]
As stated in lines 48 and 49 of its pom.xml, it hurts when the
dependencyManagement section of the reproducer POM - or, in our original
real-world case, a parent POM's properties and dependencyManagement section -
imports "org.apache.maven:maven:pom:3.8.5" as a "compile" or even "test"
dependency. This will, as documented in the comments above, cause the
NoSuchMethodError due to the incompatible change in maven-model-builder public
API between 3.8.4 and 3.8.5... :(
It turned out that in our real-world scenario, indeed our mandatory parent POM
("db-superpom") does import "org.apache.maven:maven:pom:${version.maven}"
indirectly from its dependencyManagement section, with a property default value
of 3.8.5 for the "version.maven" property.
Resolution in our real-world scenario is - as {color:#de350b}*we are forced to
stay with inheriting from this mandatory parent POM*{color} - to either
globally override/downgrade ${version.maven} to 3.8.4 or to prepend/override
just "org.apache.maven:maven-model-builder:jar:3.8.4" to our test dependencies.
(on)
So if you ([~cstamas] and the Maven team) prefer to stay with breaking the
public API for the (partly valid) reasons you stated before, *what would be
your recommendation for "us" (my customer, my team and myself) to move forward
in the most future-proof way:*
a) globally override ${version.maven} to 3.8.4 on the long run (even when
Maven's current version is 4.0+) (?)
b) prepend "org.apache.maven:maven-model-builder:jar:3.8.4" to our test
dependencies (?)
c) *fork ShrinkWrap Resolver:* [https://github.com/shrinkwrap/resolver] and in
our private fork, change implementation of its
[https://github.com/shrinkwrap/resolver/blob/master/maven/impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/internal/SettingsXmlProfileSelector.java:]
c1) *use Maven's DefaultModelBuilderFactory* from the fork ** (?) ("A factory
to create model builder instances when no dependency injection is available"):
[https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/building/DefaultModelBuilderFactory.java]
- will this be a *valid long term strategy* and stay around in Maven 4.0+? - or
c2) trying to *make ShrinkWrap use Eclipse Sisu* in the fork (?) and do a
"proper" resource injection - and if so, then the big question is: how?
>From my personal guts feeling, {+}*on the long run, only c1) and c2) are
>"truly" future-proof resolutions*{+}.... Do you agree?
Thanks a million for your kind help with this so far (y), I hope the above
arquillian-reproducer project might be helpful for this scenario in the
future...
Looking forward to your advice & kind regards
Andreas
> [REGRESSION] ModelBuilder API Change breaks ShrinkWrap: NoSuchMethodError in
> FileProfileActivator.setPathTranslator()
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-7475
> URL: https://issues.apache.org/jira/browse/MNG-7475
> Project: Maven
> Issue Type: Bug
> Components: General
> Affects Versions: 3.8.5
> Environment: any & deterministically reproducible / proven by public
> API docs
> Reporter: Andreas Loew
> Assignee: Tamás Cservenák
> Priority: Major
> Fix For: 3.8.6
>
> Attachments: arquillian-reproducer.zip
>
>
> Maven 3.8.5 breaks [Arquillian
> ShrinkWrap|https://arquillian.org/modules/shrinkwrap-shrinkwrap] (and
> thereby, most if not all use of Red Hat/JBoss Arquillian) by changing the
> published public API of class
> org.apache.maven.model.profile.activation.FileProfileActivator:
> {code:java}
> [ERROR]
> com.dbenergie.ndm.bnb.business.NutzungsinformationenCreateOrtungsinfoTest
> Time elapsed: 0.127 s <<< ERROR!
> java.lang.NoSuchMethodError:
> 'org.apache.maven.model.profile.activation.FileProfileActivator
> org.apache.maven.model.profile.activation.FileProfileActivator.setPathTranslator(org.apache.maven.model.path.PathTranslator)'
> at
> org.jboss.shrinkwrap.resolver.impl.maven.internal.SettingsXmlProfileSelector.<init>(SettingsXmlProfileSelector.java:50)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.getRemoteRepositories(MavenWorkingSessionImpl.java:327)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:199)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:71)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:53)
> at
> org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:40)
> at
> org.arquillian.container.chameleon.controller.Resolver.resolve(Resolver.java:45)
> at
> org.arquillian.container.chameleon.ContainerLoader.load(ContainerLoader.java:36)
> at
> org.arquillian.container.chameleon.ChameleonConfiguration.getConfiguredAdapter(ChameleonConfiguration.java:116)
> at
> org.arquillian.container.chameleon.ChameleonContainer.init(ChameleonContainer.java:81)
> at
> org.arquillian.container.chameleon.InitiateContainer.initiateChameleon(InitiateContainer.java:69)
> at
> org.arquillian.container.chameleon.InitiateContainer.setup(InitiateContainer.java:38)
> {code}
> It seems that method
> {code:java}
> public FileProfileActivator setPathTranslator( PathTranslator pathTranslator
> ) {code}
> as well as the class of its argument - has been refactored/renamed to
> {code:java}
> public FileProfileActivator setProfileActivationFilePathInterpolator(
> ProfileActivationFilePathInterpolator profileActivationFilePathInterpolator )
> {code}
> While the new name might be regarded as more stylish and/or even more
> appropriate, unfortunately, this results in an incompatible change of a
> publicly documented API:
> [https://maven.apache.org/ref/3.8.4/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> [https://maven.apache.org/ref/3.8.5/maven-model-builder/apidocs/org/apache/maven/model/profile/activation/FileProfileActivator.html]
> Therefore, please revert this change - it clearly breaks some valuable
> dependent software (which unfortunately is no longer maintained by RedHat)...
> Many thanks in advance! :)
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
