[
https://issues.apache.org/jira/browse/MNG-7475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17535921#comment-17535921
]
Tamás Cservenák commented on MNG-7475:
--------------------------------------
Hey. So, I feel your pain, but let me gather the facts here first and then
let's do the bid.
The class in question was introduced in 2009, and it looked like this:
[https://github.com/apache/maven/blob/c8a5c2d89a6b4cc70a41911ea2d507608f14516c/maven-model-builder/src/main/java/org/apache/maven/model/profile/activation/FileProfileActivator.java]
Notice the {{Component}} annotation on it, so this was a managed component from
very beginning, from 2009.
The reason why we do components is exactly this: container protects us from
these annoying bits how to instantiate things (as container does it for us),
also relieves us from maintaining the component graph as well (in which order
the component should be created, when and where, where to "wire" up, etc). This
is all done by container. Yes, in the end, components ARE plain Java classes,
but they clearly tell (see annotation) what is the intent, how they should be
used.
Maven2 used Plexus Container back in 2000s years, that was a great container,
but had some serious technical limitations: it could not do constructor
injection, only field or setter injection. So all our components (Java classes)
were written in "Plexus style", they were "mutable" in Java sense due Plexus:
default constructor was a must and then fields/setters injection happened in
container to populate the component. In 2009 Plexus was replaced with what
today is called Eclipse Sisu (that is backed by Guice). Hence, we can do now
constructor injection, and we can have immutable components finally (as they
should be from start). Finally, JSR330 replaced old Plexus annotations and XML,
tying it all up together nicely.
I think you can guess the trend here: we are *moving away* from "Plexus Style"
components to proper Constructor Injected immutable ones. Also, *the irony is
that if components are used as they were meant to be used* (inject it and use
it) {*}this would never happen{*}. It is exactly the container that would
protect you from changes like these. In a moment you circumvent (or dodge) this
"protection", you are left on your own, as your code becomes fragile, as
basically it has to re-implement what container does seamlessly, plus, your
logic around.
Am really unsure why these kind of (I'd call them "deep integrations") Maven
plugins happened in the first place, why did not original author(s) reach to us
and ask "how things should be done", or at least question about that annotation
and it's meaning on the class , why they decided to use it directly instead. I
hope we all agree that other way around (we check all Maven integrations out
there) is something clearly not possible.
But I believe all this above does not make *you* happy :)
Directly related:
https://tralfaz.blogspot.com/2012/01/if-woody-had-gone-right-to-police.html
> [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)
