This page discusses emerging ideas of "clean up" of Maven project and its related sub-projects.

Drop Plexus Container for JSR-330 + Sisu Guice extension

Whenever you "touch" a project, would be good to perform following steps to migrate from old Maven-specific Plexus Container IoC to JSR-330 + Sisu Guice extension:

Maven

  • ... should really drop Maven 2.x support (was it 10 years?), so maven-compat must go.

Maven Artifact Transfer

  • in addition to maven-install-plugin and maven-deploy-plugin usage, this is widely (question) used by non-core, non-plugin, maybe "shared component". 
  • we need to keep its "bridging" capability (see m-artifact-resolver 2.x plans, package renames from Maven version to version).
  • unsure about what we want with this: given planned rename, resolver API should not be used directly in upcoming code changes?
  • Given baseline increase (decided to go with 3.2.5, and even 3.5+ is considered, see here), the bridging aspect of this library is not useful any more (before Maven 4), so this library should perhaps be proactively dropped whenever a plugin is updated.
  • Maven4 has API worked on, that WILL replace currently (3.1-3.9 and even 4.0.x) "safe" direct use (as in 3.1+ there is no sonatype/eclipse package problem, is gone) of resolver.
  • Maven 3.0 should be loudly unsupported (mostly is)
  • Maven 3.1-3.999 using direct resolver APIs are the only way to go with them, these versions have no "Maven API"
  • Maven 4 will come with Maven API, but will provide transition period and support both, Maven 3.1+ way and Maven API
  • Cut off is currently undecided (seal off maven internals, stop supporting Maven 3 way), may happen in 4.1, 4.5 or maybe even Maven 5.0

Maven Plugins

  • ... should really make up the 10 year lag, and stop depending on maven-compat stuff. Baseline for plugins should be Maven 3.2.5+ line.
  • We must forget the "ill fated" Maven 3.0.x line, not only due org.sonatype/org.eclipse Resolver problem (m-artifact-transfer kinda covers it), but also due it's "sealed" Plexus/Sisu implementation and ancient version. We must comprehend, that we have no resources to support 10+ years spanning compatibility. Move on.
  • (to be reviewed) mark Maven core dependencies as scope=provided

Note about plugins carrying custom lifecycle mappings: while Plexus XML will work across 3.2.5-3.99 versions, converting lifecycle mapping to JSR330 is not so simple: there was a type erasure change that renders mappings in plugin between 3.2.5 and 3.3.9 broken (well, not trivial to migrate). In this case, simplest is to just "avoid" the breakage, and raise the bar on that plugin to 3.3.9+

See here:

Maven SCM

Maven SCM is too big given our resources and contains many providers we cannot test, given they bridging for are non OSS SCMs.

Proposal: keep only those SCM providers that are OSS and not obsolete (like cvs...) in Maven project, and provide a clear path for SCM integrators to maintain their providers in their community. Proposed plan:

Phase 1

  • mark as @Deprecated all except following providers: git (gitexe, jgit), svn (svnexe), mercurial

    • maven-scm-provider-accurev

    • maven-scm-provider-bazaar
    • maven-scm-provider-clearcase
    • maven-scm-provider-integrity
    • maven-scm-provider-jazz
    • maven-scm-provider-perforce
    • maven-scm-providers-cvs
    • maven-scm-providers-standard (skim POM)
    • maven-scm-provider-starteam
    • maven-scm-provider-synergy
    • maven-scm-provider-tfs
    • maven-scm-provider-vss
  • release as-is as next minor version = 1.12.0 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317828&version=12350600

Phase 2 (post release)

  • drop all deprecated modules/providers (incuding svnkit)
    • write down how to move these to a new home?
  • up major version: 2.0.0
  • make it Java 8?
  • provide "clear path" (documentation, repository, mini-site?) for SCM integrators (prev codebase will be still available under release tag done in phase 1)
    • SCM-1002 - Getting issue details... STATUS prepare orphaned Git branches for each removed SCM provider with the code as it was before
  • Get rid of Plexus DI


Maven Wagon

Similarly, Wagon contains many providers we have no feedback whatsoever, or, we do have feedback but are dead-end (JSch/SSH).

Phase 1

  • mark as @Deprecated all except following providers: file, http, ssh (sshexe), scm
    • wagon-ftp
    • wagon-http-lightweight
    • wagon-ssh
    • wagon-webdav-jackrabbit
  • Drop support for JSoup-based fle listing
  • release as-is as next minor version

Phase 2 (post release)

  • drop all deprecated modules/providers
  • up major version?
  • make it Java 8?
  • Wagon specific changes, like collapse DAV into HTTP (and drop webdav-jackrabbit), probably collapse http-shared into HTTP (as lightweight is gone as well)
  • Get rid of Plexus DI

