> > 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.
If this is the case, then you will probably want to build off of jboss-all, since that it was most/all developers use. > > 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. Hopefully the installed .jars will have some version number seperation (like jaxp v1.0.1 vs jaxp v1.1) otherwise you will end up with version incompatiblities. Also, you will be signing yourself up to maintain these, if there is not a active reliable maintainer for them already. > 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. This seperation does not make sence for 3.0. If you want to run a JNDI server on a node, you will need the rest of the server components to get it running, then simply modify the config to only run the required components for the JNDI service. > 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. Fine. A bit overkill, but fine. > > 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. No other Debian package will depend ong jboss-j2ee... or rather no other package should depend on jboss-j2ee. If a package is dependent on jboss it should depend on the entire jboss package or the client package (or appropriant client package as you slice them up). > > 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. What do you gain from splitting them up? > > 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. Each cvs module is a *rough* seperation of different functionality insided of JBoss. Each cvs module contains zero or more services, utilies and other functional bits which together make up the JBoss distribution as a whole (from jboss-all at least). There are other projects (like jboss-plugins) which may need to be split up by a service by service basis, but the core should not. I could see that it might be easy to build packages out of one cvs module (client, doc & whatever packages too), but I don't see how that buys anything for either the developer or users standpoint. A user will want to run the server or will want to access client libraries to connect to the server... that is about it. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
