commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [jelly] classpath issues (was Re: [jelly] value-of ??)
Date Tue, 21 Jan 2003 15:38:35 GMT
From: "Paul Libbrecht" <>
> Currently trying to reproduce this and... had to move the
> installation to another computer so... of course... the classpath had
> to be reconfigured, as guessed, it was DOM-4j-dev-7 that I was using.
> I'll dig more when I'm through with this test...
> The general question of classpath is a slight (or a big?) trouble:
> I'd like to keep the dependencies as small as possible so I am just
> using a file to store all the jars that I want to use (and not make
> "all jars in repository" like in the maven-generated build.xml, it
> includes several versions of, e.g. DOM 4j !!).

The recent refactoring of the Jelly build system should have fixed this now.
e.g. you could just build the XML library for Jelly using only the jars it
requires to build and run the unit tests.

> This file is hand produced when I need it. But I realize now that I
> will not get an update of the classpath (I did not get it in my case).
> How to maintain an up-to-date classpath for Jelly ?
> I fear this is closer to a maven debate.

You're right :-)

I use CVS HEAD of Maven to build Jelly libraries and run the unit tests. Or
add Maven targets to run certain sample programs.

e.g. take a look at the maven.xml for the swing library which has a number
of targets for running demo applications in a forked JVM using the classpath
from the Maven dependencies as well as including the java and test code in
the classpath too.


Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

View raw message