...
- get rid of maven-compat (Maven2 support) module in Maven project
- get rid of maven-artifact-transfer (MAT) "artificial" dependency ("artificial" as it provides two things: bridges between org.sonatype and org.eclipse Aether packages. This is not needed anymore, as our baseline is Maven 3.1.1 for LTS. Also, this artifact provides functionality that Maven Core should provide in the first place).
- decide fate of very much related two important components in Maven:
maven-core:RepositorySystem(is an interface, implementation of this interface is in maven-compat) andmaven-core:MavenRepositorySystem(is a budged class with lot of statics). - plugins SHOULD NOT use any core dependency (meaning Resolver, Wagon) directly, they should use Maven Core provided services instead (and Maven Core should cover all the required functionalities).
General backward compatibility notes
This section is about Maven and "our" Maven Plugins (residing in org.apache.maven group ID, maybe also org.codehaus.mojo ).
Maven 3.x line supported Maven 3 and Maven 2 compatible plugins. Maven 4.x in same sense, will support Maven 4 and Maven 3 compatible plugins, but not Maven 2 compatible plugins.
Empower Maven Core
As first step, we should provide all functionalities to Maven Core that lacks today (and are provided by MAT as a hack) but "shielding" underlying implementations from leaks (to not repeat the org.sonatype/org.eclipse fiasco). In short, plugins SHOULD NOT use Aether directly (Aether managed by Maven). Plugin could still "roll their own contaner" and do whatever they want if they have to, but goal is to extend Maven Core to cover most of the needs of plugins (artifact: resolve/install/deploy, dependencies: collect/resolve, project: install/deploy). This could be implemented in several ways, but given of spread of MAT, less resources would be needed (so to say, later transition would be simplest), if we'd reuse MAP API.
...