Sam Ruby wrote:
>
> Geir Magnusson Jr. wrote:
> >
> > Well, I would bundle it all into one pile, or at least make that
> > available, and make people work for the sub-pieces. The reason is for
> > user support... getting things from a complete kit makes (me, at least)
> > look there first if I need something before posting to a user list...
>
> This is an example of where we disagree.
>
> The approach you are describing might make sense for a TDK - something that
> is arguably a complete application where the user need add nothing more
> than their content.
>
> This approach breaks down when we are looking at components where the
> potential exists for a person to pick more than one. If each complete kit
> reflects that particular project's favorite XML parser then the we not only
> are wasting bandwidth, but also increasing the possibility of error.
Right - but I think again there is a misunderstanding.
My understanding was Vincent was talking about distributing the *Cactus*
component as N pieces.
- cactus-22-1.0.jar
- cactus-23-1.0.jar
- cactus-ant-1.0.jar
- cactus-src-1.0.zip
- cactus-doc-22-1.0.zip
- cactus-doc-23-1.0.zip
- cactus-sample-22-1.0.zip
- cactus-sample-23-1.0.zip
- cactus-dependencies-1.0.zip (will be removed if point 2) is accepeted)
Can imagine how 'exciting' this could get for end users if they wanted
to download serveral components, and each was broken in to n pieces?
So my suggestion was what I thought is the existing worldwide convention
: that we also make available a tgz/zip containing all the pieces for a
complete SINGLE component - a complete Cactus 1.0 distribution.
so
cactus-1.0.tgz
would contain the complete cactus 1.0 release.
(Again, this isn't a tgz/zip containing *all* components...)
I would assume that the same makes sense for the nightly 'snapshots' -
construct the pieces of Cactus for a snapshot into a single tgz/zip so
it's easy to download, and prevents mixing and matching peices from
different nights as it could unzip into a directory 'cactus-20010404'.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
