[ 
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17536543#comment-17536543
 ] 

Andreas Loew commented on MNG-7475:
-----------------------------------

[~cstamas]

(1) Regarding the Citrus Framework sample - sorry, I hadn't tried this myself 
before - I was just trying to point you to a project setup that on a first 
glance looked similar to me. The fact that this project also does no longer 
work, unfortunately show the flakiness of the Arquillian dependencies setup 
just one more time...

My recommendation would be that you don't try to invest any more time into 
this, but rather wait for the results of my investigation over the weekend in 
our real-life scenario... ;)


(2) While I will be doing extensive research over the weekend (sorry, my 
current job workload does not allow me to do it during the week,,,), I would 
like to ask you two questions to better understand which kind of Maven 
dependency is relevant.

We are using Arquillian Chameleon to run either embedded or managed JBoss 7.4 
instances (getting one of them to run fine is sufficient) from the 
maven-failsafe plugin. With regards to Maven dependencies, we don't set any 
explicit dependency to Maven 3.8.5 in any of our POMs, so either this is a 
result of importing another POM, or the maven-failsafe-plugin uses the 
maven-model-builder classes from the Maven version that is used to run the 
whole build.

So my questions are:

(2a) Which Maven (including dependencies such as maven-model-builder) version 
is used by the *maven-failsafe-plugin* "by {*}default{*}"? How is this version 
determined if nothing else is specified, and can we specify/override this 
version by making the plugin explicitly depend on a particular version of 
maven-model-builder?

(2b) When we use the "managed" instead of the "embedded" type, then Arquillian 
itself starts the JBoss instance in a separate JVM, but the packaging of the 
WAR file containing Arquillian tests with ShrinkWrap is AFAICT - in this 
scenario as well - still done {*}in the original JVM running the failsafe 
plugin{*}. Am I therefore correctly assuming that I need to concentrate on 
getting the maven-failsafe-plugin use a custom 3.8.4 version of Maven, and not 
make Arquillian container JBoss dependencies for the separate JVM use this 
custom version?

Many thanks for clarification - and as stated, stay tuned, I will be trying to 
find my way through Arquillian's "dependency hell" over the weekend...

And of course have a great weekend everybody! :)

 

> [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
>
>
> 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)

Reply via email to