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
    • 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

        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: