[JJAR] 2nd attempt - a NICE-TO-HAVE list

[Slawek Zachcial <sl...@yahoo.com>]

Hi,

I had a deeper look at JJAR and also browsed this 
mailing list. It looks like folks are interested in 
JJAR, Geir has some stuff to commit, but nothing 
happended in CVS for months now ...

Anyway, I think JJAR is a great and very usfull stuff,

even though, IMHO it misses some features (see WISH 
LIST below).

Here is what I understood JJAR provides:
* XML-described repository - no need for server-side 
  components
* Packages can be defined by standalone descriptors 
  and then must be referenced by the central 
  repository XML (i.e. remotedefinition)
* JJAR Ant task and command line interface
* JJAR fetches always jars from the repository
* JJAR manages package dependencies
* JJAR Ant task creates Ant path element - useful to 
  define classpath
* JJAR is able to check jar version looking into its 
  Manifest file
* JJAR supports only versions like 
  <major>.<minor>-<modifier> - only exact matching is 
  supported


And here is a WISH LIST for JJAR - feel free to add
your stuff :-)))

* Richer version semantics for dependencies: 
  e.g. 1.2.3.4-dev, 1.2+ (greater or equal 1.2), 1.2* 
  (version prefix matches 1.2); an example could be a 
  package using JUnit's assertTrue introduced in 3.7 -

  so it needs version "3.7+" - the latest available 
  in repository version could be the best feet. 
  For more details on that see Java WebStart JNLP file

  syntax spec, Appendix A

* Dependencies on Java version:
  Let's say some package (used by some package)* you 
  use depends on some 1.4+ functionality. When using 
  JJAR Ant task you could provide the target java 
  version and JJAR task would fail if the packages if 
  all dependencies are not compliant with your 
  required Java version 

* More than one jar file in a package:
  For example xdoclet ships a lot of plugins and they 
  cannot be repackaged in a single jar file as they 
  contain module descriptors having the same name and 
  being in the same place inside the jar file.

* Local repository only:
  Let's say you store all your favorites jar files 
  in /opt/jar. If in addition you maintain the JJAR 
  repository descriptor, JJAR should be able to simply

  reference files from this dir (e.g. JJAR Ant task 
  when constructing the path) - so no copying/fetching

  is needed => only one copy of this jar in your 
  system.

* Ant FileSet:
  JJAR Ant task already creates Ant's Path with all 
  the jars. I didn't figure any way to convert such a 
  Path to a FileSet. FileSet's would be useful when 
  you have to create a distribution - retrieving files

  from JJAR (local) repository.
  
* Cache package descriptors locally:
  This is something I found somebody proposed on this 
  list. Having that would enable you to work on a 
  deconnected system (no HTTP request needed) - your 
  laptop :-)
  
* Generate package descriptors from jar Manifest
files:
  This could be just a small utility that would update

  the repository descriptor using information like 
  Class-Path, Implementation-xxx, etc...
  
* Detect/handle dependency collisions:
  Let's say two packages depend on the same library 
  but on two different versions, and you have to use 
  these two :-(. JJAR could detect that and try to 
  find the best feet (e.g. using the version semantics

  described above).
  
* ... and some minor changes like:
  - refactor JJAR and JJARTask
  - add "package" JJARTask child element to be able to

    get more than one package
  - add log level to JJARTask log messages - make it 
    less verbose by default
    
    
And the final question I have - couldn't JJAR be used 
by Maven to handle package dependencies??? I think 
somebody already asked that question but I didn't see 
any answer :-(

/Slawek


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>