1 |
2006/7/8, William L. Thomson Jr. <wlt@××××××××××××××××.com>: |
2 |
> On Fri, 2006-07-07 at 21:29 -0400, nil nil wrote: |
3 |
> > Shouldn't netbeans 5 be put in the portage tree? |
4 |
> |
5 |
> Yes, but no one has really stepped up to maintain Netbeans ebuilds. |
6 |
> I started to work on it, but instead of focusing on 5 or older, I |
7 |
> started with Netbeans 5.5 Beta. There is a ebuild for that in the |
8 |
> migration packages overlay. |
9 |
|
10 |
This is the reason and a temporary solution. Add to this the fact that |
11 |
NetBeans have a Linux executable installer as well as .zip / .tar.gz |
12 |
archive of ready-to-run application. It's perfectly installable in /opt, |
13 |
for example. So, there's not much incentive to toroughly work on this |
14 |
right now. |
15 |
|
16 |
In Gentoo the goal is to compile every package from sources if possible. |
17 |
It should use already existing jars from previously installed packages, too. |
18 |
So it could for example benefit from security updates or version upgrades |
19 |
to the respective packages. This is a general direction that Gentoo takes: |
20 |
no prepackaged binary jars should be used, unless necessary. The crown |
21 |
example and a problem without current resolution is Maven, which brings |
22 |
a lot of jars in its own repositiories. |
23 |
|
24 |
In essence it means that for complex Java packages the whole build and |
25 |
packaging process needs to be different (to some degree) from the one |
26 |
used by the developers. For example, in Linux packages spread their |
27 |
files in different directories with different permissions (binaries, libraries, |
28 |
docs, manuals, working dirs/files, etc.), whereas typical "big" Java |
29 |
packages provide all their files in a single directory. This is an additional |
30 |
burden for Gentoo maintainers. And the real reason why some packages |
31 |
"lag" behind. |
32 |
|
33 |
But still the binary versions of said packages run perfectly under Gentoo: |
34 |
NetBeans, Eclipse, Tomcat, GlassFish... But they need to be put in their |
35 |
own separate directories, with all dependencies underneath. So, even if |
36 |
they have some jars in common, they cannot share them. Depending on |
37 |
your POV this is good (easy deinstallation or upgrade by removal of a single |
38 |
directory) or bad (inconsistency with the general philosophy of packaging |
39 |
in Gentoo and package management by Portage). |
40 |
|
41 |
OTOH package management tools in Linux already provide solutions for |
42 |
problems that become to occur to Java packages. Dependencies are the |
43 |
first thing that comes to my mind. Every non-trivial Java program requires |
44 |
a number of libraries in the form of jar files to perform its function. Said |
45 |
libraries have to be provided by every application, so they are duplicated |
46 |
and cannot be easily upgraded in the event of a repaired bug or security |
47 |
issue. Currently it requires lots of manual work, so every existing copy |
48 |
of each library has to be tracked and upgraded independently. |
49 |
|
50 |
Maven tries to solve this problem by providing a vast number of existing |
51 |
*binary* packages (jars) that projects under development can use. But |
52 |
still, they are binary files. I know, there are notions of providing sources |
53 |
for such jars in Maven, but many packages don't do it properly. These |
54 |
are some reasons why Maven is not fully supported in Gentoo/Portage |
55 |
yet. However, you can always install it by hand. But keeping all the |
56 |
manually installed packages up to date is, frankly, hard to do. |
57 |
|
58 |
Remember, in Gentoo the source code is the most important and gives |
59 |
the most flexibility. This is a general problem with Java packaging that |
60 |
the world will have to tackle sooner or later. Or we will have another |
61 |
"dependency hell" (or make it "the jar hell") upon us. But the whole |
62 |
upstream is not aware of the problem yet - if it works why break it? |
63 |
Yes, it works today. But we're talking on a long-term problems here. |
64 |
Which, I think, Gentoo is able to avoid in a clean, comprehensive way. |
65 |
|
66 |
If I missed sth or said sth fundamentaly wrong, please tell me. |
67 |
|
68 |
Regards, |
69 |
Wiktor Wandachowicz |
70 |
|
71 |
-- |
72 |
Registered Linux user #390131 (http://counter.li.org) |
73 |
-- |
74 |
gentoo-java@g.o mailing list |