Additions
- Add hooks for different versions of the model and Polyglot support in general (the strategy can be taken from Polyglot for Maven), but an extension point is required in the core so that different libraries needed for parsing various formats are not all required in the distribution.
- A Builder interface for the different strategies we have for modes like single threaded, multi-threaded, and introduce a new implementation for aggressive parallelization and smart scheduling.
- A proper place at the beginning and end of the build to execute. The AbstractMavenLifecycleParticipant is working now to do some of that work, but with aggressive concurrency many of the techniques currently used (like the deploy-at-end technique in the deploy plugin) are not thread safe and assume a mode of serial execution. Robert Scholte: We should think of a smarter lifecycle-mechanism. The install and deploy phases are kind of finalize phases, which are only useful when all projects were packaged successfully.
- Execution environments: being to specify versions of the JVM in a similar way as Eclipse does, for spawned processes being able to pass in all Maven parameters and settings consistent (MNG-5199). This probably requires coming up with the one way to fork/invoke projects and finally get rid of the 5 ways we currently do it. Here I'm not sure what happens to the toolchains as they are a mechanism which is primarily used for finding a JDK other than the one Maven is started with.
- Overhauling profiles
Cleanup
- All the listener interfaces are pretty convoluted and incomplete, we should probably review again. EventSpies cannot be hooked into the build as normal extensions so they are really kind of useless (hence the recent addition of AbstractMavenLifecycleParticipant#afterSessionEnd)
- ReactorManager: there are many inconsistencies where test jars are not resolved in the reactor, and the special magic that happens in the compiler plugin currently where it sets the artifacts file to the compile classes directory. This all needs to be encapsulated in a new workspace reader that behaves consistently and doesn't require special behavior in certain plugins. If you wrote a new compiler plugin for example and didn't set the file everything would break which is just poor encapsulation.
...
Removal
- Remove all site related configuration from the POM: Herve Boutemy: I'm not ok with this one, reporting is useful. JVZ, then we'll need to discuss this because I don't see it as different than a normal set of plugins and there is no reason they can't just work as normal plugins. No disagreement that some think the site plugin is important but it should have no special provisions in the core.
- Remove Ant Mojos, Beanshell and anything else no one is actually using. I think people will prefer the polyglot mode
- Remove RuntimeInfo (MNG-3954)
- Remove scope=system
- Remove LegacySupport
- Remove automatic plugin version selection (MNG-4173)
- Remove much deprecated code:
- In MavenSession, all the Plexus container related code
- PlexusUtilsInjector (not required it was a bridge way back for Maven 2.x)
- maven-compat and update our plugins not to use it
- Remove dynamic dependency addition. Dependencies should be explicit, no more magic support for things like the Cobertura plugin that injects dependencies (MNG-4363)
Get rid of aggregator plugins, there are better ways to deal with aggregation. Something that can execute at the end of the build the start of the is the AbstractLifecycleParticipant.afterSessionEnd
...