Dependency isolation of implementation details

[starksm64]

With the desire to expand the use of hibernate as an implementation detail in the jms(http://www.jboss.com/index.html?module=bb&op=viewtopic&t=70327) and ejb timer(http://www.jboss.com/index.html?module=bb&op=viewtopic&t=68256) pms comes the problem of leaking the hibernate classes used as an implementation detail into the user space. Throw ejb3 into the mix with its potentially different version requirements and dual implementation detail and public api use of hibernate and you have a mess. The har deployer adds yet another potential point of conflict. A related JBBUILD is the following jarjar/genjar tool investigation:
http://jira.jboss.com/jira/browse/JBBUILD-158

Here we need to decide on how we are going to handle this. The jarjar tool should allow for isolation at the expense of bloat and possibly increased debugging/support issues. We may want different solutions for 4.0.x vs 5.0.x where we have additional opportunities to tweak the underlying architecture to better deal with this problem.

[starksm64]

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.

[ruel.loehr]

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.

[starksm64]

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.

[ruel.loehr]

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.