[jira] Commented: (MCOMPILER-65) Intelligent fork or bootclasspath based on desired target JDK

["Joerg Schaible (JIRA)" <ji...@codehaus.org>]

    [ http://jira.codehaus.org/browse/MCOMPILER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122023 ] 

Joerg Schaible commented on MCOMPILER-65:
-----------------------------------------

It's too short sighted to think only of JDK 1.4 vs. JDK 5. For some libraries it makes also a tremendous difference which vendor delivered the JDK, because a JDK 5 delivered by Sun, IBM, BEA, Apple, SAP, Hitachi, Oracle and the more individual JDKs like Apache Harmony, gcj, IVKM may really behave different. Simply because it is not relevant for a lot of applications (or they do not care using com.sun.* classes and therefore enforcing a JDK) it should be supported by Maven. By defining individual JDKs in the settings using an individual id (like it is done for servers), you may support such a strategy.

> Intelligent fork or bootclasspath based on desired target JDK
> -------------------------------------------------------------
>
>                 Key: MCOMPILER-65
>                 URL: http://jira.codehaus.org/browse/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 http://madbean.com/2006/target14/ ) 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: http://maven.apache.org/general.html#Compiling-J2SE-5  -- 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: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira