Why are you splitting it up at all? I guess I can see why you would want to split up thirdparty stuff, perhaps even client stuff... but there is no reason (or desire) to have the rest split up on a cvs module basis (or generated jar basis).
To make things more cpmlicated for you, jboss will want to have its thirdparty jars installed into lib/ext, which seems like it will complicate the process of splitting those up into packages. I played with debian for some time (once I could get the damn thing installed... or rather once someone told me not to use the custom mode so the installer would not ask me a billon questions). I thought apt was nice, though to upgrade to woody, I had to keep running apt-get over and over and over and over... finally it worked. So, I did not write this to knock debian or there package system, but more to find out the motivation to make the package and why you inist on this level of seperation. I would expect a jboss-system and jboss-client as core packages, then put the extra plugins (from jboss-plugins) like the iiop and such into there own. There is no reason the split up the jboss-system package into smaller bits (like a jboss-naming or jboss-j2ee packages) because they are completly useless out of the context of the supporting modules. Modules are not realeased individialy, but as a whole. They do not have there own versioning, they use the versioning from the cvs project from which they are a member. I know this is hard to understand based on the currect pyhsical cvs layout. Perhaps we can fix that once 3.0 has been moved to production, perhaps 3.2 as well. Why not simply make a .deb from the archives released to sf.net? If the point is to generate a .deb that is the easiest thing todo, which will also have the least amount of maintenece required by you (or another) when building an updated package. I am not against building .debs, .rpms or whatever, but we need to keep them uptodate with the current releases. we need to make sure the packaging suites the needs of our users (not the ultra-purist package system designers). And we need to make sure it is easy to maintain the package generation. Ideally an optional target of the build/build.xml for the given project should make packages, so you, me, scott or anyone could generate them... and not have to know the details of the packaging system. I will respond to your other email when I get into work. Could you explain (in a brief-like manner), your motivation to split up everything in jboss at the cvs module level? --jason On Thu, 15 Nov 2001, Adam Heath wrote: > On Thu, 15 Nov 2001, David Jencks wrote: > > > 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. > > The stuff I did for 2.4 was done based on jar names. If it was a separate > jar, I split it off. This is obviously not the correct way to do it. It > should be split based on the functionality. > > I'm still learning about all the different functionality parts of jboss, and > how they relate. Previously, I had just downloaded jboss-tomcat, and ran it. > > > _______________________________________________ > 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
