Peter Donald wrote:
>
> Hi Geir,
>
> I just wanted to find out status of JJar. You seem to have done some work on
> it recently and I am getting desperate for it to be here ;) I was wondering
> if docs are uptodate? If so would you consider placing the test repository
> somewhere on jakarta because the IP addie you plugged in won't respond for me
> ;) Also where do you see work needing to be done?
Apologies again for not moving it as promised. Was out of town for 2
days, and was trying to get it done before I went, but issues related to
the trip (consulting work) soaked up time.
The current status is that things are moving forward and working.
The idea (again) is to have one or more 'central' JJAR repositories,
which will contain a 'repository descriptor'. This is an XML-based list
of projects, which each project definition containing
- an information section about the project, such as homepage, brief
description, etc.
- a list of their their 'deliverable' jars, their versions, and the jars
referenced by the descriptor.
The JJAR software is a small toolkit that understands these repository
decriptors and fetches jars and dependencies from wherever source of the
jar is defined in the repository descriptor.
A key thing is dependency handling, so that when you ask for foo.jar,
JJAR knows that it depends on bar.jar and woogie.jar, and also that
bar.jar depends on twonk.jar, and will fetch all the pieces. It figures
this out from the repository descriptor. When you write an entry for a
project, you declare what the dependencies are for your project - just
the first level - JJAR will figure out the rest from the repository
declaration of those dependencies. So in the case of Velocity, we say
our dependencies are the jakarta-commons-collection project (version
1.0), oro (version whatever), etc. Oro may have it's own dependencies,
but that is defined in the oro descriptor. It's not up to Velocity to
have to define that.
A newly added feature is support for the idea that each project defines
and maintains their own repository descriptor. In this case, the
central repository descriptor will contain an entry for the project, and
a pointer to where the project descriptor can be found.
In this way, the management of JJAR is pushed outwards to the projects.
They are best qualified to know what their dependencies are, and it
takes some of the load off of the central repository maintainers.
One goal of this is to make the build process (ant based, of course) be
able to depend upon this same repository descriptor to get the jars
needed for building the project. That way, once the developers change
the dependency (adding a new one, changing the version, etc), then the
build process automatically will fetch/upgrade the requisite jars. The
benefit is that it should motivate the project developers to keep their
repository information up to date, as it drives their build process.
Further, all jars can be kept completely out of CVS, as they are now
fetched from the repository.
The Veltag JSP taglib is a small project in the contrib/temporary
section of Velocity's CVS, and it has been the guinuea pig for this.
Right now, it has a repository.xml in it's CVS that defines the Veltag
project's dependencies, namely servletAPI and velocity. The central
repository.xml has a pointer to the CVS entry (via HTTP) and JJAR (in an
ant task) first reads the central repository, finds the pointer so
fetches veltags repository descriptor, and then fetches servletAPI jar
and velocity's jar from the repository.
There is still more polishing to be done - for example, I am making it
so that jjar can also feed those dependency information right into the
ant classpath automatically. However, it seems to work well - Veltag
depends on itself to build itself.
Hopefull, dom4j will be hosting their own repository descriptor, so we
can hook that in soon, which will let us test and explore that idea of
distributing the repository information. (Yes, veltag does it, but no
one cares about including Veltag...) Once we test that a bit, we can
then go flog the usual suspects (JDOM, JUnit, etc) to see if they will
do the same. That will mean that the Jakarta repository will only have
to maintain our own products (and fewer external ones...)
I am also trying to get the Gump crowd interested in using this - I am
not sure yet if it is sufficient for their needs, or if they even want
it.
Anyway, I think the best work to do on it now is start using it (playing
with it). That way we can take the current rough tool and polish and
shape to our needs.
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
