Latest in JJAR-land, in the order I remember it :

1) Repository is now hosted on jakarta.apache.org (as promised many
times... sorry bout that)  This should make life easier for Peter :)

2) I did a bit of documentation so people can see what this is about,
and I can remember what is going on.  You can find it at

http://jakarta.apache.org/commons/jjar.html

it is also the index page on http://jakarta.apache.org/jjar/ but the
links are broken, and I don't care.  It's a sandbox toy project :) (Is
there a way to *not* have that project.xml dependency so we can just use
the styling to render content?)

The documentation is not complete - I will work on more this weekend,
trying to get as much of a mind-dump as I can into it.

3) Added support in the ant task to also setup a classpath with the jars
that get downloaded, so build.xml authors don't have to know the full
dependency list of something their project depends on :

ex, in a compile target...
    
    <jjar package="veltag" 
          onlydependencies="true"  
          verifyignore="true" 
          localrepository="${local.repository}"
          pathrefid="jjarclasspath"  >
    </jjar>
  
    <javac  srcdir="${source.home}/java"
            destdir="${build.home}/classes"
            debug="${compile.debug}"
            deprecation="${compile.deprecation}"
            optimize="${compile.optimize}">
        <classpath refid="jjarclasspath"/>
    </javac>

So this gets the dependencies for veltag, and adds them to the
classpath.  The javac then uses that classpath when compiling.  When the
dependencies change, nothing changes in the build.xml.

The cool part (I think) is demonstrated by the veltag contrib in
Velocity.  It has an entry in the central repository, and that entry
points to a repository.xml in the veltag CVS.  So the Veltag build uses
JJAR to get it's own dependencies, download the jars, and put those jars
in the classpath.  Ok, I think it's cool.

The result is that we should be able to start taking explicit dependency
references out of build.xml files.  I have a few more things I want to
play with as I want this as flexible as possible, as there is no One
True Way for build files. :)

geir

-- 
Geir Magnusson Jr.                           [EMAIL PROTECTED]
System and Software Consulting
Developing for the web?  See http://jakarta.apache.org/velocity/
Well done is better than well said - New England Proverb

Reply via email to