Questions

  • if maven-compat goes away, how does Wagon fit/interface with Maven?


Maven Resolver (aka Maven Artifact Resolver)

Phase 1

Phase 2

  • up major version (2.x)
  • Drop ServiceLocator, as it currently forces us to use bad practices: create mutable components, and is just cruft (member population is "circumvented" by init method, no way for ctor injection). Anyway, anyone integrating resolver w/o guice should just manually craft the "component graph", basically all they need is a "factory pattern" w/o the half-ass DI-like cruft in SL (that forces how components are created), see MRESOLVER-157 - Getting issue details... STATUS
  • make all things proper ctor injection and final (lot of code breakage)

Phase 3 (later)

  • Java package change from org.eclipse.aether to org.apache.maven.resolver? Package change is postponed post Maven 4 and serves the purpose of smoother transitioning from Maven 3 plugins to Maven 4 plugins: as Maven 4.0 will allow still "old style" plugins (using maven-core and other, so 3.x plugins will work with Maven 4.0 unchanged) but at the same time it will introduce new Maven API as well. This "transitioning state" will be kept as long as needed, but at some point (4.1 or later, undecided, maybe even only in 5.0, yet to be seen, to keep kangaroos who overslept last two years calm) Maven will seal off internal access and require plugins to use new Maven API only. That will be the point when 4.x plugin line will require to switch. Renaming packages before this introduces abrupt breakage for plugins. This also means that there will be a "window" from 4.0 to 4.something where both, 3.x style and 4.x style plugins will both be able to work unchanged, giving time and allowing plugin developers to migrate gradually to new Maven API.

Have to note, that as long as Maven internals are exposed to plugins, we are doomed at "slow pace" as we cannot make huge leaps in progress, as changing private internals (that plugins currently depends on due lack of API) will introduce breakage. IMHO, our and also plugin developers benefit is to perform this switch to new API as fast as possible (so not in 10-ish years).

Resolver and Maven

Maven version lineJava levelPlexus XMLSisu indexResolverLatest Maven release
Java package (code)Artifact GA (dependency)Version
3.0.x5YesNoorg.sonatype.aetherorg.sonatype.aether:aether-api1.113.0.5, 2013-02-19
3.1.xYesorg.eclipse.aetherorg.eclipse.aether:aether-api0.9.0.M23.1.1, 2013-09-17
3.2.x61.0.0.v201405183.2.5, 2014-12-14
3.3.x71.0.2.v201501143.3.9, 2015-11-10
3.5.xorg.apache.maven.resolver:maven-resolver-api1.1.13.5.4, 2018-06-21
3.6.x1.4.13.6.3, 2019-11-19
3.8.x1.6.3

3.8.8, ?

3.9.x ?81.9.x (1.9.18)3.9.6, ?
4.0.x (old + new Maven API)8?2.x (compat with 1.9.x)?
4.1.x (only Maven API)?2.x (direct resolver access removed)?
5.x ??No ?org.apache.maven.resolver3.x (direct resolver access removed)?

Note: this table contains latest releases only and just for quick reference. For details history of Maven, go to Maven Releases History page.

Maven Doxia

Phase 1

Phase 2 (post release)

  • drop all deprecated modules/providers/classes
  • up major version?
  • make it Java 8?
  • Get rid of Plexus DI
  • Get rid of Doxia Logging

Maven Doxia Sitetools

Phase 1

Phase 2 (post release)

  • drop all deprecated modules/providers/classes
  • up major version?
  • make it Java 8?
  • Get rid of Plexus DI
  • Get rid of Doxia Logging


  • No labels

