+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
