[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17535131#comment-17535131
]
Andreas Loew commented on MNG-7475:
-----------------------------------
Sorry, but whom do you, Tamás, refer to when saying: "{+}**You**{+} are
misusing..."
It's not "me"... I am just an ordinary end user - and my customer, my team and
myself are simply using Red Hat commercial JBoss together with Arquillian suite
code to run and unit/integration test our legacy Java EE applications.
So I +**do not**+ have any chance to modify Red Hat's code (well, other than
possibly forking its Git repo myself and updating my fork, if all other
attempts fail), and sadly, the Arquillian code is no longer maintained by Red
Hat...
*I wouldn't think it is good practice or appropriate from the Maven side to
change a* *public API,* *publicly documented with officially published
Javadocs, six years later in a minor dot release, without any previous
deprecation or public notice - and then telling end users that a company like
Red Hat simply used your API the completely wrong way back in 2016.*
Are you sure that this even clearly was a "managed component" back in 2016 when
Maven version 3.3.9 was current? Why had its setter method been made public at
all back then if this were the case? And in case it indeed already was a
managed component in Maven 3.3.9, then the mistake is also on the Maven side,
as the code then should never have been written with a public setter method the
way it used to be for 6 years until the most recent change.
Sorry, but please don't try to duck out of a clear mistake on the Maven side
here, namely breaking binary compatibility. When you do some refactorings on
your widely used codebase, fine, but not at the cost of breaking a public API
in this way.
Please let's try to think about some less "negative" approach: *Why not try and
focus on finding a meaningful way to stay with your new concept of a managed
component, but still implement/wrap/map the missing method in order to still
support and not break the published API...*
Shouldn't it be possible to keep binary compatibility on the Maven side by
still providing the old API (i.e. the old public method and the old class used
as a parameter) but do so by properly wrapping/mapping it to the correct, new
implementation?
Many thanks for listening! ;)
> [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
> Priority: Major
>
> 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)
