Apparently Conrad forgot to send his reply to the mailing list. With his permission
I'm quoting the message he sent to me:
--- On Wed, 11/19/08, Conrad Meyer wrote:
> Hi,
> 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.
>
> JAVA GUIDELINES:
>
> - "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.
rpm -ql jpackage-utils | grep /usr/bin
A lot of these are useful.
Yes, I agree. But can't we leave the BR out for those packages which don't use
these tools?
> - 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.
We prefer both, but only require .class files (compiled by
either GCJ or
OpenJDK).
> 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.
I think we require you to ship .class files as well if
it's a java project.
Let's make this clear: .jar files are nothing but containers of .class files and a
manifest file, right? When you say we require .class files, does that imply that we
require them either standalone or inside some .jar file? If yes, these statements should
go to the guidelines.
Also, I'd be glad if someone answers my question above?
> - 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?
Just those, I think. Adding them somewhere couldn't
hurt.
> - The Specfile Templates for ant and maven contradict
with what was written
> in the BuildRequires and Requires section.
How?
In the "BuildRequires and Requires section", it states that we need to put
explicit versions for R:java and BR:java-devel. Yet in the templates no explicit versions
were used or indicated.
> - the abbreviation "SNPG" should be defined
in the first possible place,
> not in the third iteration (both for ant and maven).
It's commonly used by other
non-normal-packaging-guidelines documentation, but
this confused me at first as well.
> - "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 :)
>
> GCJ GUIDELINES:
>
> - 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.
When this was written F-7 wasn't yet EOL, I think.
Agreed.
> - The occurences of
> %attr(-,root,root)
> 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@'.
Eh, it's in the GCJ/Java guidelines page, not anything
for all packages.
I am not saying "all packages". I say "all Java packages". I have to
say that being explicit clears an important amount of confusion in most cases I encounter
in life.
> 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.
Makes sense.
> 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 :)
>
> -oget
I agree with most of your criticisms and would welcome
these changes. I think
the wiki page is locked though.
Regards,
--
Cheers,
-oget