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