+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 <rfscho...@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 >
