maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] Commented: (MCOMPILER-65) Intelligent fork or bootclasspath based on desired target JDK
Date Fri, 02 May 2008 21:47:46 GMT


David Smiley commented on MCOMPILER-65:

Great, it appears that this new "Toolchains" feature of Maven specifically addresses this
concern.  Hopefully it'll be the standard way the compiler is executed in maven.  Does this
replace the compiler plugin somehow?  If not I think it'll add configuration complexity because
then there are two areas to configure this, the compiler and toolchain.

> Intelligent fork or bootclasspath based on desired target JDK
> -------------------------------------------------------------
>                 Key: MCOMPILER-65
>                 URL:
>             Project: Maven 2.x Compiler Plugin
>          Issue Type: Improvement
>            Reporter: David Smiley
> I work with Maven on a few projects, some jdk 1.4, some jdk 1.5.  The only way to get
a consistent compiled build is to fork the compiler so that a particular jdk is used, it's
not necessarily enough to set the "source" and "target" params on the compiler plugin ( see ) for an explanation.  I say not necessarily in part not
just on the info in that referred URL, but we really can't and shouldn't assume that maven
itself is using a particular jdk either.  I think this is a big deal and I would guess that
the maven team would also think it's a big deal based on a cornerstone philosophy of repeatable
builds.  -- Builds that shouldn't come with special instructions to do some magic (like run
maven in a certain VM or set certain system properties).
> This issue needs to be more prominently displayed in the maven documentation, both for
the plugin and most certainly this FAQ entry:
 -- if only it were that simple.
> I have an idea for a solution that involves only forking when necessary and if not that
possibly setting the bootclasspath.  The idea is to avoid forking, and to avoid setting bootclasspath
if neither are necessary.  And of course the result is a compiler configuration that can and
should be as simple as setting the "target" param to get a repeatable build no matter what
JDK maven is running under. 
> 1. Standardize on the system property names for the java homes, i.e. JAVA_1_4_HOME JAVA_1_5_HOME
etc.  Furthermore... this *should* be set in the user's settings.xml.  Yes this means installation
requires another step but I see no way around that unless maven were to try and figure out
these based on operating-specific logic.
> 2. Based on the "source" and "target" parameters, determine wether (a) Maven's current
VM can be used as-is without setting bootclasspath for javac (b) Maven's current VM can be
used but needs to set the bootclasspath for javac, or (c) fork and use an external javac.
 If (a) can be chosen then the standardized property names don't need to be consulted.  In
(b) the java home is needed for the bootclasspath, and in (c) to fork javac.  Also, ensure
that the choice of a,b,c is somehow displayed in the maven output so the developer knows.
> Implementation note:  I noticed that the maven compiler plugin uses Ant heavily to do
its job.  In light of that, implementing this feature might instead involve enhancing the
ant side to have this feature and then making minor changes on the maven side to accommodate

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message