[
http://jira.codehaus.org/browse/MCOMPILER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133301#action_133301
]
Benjamin Bentmann commented on MCOMPILER-65:
--------------------------------------------
Compare the related proposal about
[Toolchains|http://docs.codehaus.org/display/MAVEN/Toolchains].
> 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
