You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "David Smiley (JIRA)" <ji...@codehaus.org> on 2008/02/01 13:47:57 UTC
[jira] Created: (MCOMPILER-65) Intelligent fork or bootclasspath
based on desired target JDK
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
[jira] Commented: (MCOMPILER-65) Intelligent fork or bootclasspath
based on desired target JDK
Posted by "David Smiley (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MCOMPILER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_122035 ]
David Smiley commented on MCOMPILER-65:
---------------------------------------
I was about to suggest that adding a "targetVendor" attribute would address your concern (and I suppose it would), but then I got thinking about an entirely different approach. What if a project didn't articulate that it was targeting jdk 1.4 via "target", what if it used a dependency? For example here's a hypothetical groupid:artifactId:version -- java:java:1.4 and the proposed scope would be something like "jdk". The installed JDK's pom would transitively depend on java:java:1.4 but it would itself offer it's extras. It's pom might be something like com.sun:java:1.4.2 So if you want sun's stuff, you refer to com.sun:java:1.4.2 otherwise you refer to just java:java:1.4. This would be a sort of special dependency that isn't searched for in repos since the installed JDKs contain it. It's something that maven would make available specially.
What do you think?
In any case... the status quo of just "source" and "target" is misleading and arguably a bad practice if maven's philosophies are to be taken to heart.
> 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
[jira] Commented: (MCOMPILER-65) Intelligent fork or bootclasspath
based on desired target JDK
Posted by "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
[jira] Commented: (MCOMPILER-65) Intelligent fork or bootclasspath
based on desired target JDK
Posted by "David Smiley (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MCOMPILER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133365#action_133365 ]
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: 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
[jira] Commented: (MCOMPILER-65) Intelligent fork or bootclasspath
based on desired target JDK
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MCOMPILER-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133396#action_133396 ]
Benjamin Bentmann commented on MCOMPILER-65:
--------------------------------------------
bq. Does this replace the compiler plugin somehow?
No, the toolchains will only help the Compiler Plugin to locate a JDK (javac, boot class path). For more information/questions, please use the comments thread of the wiki article, where Milos Klient, the author of the proposal, can hopefully shed some more light on your concerns.
> 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
[jira] Commented: (MCOMPILER-65) Intelligent fork or bootclasspath
based on desired target JDK
Posted by "Benjamin Bentmann (JIRA)" <ji...@codehaus.org>.
[ 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