Scott, you mentioned something early in the other thread about moving javassist.jar here. Can you elaborate a bit please.
At the moment I don't see a way to go with option b) short of moving the javassist specific annotation stuff out of the mc project into the aop-mc-int project, or splitting jboss-container.jar into a jboss-container-boot.jar and a jboss-container-deployer.jar as has been done for the aop-mc-int project.
The javassist issue is simply do we want to expose this api from the bootstrap class loader. Its a question of how public an api javassist is, and do we expect users to be able to use a different version than that bundled with jboss. If we do, then we should be created a javassist release under the org.jboss package namespace to isolate our usage from users.
I'm probably missing something here, but how does it make a difference if it is deployed in jboss/lib or jboss/server/xxx/ling wrt to being able to use a different version?
Its just more difficult to override as the scope of the types bound to this version of javassist expands. The question of whether we should be jarjaring javassist does exist independent of putting it into the bootstrap classpath.