Page History

...

...

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 ?in current implementation). If no
toolchain of given type is available to the infrastructure, the build
fails. The JDK toolchain shall have a fallback default value of the
JDK maven runs with. Others might not have such a default value
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 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 can be done completely behind the scenes, so marking the plugin as toolchain-aware is primarily documentation oriented.

2. User defines the toolchain instances that are available in his
current setup. Shall be user based, project independent, stored in
$HOME/.m2/toolchains.xml file?
Could look like this.
Example toolchains.xml file:

<toolchains>
    <toolchain>
        <type>jdk</type>
       <provides>
           <version>1.5</version>
           <vendor>sun</vendor>
        <instanceId>jdk15</instanceId>
     <id>for_mevenide</id>
       </provides>
       <configuration>
          <jdkHome>/home/mkleint/javatools/jdk</jdkHome>
       </configuration>
    </toolchain>
    <toolchain>
       <type>jdk</type>
       <provides>
           <version>1.6.0</version>
       </provides>
       <configuration>
         <directory> <jdkHome>/home/mkleint/javatools/jdk1.56.0_07<0</directory>jdkHome>
        </configuration>
    </toolchain>
<toolchains></toolchains>

3. Project shall be allowed to state which instance of the given
toolchain type it requires for the build. Therefore making sure that
all plugins use jdk15 for example.
if such toolchain instance is not found in user's local setup, the
build shall fail early.

Q2: how to mark that in the pom? Shall also be profile-able, eg. have
different configurations run with different instances of toolchains..

a new pom element?
eg For this purpose a new plugin (maven-toolchain-plugin) is introduced.
It is responsible for matching the correct
toolchain instances from the user's setup against the requirements of the project and make it available for other plugins to use (in the build
context).

<toolchains><plugin>
   <toolchain><groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-toolchains-plugin</artifactId>
   <type>jdk</type><version>1.0-SNAPSHOT</version>
   <executions>
      <instance>jdk15</instance>
<execution>
      </toolchain>
</toolchains>

or rather some backward compatible solution? Possibly something along
the lines of the enforcer plugin?
A toolchain-plugin would be responsible for picking the correct
instances and make it available for other plugins to use (in the build
content).

<plugins>
   <phase>validate</phase>
         <goals>
    <plugin>
        <artifactId>maven-toolchain-plugin</artifactId>
<goal>toolchain</goal>
         <configuration></goals>
      </execution>
   </executions>
   <toolchains><configuration>
       <toolchains>
          <jdk>jdk15</jdk><jdk>
              <j2me>toolkit22</j2me>
<version>[1.4)</version>
            <toolchains>  <!--vendor>sun</vendor-->
          </configuration>jdk>
      
  </toolchains>
  </plugin>configuration>
</plugins>
plugin>

The process of matching required toolchain against the provided ones is following.

1. Get all toolchains for a given type (eg. jdk)
2. 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.
3. first successful match is pushed into the maven build environment (BuildContext) for use by other plugins down the road
4. if there are no matches, the build fails.

Backward compatibility

Can we achieve backward compatibility with 2.0.x or do we have to go with 2.1 only? It would be nice if at least plugins that start using toolchains would not require 2.1.
The only roadblock for backward compatibility is the build-context that is needed for inter-plugin communication. Build-context seems to be relatively independent of the rest of maven, just requires plexus container that is newer than the one used in 2.0.x. Can we upgrade?