[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537529#comment-17537529
]
Tamás Cservenák commented on MNG-7475:
--------------------------------------
Okay, I understand that my proposal is not feasible.
IMHO, the change you will need to implement in shrinkwrap/maven-resolver is
really to instead manually construct components, use SISU to inject them. This
change is really "internal" to shrinkwrap resolver, none of these should
"surface up" to client code, so to say, your test should remain totally
unchanged. So, IMHO, this is not like you mention "use cases of the surefire or
failsafe plugin where the test driver code additionally creates a Sisu
environment". No, this is really internal matter of
[https://github.com/shrinkwrap/resolver/tree/master/maven/impl-maven] (if I
guessed the module correctly). The change itself is not quite trivial, but may
be done gradually. For example look at breakage:
[https://github.com/shrinkwrap/resolver/blob/f564882d785db86460f43cc7512650e3efae3380/maven/impl-maven/src/main/java/org/jboss/shrinkwrap/resolver/impl/maven/internal/SettingsXmlProfileSelector.java#L46-L51]
All these classes created in this ctor are actually components, hence, they
should be injected. This means a change to ctor of SettingsXmlProfileSelector
and have it all parameters declared and added @{{{}Inject{}}} annotation. For
this to work, you'd want to add @{{{}Named{}}} annotation as now
SettingsXmlProfileSelector itself must be managed as well. Finally, you would
want to look for all places where instance of SettingsXmlProfileSelector are
instantiated and replace that with either inject or play a bit "dirty" and use
direct container lookup instead. So, as you see, these changes will have effect
to "propagate", so for start, I'd play a bit opportunistic, and fix known
breakage (by converting SettingsXmlProfileSelector into a component, fix places
where it's created) and stop, and give it a try. Maybe this is it. But maybe
not.
For creating Plexus Shim (sisu container plexus compatibility layer) look into
resolver demos (there are demos for service locator and "vanilla" guice as
well, but I'd not use those, sisu would simplify a lot for you).
[https://github.com/apache/maven-resolver/tree/master/maven-resolver-demos/maven-resolver-demo-snippets/src/main/java/org/apache/maven/resolver/examples/sisu]
but again, am unsure "how much" or "what" is shrinkwrap resolver using from
Maven universe, so maybe this above in resolver is not enough, and you may want
actually Plexus Shim (sisu powered container that provides Plexus backward
compatible behavior like honoring legacy component descriptors).
I know all this may sound overwhelming, will try to create a PR for you to show
what I mean...
> [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)
