See below.
On Mon, 9 Apr 2001, Vincent Massol wrote:
>
> ----- Original Message -----
> From: "Vincent Massol" <[EMAIL PROTECTED]>
> To: "Craig R. McClanahan" <[EMAIL PROTECTED]>;
> <[EMAIL PROTECTED]>
> Sent: Sunday, April 08, 2001 11:57 PM
> Subject: Re: File directory structure for jakarta-commons
>
>
> >
> > ----- Original Message -----
> > From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>; "Vincent Massol"
> > <[EMAIL PROTECTED]>
> > Sent: Sunday, April 08, 2001 11:43 PM
> > Subject: Re: File directory structure for jakarta-commons
> >
> > [snip]
> > > > > I would still deliver one big bag, and let people get what they want
> > > > > from that. Will make user support easier if you can ask which
> nightly
> > > > > or release the little part they have a problem with came from.
> > > > >
> > > >
> > > > Yes, I get you but I guess I still feel awkward about enforcing a
> > download
> > > > of a few megs when my runtime jar is only 50 or so kilobytes ...
> > > > Could we try with several files first (of course, each file either has
> a
> > > > version postfixed - for releases - or a date stamp - for nightlies -)
> > and do
> > > > a single zip later if we find problems with that ?
> > > >
> > > > > geir
> > > >
> > > > Thanks
> > > > Vincent
> > > >
> > > >
> > >
> > > The Jakarta "tradition" is all-in-one distributions, and I think we
> should
> > > respect that for those who want it. (In addition, a source distro that
> is
> > > essentially a mirror of CVS is generally provided.)
> > >
> >
> > ok. I'll align myself with this "tradition" :)
> >
> > > Because this subproject is designed to produce small independent JARs as
> > > well, I think we should offer that *in addition* to the all-in-one
> > > downloads.
> > >
> > > What I really don't want to see is the *lack* of an all-in-one download,
> > > forcing me to make multiple downloads if I really do want everything.
> > >
> >
> > ok. Thus, that would mean.
> >
> > 1)
> >
> www/jakarta.apache.org/builds/jakarta-commons/release/commons-cactus/v1.0-b1
> > /commons-cactus-1.0-b1.zip
> > - that's the full disto excluding sources. Meaning it will contain :
> > commons-cactus-22-1.0-b1.jar
> > commons-cactus-23-1.0-b1.jar
> > commons-cactus-ant-1.0-b1.jar
> > commons-cactus-sample-22-1.0-b1.zip
> > commons-cactus-sample-23-1.0-b1.zip
> > commons-cactus-doc-22-1.0-b1.zip
> > commons-cactus-doc-23-1.0-b1.zip
> >
> > Do you think I have to redo my build file to have a directory structure
> > instead of zips or jars ? Like :
> >
> > commons-cactus
> > |_ 22
> > |_ doc
> > |_ lib
> > |_ sample
> > |_ 23
> > |_ doc
> > |_ lib
> > |_ sample
> > |_ README
> >
>
That would be my preference. If I want the all-in-one bundle, then it's
more convenient to not have to unzip things inside the download.
One file to add in the top-level directory would be "LICENSE", to remind
people what license the code is distributed under.
> It makes more sense to have a directory structure. I'll do that. Geeze ... I
> wanted to deliver tonight but it's already past midnight ... I'll have to
> deliver tomorrow ... :)
>
Sorry about that. I promise to be patient :-)
> > 2)
> >
> www/jakarta.apache.org/builds/jakarta-commons/release/commons-cactus/v1.0-b1
> > /commons-cactus-src-1.0-b1.zip
> > - that's the sources
> >
Sounds good.
> > 3)
> >
> www/jakarta.apache.org/builds/jakarta-commons/release/commons-cactus/v1.0-b1
> > /ant.zip
> > - that's the prepackaged Ant application with the correct jars already in
> > the lib directory. That's to help newcomers.
> >
Hmm, over time I guess we need to talk about how to deal with optional Ant
tasks that need extra Jars there. I guess this is fine in the mean time.
> > Notice that I have removed the single distribution of jars. That's fine
> with
> > me.
> >
Does it make sense to have commons-cactus-22-$VERSION.jar and
commons-cactus-23-$VERSION.jar to be downloadable as well? I'm
envisioning that ultimately people are going to start building Ant scripts
with targets that go grab just the required JAR files off a server
(ultimately this would be done in a "CJAN" style), without having to
unpack anything.
> > > Craig
> > >
> > Vincent
> >
> >
>
> Vincent
>
>
Craig
