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
--
fedora-devel-java-list mailing list
fedora-devel-java-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
