[ https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537550#comment-17537550 ]
Andreas Loew edited comment on MNG-7475 at 5/16/22 1:53 PM: ------------------------------------------------------------ [~cstamas] thanks a million - yes I was very well aware of the fact that we need to fork and modify Arquillian ShrinkWrap code itself, and NOT our test cases using ShrinkWrap - that was fully understood from the beginning. I think it is quite likely that ShrinkWrap also uses parts of old Plexus compatible infrastructure, so Plexus Shim is a Plexus "flavour" of Sisu, did I get this right? I am well aware of the concepts of DI, so I have been able to follow your explanations - it's much less a question of how to change all the "to-become-managed-components" classes, my main question is where and how is the Guice/Sisu/Shim/whatever it's called IoC "container" configured and started up in a "test case" to be started from the maven-failsafe (very similar to maven-surefire) plugin? (and with the exception of "how-to start-the whole-thing-up-properly-from-a-maven-failsafe-plugin-execution" - which is the million dollar question to me - the whole rest sounds not overwhelming at all... :P) was (Author: JIRAUSER289351): [~cstamas] thanks a million - yes I was very well aware of the fact that we need to fork and modify Arquillian ShrinkWrap code itself, and NOT out test cases using ShrinkWrap - that was fully understood from the beginning. I think it is quite likely that ShrinkWrap also uses parts of old Plexus compatible infrastructure, so Plexus Shim is a Plexus "flavour" of Sisu, did I get this right? I am well aware of the concepts of DI, so I have been able to follow your explanations - it's much less a question of how to change all the "to-become-managed-components" classes, my main question is where and how is the Guice/Sisu/Shim/whatever it's called IoC "container" configured and started up in a "test case" to be started from the maven-failsafe (very similar to maven-surefire) plugin? (and with the exception of "how-to start-the whole-thing-up-properly-from-a-maven-failsafe-plugin-execution" - which is the million dollar question to me - the whole rest sounds not overwhelming at all... :P) > [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)