Sam Ruby wrote:
>
> Geir Magnusson Jr. wrote:
> >
> >That's not the issue. It's a build-script dependency that I am
> >advocating a solution for, not a functional one. And didn't you just
> >suggest exactly that in the last post? In the context of a snapshot for
> >users :
> >
> >Sam Ruby :
> >>> Now, can we begin a discussion as to what would be maximally useful?
> >>> Let me start:
> >>>
> >>> I believe that a snapshot of *just* the sources of cactus, combined
> with
> >>> the exact versions of the dependent jars needed to produce what you
> see
> >>> posted on the gump site would be useful to some. That way if Gump
> >>> reports an error, you can download and unpack a single file and
> >>> reproduce it. Does anybody else think this would be useful?
>
> I am not advocating a build script dependency.
Ah! Since that was what we were talking about, making a nightly
snapshot constructed by Gump to make available for users, you can see
how I got confused. There was a subtle shift somewhere :)
>
> The exact versions of the dependent jars needed to reproduce the results
> shown on the gump site would be those that were just built minute before
> from source.
Yes - for the case of Gump testing. +1000.
For gump testing of functional dependencies, where you want to test a
project against a set of other jars it depends on, whether or not you
use specific versions, or play the lottery with the CVS heads of those
dependencies, this is 100% the way to go. I have been saying for a
little while now that augmenting the Gump process by also testing
against a specific set of jars would be great, especially when preparing
for a release. We do it in velocity for two gump 'targets', the regular
build as well as a 'testbed run', and I want to add a third which is
testing our codebase against a set of specific jars (although we have no
external dependencies at the moment...).
So, I think we can agree that I 100% agree with you, and we can put this
one to bed?
Great. Yet...
This doesn't address the need of making the project easy to download and
get started by having a build script that doesn't depend on the user
having other things, like Ant, Stylebook, Velocity, Xerces etc
installed just to 'boot' the build process (so the build process could
go tell the user to go get something functionally critical, like Oro or
something).
All I wanted was to be able to start a build script via Ant. I don't
need to have the functional jars that the component the user is building
be present - an Ant based build is mighty powerful in figuring out what
the user has, and communicating any requirements to the user. It could
even go fetch and build a CVS snapshot for the dependend-upon jars.
But ya gotta somehow boot Ant first... :)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
