Re: [gentoo-java] Netbeans

["nil nil" <thaoeuns@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5370 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 5952 bytes --]