That makes sense. I mean that, I understand the gentoo philosophy concerning source code, however, I don't think it really applies to java code. Java byte code is supposed to compile the same everywhere. There are very few javac options which will affect the bytecode coming out. If compilation to native code is needed, gcj et al. can handle compiling bytecode. Point being, there's no benefit to compiling from java source (except to native), and if the distributers will compile it for you it only saves cpu cycles.
The second thing with distributers packing their own jars in I understand. I can only say that if it does waste memory to have extra jars lying around, it's still better to have that and the application than no application at all. At least in my book. A solution could be worked out later to put the jars in their own ebuilds.
The third thing, and I mention it now to make up for being perhaps overly critical of a process I know very little about, is why I joined this list in the first place. I'd like to help the gentoo-java project. I don't know much about how to help, though, so if anyone could point me in the right direction I'll come back later in a better position to help.
~Cheers
p.s.
On 7/8/06, Wiktor Wandachowicz <siryes@gmail.com> wrote:
2006/7/8, William L. Thomson Jr. <wlt@obsidian-studios.com>:
> On Fri, 2006-07-07 at 21:29 -0400, nil nil wrote:
> > Shouldn't netbeans 5 be put in the portage tree?
>
> Yes, but no one has really stepped up to maintain Netbeans ebuilds.
> I started to work on it, but instead of focusing on 5 or older, I
> started with Netbeans 5.5 Beta. There is a ebuild for that in the
> migration packages overlay.
This is the reason and a temporary solution. Add to this the fact that
NetBeans have a Linux executable installer as well as .zip / .tar.gz
archive of ready-to-run application. It's perfectly installable in /opt,
for example. So, there's not much incentive to toroughly work on this
right now.
In Gentoo the goal is to compile every package from sources if possible.
It should use already existing jars from previously installed packages, too.
So it could for example benefit from security updates or version upgrades
to the respective packages. This is a general direction that Gentoo takes:
no prepackaged binary jars should be used, unless necessary. The crown
example and a problem without current resolution is Maven, which brings
a lot of jars in its own repositiories.
In essence it means that for complex Java packages the whole build and
packaging process needs to be different (to some degree) from the one
used by the developers. For example, in Linux packages spread their
files in different directories with different permissions (binaries, libraries,
docs, manuals, working dirs/files, etc.), whereas typical "big" Java
packages provide all their files in a single directory. This is an additional
burden for Gentoo maintainers. And the real reason why some packages
"lag" behind.
But still the binary versions of said packages run perfectly under Gentoo:
NetBeans, Eclipse, Tomcat, GlassFish... But they need to be put in their
own separate directories, with all dependencies underneath. So, even if
they have some jars in common, they cannot share them. Depending on
your POV this is good (easy deinstallation or upgrade by removal of a single
directory) or bad (inconsistency with the general philosophy of packaging
in Gentoo and package management by Portage).
OTOH package management tools in Linux already provide solutions for
problems that become to occur to Java packages. Dependencies are the
first thing that comes to my mind. Every non-trivial Java program requires
a number of libraries in the form of jar files to perform its function. Said
libraries have to be provided by every application, so they are duplicated
and cannot be easily upgraded in the event of a repaired bug or security
issue. Currently it requires lots of manual work, so every existing copy
of each library has to be tracked and upgraded independently.
Maven tries to solve this problem by providing a vast number of existing
*binary* packages (jars) that projects under development can use. But
still, they are binary files. I know, there are notions of providing sources
for such jars in Maven, but many packages don't do it properly. These
are some reasons why Maven is not fully supported in Gentoo/Portage
yet. However, you can always install it by hand. But keeping all the
manually installed packages up to date is, frankly, hard to do.
Remember, in Gentoo the source code is the most important and gives
the most flexibility. This is a general problem with Java packaging that
the world will have to tackle sooner or later. Or we will have another
"dependency hell" (or make it "the jar hell") upon us. But the whole
upstream is not aware of the problem yet - if it works why break it?
Yes, it works today. But we're talking on a long-term problems here.
Which, I think, Gentoo is able to avoid in a clean, comprehensive way.
If I missed sth or said sth fundamentaly wrong, please tell me.
Regards,
Wiktor Wandachowicz
--
Registered Linux user #390131 (http://counter.li.org)
--
gentoo-java@gentoo.org mailing list