maven-issues mailing list archives

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

                 Key: MCOMPILER-65
             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 them.

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