ability to consistently apply a toolchain across plugins

discussed on mailing list at http://www.nabble.com/-proposal--toolchain-support-for-Maven-2.1-tf1942937.html#a5325520

netbeans ant property file in netbeans userdir defining the J2se platform (ak toolchain)

nb ant project property file for a j2se project that defines the active.plaform property that links the build script to the IDE's definition of toolchain. please note that this doesn't work in headless mode without configuration.

build.classes.dir=$

/generated

1. Only compile against the classpath explicitly listed here:
   build.sysclasspath=ignore
   build.test.classes.dir=$ {build.dir}/test/classes
   build.test.results.dir=${build.dir}

   /test/results
   debug.classpath=\
   $

   {run.classpath}

   debug.test.classpath=\
   $

   {run.test.classpath}
2. This directory is removed when the project is cleaned:
   dist.dir=dist
   dist.jar=$ {dist.dir}/JavaApplication4.jar
   dist.javadoc.dir=${dist.dir}

   /javadoc
   jar.compress=false
   javac.classpath=

3. Space-separated list of extra javac options
   javac.compilerargs=
   javac.deprecation=false
   javac.source=1.4
   javac.target=1.4
   javac.test.classpath=\
   $ {javac.classpath}:\
   ${build.classes.dir}:\
   ${libs.junit.classpath}
   javadoc.additionalparam=
   javadoc.author=false
   javadoc.encoding=
   javadoc.noindex=false
   javadoc.nonavbar=false
   javadoc.notree=false
   javadoc.private=false
   javadoc.splitindex=true
   javadoc.use=true
   javadoc.version=false
   javadoc.windowtitle=
   main.class=javaapplication4.Main
   manifest.file=manifest.mf
   meta.inf.dir=${src.dir}/META-INF
   platform.active=Java_HotSpot_TM__Client_VM_1.6.0-rc-b91
   run.classpath=\
   ${javac.classpath}

   :\
   $

   {build.classes.dir}
4. Space-separated list of JVM arguments used when running the project
5. (you may also define separate properties like run-sys-prop.name=value instead of -Dname=value
6. or test-sys-prop.name=value to set system properties for unit tests):
   run.jvmargs=
   run.test.classpath=\
   $ {javac.test.classpath}

   :\
   $

   {build.test.classes.dir}

   src.dir=src
   test.src.dir=test

Milos and I will try a simple example this week but essentially it will consist of a Toolchain interface to describe everything in a toolchain, and a ToolchainAware interface so that tools can query for the ToolChain information using a ToolChainAware interface. But this interface should probably not be in Maven's core, but possibly in the plugin api. The only problem there is that it limits the toolchain awareness to plugins. Maybe that's ok. Milos and I will take a stab at resolving this during the week.

We need to have a way to select the toolchain for a particular project, and what netbeans does is allow you to set the toolchain that you want to use but will default to the one used to start up the IDE. So we can do something similar.

We also need to account for things like J2ME, where you really need to use the tools provided there so things will work at runtime.

We also need to account for things like .net as the Java only toolchains are obviously not going to work for .net. We also need to account for other languages in general.

re: j2me comment - I think that's actually the original inspiration for this in general, so agreed.

re: selection - won't this be declaring available toolchains in settings.xml and declaring required toolchain(s) in pom.xml as a new element?

I'm assuming from the comments above that we're now planning to implement multi-language support through the toolchain now...I'm really not sure this is wise, since some languages will require additional steps beyond a single-step compile, or possibly a rearrangement of a multi-step compile sprinkled through several phases. No, Jason, I don't have concrete examples...but I strongly suspect that's because I've stopped working with the project that required me to orchestrate Make-ish builds with Maven. I think adapting the Java lifecycle using toolchain is a bit simplistic, if that's what we're attempting here.

Beyond all that, I'd say we definitely need to provide for more than just plugins gaining access to the toolchain in use. For one thing, I can see it being useful to determine an alternative artifact resolver (or set of resolvers, or even derivative repository URLs) based on the language being used. In addition, I can easily see Wagon implementations looking at the toolchain to decide between a pure-java version of scp and one on the filesystem somewhere...that belongs here (it could be used in many places within the build: SCM, resolution, deployment...).

One way to avoid locking this into the plugin api would be to make the Mojo interface extent ToolchainAware, then AbstractMojo could provide a default (empty) implementation of the methods in ToolchainAware. This allows the plugin API to bring in ToolchainAware from a dependency, which could also be used elsewhere in Maven.

can we increase priority of this one?

Milos, is there anything left to do on this, or should be close it for 2.0.9?

yes, I guess we can close it.

If this is closed then how do I use this feature? I found this: http://docs.codehaus.org/display/MAVEN/Toolchains but it appears to be merely a proposal.

http://maven.apache.org/guides/mini/guide-using-toolchains.html

As noted, there is still some work to be done to make this accessible through plugin releases. See:

http://mail-archives.apache.org/mod_mbox/maven-dev/200809.mbox/%3C86983908-81DA-4974-BF6B-286C9FBE8F6B@apache.org%3E