| Summary: | Merge-time rewriting of build.xmls | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Karl Trygve Kalleberg (RETIRED) <karltk> |
| Component: | Current packages | Assignee: | Java team <java> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | iyosifov, java, Martin.vGagern |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 127816 | ||
| Bug Blocks: | 65937 | ||
| Attachments: |
GentooJavac.java
Patch to use build.source and build.target properties as default Patch to commons-pool-1.2.ebuild to add source version buildfile_rewrite.xsl gentoo.build.xml - wrapper around buildfile |
||
|
Description
Karl Trygve Kalleberg (RETIRED)
2005-03-27 15:09:03 UTC
I suggest the following ant-based solution:
1) compile the attached source in , say , GentooJavac.jar
2) place the GentooJavac.jar in /usr/share/ant-core/lib
3) append ":/usr/share/ant-core/lib/GentooJavac.jar" to CLASSPATH in
/usr/share/ant-core/package.env
Now the class org.gentoo.GentooJavac will be visible to ant
4) edit the java-pkg.eclass. Somewhere near the begining of the file add:
export _JAVA_OPTIONS_SAVE=${_JAVA_OPTIONS}
export _JAVA_OPTIONS="${_JAVA_OPTIONS} -Dbuild.compiler=org.gentoo.GentooJavac"
Contents of _JAVA_OPTIONS are passed to the jvm on startup. The build.compiler property
makes ant use the specified compiler adapter class instead of it's default. Since all
java ebuilds inherit this eclass, all will be affected. So far, we have effectively
reverted the compiler defaults to -source 1.4 -target 1.4 , as far as ant projects are
concerned.
5) In ebuilds that need 1.5 or do their own source/target managment call before the
build proccess:
export _JAVA_OPTIONS=${_JAVA_OPTIONS_SAVE}
Thus the system compiler will be used, instead of our stub, and if the user already
has something in _JAVA_OPTIONS it will not be lost. The above may be placed in a
function , say , use_system_javac() and moved to the eclass.
Using the above technique I've been able to compile a small ant-based test project that
uses enum as an identifier and to get the java ebuilds I tested to fail for
non-language reasons, but rather for the excesive use of com.sun.* packages
( non-public API ).
Created attachment 55798 [details]
GentooJavac.java
The source of the compiler adapter. A very basic, first shot, implementation.
Or this: http://forums.gentoo.org/viewtopic-t-317253.html Hello ? we already have a solution for this problem, compnerd wrote something with python for it which will be integrated into java-config-ng... i've also created an xslt stylesheet for that purpose but we're going to use a dom solution. anyways, thanks for your effort >>> we already have a solution for this problem
Good to hear that.
Please post such messages on bugs for which you already have a solution, because from the outside it looks like nobody is working on it.
I don't see anything checked in to cvs for java-config-ng...maybe a pointer to where it lives might help. Convincing ant to do the right thing requires something similar to what Ivan proposed. I'd extend it slightly so that when the source property is set, it actually takes its default value from a "build.source" environment variable. We can then use the ANT_OPTS environment variable to include "-Dbuild.source=1.4", and every version of ant will get that. Prior to calling the ant execution script JAVACMD can be set to point to any arbitrary VM. The javac task will use the compiler that are part of its running VM, by default. You can create many combinations -- for example: ANT_OPTS="-Dbuild.source=1.4" + JAVACMD="/jdk1.4/bin/java" Creates complete 1.4 compatibility ANT_OPTS="-Dbuild.source=1.4" uses default system VM, but compiles with compatibility to 1.4 source level. There are very few places in the Java library that will prevent a 1.4 program from compiling with 1.5 as is, if the -source 1.4 switch is set. The biggest offender is probably the XML base classes. The newer XML spec has a lot of extra stuff, and packages that implement their own XML nodes (like Batik) need a fair amount of massaging; anything that just uses the Java library as its base classes is fine. You can also point the java5 compiler at a boot class path consisting of 1.4 jars, and it works just fine. Personally I think the java-config program needs to support a dialect (-d) option; that seems a simple enough solution. Is there some way to help? I believe those build.source and build.target properties could be useful enough to be supported by ant itself, where ist should be not too difficult to implement. I filed an enhancement request: http://issues.apache.org/bugzilla/show_bug.cgi?id=35325 Created attachment 61028 [details, diff]
Patch to use build.source and build.target properties as default
I used this patch in ant-core-1.6.2-r3 and afterwards successfully emerged
dev-java/commons-pool-1.2 (which uses enum as an identifier in its sources and
therefore is not valid 1.5 code) with sun-jdk-1.5.0.03 using
ANT_OPTS="-Dbuild.source=1.4" emerge -1 dev-java/commons-pool
Created attachment 61029 [details, diff] Patch to commons-pool-1.2.ebuild to add source version I just successfully tested the approach suggested by Alexey Solofnenko at http://issues.apache.org/bugzilla/show_bug.cgi?id=35325 This patch shows how an ebuild might be modified to change the default values of the javac task's arguents without modifying the build.xml at all. I guess this should be moved to some eclass if it is to be applied to lots of packages. Created attachment 74394 [details]
buildfile_rewrite.xsl
I read on axxo-overlay/README/todo that buildfile rewriting seems to be still
an issue, and an XSLT approach was still discussed. I checked that this file
here works for example with the external entity in openjnlp. The content of
this external entity is included and processed as well.
"xsltproc --param version 1.3 buildfile_rewrite.xsl targets/OpenJNLP/build.xml"
Created attachment 74395 [details] gentoo.build.xml - wrapper around buildfile This is a refined form of the approach used in comment #10. Simply copy this file to the same directory as the original buildfile and specify it with the ant -f flag. No matter whether a target is named on the command line or not, this build file will build the corresponding target from the original build file. Any "-f filename" switch already present on the command line should be replaced by "-Dgentoo.antfile=filename", taking care of spaces of course. Also add "-Dgentoo.source=..." and "-Dgentoo.target=...", probably with values from the environment, and I would think the whole thing (copy file, change command line) could be used as a wrapper around ant, located in some ebuild. The new Java system which does this has been unmasked. Marking fixed. See the upgrade guide: http://www.gentoo.org/proj/en/java/java-upgrade.xml |