2.1's toolchains

[Milos Kleint <mk...@gmail.com>]

Hey,


I've been thinking about toolchains support lately. Here's what I came
up with, as a starter for discussion.


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 (mine at least):
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. (What are they?)
But the basic principles shall be the same.

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
${user.home}/.m2/toolchains.xml file? The exact persistence format
TBD.

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>

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


Comments? Anyone already working on toolchains? or planning to?


Milos

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: 2.1's toolchains

[Jason van Zyl <ja...@maven.org>]

If you want to actively start designing it then put it in here:

http://docs.codehaus.org/display/MAVEN/Home

In the "Design in Progress"

I think there are relatively few people interested (I am but too  
swamped to help you ATM) and this will get lost in the shuffle and if  
you put in the Wiki on that page there then people will know that you  
are focused on this.

On 25 Jun 07, at 2:38 AM 25 Jun 07, Milos Kleint wrote:

> Hey,
>
>
> I've been thinking about toolchains support lately. Here's what I came
> up with, as a starter for discussion.
>
>
> 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 (mine at least):
> 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. (What are they?)
> But the basic principles shall be the same.
>
> 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
> ${user.home}/.m2/toolchains.xml file? The exact persistence format
> TBD.
>
> 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>
>
> 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).
>
>
> Comments? Anyone already working on toolchains? or planning to?
>
>
> Milos
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org