1) We need a section on what jars the user needs on the client and server classpaths, e.g.
If you're using core, you need:
if you're using netty you need netty.jar
if you're using jms you need jbm-jms-cllient.jar (we should have separate jar for jms *client* stuff)
If you're using log4j you need.. blah blah
We should also take the javax.jms.* interface classes out of jboss-jee.jar and put them in their own jar so the user doesn't have to include *all* the jee classes.
4) Also I think we should take all the jars that the JBoss MC needs to run, unzip them and rebuild them into another jar jboss-mc.jar (or whatever) and distribute that, this will greatly limit and simplify the number of jars we distribute.
what happened to 2?
makes sense. should we do this in the build, i.e. unzip - zip or is there a better way?
5) jboss-logging.jar has dependencies to both log4j *and* jboss as logging. Is this right? I don't think we should expect users who just want to use log4j to include all the jboss as logging jars!
do you mean jbm-logging.jar or jboss-common-logging.jar?
6) Why are we including jbm-ra.jar in the distro? Isn't jbm-ra.jar sufficient?
Its used when creating the AS profile from the distro.
For 1) I' ve listed the dependencies on the JARs versus feature. I will try to make it more explicity though.
+1 on 4. Too many JARs. and it would be easier to redistribute it as one jar.
Don' t know if there are license issues with trove and jaxb used by the MicroContainer though. Can we repack and redistribute a jar?
(I know there are some restrictions.. sometimes you can as long as you mention license terms.. .I" m not sure)
I added a chapter on client classpath, Clebert please check and complete.
We need to cover:
pure core client
java ee jars