On Sun, 8 Apr 2001, Vincent Massol wrote:
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Vincent Massol"
> <[EMAIL PROTECTED]>
> Sent: Sunday, April 08, 2001 10:30 PM
> Subject: Re: File directory structure for jakarta-commons
>
>
> >
> >
> > On Sun, 8 Apr 2001, Vincent Massol wrote:
> >
> > > Do we agree with this structure for the release files and nightly builds
> for
> > > jakarta-commons subprojects ?
> > >
> > >
> /www/jakarta.apache.org/builds/jakarta-commons/release/<subproject>/<version
> > > >
> > >
> /www/jakarta.apache.org/builds/jakarta-commons/nightly/<subproject>/<version
> > > >
> > >
> >
> > For nightlies, I would prefer using the date in the downloadable filenames
> > (so there is no question about which version you've downloaded), although
> > the unpacked directory would be the same. For example:
> >
>
> +1
>
> > /www/jakarta.apache.org/builds/jakarta-commons/nightly/commons-cactus/
>
> Is the name 'cactus' or 'commons-cactus' ? Can I keep the name Cactus
> whenever I speak about it ? Is commons-cactus the full official name,
> meaning all unix directories and files should contain common-cactus and not
> cactus alone ?
>
Within the jakarta-commons CVS repository, it would be subdirectory
"cactus". But I was making an assumption I thought we'd talked about (but
being on the road so much lately, I might have only *thought* so :-) that
we'd package things "commons-foo" -- a little pride of subproject
ownership -- so everyone would know where all the cool packages came from.
> > commons-cactus-20010408.tar.gz
>
> I'm not sure what you imagined inside this tar. I wanted to deliver the
> following files (extract from the Cactus web site) :
>
> "
> Here follows the list of files that you can download :
> - cactus-<servletapi>-<version>.jar : the Cactus framework runtime jar for a
> given servlet API,
> - cactus-ant-<version>.jar : some custom Ant tasks that are helpful for
> automating running Cactus unit tests. Especially the runservertests which
> automagically start a servlet engine, run the Cactus tests against it and
> stop the server once it is finished,
> - cactus-sample-<servletapi>-<version>.zip : a Cactus Sample application
> that shows how to write Cactus tests and how to run and deploy them in a
> servlet engine using Ant,
> - cactus-doc-<servletapi>-<version>.zip : Cactus documentation for a given
> servlet API. It contains the javadoc and a local copy of the Cactus web
> site,
> - cactus-src-<version>.zip : full Cactus sources,
> - ant.zip : a prepackaged version of Ant, which contains all needed external
> jars for tasks used by Cactus build files. This is not a compulsory download
> but it makes it easier for installing Ant and preparing it for Cactus. This
> file is only delivered for releases (and not for nightly builds).
> "
>
> Delivering a single file means including all these files. However, they will
> not be of use to everyone. Some only want to get the latest runtime jars,
> others the doc, others the sample, ....
>
> >
> > which would unpack to directory "commons-cactus".
> >
> > > As I'd really like to deliver the 1.0 release of Cactus tonight I'll go
> > > along and create the directories. Of course, if the general agreement is
> for
> > > another structure, I'll modify it (or anyone else interested in doing
> it).
> > >
> > > Thanks.
> > > Vincent
> > >
> > >
> >
> > Craig
> >
> >
> >
>
>
I think there can be more than one answer to what you can download. For
something simple like beanutils, there should be at least:
* commons-beanutils.{tar.gz,tar.Z,zip} -- complete contents of the "dist"
directory produced by the "ant dist" target. Includes the JAR file,
the docs, and the source code.
* common-beanutils.jar -- Just the binary classes (so people can set up
Ant scripts that just grab the JAR files).
For Cactus, there would be more than one JAR, but shouldn't there still
only be one "all in one" distribution?
Craig
