Suggestions to improve the JAVA guidelines
by Orcan Ogetbil
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.
- 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 :)
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.
- 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@'. 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 :)
-oget
14 years, 9 months
Eclipse p2's artifacts.xml/jar and hard-coded paths
by Sean Flanigan
From irc the other day:
<akurtakov_> artifact.xml is simply unusable because it has paths from
build time in it
<akurtakov_> and the repo is invalid with only content.xml
I can see that artifacts.xml does contain some build-time filesystem
paths, but I don't really understand the problem, since Eclipse doesn't
seem to care too much.
Are there any old discussions about this that I should be reading,
instead of bothering the list?
I'm interested because I have found that suitably massaged
(optional+non-greedy) P2 metadata can help Eclipse to cope with the
Babel langpacks and the fragment plugins they contain:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=256430
So I would like to include the P2 metadata with eclipse-nls (RPMs for
the Babel langpacks).
1. Does Eclipse in fact care about these paths? In which case, why does
P2 work (occasionally!) on my machine, with completely different
filesystem paths?
2. Is there a Fedora packaging rule that says build-time paths are not
allowed into packages, perhaps because they make it impossible to
reproduce byte-identical builds?
3. Assuming one of the above is true: Could we sed-patch the
artifacts.xml file to remove/normalise the build path?
4. Alternatively, would it help if we were to use the P2 director to
install eclipse-nls from a local update site, thus installing the
features the P2 way, rather than using dropins?
Thanks
Sean
--
Sean Flanigan
Senior Software Engineer
Engineering - Internationalisation
Red Hat
15 years
general maven questions
by Christoph Höger
Hi guys,
according to https://bugzilla.redhat.com/show_bug.cgi?id=429551
rebuilding maven is a mess. While waiting for progress patiently, I have
some more general questions about maven in fedora:
1. I see a lot of maven-* packages floating around. How are those
supposed to do anything? Doesn't maven download all stuff from the cloud
[tm]?
2. If I want to package a maven project, how would I do that?
Especially: How do I manage dependencies?
3. Does anyone know if mavens pde plugin is ever going to work again?
regards
Christoph
15 years
Packaging toot2
by Orcan Ogetbil
Hi,
On the package review of toot2 [1], Alexander pointed me that the
source tree contains a few files from the tritonus project [2].
Normally, as the guidelines request, we package every library
separately.
I would like to ask if an exception can be provided in this case.
tritonus is a large project, and packaging it (and its dependencies)
is a lot of work (for instance, tritonus contains mp3 encoder/decoders
and therefore needs patched) , and I'm not much enthusiastic about
packaging it.
toot2 contains 5 independent java files (out of ~500) from tritonus.
So, can we tolerate these 5 files slipping in? What do you think?
Orcan
[1] https://bugzilla.redhat.com/show_bug.cgi?id=492197
[2] http://www.tritonus.org/
15 years
Drop GCJ AOT bits for F12?
by Orcan Ogetbil
Here is the original thread:
https://www.redhat.com/archives/fedora-devel-java-list/2008-November/msg0...
So, shall we or shall we not?
* Andrew Haley wrote:
> Andrew Overholt wrote:
>
> > 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?
> >
> > [...]
>
> This is a bit premature. We still don't have the OpenJDK JIT for PPC and
> ARM arches. We're working hard on it but it's not ready yet for prime-time.
> Without the JIT, OpenJDK is crushingly slow on these arches.
Any progress on these parts?
Orcan
15 years
Re: [fedora-java] Very slow Eclipse on F10
by samk＠twinix.com
See Thread at: http://www.techienuggets.com/Detail?tx=70547 Posted on behalf of a User
I had exactly the same problem here and managed to reduce it (using strace) to timeouts communicating with another host on our network - which turned out to be configured as the eclipse host's print server in /etc/cups/client.conf.
After upgrading the printing configuration "as it should be" - using localhost in /etc/cups/client.conf and setting up browsing in the local cups configuration to automagically attach the printers exported by the network cups server - opening new editors in eclipse became instantaneous.
Background:
- run:
strace -f -tt -o /tmp/eclipse eclipse
- reproduce the delay
- run:
cat /tmp/eclipse | grep AF_INET
This will show all network communication performed by eclipse. You'll be looking for 'connect' calls returning EINPROGRESS / EALREADY followed by a delay (cf. time stamps in the second column).
HTH.
In Response To:
Before I file this in bugzilla, I wanted to check if it's just my
problem ... Lately, in Eclipse (3.4.1 on Fedora 10), I've been
noticing that it takes several seconds to open a new editor. So if I
click on a Java source file (in Java perspective), the new tab appears
immediately, but it takes several seconds for the actual editor to
finish rendering. In the meantime, the tab just says "Java editor".
Similar things happen with the Ant buildfile editor.
I have several third-party plugins installed that I don't want to
remove unless I have to, which is why I wanted to check first -- is
anyone else seeing similar symptoms?
Thanks,
MEF
--
Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/
Informatik 6: Robotics and Embedded Systems, Technische Universität München
and ICCS, School of Informatics, University of Edinburgh
--
fedora-devel-java-list mailing list
fedora-devel-java-noway(a)spam.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list
15 years
