I would like to prototype a use of jarjar by removing the dom4j.jar classes from the public namespace. This seems like the simplest implementation detail dependency we have. The only problem I see is other jems components relying on the bundled dom4j.jar.
I have been doing some reading about jarjar and genjar and will work on setting up the prototype.
My understanding of the use case for this prototype is as follows:
A build would be created as usual but when the distribution is built instead of copying the dom4j.jar to output/jbossas5.0.alpha/lib we would instead create a new jar (using the jarjar task) called jboss-internal.jar (or something).
The jarjar tool would take the classes from dom4j, give them a new package name and place them into the new jar.
The jar name would have to remain dom4j.jar as we currently have that defined as a hard coded bootclasspath entry, but this could be externalized. It should be named the same as whatever the normal build uses or else there will be conflicts when running the normal build vs the dist build due to classpath entry mismatches.
The jarjar util will have to modify every jar that uses the dom4j.jar to modify the org.dom4j.* package names used at compile time to jarjard org.jboss.dom4j.* package name as well or else nothing will work. You will get ClassNotFoundErrors for the org.dom4j.* classes from the jboss jars unless this is done.
So the first part of this will basically be transforming all of the jars in build/output/...... and replacing the dom4j packaging schema with a new org.jboss.dom4.... schema as appopriate. The next step would be to run the testsuite against this version of the server. In order for the testsuite to work we will need to perform the transformation operation against the output/libs/jars of each of the modules.