Message-ID: <1026414416.12211.1422665782870.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_12210_1083256.1422665782870" ------=_Part_12210_1083256.1422665782870 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
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
to= olchains, the JDK that Maven is running within, shall be irrelevant
t= o the project in question.
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.
maven-compi= ler-plugin maven-surefire-plugin <= a href=3D"http://maven.apache.org/plugins/maven-javadoc-plugin/" class=3D"e= xternal-link" rel=3D"nofollow">maven-javadoc-plugin keytool-maven-plugin exec-maven-plugin = webstart-maven-plugi= n
native tools? c#?
nbm-maven-plugin The= various goals could make use of it.
Note: I'll be focusing on JDK toolchain. I don't have enough
backg= round information for other types of toolchains.
The associated issue= is: MNG-468
3 basic points of view:=20
1. Plugin denotes what toolchain type it requires for i=
operation. So compilation, surefire, jnlp, ... need a JDK toolcha= in
instance for example. The actual instance of the toolchain is pass= ed
into the plugin by the infrastructure (using MavenSession in curre= nt implementation).
Most current plugins that use JDK for processing,= use the maven's JDK instance by default. The only change introduced is
to use the toolchain in the MavenSession if found. If not, do as we did = so far.
Q1: how shall the plugin tell what toolchains it needs? parameter?
= parameter's or mojo's @toolchain annotation? The actual retrieval of the t= oolchain from build context can be done completely behind the scenes, so ma= rking the plugin as toolchain-aware is primarily documentation oriented.
2. User defines the toolchain instances that are availa=
ble in his
current setup. Shall be user based, project independent, s= tored in
Example toolchains.xml = file:
3. Project shall be allowed to state which instance of =
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 ear= ly.
For this purpose a new plugin (maven-toolchain-plugin) is introdu= ced.
It is responsible for matching the correct
toolchain insta= nces from the user's setup against the requirements of the project and make= it available for other plugins to use (in the build
The process of matching required toolchain against the provided ones is = following.=20
The changes are rather simple. An additional dependency on the toolchain= s component artifact is necessary and then a short code snippet added to mo= jo's execute method.=20 =20
after compiling, make sure you put the jar with toolchain components int=
o the 2.1-SNAPSHOT maven binary, into the lib/ subfolder.
Attached is= sample project and toolchain definition.