I'm not sure I responded to this fully... I think I started and never
completed.
inline..
Sam Ruby wrote:
>
> Geir Magnusson Jr. wrote:
> >
> > I think it would be nice if for the jakarta-commons tree, there is a
> > build.sh/build.bat that will invoke the build of every component,
>
> I doubt that individual developers would make use of such sh/bat files.
> Furthermore, from a Gump perspective it probably makes sense to build and
> report on each separately.
I agree, but this has nothing to do with Gump. This has to do with an
end user who wants to download things and try them out.
> Net: I don't object, but I don't see much point.
>
> > and
> > further, that the jakarta-commons tree include all the necessary jars to
> > build all components completely, except the JDK.
> >
> > This way, our nightly snapshot is self contained - very convenient for
> > first time users as well as those instances where you are on a strange
> > machine and need to quickly download and build (which happens to me
> > often as a consultant...)
>
> I post the nightly snapshots and builds for a number of projects (ant,
> xalan, avalon*, slide, soap, axis, and regexp) and would be glad to do so
> for commons.
Fantastic. I assumed we would use Gump for build and
cross-project/component compatibility testing, but if will assemble a
nightly CVS snapshot with all the pieces needed by a user to build, cool
beans....
> Such snapshots could be designed to order. Note that the
> avalon-cornerstone cvs has a snapshot of the avalon-phoenix jar in it, but
> the nightly builds are built against, and posted with, the latest
> cornerstone. (This is particularly appropriate as there never has been a
> release of any of the avalon sub projects.)
That's what we need to augment : we should be able to build against
something specific, not CVS head du jour, as there is no guarantee that
will work. Of course, for the usualy Gump testing, going against the
head is a great thing.
>
> I know some people are wary about trusting on the stability of other
> components, but I feel that it is only by trying to make it work that we
> can actually get to the point where stability is obtained and maintained.
I agree - except that making it a Lottery for end users that want to try
things out might not be the right place for that experimentation.
I like gumping cross-project, CVS head to CVS head. But additionally,
the functionality of building specific, non-random configurations of
builds and snapshot would be great to have.
> Besides, components in commons are likely to have an absolute minimum of
> dependencies, right?
Well, you need ant to build, will need junit to test, prollie xerces,
velocity for documentation...
We aren't talking about 'functional dependencies' required by the
component itself. We are talking about what we need to build and test
the component.
> > I am happy to do the work. I am looking for alternative suggestions or
> > votes of support.
>
> So am I. Furthermore, I am building the components daily anyway...
Here is where I begin to realize that I wasn't able to be clear in what
I was trying to say - what I was offering to do is simply make a place
/build and /build/lib where build would contain build.sh, build.bat and
build.xml needed to invoke each components build process. Yes, this
would be useless for developers, but might be useful for *users*.
Second, the /build/lib directory would contain common things like Ant,
xerces and Velocity used for building and documenting. *Not* things the
components themselves are dependent upon...
>
> > <aside>
> > I want to note that I think having each component under the same CVS
> > tree will be ungainly as we acquire more components. It will be
> > important to be able to download individual nightly builds of each
> > component, as well as the whole thing...
> > </aside>
>
> No problem. Describe what you want, and I'll see to it that it happens.
Cool! :)
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
