| 1 |
Hi, |
| 2 |
|
| 3 |
I have recently been trying to compile JBoss from source, first by using |
| 4 |
the JBoss ebuild and then by manually compiling the latest version of |
| 5 |
JBoss (3.0.6). |
| 6 |
When compiling with the ebuild for version 3.0.1_rc1 I came across bug |
| 7 |
10014 which is, I think, due to the fact that I use Blackdown's JDK |
| 8 |
version 1.4.1_01. |
| 9 |
When compiling JBoss 3.0.6 manually I came across a trivial error where |
| 10 |
a certain Ant build file (build.xml) was lacking a target named 'all'. |
| 11 |
Apparently someone else came across another trivial compilation bug in |
| 12 |
an earlier release (release 3.0.4, bug 15642). |
| 13 |
|
| 14 |
It seems to me that the JBoss source releases are filled with trivial |
| 15 |
bugs in the build system and that those source releases are not meant to |
| 16 |
be compileable without some fine tuning. The parts of JBoss that do |
| 17 |
compile generate an enormous amount of warnings. |
| 18 |
|
| 19 |
Tomcat's ebuild, downloads the binary release and installs that. So I |
| 20 |
wonder why certain ebuilds download Java source and others download Java |
| 21 |
binaries (when both are available). |
| 22 |
|
| 23 |
Wouldn't it be better if the JBoss ebuild would download the binary |
| 24 |
release just like the Tomcat ebuild? The alternative would be to write a |
| 25 |
set of patches for each new JBoss release that would fix the 'bugs' in |
| 26 |
JBoss's build system for that release, but as I said I have the |
| 27 |
impression that the source releases are 'snapshots' that are taken when |
| 28 |
the JBoss code itself was stable (not caring about the build system). |
| 29 |
I am, of course, willing to write such an ebuild, but only if it would |
| 30 |
be of any use. Such an ebuild could also be provided as an alternative |
| 31 |
to the source ebuild. |
| 32 |
|
| 33 |
Cheers, |
| 34 |
Lars |
| 35 |
|
| 36 |
|
| 37 |
|
| 38 |
|
| 39 |
-- |
| 40 |
gentoo-dev@g.o mailing list |
Archives