Maven
  1. Maven
  2. MNG-468

ability to consistently apply a toolchain across plugins

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.9
    • Component/s: Settings, Toolchains
    • Labels:
      None
    • Number of attachments :
      2

      Description

      for things like the JDK, it may be desirable to compile, jar etc. across the board with a particular version of the toolchain, other than the one currently executing. It would be good to be able to configure this location in the settings.xml and have the plugins use it, forking the compiler, using a particular runtime, and generating an appropriate manifest.

      This is likely to be relevant to other languages too.

      1. build.properties
        6 kB
        Milos Kleint
      2. project.properties
        2 kB
        Milos Kleint

        Issue Links

          Activity

          Show
          Milos Kleint added a comment - discussed on mailing list at http://www.nabble.com/-proposal--toolchain-support-for-Maven-2.1-tf1942937.html#a5325520
          Hide
          Milos Kleint added a comment -

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

          Show
          Milos Kleint added a comment - netbeans ant property file in netbeans userdir defining the J2se platform (ak toolchain)
          Hide
          Milos Kleint added a comment -

          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.

          Show
          Milos Kleint added a comment - 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.
          Hide
          Jason van Zyl added a comment -

          build.classes.dir=$

          {build.dir}/classes
          build.classes.excludes=*/.java,*/.form
          # This directory is removed when the project is cleaned:
          build.dir=build
          build.generated.dir=${build.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

          Show
          Jason van Zyl added a comment - build.classes.dir=$ {build.dir}/classes build.classes.excludes=* / .java,* / .form # This directory is removed when the project is cleaned: build.dir=build build.generated.dir=${build.dir} /generated 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} 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= 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} Space-separated list of JVM arguments used when running the project (you may also define separate properties like run-sys-prop.name=value instead of -Dname=value 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
          Hide
          Jason van Zyl added a comment -

          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.

          Show
          Jason van Zyl added a comment - 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.
          Hide
          Jason van Zyl added a comment -

          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.

          Show
          Jason van Zyl added a comment - 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.
          Hide
          Jason van Zyl added a comment -

          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.

          Show
          Jason van Zyl added a comment - 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.
          Hide
          Jason van Zyl added a comment -

          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.

          Show
          Jason van Zyl added a comment - 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.
          Hide
          Brett Porter added a comment -

          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?

          Show
          Brett Porter added a comment - 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?
          Hide
          John Casey added a comment -

          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...).

          Show
          John Casey added a comment - 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...).
          Hide
          John Casey added a comment -

          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.

          Show
          John Casey added a comment - 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.
          Hide
          Milos Kleint added a comment -

          can we increase priority of this one?

          Show
          Milos Kleint added a comment - can we increase priority of this one?
          Hide
          Brett Porter added a comment -

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

          Show
          Brett Porter added a comment - Milos, is there anything left to do on this, or should be close it for 2.0.9?
          Hide
          Milos Kleint added a comment -

          yes, I guess we can close it.

          Show
          Milos Kleint added a comment - yes, I guess we can close it.
          Hide
          David Smiley added a comment -

          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.

          Show
          David Smiley added a comment - 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.
          Hide
          Brett Porter added a comment -
          Show
          Brett Porter added a comment - 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

            People

            • Assignee:
              Milos Kleint
              Reporter:
              Brett Porter
            • Votes:
              9 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: