can I assume this proposal is ok with everyone and start some initial work on it?
Milos On 9/2/07, Milos Kleint <[EMAIL PROTECTED]> wrote: > Hello, > > See: http://docs.codehaus.org/display/MAVEN/Toolchains > > Text included below for inline comments (which I'll feed back into > the document as needed). > > Milos > > > Goal > > Have a way for plugins to discover what JDK (or other tools) are to > be used, without configuring the plugins. The current Maven way of > achieving this is to run Maven itself with the required JDK. After > toolchains, the JDK that Maven is running within, shall be irrelevant > to the project in question. > Motivation > > Current way or enforcing project's JDK version (via the enforcer or > otherwise) by forcing the user to run Maven itself with the given JDK > version breaks embedded use. > Additionally toolchains will allow a type of user interaction that IDE > users are used to. Just set the JDK to the project and go. > > Design > > Note: I'll be focusing on JDK toolchain. I don't have enough > background information for other types of toolchains. > The associated issue is: MNG-468 > > 3 basic points of view: > > 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?). 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. > > Q1: how shall the plugin tell what toolchains it needs? parameter? > parameter's or mojo's @toolchain annotation? > > 2. User defines the toolchain instances that are available in his > current setup. Shall be project independent, stored in > $HOME/.m2/toolchains.xml file? > Could look like this: > > <toolchains> > <toolchain> > <type>jdk</type> > <instanceId>jdk15</instanceId> > <configuration> > <directory>/home/mkleint/javatools/jdk1.5.0_07</directory> > </configuration> > </toolchain> > <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. > > <toolchains> > <toolchain> > <type>jdk</type> > <instance>jdk15</instance> > </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> > <plugin> > <artifactId>maven-toolchain-plugin</artifactId> > <configuration> > <toolchains> > <jdk>jdk15</jdk> > <j2me>toolkit22</j2me> > <toolchains> > </configuration> > </plugin> > </plugins> > > 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? > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
