3 Replies Latest reply: Jan 12, 2010 8:10 PM by Brian Carothers RSS

JBoss DNA bundles

Randall Hauch Master

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:

 

<dependency>

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

  <artifactId>dna-jcr</artifactId>

  <version>0.7</version>

</dependency>

 

 

plus a similar dependency for each optional extension (sequencers, connectors, MIME type detectors, etc.):

<dependency>

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

  <artifactId>dna-connector-store-jpa</artifactId>

  <version>0.7</version>

</dependency>

...

<dependency>

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

  <artifactId>dna-sequencer-java</artifactId>

  <version>0.7</version>

</dependency>

 

 

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!
(This 'feature' is being tracked with DNA-643)
  • 1. Re: JBoss DNA bundles
    Brian Carothers Apprentice

    Personally, I would like to see the following breakdown:

     

    dna-all (source/binaries for all core and extension modules)

    dna-core (source/binaries for the core modules)

    dna-foo (source/binaries for the foo extension module)

     

    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.

  • 2. Re: JBoss DNA bundles
    Randall Hauch Master

    Right, we're not talking about artifacts for Maven users, but we are talking about files that would be available from our downloads page.  And the breakdown you gave would be pretty useful.

     

    • dna-all (all core and extensions PLUS plus required dependencies)
    • dna-core (all core modules PLUS required dependencies)
    • dna-<extension> (one for each extension, including that extension's source/binaries PLUS required dependencies)

     

    Do each of these have the source and the binaries, or were you suggesting having one set for binaries and one set for sources?

     

    Would there be a benefit to having these be JARs of JARs?

  • 3. Re: JBoss DNA bundles
    Brian Carothers Apprentice
    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.