From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1FzK7h-0002XY-5C for garchives@archives.gentoo.org; Sat, 08 Jul 2006 21:13:58 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.7/8.13.6) with SMTP id k68LCLHx014492; Sat, 8 Jul 2006 21:12:21 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.13.7/8.13.6) with ESMTP id k68LCKTt017752 for ; Sat, 8 Jul 2006 21:12:20 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 321DC64581 for ; Sat, 8 Jul 2006 21:12:20 +0000 (UTC) Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12661-04 for ; Sat, 8 Jul 2006 21:12:13 +0000 (UTC) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.206]) by smtp.gentoo.org (Postfix) with ESMTP id F17366479D for ; Sat, 8 Jul 2006 21:12:12 +0000 (UTC) Received: by nz-out-0102.google.com with SMTP id i11so268815nzh for ; Sat, 08 Jul 2006 14:12:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=OrG/tzCfWFgjzVhGanz72oMnmMBf5BuTZYg1zVS4RT5rZctOQDpiDcEO+Pa8hzdrmNnr8h3byS2Mb2eEE+mt0sAsJX+53PXHs5FqzD5/E0SLXrgZVJ9loAMGB14PWWdD8Ad0cDEtJ+E97tMMtuaeeR1pk5MclzwIAc71QBCexnQ= Received: by 10.36.67.19 with SMTP id p19mr3082232nza; Sat, 08 Jul 2006 14:12:11 -0700 (PDT) Received: by 10.36.41.17 with HTTP; Sat, 8 Jul 2006 14:12:11 -0700 (PDT) Message-ID: <4e2f58480607081412l5d0db64axb2ae4439673b4c14@mail.gmail.com> Date: Sat, 8 Jul 2006 17:12:11 -0400 From: "nil nil" To: gentoo-java@lists.gentoo.org Subject: Re: [gentoo-java] Netbeans In-Reply-To: <254054bc0607080240r6be2968ayff4ff2aa17580f2e@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21005_17990424.1152393131500" References: <4e2f58480607071829g2ccf0c12jcfade2fac87c75bf@mail.gmail.com> <1152324992.30603.10.camel@wlt.obsidian-studios.com> <254054bc0607080240r6be2968ayff4ff2aa17580f2e@mail.gmail.com> X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Status: No, score=-0.711 required=5.5 tests=[AWL=0.259, BAYES_00=-2.599, DNS_FROM_RFC_ABUSE=0.2, HTML_10_20=1.351, HTML_MESSAGE=0.001, TW_GC=0.077] X-Spam-Score: -0.711 X-Spam-Level: X-Archives-Salt: 617bd03f-f431-4079-aaff-b130310db1fa X-Archives-Hash: 1730bdaa261913b4ec1e79645fea61b8 ------=_Part_21005_17990424.1152393131500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 wrote: > > 2006/7/8, William L. Thomson Jr. : > > 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 > > ------=_Part_21005_17990424.1152393131500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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


------=_Part_21005_17990424.1152393131500-- -- gentoo-java@gentoo.org mailing list