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:
<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]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
