Re: [PROPOSAL] toolchains
On 7 Sep 07, at 2:36 AM 7 Sep 07, Milos Kleint wrote: can I assume this proposal is ok with everyone and start some initial work on it? The plan was that we collect all the proposals, and give people until next friday. Then we decide what will be done and in what release. If you want to start features then do it on a branch because the first couple releases should focus on making sure that regressions are eliminated (alpha-1), and then alpha-2 should focus on usability i.e. making every last possible thing that can go wrong reaches a user in a way that is understandable. Honestly your changes of adding a feature like toolchains being done prior to some key components being refactored and the plugin api sort I think will be hard. I am focusing solely on cleaning up code to prepare for people like you being able to add features but if you want to start now and prepare then please do it in a branch and just pull in the changes I'm making from trunk. We have to focus on compatibility and usability and test that for the first couple releases. The alpha-1 can be cut when the prereqs are done (doxia and maven-artifact) and the regressions are gone. The second release should be the improvements users most need and that's understanding anything problem that occurs. There really also needs to be some refactoring in the core before you could do a serious stab at toolchains. 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: jdk jdk15 /home/mkleint/javatools/jdk1.5.0_07directory> 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. jdk jdk15 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). maven-toolchain-plugin jdk15 toolkit22 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] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com --
Re: [PROPOSAL] toolchains
Yeah, go for it - lazy consensus :) I actually started to flip through this the other day - I'll take another look. I also started marking JIRA issues that might be related with [toolchain]. - Brett On 07/09/2007, at 7:36 PM, Milos Kleint wrote: 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: jdk jdk15 /home/mkleint/javatools/jdk1.5.0_07directory> 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. jdk jdk15 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). maven-toolchain-plugin jdk15 toolkit22 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] -- Brett Porter - [EMAIL PROTECTED] Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] toolchains
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: > > > > jdk > jdk15 > > /home/mkleint/javatools/jdk1.5.0_07 > > > > > 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. > > > > jdk > jdk15 > > > > 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). > > > > maven-toolchain-plugin > > > jdk15 > toolkit22 > > > > > > 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]
[PROPOSAL] toolchains
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: jdk jdk15 /home/mkleint/javatools/jdk1.5.0_07 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. jdk jdk15 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). maven-toolchain-plugin jdk15 toolkit22 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]