Out of curiousity, where does connector (jbosscx) fit into your packaging scheme? For 3.0 you might consider putting the contents of pool and connector into one package (if they aren't already) as pool is now small and only used by jbosscx.
david jencks On 2001.11.15 01:11:20 -0500 Adam Heath wrote: > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
