[gentoo-java] Netbeans

[gentoo-java] Netbeans

[nil nil]

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

Shouldn't netbeans 5 be put in the portage tree? It's out of beta (for a
while now) - I've been using it without problems for longer. I know I may
have a shorter version than most about what a while is. Anyways, if it can't
be added to the tree, why?

~Cheers

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

Re: [gentoo-java] Netbeans

[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. It compiles, installs, and runs, but it is
not very useful. Ebuild still needs some work, and not sure if something
is off or what, but seems to be missing like all modules or etc to make

I just do not have much time to dedicate to it. Busy trying to get
Tomcat ebuild and etc all squared aware. Partly because of on Netbeans
dependencies is Tomcat.

I do welcome any input, testing or etc on the 5.5 beta ebuild though. If
anyone cares to mess around with it. Otherwise I will see about getting
to it

-- 
Sincerely,
William L. Thomson Jr.
Obsidian-Studios, Inc.
http://www.obsidian-studios.com

-- 
gentoo-java@gentoo.org mailing list

Re: [gentoo-java] Netbeans

[Wiktor Wandachowicz]

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

Re: [gentoo-java] Netbeans

[nil nil]

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

Re: [gentoo-java] Netbeans

[William L. Thomson Jr.]

On Sat, 2006-07-08 at 17:12 -0400, nil nil wrote:
> 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.

It has more to do with philosophy, layout, using the latest deps that
are normally bundled to build any given app. Not so much compile time
tweaks, optimizations or the other stuff one can do with say C or C++
during compilation.

For example diff of compiling an app say with it's bundled log4j v1.2.11
or using the current 1.2.13.

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

Java code compiles so fast it's a moot issue. Even something as big as
Netbeans on slower hardware almost takes more time to unpack than to
compile.

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

Been there done that. Which is why these days any new ebuilds MUST not
use any bundled jars. If they are not in their own packages, that has to
occur before the ebuild. Such is life.

The previous state there was a mixture of binaries, most all with their
own bundled deps. Even if that is already present on the system. It made
a mess, took a while to clean up, and pretty sure those in charge are
really against going back down that road. I don't blame them.

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

Hit up IRC #gentoo-java @ freenode.net most all of the active players
tend to lurk there at some point or another. Bug squashing or reporting
is always welcome. Testing experimental packages providing feedback etc
is all greatly appreciated.

If you want to do more than that, ebuild contributions are welcome,
patches to improve existing ones. For those with allot of time, or the
motivation. We surely could use more Gentoo Java Developers, which I am
in the process of becoming one. Bit of work and time commitment to get
to that point.

-- 
Sincerely,
William L. Thomson Jr.
Obsidian-Studios, Inc.
http://www.obsidian-studios.com

-- 
gentoo-java@gentoo.org mailing list