TODO
====

 - Pros/cons of <dependencies>+<dependencySets> vs. <modules>+<moduleSets>?

 - Known issues:
 
   In order to rebuild the -distribution.zip file from the -source-release.zip
   the <modules> in the pom.xml needs to be:
   
     <module>../jena-top</module>
     <module>../jena-core</module>
     <module>../jena-iri</module>
     <module>../jena-arq</module>
     <module>../jena-larq</module>
     <module>../jena-tdb</module>
 
   An easy solution for this would be to adopt a consistent naming convention
   common for Maven artifacts, Eclipse project names and SVN directories.
   An alternative solution would be to include a different pom.xml file in
   the -source-release.zip file with the only difference being the <modules>.

   
   META-INF/DEPENDENCIES in the -jar-with-dependencies.jar file is not correct.
   How can we exclude it?

 - OSGi bundles?
 
   """
   > == Goals
   [snip]
   >> + A single download zip file  for using Jena as a library
   >> 
   >> + A single jar file for using Jena as a library

   +1 for goals overall and for the notion of a single jar.

   I'd like (as in, I would put work into this) to also have osgi support. 

   Suggest:

   o the jena-one-jar would also be marked as an OSGI bundle (easy to do
   via maven bundle plugin)

   o a third top level download, jena-complete, which is the jena-one-jar
   plus dependent jars (i.e. xerces, slf4j/log4j etc) packaged as an single
   jar/OSGI bundle. 

   The latter is not *necessary* for OSGi support but the way we/I
   currently work with OSGi makes it easier to have reasonably chunky
   self-contained bundles than do the fine grain dependency management at
   the OSGi level. 

   This can also be used via "java -jar jena-complete.jar ..." to run any
   of the command line utilities which would save some support list load on
   classpath advice
   """ 
   
   -- http://markmail.org/message/3t7vn3ug6pydfhw7