...
1. Plugin denotes what toolchain type it requires for it's
operation. So compilation, surefire, jnlp, ... need a JDK toolchain
instance for example. The actual instance of the toolchain is passed
into the plugin by the infrastructure (using Build context MavenSession in current implementation).
Most current plugins that use JDK for processing, use the maven's JDK instance by default. The only change introduced is
to use the toolchain in the BuildContext MavenSession if found. If not, do as we did so far.
Q1: how shall the plugin tell what toolchains it needs? parameter?
parameter's or mojo's @toolchain annotation? The actual retrieval of the toolchain from build content context can be done completely behind the scenes, so marking the plugin as toolchain-aware is primarily documentation oriented.
...
- Get all toolchains for a given type (eg. jdk)
- go through them one by one and try match the requirements in the toolchain-plugin configuration against the provided tokens. Some like 'version' are to be specially handled and allow for range matching etc, the rest is exact match only. The creator of the particular type of toolchain can define the specially handled tokens.
- first successful match is pushed into the maven build environment (MavenSession) for use by other plugins down the road
- if there are no matches, the build fails.
Backward compatibility
...
- The Toolchain core components need to go to 2.0.9-SNAPSHOT and 2.1-SNAPSHOT codebase.
...
- maven-toolchains-plugin gets the maven prerequisite of 2.0.9-SNAPSHOT. That way anyone actively using toolchains needs to be using 2.0.9-SNAPSHOT+
...
- Any other plugins using the toolchains components don't need to explicitly set the maven prerequite to 2.0.9-SNAPSHOT. The components will work but will fail to deliver a configured toolchain, thus they will keep behaving the same way as they did before. That's critical for further development of plugins.
What changes are needed in plugin code to start using toolchains?
...