1 |
Hi, |
2 |
|
3 |
I'm in the process of upgrading the JBoss ebuild to the latest JBoss |
4 |
release, and am in need of some advice. |
5 |
|
6 |
Here's the deal: JBoss comes with a *LOT* of third-party libraries, |
7 |
which it relies upon to run with the full monty of features. With the |
8 |
original JBoss ebuild I just stuffed all of these third party libraries |
9 |
in the JBoss file hierarchy. This time around, however, I'm tempted to |
10 |
write separate ebuilds for each third party library included, and |
11 |
instead sym linking them on need (I'm working on a tool to handle |
12 |
library and service dependencies when adding new server archives to |
13 |
JBoss). |
14 |
|
15 |
In my eyes having separate ebuilds for the third-party libraries is a |
16 |
good thing(tm), as more Java applications can share the same libraries. |
17 |
This could be a start in solving the inherent problem with Java |
18 |
applications living as separate islands on the file system, independent |
19 |
of each other. |
20 |
|
21 |
The consequence of separating the third-party libraries from the JBoss |
22 |
installation, however, is that we'd see a growth in the number of |
23 |
ebuilds in dev-java. JBoss requires around twenty third-party libraries |
24 |
for its complete functionality. That is some twenty odd new ebuilds in |
25 |
dev-java and possibly some in net-www. I'm unsure whether this will |
26 |
result in a cluttered dev-java dir. |
27 |
|
28 |
I'm tempted to start writing separate ebuilds for the third-party libs, |
29 |
but want to hear if anyone else have opinions on the matter before I |
30 |
start with the task. |
31 |
|
32 |
Cheers, |
33 |
|
34 |
Thomas Osterlie |