You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Robert Scholte <rf...@apache.org> on 2021/02/06 13:32:14 UTC
[DISCUSS] MNG-7020 Remove Maven 2 WagonExcluder backward compat code
(I'm not sure if this has already been discussed on the dev-list, but I can't find any related thread)
Plugins that depend on maven-core 2.x will pull in Wagon, which causes unwanted behavior (it will superseed the one bundled with Maven for that plugin).
MNG-7020 asks for removing this class, but that would imply that such (old) plugin would again have the unwanted behavior in Maven 4.
I don't think we should assume that old plugins aren't used anymore.
There are a couple of options to solve this.
1. Indeed delete WagonExcluder, accept that users of of such old plugin will have unwanted behavior without warning
2. Replace WagonExcluder with Maven2Excluded. This would solve one awkward fact: for plugins Maven always downloads dependencies of maven, but often an older version? Why download, if they are being removed from the classpath afterwards due to classworld config[1]?
3. Throw an exception in case Maven2 compatible plugins are being used. This will force the user to update those plugins before being able to build the project.
4. Keep it as it is, so we will have consistent behavior.
Right now I think option 3 is an elegant way to be able to move forward without being blocked by deprecated Maven 2 code. We can assume at least Maven3 compatible plugins. And it fits in a model of any future release where we can define at Maven Core what the minimum required plugin compatibility version is.
WDYT?
Robert
[1] https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml
Re: [DISCUSS] MNG-7020 Remove Maven 2 WagonExcluder backward compat
code
Posted by Michael Osipov <mi...@apache.org>.
Am 2021-02-06 um 14:32 schrieb Robert Scholte:
> (I'm not sure if this has already been discussed on the dev-list, but I can't find any related thread)
>
> Plugins that depend on maven-core 2.x will pull in Wagon, which causes unwanted behavior (it will superseed the one bundled with Maven for that plugin).
>
> MNG-7020 asks for removing this class, but that would imply that such (old) plugin would again have the unwanted behavior in Maven 4.
>
> I don't think we should assume that old plugins aren't used anymore.
>
> There are a couple of options to solve this.
>
> 1. Indeed delete WagonExcluder, accept that users of of such old plugin will have unwanted behavior without warning
>
> 2. Replace WagonExcluder with Maven2Excluded. This would solve one awkward fact: for plugins Maven always downloads dependencies of maven, but often an older version? Why download, if they are being removed from the classpath afterwards due to classworld config[1]?
>
> 3. Throw an exception in case Maven2 compatible plugins are being used. This will force the user to update those plugins before being able to build the project.
>
> 4. Keep it as it is, so we will have consistent behavior.
>
> Right now I think option 3 is an elegant way to be able to move forward without being blocked by deprecated Maven 2 code. We can assume at least Maven3 compatible plugins. And it fits in a model of any future release where we can define at Maven Core what the minimum required plugin compatibility version is.
I'd like to propose a slightly different approach since the raised
discussion is not explicitly related to Wagon2Excluder, but rather old
cruft in general. My proposal:
* Create a seperate clean JIRA issue which describes option 3,
* Implement it that only Maven 3.1 capable plugins are compatible,
* Merge MNG-7020 because that would be ultimately a consequence of it.
The result would be cleanly defined behavior. I would expect option 3 to
fully cover Wagon2Excluder because it contains Maven Core 2 deps.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [DISCUSS] MNG-7020 Remove Maven 2 WagonExcluder backward compat code
Posted by Sylwester Lachiewicz <sl...@gmail.com>.
+1 for option 3
sob., 6 lut 2021, 14:43 użytkownik Tamás Cservenák <ta...@cservenak.net>
napisał:
> +1 fot option 3: we drag so much of legacy, that m4 really should accept
> maven 3.1+ plugins only (covers 14 years?).
>
> T
>
> On Sat, Feb 6, 2021, 14:32 Robert Scholte <rf...@apache.org> wrote:
>
> > (I'm not sure if this has already been discussed on the dev-list, but I
> > can't find any related thread)
> >
> > Plugins that depend on maven-core 2.x will pull in Wagon, which causes
> > unwanted behavior (it will superseed the one bundled with Maven for that
> > plugin).
> >
> > MNG-7020 asks for removing this class, but that would imply that such
> > (old) plugin would again have the unwanted behavior in Maven 4.
> >
> > I don't think we should assume that old plugins aren't used anymore.
> >
> > There are a couple of options to solve this.
> >
> > 1. Indeed delete WagonExcluder, accept that users of of such old plugin
> > will have unwanted behavior without warning
> >
> > 2. Replace WagonExcluder with Maven2Excluded. This would solve one
> awkward
> > fact: for plugins Maven always downloads dependencies of maven, but often
> > an older version? Why download, if they are being removed from the
> > classpath afterwards due to classworld config[1]?
> >
> > 3. Throw an exception in case Maven2 compatible plugins are being used.
> > This will force the user to update those plugins before being able to
> build
> > the project.
> >
> > 4. Keep it as it is, so we will have consistent behavior.
> >
> > Right now I think option 3 is an elegant way to be able to move forward
> > without being blocked by deprecated Maven 2 code. We can assume at least
> > Maven3 compatible plugins. And it fits in a model of any future release
> > where we can define at Maven Core what the minimum required plugin
> > compatibility version is.
> >
> > WDYT?
> > Robert
> >
> > [1]
> >
> https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml
>
Re: [DISCUSS] MNG-7020 Remove Maven 2 WagonExcluder backward compat code
Posted by Tamás Cservenák <ta...@cservenak.net>.
+1 fot option 3: we drag so much of legacy, that m4 really should accept
maven 3.1+ plugins only (covers 14 years?).
T
On Sat, Feb 6, 2021, 14:32 Robert Scholte <rf...@apache.org> wrote:
> (I'm not sure if this has already been discussed on the dev-list, but I
> can't find any related thread)
>
> Plugins that depend on maven-core 2.x will pull in Wagon, which causes
> unwanted behavior (it will superseed the one bundled with Maven for that
> plugin).
>
> MNG-7020 asks for removing this class, but that would imply that such
> (old) plugin would again have the unwanted behavior in Maven 4.
>
> I don't think we should assume that old plugins aren't used anymore.
>
> There are a couple of options to solve this.
>
> 1. Indeed delete WagonExcluder, accept that users of of such old plugin
> will have unwanted behavior without warning
>
> 2. Replace WagonExcluder with Maven2Excluded. This would solve one awkward
> fact: for plugins Maven always downloads dependencies of maven, but often
> an older version? Why download, if they are being removed from the
> classpath afterwards due to classworld config[1]?
>
> 3. Throw an exception in case Maven2 compatible plugins are being used.
> This will force the user to update those plugins before being able to build
> the project.
>
> 4. Keep it as it is, so we will have consistent behavior.
>
> Right now I think option 3 is an elegant way to be able to move forward
> without being blocked by deprecated Maven 2 code. We can assume at least
> Maven3 compatible plugins. And it fits in a model of any future release
> where we can define at Maven Core what the minimum required plugin
> compatibility version is.
>
> WDYT?
> Robert
>
> [1]
> https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/maven/extension.xml