You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 43 Next »

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

General guidelines

Whenever you "touch" a project, would be good to perform following steps:

Maven

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

Maven Artifact Transfer

  • this is widely used non-core, non-plugin, maybe "shared component". 
  • we need to keep it's "bridging" capability (see m-artifact-resolver 2.x plans, package renames again).
  • unsure about what we want with this: given planned rename, resolver API should not be used directly in upcoming code changes?
  • Given baseline increase (3.1+ and even 3.5+ is considered, see here) this library should 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 Plugins

  • ... should really make up the 10 year lag, and stop depending on maven-compat stuff. Baseline for plugins should be Maven 3.1.x 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

Maven SCM

Maven SCM is bloated and contains many providers we cannot test, given they bridging for are non OSS SCMs. Proposal: keep only those SCM providers that are OSS in Maven project, and provide a clear path for SCM integrators. Propose 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?
  • 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)
  • 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

Phase 1

Phase 2 (post release)

  • up major version (2.x)
  • Drop ServiceLocator, removes a lot of cruft and "default ctors"
  • 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) 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.

Resolver and Maven

Maven version lineJava levelPlexus XMLSisu indexResolverLatest release
Java packageArtifact GAVersion
3.0.x5YesNoorg.sonatype.aetherorg.sonatype.aether:aether-api1.113.0.5, 2013-02-19
3.1.x5YesYesorg.eclipse.aetherorg.eclipse.aether:aether-api0.9.0.M23.1.1, 2013-09-17
3.2.x6YesYesorg.eclipse.aetherorg.eclipse.aether:aether-api1.0.0.v201405183.2.5, 2014-12-14
3.3.x7YesYesorg.eclipse.aetherorg.eclipse.aether:aether-api1.0.2.v201501143.3.9, 2015-11-10
3.5.x7YesYesorg.eclipse.aetherorg.apache.maven.resolver:maven-resolver-api1.1.13.5.4, 2018-06-21
3.6.x7YesYesorg.eclipse.aetherorg.apache.maven.resolver:maven-resolver-api1.4.13.6.3, 2019-11-19
3.8.x7YesYesorg.eclipse.aetherorg.apache.maven.resolver:maven-resolver-api1.6.3

3.8.6, 2022-06-11

3.9.x ?8YesYesorg.eclipse.aetherorg.apache.maven.resolver:maven-resolver-api1.8.x?
4.0.x (old + new Maven API)8?YesYesorg.eclipse.aetherorg.apache.maven.resolver:maven-resolver-api2.x?
4.1.x (only Maven API)?YesYesorg.eclipse.aetherorg.apache.maven.resolver:maven-resolver-api2.x?
5.x ??No ?Yesorg.apache.maven.resolverorg.apache.maven.resolver:maven-resolver-api3.x?

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