[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537459#comment-17537459
]
Andreas Loew edited comment on MNG-7475 at 5/16/22 10:39 AM:
-------------------------------------------------------------
[~cstamas] sorry but what you propose ist simply not feasible for the remaining
lifetime of our (admittedly, "legacy") Java EE application.
Basically, the role of Arquillian is to be the (only feasible) vehicle to
execute such maven-failsafe-plugin "integration" type tests that require Java
EE container infrastructure to run: access to JPA Entity Manager, transactional
EJBs, JMS Message Endpoints etc.) within a managed (or even embedded) Java EE
container such as Wildfly (or the commercial JBoss EAP).
{color:#de350b}*There simply is no viable alterative for us to replace
Arquillian by something else as long as the Java EE "legacy" application still
exists.*{color}
As stated before, I am with you and also support {*}closing this
maven-model-builder related ticket with "won't fix"{*}.
What I would like to receive some kind help from you before we do so is some
educated advice on how we can change our own (inevitable) fork of Arquillian
(or rather at least its ShrinkWrap component), to be able to {*}make Sisu
annotation processing and Sisu component injection at runtime part of the
ShrinkWrap process{*}.
Do you e.g. have any other typical use cases of the surefire or failsafe plugin
where the test driver code additionally creates a Sisu environment such that
the FileProfileActivator from maven-model-builder could be created as an
annotated/injected component from ShrinkWrap-fork code?
I hope I succeeded in making our dilemma clear enough: I am searching for a way
to make the whole Arquillian, e.g. Arquillian Shrink Wrap, being able to
utilize Sisu as an Maven annotated component injection provider, and am looking
for a code examples what must be done to achieve this...
Thanks again & best regards!
was (Author: JIRAUSER289351):
[~cstamas] sorry but what you propose ist simply not feasible for the remaining
lifetime of our (admittedly, "legacy") Java EE application.
Basically, the role of Arquillian is to be the (only feasible) vehicle to
execute such maven-failsafe-plugin "integration" type tests that require Java
EE container infrastructure to run: access to JPA Entity Manager, transactional
EJBs, JMS Message Endpoints etc.) within a managed (or even embedded) Java EE
container such as Wildfly (or the commercial JBoss EAP).
{color:#de350b}*There simply is no viable alterative for us to replace
Arquillian by something else als long as the Java EE "legacy" application still
exists.*{color}
As stated before, I am with you and also support {*}closing this
maven-model-builder related ticket with "won't fix"{*}.
What I would like to receive some kind help from you before we do so is some
educated advice on how we can change our own (inevitable) fork of Arquillian
(or rather at least its ShrinkWrap component), to be able to {*}make Sisu
annotation processing and Sisu component injection at runtime part of the
ShrinkWrap process{*}.
Do you e.g. have any other typical use cases of the surefire or failsafe plugin
where the test driver code additionally creates a Sisu environment such that
the FileProfileActivator from maven-model-builder could be created as an
annotated/injected component from ShrinkWrap-fork code?
I hope I succeeded in making our dilemma clear enough: I am searching for a way
to make the whole Arquillian, e.g. Arquillian Shrink Wrap, being able to
utilize Sisu as an Maven annotated component injection provider, and am looking
for a code examples what must be done to achieve this...
Thanks again & best regards!
> [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)
