JBoss DNA is a Maven-based project. If your application is using Maven, it is very easy to add a dependency on JBoss DNA's JCR library (plus any extensions), and Maven will ensure your application has access to all of the JBoss DNA artifacts and all 3rd-party libraries upon which DNA depends. All you need is the following dependency in your application's POM:

Should we create an artifact for Maven that includes JCR and all extensions? Something perhaps like:

<dependency>

<groupId>org.jboss.dna</groupId>

<artifactId>dna-jcr-all</artifactId>

<version>0.7</version>

</dependency>

The challenge here is that, while this is very easy to do, it perhaps unnecessarily includes dependencies on third-party libraries that may not be needed. This is becoming more of a big deal now that we have quite a few extensions. Plus, some of our 3rd party dependencies are very large! Perhaps it is sometimes easier to "<exclude>" a few extensions than it is to add dependencies for many extensions. Thoughts?

Also, consuming JBoss DNA in applications that do not use Maven can be difficult. We have a lot of JARs at the moment, and we depend on even more 3rd party jars (that often have their own dependencies). We could produce a single JAR (or OSGi bundle) containing our JCR implementation and all extensions, but then what do we do about the 3rd-party libraries? If we include them (can we include all of them?), then again this JAR might be huge. Do we create multiple flavors, and if so, how many flavors do we need? At what point are we solving a problem that really needs to be solved by each individual application?

Please let us know so that we can make it much easier for you to use JBoss DNA!

I would like to see each of these be a ZIP file with dependencies bundled in. My logic is that Maven users don't need the dependencies, but then again they're probably not downloading from the download page anyway. People who do download from that page are probably doing so because they don't use Maven and don't want to hunt down the N dependencies that the full project uses.

I've always preferred having the source and binaries in separate artifacts for download. I think it's extremely important that the dependencies be kept in their original JARs (this makes it possible for users to update individual JARs to pick up security fixes independently of our release schedule and makes it easier to manage classloader issues). I do prefer a zip of JARs rather than a JAR of JARs, though. I may be unique in that regard.