Introduction prior GSOC
by Vipul Amler
Hi all,
I am Vipul A. M. a Final Year Computer Science Student.
I am interested to work on Java API/ABI changes checker proposed by
Stanislav Ochotnický
over here [1].
I have been having discussions with him for the past 1-2 weeks and getting
to know more about the Java Packaging
System needs on Fedora{and other, need of all platforms as he says}, and
the various pathways for [1]
Till now, I have been trying to understand more how and where the need for
[1] is
as also the available solutions, and pathways there could be. Me learning
from Java API Compliance Checker [2] and others
our discussions have come down to,
* Developing a Java based framework for matching results for single jar to
that of [1]
* Work on build environment to analyse the breakage at CLASSPATH and other
relevant levels
* Create a comparison based large database for analyzing or suggesting how
to proceed ahead.
* Generate outputs of comparison{in different forms json,xml,etc} that
could be further parsed for other purposes
* Generate Web-View of the same
Some of the use-cases suggested for these are as below
Quoting Stanislav
"
I envision following use cases:
1. packagers will run this on new release of upstream jar, and old
release of upstream jar, compare results and decide how to proceed
2. generate a big database of comparison data for a lot of different
versions of various projects/jars where developers can go and see
the stuff without actually running the tool themselves
3. [possibly in the far future] runs by automatic quality control
tools such as AutoQA that would prevent an update to a package in a
released version of distribution that would break compatibility.
"
So,
what I would try and target more in {the very small 3 months of} GSoC ,is
to first develop a base solution that does
proper analysis and breakage detection at singular unit of jar/build
environment.
After a good base try and handle as many features suggested above, in
future.
I would like hear your thoughts/criticisms, to help me identify any other
approaches.
Cheers
[1]
https://fedoraproject.org/wiki/Summer_coding_ideas_for_2012#Java_API.2FAB...
[2] http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
Vipul A.M.
+91-8149-204995
11 years, 2 months
Plans for Java 7 in EPEL?
by Michael Ekstrand
Are there any plans to add java-1.7.0-openjdk to EPEL? Is there a
particular reason (compatibility, RH is planning to ship it in a RHEL
update, something like that) why it could or should not be done, other
than no one doing it yet?
Best,
- Michael
11 years, 2 months
Ant launcher script
by Andrew Hughes
Hi,
We've had IcedTea8 failing for some time on our Fedora build machine:
JAVA_HOME=/notnfs/nighttester/icedtea8-target-testing/bootstrap/jdk1.6.0 ANT_OPTS=-Djava.io.tmpdir='/notnfs/nighttester/icedtea8-target-testing/openjdk.build/langtools/build/ant-tmp' /usr/bin/ant -diagnostics > /notnfs/nighttester/icedtea8-target-testing/openjdk.build/langtools/build/ant-diagnostics.log ; \
JAVA_HOME=/notnfs/nighttester/icedtea8-target-testing/bootstrap/jdk1.6.0 ANT_OPTS=-Djava.io.tmpdir='/notnfs/nighttester/icedtea8-target-testing/openjdk.build/langtools/build/ant-tmp' /usr/bin/ant -version >> /notnfs/nighttester/icedtea8-target-testing/openjdk.build/langtools/build/ant-diagnostics.log
Error: Could not find or load main class org.apache.tools.ant.launch.Launcher
Error: Could not find or load main class org.apache.tools.ant.launch.Launcher
make[3]: *** [/notnfs/nighttester/icedtea8-target-testing/openjdk.build/langtools/build/ant-diagnostics.log] Error 1
while it succeeds fine for me locally. I've finally managed to have a quick look at
why this is, motivated by the fact that the 6 builds also broke when we upgraded to F16
(though for a different reason).
It seems the Ant script calls /usr/bin/build-classpath by default which in turn runs
/usr/share/java-utils/java-functions. It is set_jvm_dirs in this which fails as it
can't find /usr/share/java-1.8.0:
$ JAVA_HOME=/notnfs/nighttester/icedtea8-target-testing/bootstrap/jdk1.6.0 ANT_OPTS=-Djava.io.tmpdir='/notnfs/nighttester/icedtea8-target-testing/openjdk.build/langtools/build/ant-tmp' /usr/bin/ant --execdebug -diagnostics
exec "/notnfs/nighttester/icedtea8-target-testing/bootstrap/jdk1.6.0/bin/java" -Djava.io.tmpdir=/notnfs/nighttester/icedtea8-target-testing/openjdk.build/langtools/build/ant-tmp -classpath "/usr/bin/build-classpath: error: JAVAVER_LIBDIR /usr/share/java-1.8.0 does not exist or is not a directory:/notnfs/nighttester/icedtea8-target-testing/bootstrap/jdk1.6.0/lib/tools.jar" -Dant.home="/usr/share/ant" -Dant.library.dir="/usr/share/ant/lib" org.apache.tools.ant.launch.Launcher -cp "" "-diagnostics"
Error: Could not find or load main class org.apache.tools.ant.launch.Launcher
Obviously this doesn't yet exist as there is no system 1.8 install. I don't see
why this is worth causing an error and dropping out of the script. Indeed, if
the following lines are commented out:
# elif [ ! -d "$JAVAVER_LIBDIR" ]; then
# echo "$0: error: JAVAVER_LIBDIR $JAVAVER_LIBDIR does not exist or is not a directory"
# return 1
# elif [ ! -d "$JAVAVER_JNIDIR" ]; then
# echo "$0: error: JAVAVER_JNIDIR $JAVAVER_JNIDIR does not exist or is not a directory"
# return 1
the script works fine and produces the same classpath as for 1.6 or 1.7:
JAVA_HOME=/notnfs/nighttester/icedtea8-target-testing/bootstrap/jdk1.6.0 build-classpath ant ant-launcher jaxp_parser_impl xml-commons-apis
/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar
So /usr/share/java-${ver} isn't used anyway. java-1.5.0, java-1.6.0 and java-1.7.0 all exist
but are empty.
Given the script will allow the user to set JAVA_HOME, and this can be to a version < 1.5 or > 1.7,
I see no reason why it shouldn't just silently ignore the path if it doesn't exist, rather than
erroring out.
It's possible to workaround this by passing --noconfig to /usr/bin/ant and setting ANT_HOME, but
I don't know what effect this will have on the numerous other ant scripts on other distributions,
not to mention how we work out what to set ANT_HOME to in the first place. Fixing this script
on the problem distro (Fedora) seems like a much simpler solution.
Would this be possible?
--
Andrew :)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07
11 years, 2 months
shrinkwrap packaging
by Anthony Sasadeusz
Hello,
I'm trying to package all of the separate components of shrinkwrap. So to
start off with I try to build the entire project against rawhide,
investigate the dependencies and then build the seperate packages. The
problem I am having is maven-enforcer-plugin fails with a message
JAVA5_HOME needs to be set. Here is part of the build log.
[WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is
missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for
org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin
org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies
could not be resolved: Failed to read artifact descriptor for
org.eclipse.m2e:lifecycle-mapping:jar:1.0.0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building ShrinkWrap Aggregator and Build Parent 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java-version)
@ shrinkwrap-parent ---
[WARNING] Rule 3: org.apache.maven.plugins.enforcer.RequireProperty
failed with message:
"JAVA5_HOME needs to be set to run some tests in the JRE5 runtime"
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Skipping ShrinkWrap Aggregator and Build Parent
[INFO] This project has been banned from the build due to previous failures.
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] ShrinkWrap Aggregator and Build Parent ............ FAILURE [0.430s]
[INFO] Shrinkwrap Build Resources ........................ SKIPPED
[INFO] ShrinkWrap API .................................... SKIPPED
[INFO] ShrinkWrap Bill of Materials ...................... SKIPPED
[INFO] ShrinkWrap SPI .................................... SKIPPED
[INFO] ShrinkWrap Implementation Base .................... SKIPPED
[INFO] ShrinkWrap Dependency Chain ....................... SKIPPED
[INFO] ShrinkWrap Distribution ........................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.134s
[INFO] Finished at: Mon Mar 19 03:37:50 UTC 2012
[INFO] Final Memory: 15M/210M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-enforcer-plugin:1.0.1:enforce
(enforce-java-version) on project shrinkwrap-parent: Some Enforcer
rules have failed. Look above for specific messages explaining why the
rule failed. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
error: Bad exit status from /var/tmp/rpm-tmp.VFfrT2 (%build)
Bad exit status from /var/tmp/rpm-tmp.VFfrT2 (%build)
RPM build errors:
Child returncode was: 1
EXCEPTION: Command failed. See logs for output.
# ['bash', '--login', '-c', 'rpmbuild -bb --target noarch --nodeps
builddir/build/SPECS/shrinkwrap.spec']
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/mockbuild/trace_decorator.py",
line 70, in trace
result = func(*args, **kw)
File "/usr/lib/python2.6/site-packages/mockbuild/util.py", line 352, in do
raise mockbuild.exception.Error, ("Command failed. See logs for
output.\n # %s" % (command,), child.returncode)
Error: Command failed. See logs for output.
# ['bash', '--login', '-c', 'rpmbuild -bb --target noarch --nodeps
builddir/build/SPECS/shrinkwrap.spec']
LEAVE do --> EXCEPTION RAISED
11 years, 2 months
Roadmap for Java things in Fedora
by Stanislav Ochotnicky
Hi,
I believe it might be nice to get everyone up to speed on what is
happening in Java world in Fedora and what is planned in near future.
1. Packaging guidelines updates
- I'd like to add guidelines for packaging compat libraries. Maven
already has support for this (see [1]) so I'd like to describe how
to package compat things properly. Together with unversioned jars we
already have, this is gonna make things easier. I'll add big red
"DON'T DO THIS IF YOU DON'T HAVE TO" of course...
- Remove mention of maven2 in guidelines since all supported versions
have maven-3.x. Some other small cleanups as well perhaps
- Add optional use of %generate_javadoc macro that automates
generating of javadoc subpackages (already available for a while,
not used though :-) )
- Update JNI part of the guidelines to reflect current practice. The
guidelines are actually out of date for JNI.
- If you have things you'd like to include, please do changes directly
to [2] and we can discuss them later. We can always revert them if
we decide not to do whatever you come up with. Just propose
something sane :-)
2. Improvements to Maven packaging and creating of Maven repository
- Carlo de Wolf is working on new maven macros/extension[3] that
would enable us to provide a proper Maven repository to developers
so that they can test against our Fedora versions more easily
- There are still a few questions that need to be answered, but I
believe this will be the future for us barring any catastrophic
failures :-)
3. Various packaging efforts
- JBoss AS 7
A F17 feature, a big chunk of JBoss AS 7 has already been packaged,
but more packages are still on the way. I am sure Marek Goldman who
is the main person driving this effort will appreciate any package
reviewers wanting to drop by. See [4] for current status
- Resteasy, Picketbox, Hibernate and few other things
Work being done by various people on #fedora-java. Currently some
work depends on JBoss being packaged so we'll see how it goes. It
would be nice to have some real-time status of these things I guess
so for the future I created [5].
If you have something to add, please do so! I CCed fedora-java, please
post replies to devel@ though :-)
[1] https://bugzilla.redhat.com/show_bug.cgi?id=757732
[2] https://fedoraproject.org/wiki/User:Akurtakov/JavaPackagingDraftUpdate
[3] https://github.com/wolfc/fedora-maven
[4] https://fedoraproject.org/wiki/JBossAS7#Current_progress
[5] https://fedoraproject.org/wiki/SIGs/Java#Ongoing_projects
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
11 years, 2 months
