| 1 |
Ok here it goes. Im sure that this has been discussed before (even for |
| 2 |
packages other than jboss but....) but im bringing it up again. |
| 3 |
|
| 4 |
[Quote jboss-4.0.4.GA-src/build/docs/readme_j2ee.html] |
| 5 |
ADDITIONAL NOTICE FROM SUN MICROSYSTEMS: This version of the JBoss Application |
| 6 |
Server source code is made available in support of the open source |
| 7 |
development process. Some numbered or tagged revisions of this source have |
| 8 |
been tested and found to pass the Java™ 2 Platform, Enterprise Edition |
| 9 |
(J2EE™) Compatibility Test Suite, and you can find information on which |
| 10 |
revisions or tags at www.jboss.com. Please note that since only binaries can |
| 11 |
be tested, source code cannot be described as a compatible implementation of |
| 12 |
the J2EE Specification. The different build environment on your machine and |
| 13 |
any changes you may make to this code could render your resulting build |
| 14 |
incompatible. Because of this, writing or deploying applications to builds |
| 15 |
based on this code can lead to lack of portability. You should instead |
| 16 |
consider deploying production applications on the pre-built binaries of the |
| 17 |
JBoss Application Server that are available at www.jboss.com that have been |
| 18 |
tested and certified to meet the J2EE compatibility requirements. |
| 19 |
[/Quote] |
| 20 |
|
| 21 |
Now as everyone can see no matter what we do we will never be able to |
| 22 |
compile/patch etc etc jboss (or in fact any J2EE Application Server) and be |
| 23 |
able to certify that it is complient. If that takes jboss months to do, we |
| 24 |
dont have a shit shoiw. |
| 25 |
|
| 26 |
So I want to talk strategies for gentoo related to J2EE for a couple of |
| 27 |
reasons. |
| 28 |
|
| 29 |
1) I dont want upstream(s) hating us because they get lots of "Your server |
| 30 |
isn't workning on Gentoo" or "Something worked on gentoo but not on ...." |
| 31 |
2) I don't want users to be deluded into thinking they are getting something |
| 32 |
they are not. |
| 33 |
|
| 34 |
The solution(s) to this is(are).... |
| 35 |
|
| 36 |
1) a) Any source based build have an einfo message stating that the package |
| 37 |
may not be J2EE complient and that upstream will not support this |
| 38 |
implementation. |
| 39 |
b) Provide a binary ebuild as the official implementation and attempt to get |
| 40 |
upstream developers (even unofficially) to agree/accept the build |
| 41 |
location/layout/etc (so that there is at least a forum level of support). |
| 42 |
Maybe this package could be located just in the overlay (like a J2EE overlay |
| 43 |
with bin packages for each j2ee implementation) |
| 44 |
|
| 45 |
2) Be true gentooians and go source but be prepared to not be |
| 46 |
considered 'enterprise'. Initial include a warning as above but once we are |
| 47 |
a happy with the stability of jboss remove the warning. |
| 48 |
|
| 49 |
Now im aware of why_we_build_from_source and my preference IS to have a jboss |
| 50 |
implementation compiled from source (as you maybe able to tell from the work |
| 51 |
im doing) . But I also want a jboss implementation that is as true to |
| 52 |
production (and certifiable) ready as possible. So therefore my preference |
| 53 |
has to be option 1. |
| 54 |
|
| 55 |
What are ppl's ideas, feedback etc etc on this. |
| 56 |
|
| 57 |
Ps. Im writing this just after a game of hockey (field) so hopefully im able |
| 58 |
to string sentences together. |
| 59 |
|
| 60 |
Ps. I would also like to make sure that the source jboss build depends on |
| 61 |
the specific version (or very close relatives) of the thirdparty packages |
| 62 |
within the bin. What are ppl's feadback on this. |
| 63 |
|
| 64 |
-- |
| 65 |
gentoo-java@g.o mailing list |
Archives