commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject RE: property naming (Re: cvs commit: jakarta-commons/digester bui
Date Thu, 21 Mar 2002 22:23:16 GMT

On Thu, 21 Mar 2002, Steve Downey wrote:

> Date: Thu, 21 Mar 2002 16:12:03 -0500
> From: Steve Downey <>
> Reply-To: Jakarta Commons Developers List <>
> To: 'Jakarta Commons Developers List' <>
> Subject: RE: property naming (Re: cvs commit: jakarta-commons/digester
>     bui
> > So, the proposal would be to change this to the following:
> >
> >   commons-collections.jar=${lib.repo}/commons-collections.jar
> >   commons-logging.jar=${lib.repo}/commons-logging.jar
> >   junit.jar=${lib.repo}/junit.jar
> >
> > right?  You would rely on the user to define their own
> > lib.repo property
> > someplace if they are using this approach.
> That catch is, which junit.jar are you talking about? The configuration
> information is completely lost.

Well, not completely ... it's just not easily machine readable.  The
STATUS.html tell you that JUnit 3.7 is required.

A good JAR repository mechanism would encode this kind of knowledge in its
definition of the fact that BeanUtils depends on JUnit.  In addition, it
would provide a way to ask for version 3.7 of JUnit (most likely without
depending on the third party provider to maintain a stable URL for this).

But even if such a thing existed, it would not solve a different problem
that I face every day -- combining lots of packages, with overlapping
dependencies, into a single project.  I need to be able to specify
*exactly* what commons-foo.jar file is used to compile *all* of the pieces
(no matter what the repository's versioning info might say), in order to
test whether it can all work together.  (Tomcat's build process has a few
shared dependencies like this; I work on internal projects with *many*

> Junit's MANIFEST.MF doesn't carry the
> information. That's suboptimal, but needs to be taken up with the junit
> project. Creating a jakarta version of junit is a way to madness.

No matter what conventions *we* agree to follow, we can't guarantee that
external projects will.  We'll just have to deal with the fact that
junit.jar contains neither a license file nor a version number.

> OK, you can actually tell the difference between junit distributions by
> examination of the contents of the jar. Their build process leaves some
> cruft, such as build.xml and a junit3.7 directory. But that's not really
> reliable. And there are probably other cases out there.

Lots of them.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message