On Wed, 14 Nov 2001, Jason Dillon wrote: > First off you are using the wrong cvs module to build a functional JBoss 3.0 > release. The build system and cvs organization has changed drammatically > from 2.x > > I know there are not any docs to point this out directly, which I am going > to fix. http://jboss.org/developers/cvs.jsp has been updated to reflect the > current list of supported modules.
I hope the doc situation is taking care of by the time a beta release of 3.0 comes out(this is similiar to the way tomcat work(s/ed)). > I assumed that you had checked out jboss-all, which is why I responded with > the questions about your cvs acess and such... which I did not see an answer > too. Look in the mail where I included the build.sh. > I will now assume that you have checked out 'jboss', which is just the > jboss-all/server module in MAIN, but is the entire server environment for > 2.4. > > You can not simply build this module by itself. It depends on the > jboss-all/j2ee and jboss-all/naming modules as well as the thirdparty and > tools modules. Does the stuff in j2ee and naming depend on other jboss items? Do they depend on the jboss module? If no, then I started at the wrong spot. Making a deb of naming first, then j2ee, then finally jboss, is perfectly fine, as far as normaly Debian packaging goes. Is everything in thirdparty exact copies of external libraries, that get built, or just checked in pre-compiled version, or a mixture of the two? In either case, since they are third party modules, and not part of jboss, they can not be packaged with jboss in Debian. What I will end up doing(and have already started, I made a jaxp.deb tonight), is packaging each one of these external bits of code, by going to the proper location upstream, and packaging what they release. If jboss has patched these upstream sources, have the patches then been sent upstream? > If you are trying to build a 3.0 .deb then please use the 'jboss-all' module > from cvs and use 'build/build.sh release' to create a release suitable for > stuffing into the package. The files will be inder 'build/output/jboss-*/ I'm not building a single jboss deb. What I have done for 2.4, is make separate debs, split along the same lines as each top-level directory in the 2.4.3 tarball. The list of packages follows: jboss jboss-server jboss-transaction jboss-tomcat-service jboss-client jboss-admin jboss-common jnp-server jnp-client jbossmq jbossmq-client jbosssx jbosssx-client jboss-contrib-hsqldb jboss-contrib-oswego jboss-contrib-tyrex jboss-contrib-castor jboss-contrib jboss-dev jboss-docs jboss-contrib contains external sources, that shouldn't be part of the final jboss deb framework. I put them there, to make it quicker for me to get things going. jboss-contrib-* are things that I have identify as being DFSG-free, and should be packaged separately, by going to each upstream location. After that is done, jboss would then just depend on those. jboss-transaction and jboss-contrib-tyrex both provide transaction services, and can't be installed at the same time. The -client packages are for use on system that talks to a remote jboss server. jboss-server has an init script, and starts the jboss server as a separate user(jboss). jnp-server is the same, but the user is jnp-server. jboss-tomcat-service depends on tomcat.deb. Because of the way tomcat.deb is layed out, tomcat.home needs to be set correctly for it to build. However, the TomcatService stuff in jboss doesn't support setting tomcat.home, so I made a patch for it(see my earlier email). Finally, package jboss is an empty package, that depends on all the other appriopriate packages, so that once they are all installed, you end up with jboss-tomcat.tar.gz. Additionally, to support all these splits, I chopped jboss.conf and jboss.jcml into configuration fragments. Each deb can then include a config fragment, and I rebuild the config files when the debs are installed. I understand that 3.0 does this completely differently, which means my work will be wasted. That's fine by me, as what I have seen discussed on this list in the last few days seems quite nice(the -service stuff). _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
