On Thu, 15 Nov 2001, Jason Dillon wrote: > 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).
I am going to split it up along lines that make sense in jboss development. I don't know what lines yet make sense, so it remains to be seen how it ends up. > 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. Not a problem. The jars in the other debs will reside in /usr/share/java, so I can just make symlinks to them. This allows for code reuse, reduced disk usage, reduced download size, etc. > 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). The current installing in debian stable(potato) is difficult for those not familiar with it. testing(woody) is not much better, but is somewhat. The next version of debian after testing will be much better, but that installer is no where near usable. > 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. Sometimes these are bugs in the packages. The maintainers didn't do full upgrade testing. Other times, they are bugs in dpkg(which apt calls) itself. Lots of these bugs have been fixed in dpkg(segfaults, buffer overruns, even speedups) for testing/woody. > 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. We could argue which OS is better than which other OS all day. I don't think it has any bearing on this discussion. The actual layout of the files depends on the distribution, but the logical separation doesn't. > 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. For example, I have jnp-server.deb and jboss-server.deb(for 2.4.3). Both contain jnpserver.jar. You can not have both installed at the same time, as they both run a JNDI daemon. I did this for those who might only want a JNDI daemon on a node. For each separate deb(that makes sense to have a separate deb) that also has a -client.jar, I make a separate -client.deb. Again, for 3.0, I am not sure how things are going to be split yet. Even for 2.4.3, I did the splitting based on jar name, and not on the services each provided. > 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. If other packages in Debian only depend on a 'j2ee' package, and there could be several packages that provide a 'j2ee' package, then jboss-j2ee should be split. But that is something that doesn't really affect the jboss community. > 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. That's not a problem. There will be a single jboss source packages, that produces multiple debs, each with the same version. > 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. That's what I did for my first version of 2.4.3 debs. I then split it into multiple. > 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. Debian packaging works by creating a debian directory off the top, and having text files, make files, shell scripts, etc describe what has to be done. There is a very defined api to the main entry point, debian/rules(chmod +x, generally a make file), so make hooking into external systems easy. > 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? I assume that each separate cvs module wholy contains a separate service. I am not sure if this is correct, as I only checked out 3.0 yesterday, and there are no docs to read(either about building, or general features) available on the web for me to read. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
