As I promised overholt on IRC, I wanted to share my views about the Fedora Java packaging guidelines from a non-Java-coder point of view.
- "JNI-using JAR files"
This link is broken. It can be fixed easily.
- BuildRequires: jpackage-utils
Why do we need this? I understand Requires: jpackage-utils for directory ownership etc, but the BR is not necessary for most packages (at least all the ones I saw so far). I think this should *not* be required.
- In certain cases, we can build applications GCJ-natively (producing .so files). But these won't work with any JVM. What should be the packager's primary preference? GCJ-native or OpenJDK? The first one runs faster, but the second one has larger coverage.
For instance, tuxguitar (that I packaged) provides GNU Makefiles (that use GCJ) for this. Are the resulting .so files going to be the same as the ones built by aot-compile-rpm? (More about AOT later)
This case has confused me a lot in the past.
- Some explanation in the beginning about what GCJ can do and what openjdk can do; and some information about byte-code vs. machine-code will be very useful.
- BuildRequires: java-devel [>= specific_version]
How will the packager get to know the "specific_version"? For openjdk this is 1:1.6.0 , but for GCJ this is 1.5.0 . Are there other numbers that we need to know? Can't we put the numbers for all the cases in the guidelines?
- The Specfile Templates for ant and maven contradict with what was written in the BuildRequires and Requires section.
- the abbreviation "SNPG" should be defined in the first possible place, not in the third iteration (both for ant and maven).
- "Will this preserve the line ending as the this page says it must?"
This would be an artistic ending if we were writing a novel. But I think a guideline shouldn't end with open questions :)
- It would be nice if there was a definition of GCJ-AOT bits. What do they do? Why do we like them? What does gij do? etc
- "Note: For Fedora versions < 8, no JDK was available other than GCJ so java packages with executable code MUST have the GCJ AOT bits."
This notice can be removed safely.
- The occurences of
should be removed.
- GCJ AOT bits SHOULD be built and included in packages.
This needs to be more explicit. ie. 's@in packages@in all Java packages@'. I also think that this sentence should go to JAVA GUIDELINES so people click on the link for "GCJ Guidelines". The way that "GCJ Guidelines" link is put there, doesn't give an impression that it should be visited for any possible Java package.
These are all issues I encountered. If I remember more I will post them here. I thought a review on the guidelines from a Java-ignorant person would help other Java-ignorant people in the future. Thanks for reading :)
First, I'm not a programer. I'm maintaining OmegaT and dependencies in
Fedora, all java based.
Since first moment I'm experiencing problems with the CLASSPATH. When
removing it from the MANIFEST I can't get the jvm to find the
dependencies, no matter I set them by the CLASSPATH variable or the -cp
I'm supposing I'm doing (or not doing) something almost trivial. Anybody
have any idea of what I'm doing wrong? Any document to read?
Of course I've readed the Fedora Java package guidelines but doesn't
Thanks in advance.
A. Ismael Olea González
El mundo debe empezar a tener miedo a un planeta OLEA
Back when we wrote the initial Java packaging guidelines, we said that
packagers *should* include GCJ AOT bits. Should we remove this
requirement for Fedora 11 and beyond?
Also, GCJ is still in the base install set for Fedora. Should we remove
this and make OpenJDK a default?
I recently got this query for itext  that is maintained in Fedora by me. I've been asked to provide a "JNI subpackage" . Unfortunately, I am not familiar with JNI.
This person wants to package pdftk , which is a c++ application. The original pdftk code contains an old version of itext and it links to it statically. Meanwhile, the old version of itext had licensing issues and it had been removed from Fedora almost 2 years ago. But these issues got resolved recently and I packaged itext for Fedora once again. Now the question is: Can we link pdftk dynamically to new itext we have on the system?
After some consultation in IRC, I've been told that JNI is not what we need in this case. And a suggestion came up: Apparently we can use GCJ to do this job. But this will require non-trivial hacking. Can anyone point me to some guidelines for this and/or give me a head-start?
Is there anything preventing glassfish-jaxb from being packaged in Fedora?
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
I plan on orphaning jakarta-commons-cli. This package is still required
by checkstyle and others, but I have no interest in maintaining it.
This old bugzilla.....
...tells me there's a new version. I have not managed to make time to
upgrade the package, so I'm hoping somebody with more interest will make
the effort. Contact me if you are willing to take this package over.
The submission system for EclipseCon 2009 is now open:
The deadline is the 24th of November which is coming up very soon.
For those who don't know, EclipseCon is a great conference that is
taking place this year from 23 - 26 March, 2009 in Santa Clara,
California. It's the premiere North American Eclipse gathering and is
an awesome place to learn about the latest Eclipse happenings, interact
with everyone in the community and generally have a good time.
There are a variety of submission categories to choose from so read the
** New for 2009 **
This year we're having a special 1 day Linux DevCon in conjunction with
the Linux Foundation. For this one day sub-conference we are looking
for short talks, long talks, and tutorials dedicated to the intersection
of Eclipse and Linux. We'd like to hear about Linux developments that
will affect Eclipse. Much Eclipse development on and for Linux takes
place on "enterprise" distributions so talks discussing more bleeding
edge developments and ideas about the future of Linux technologies would
be especially welcome. We are also interested in learning about
Linux-specific Eclipse tooling and Linux adoption of Eclipse tools -
what's good, what's bad, what's missing? What recent and upcoming
developments in the Linux ecosystem will affect Eclipse? We would also
like to hear about development, deployment, and use of Eclipse
technologies in multi-platform environments. What are some areas where
Eclipse and Linux technologies can make more effective use of each
other? What can Eclipse learn from Linux and other Free Software/Open
Source communities and vice versa?
Let me know if you have any questions. I look forward to lots of great