Java packages and target bytecode
Hi, Lot of Java packages from JPackage/Fedora and other distros would build "as is" on openSUSE/SLE except for a small "mess". - SLE requires target bytecode set to 1.5. (because there is only 1.5 Java for all archs) - This bytecode requirement is usually fixed by changing the ant call to ant -Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5. However sometimes you need to pass similar options to javac or mvn-jpp if they are invoked from the spec file. - Even while SLE requires 1.5 bytecode, %{ant} evaluates to "JAVA_HOME=/usr/lib64/jvm/java ant", the same as in openSUSE - Some specs call %{ant}, but others just call ant. I am tired of editing spec files only to add this SLE specific requirement in order to keep packages building for all repositories. So I am looking for a better solution for our Java:base repository. One solution I was thinking was to create a helper package installing an alias in /etc/profile.d so that ant becomes ant -Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5. Add this package to the project config surrounded by if sle_version. A similar alias would be added for mvn-jpp. However I could not get this to work with rpm. This would allow to build the packages that use "ant" or "mvn-jpp" directly without touching the spec file. Fixing the spec files to use %{ant} would still be possible in parallel, but is not worth while this fixes do not go upstream and a similar macro would be needed for mvn-jpp. I am open to hear more solutions. Another may be using source services to "fix" the spec file, but that would require to add a _service per package. Only have in mind that the goal is to not touch the spec file, but either workaround it in the project setup, or to adapt SUSE conventions so that other's packages become buildable. And the ideal solution of course would be to fix all packages to use a target macro, but this is only worth if these changes go upstream to Fedora and JPackage. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
On Wed, Jul 06, 2011 at 05:35:05PM +0200, Duncan Mac-Vicar P. wrote:
Hi,
Hi Duncan,
Lot of Java packages from JPackage/Fedora and other distros would build "as is" on openSUSE/SLE except for a small "mess".
- SLE requires target bytecode set to 1.5. (because there is only 1.5 Java for all archs) - This bytecode requirement is usually fixed by changing the ant call to ant -Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5. However sometimes you need to pass similar options to javac or mvn-jpp if they are invoked from the spec file. - Even while SLE requires 1.5 bytecode, %{ant} evaluates to "JAVA_HOME=/usr/lib64/jvm/java ant", the same as in openSUSE - Some specs call %{ant}, but others just call ant.
I am tired of editing spec files only to add this SLE specific requirement in order to keep packages building for all repositories. So I am looking for a better solution for our Java:base repository.
One solution I was thinking was to create a helper package installing an alias in /etc/profile.d so that ant becomes ant -Dant.build.javac.source=1.5 -Dant.build.javac.target=1.5. Add this package to the project config surrounded by if sle_version. A similar alias would be added for mvn-jpp. However I could not get this to work with rpm.
This cannot work because you found the bash-starting-madness. Which is bash can start in various modes and read the various files depending on the mode. The /etc/profile(.d/*) is read only when it's started as a login shell. And rpmbuild don't call it as a login shell. What makes things worse for you is that rpmbuild is not call bash by default, but /bin/sh. And probably you now have the poiny - sh is an another mode and in this case it does not read **any** configuration file.
This would allow to build the packages that use "ant" or "mvn-jpp" directly without touching the spec file. Fixing the spec files to use %{ant} would still be possible in parallel, but is not worth while this fixes do not go upstream and a similar macro would be needed for mvn-jpp.
I am open to hear more solutions. Another may be using source services to "fix" the spec file, but that would require to add a _service per package. Only have in mind that the goal is to not touch the spec file, but either workaround it in the project setup, or to adapt SUSE conventions so that other's packages become buildable.
OK, so here is my total crazy one: We will create ant-target15 package, which will contains /usr/bin/ant enforcing the 1.5 target/source by default. This package will conflicts with ant and will be enforced by prjconf of the project. There is ony one remaining problem - in the ant's world command line arguments can be overrided by build.xml, which will probably never win the-best-design-of-the-year. But on the other hand, if we are going to have own ant package, why not patch it to ignore values higher than 1.5, so even build.xml with <javac target="1.6" /> will be built using target 1.5. I think it is really simple, we need just change the getTarget and getSource methods os Javac.java taskdef, so the values up 5/1.5 will be ignored. See the quick patch Index: apache-ant-1.8.2/src/main/org/apache/tools/ant/taskdefs/Javac.java =================================================================== --- apache-ant-1.8.2.orig/src/main/org/apache/tools/ant/taskdefs/Javac.java 2010-12-20 19:48:16.000000000 +0100 +++ apache-ant-1.8.2/src/main/org/apache/tools/ant/taskdefs/Javac.java 2011-08-04 13:13:22.392129625 +0200 @@ -176,13 +176,22 @@ this.debugLevel = v; } + private String get15(String target) { + if (target.equals("6") || target.equals("7") || target.equals("8") + target.equals("1.6") || target.equals("1.7") || target.equals("1.8")) { + return "1.5"; + } + return target; + } + /** * Get the value of source. * @return value of source. */ public String getSource() { - return source != null - ? source : getProject().getProperty(MagicNames.BUILD_JAVAC_SOURCE); + return get15(source != null + ? source : getProject().getProperty(MagicNames.BUILD_JAVAC_SOURCE)); + } /** @@ -610,9 +619,9 @@ * @return the target VM */ public String getTarget() { - return targetAttribute != null + return get15(targetAttribute != null ? targetAttribute - : getProject().getProperty(MagicNames.BUILD_JAVAC_TARGET); + : getProject().getProperty(MagicNames.BUILD_JAVAC_TARGET)); } /** What would you say? I can create such package easily. Regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-java+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-java+help@opensuse.org
participants (2)
-
Duncan Mac-Vicar P.
-
Michal Vyskocil