11 Comments

  1. Olivier Lamy

    in case of dropping ServiceLocator we must provide an alternative to our users.

    quick search shows a lot of usage https://github.com/search?q=import+org.eclipse.aether.impl.DefaultServiceLocator&type=code

    the world is not made only of people using DI. 

    A module with some factory we maintain and hide the details or users will simply use their own stuff.

    And potentially every release we will make will break users as we don't test all possibilites.

    At least as a courtesy for our users to replace what "we" consider bad we should (must) provide this.


    1. Tamas Cservenak

      If you look at the refd issue(s), problem is that there is no "single use case", everyone does it differently. Hence, IMHO is really simplest that they create their own factories, instead as we did (tried) with SL, provide some semi-half-assed-DI-like-stuff that kinda fits all at high costs. Literally, why would it be hard for them, that on spot where they created SL actually create whole repo system instead? Yes, we may provide some abstract factory, quality patches accepted!

      1. Olivier Lamy

        fair enough.

        But not sure how you can reduce a single comment on the ref Jira to a general there is no "single use case".

        Anyway if we go that way I hope at least we will have some demos modules providing some examples...

        the only problem I can see here is to create some object model really DI oriented which will remove the extensibility/modularity for users not using DI.

        e.g immutable for components means closing every possible extensibility capability?


        1. Tamas Cservenak

          Of course not, in fact, people choosing no-SISU way are automatically rejecting any kind of auto-extensibility ability as well, unless they set/add things manually beforehand. That is one of 2nd major reason why we want to get rid of SL.

          DI is discrete in this respect, it does not enforce you anything. It was actually the SL that enforced "bad things" like presence of def ctor, and use of 2nd method post-construct "init" (very much like oldie Plexus did). The classes will be plain Java immutable classes, nothing special.

          1. Olivier Lamy

            Please read this in a view of someone who want to use maven-resolver outside of a Maven plugin.

            i do not feel adding set/add to help user extending an opensource component as a problem... as long as there are good defaults.

            just give users the freedom to do so (as long as there are good default if they choose to use something else it's their responsibility).

            if for whatever reason component A contains service B with a default B implementation, I do not see a problem having a setB to change to another implementation.

            reading this it looks like similar to "to use this project you must use xx" with xx could be DI or OSGI or anything else.

            "DI is discrete" no it's wrong if you force users to use it.

            just a bit closed mind to a single technology and not really opening this to different users.


  2. Olivier Lamy

    as said here in this page regarding maven-artifact-transfer 

    Cut off is currently undecided (seal off maven internals, stop supporting Maven 3 way), may happen in 4.1, 4.5 or maybe even Maven 5.0` 


    So there is no need to remove maven-artifact-transfer  usage from plugins until maven-resolver use a proper Apache package.

    As an Apache project we do not own the package org.eclipse we cannot promote the use of such package distributed in a org.apache.maven groupId.

    It's now almost 7 years the project has been moved here. So as a transition we had enough time to change this aberration from our source code.



    1. Herve Boutemy

      one interest of maven-artifact-transfer is to ease transition for plugins from one internal Maven API to new ones

      IIUC, until now, it helped hide details of Maven 3.0.x Sonatype Aether vs Maven 3.1.x Eclipse Aether vs Maven 3.2+ Maven Resolver (Maven groupId, but org.eclipse java package)

      if in the future there is a transition from org.eclipse Java package to a new API, I suppose we'll need again such a transition, isn't it?

      (notice: I did not read all the discussions, I'm just writing one aspect I see now)

      1. Olivier Lamy

        correct apart from the ownership naming problem. That's my understanding as well. So I don't understand why we have such PRs https://github.com/apache/maven-install-plugin/pull/31


        1. Herve Boutemy

          I understand how this PR removes maven-artifact-transfer at a time where old Maven 3.0 and 3.1 compatibility is not needed any more: then it's a simplification

          even if when I read it, I don't get why it uses org.eclipse.aether groupId instead of org.apache.maven.resolver ones: the similarities between groupId and Java package name need also to be very precise when we talk about namespaces, because we have groupId namespace and Java package namespaces

          and we still miss the next step which will be either the moves to Maven groupId and Java package name, which will require a new move

          and the move to the new Maven 4 API


          I don't know if Tamas Cservenak sees some independant issues on the maven-artifact-transfer API = which would add another reason to try to avoid it

        2. Sylwester Lachiewicz

          Simplify it now, drop old stuff. As you can see in history of MAT - it was even pain to split it to modules and it never gained more attention (ie no release for 1,5 years of this new packages). 

          If we would be near to having maven-resolver in new package and API in core - we could write something that will adjust only where we need. 

          And btw - we are now talking about maven-install and maven deploy plugins - we can always release version only for Maven 5. Its quick to rename used packages - right ?

          1. Olivier Lamy

            Sylwester Lachiewicz  not sure what you consider old stuff?

            org.eclipse.aether will be replaced by org.apache.maven.resolver and plugin writers will be able to use this directly or use a new Maven API.

            So let's look at the other way, we can consider org.eclipse.aether as deprecated or "old stuff"/

            This had a lot of changes in the past and m-artifact-t was build to hide a lot the previous "decisions" made around the real implementation location and naming.

            As we will still changing this in the future (e.g package change and new Maven API) maybe it's still a nice courtesy to keep providing plugin writers something hiding.

            Maybe with old stuff you consider removing the mapping to package org.sonatype. (e.g old maven version)? In this case we can remove this for sure (1 module of m-artifact-t to remove or even exclude when using m-artifact-t)