Sam Ruby wrote:
>
> Geir Magnusson Jr wrote:
> >
> > 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.
>
> Take a look at the guarantee that is provided for Nightly builds:
>
> http://jakarta.apache.org/site/binindex.html
I am not talking about a nightly build. I know I said that originally,
but I misspoke, and clarified on a later post.
I mean a 'nightly snapshot', a tgz or zip of the CVS to make it easy for
people to grab a copy of what we are working on and play w/ it without
having to get a CVS client. In many places, such 'foreign software' is
verboten by corporate IT departments, and just getting a tgz or zip is
so much easier.
The motivation here is to lower the cost of entry for someone wandering
by - if you can just grab something, build it, then I think we have a
chance of hooking someone with this open source thing....
At least get the build started - if a user don't have some of the
functional parts, and have to get them, that's cool too. Nothing turns
me off personally like typing 'build' or 'make' and having things go
ugly immediately. I don't mind having to get parts if it tells me, but
my interest is sustained only if I have the feeling that the developers
took a femtosecond or so to make what they are doing accessable.
> My goal is to make progress toward the goal of having a guarantee that it
> will work:
Yes. I agree 100%. But I think we are talking about two different
things here.
As I understand it, you are talking about cross-functional dependencies,
and I agree with you 100% on this.
As I am trying to communicate, I am talking about solving the
*non-functional* dependencies of the 'project environment'. Building,
making docs, etc, for a project that is supposed to be little building
blocks for people both inside and outside of Jakarta to use.
>
> Over in xml land, every other release of Xerces would break Xalan. Now
> nightly not only are each built against each other (the process involves
> Stylebook), but there also is a "smoketest" that looks for breakages.
>
> Did you know that the nightly velocity tests run by Gump use the latest
> junit, Ant, and jdom?
If you had asked directly, I would probably say "I'm not sure, but I'm
not surprised, and I like it".
And I think that's good. That's a cross-functional dependency.
> The nightly tests of ant are run with the latest xerces, xalan, junit,
> regexp, and org?
Excellent!
> So the question to ponder: if you were going to download a snapshot, and
> had access to the build logs and test logs that showed some indication of
> what worked and what didn't, wouldn't you prefer that the exact versions
> used to run the tests were included in the download?
Yes. Those logs would be pointless if they were the equivalent of "When
I used some version of Foo, something didn't work." as my answer would
be "I'll take a look at it sometime..." :)
> Note: the question above is a quite different one than what should or
> should not be included in CVS.
Well, just to continue my assault on the equine with a negative
patient-care outcome, I am talking about non-functional support issues -
Ant, JUnit(?), Stylebook, Velocity(Anakia) - to let a user start a build
of our stuff w/ minimum of pain, or build the docs, or...
However, I will point out that while the question is quite different,
there is something relevant there - by making it a version Monte Carlo
from soup to nuts, user support gets more laborous. Since it is assumed
that starting with step 1, building, we are relying on random jars in a
users classpath, then user/community support now starts with step 1,
building. And I am sure that will result in repeated instances of
asking a user to tell us what version of Ant they are using.... then,
each component will get sick and tired of that, and each component will
add a FAQ explaining how to find, download and install Ant.... so
instead of tossing an ant-1.3.jar and ant-1.2.jar into
jakarta-commons/build/lib (or tools/lib) so each component is assured
that a build script can find a known Ant to use to get started...
And preempting the counter argument that you should point people to
milestone or release builds, in the early going, you tend not to have
that...
>
> - Sam Ruby
>
> P.S.
>
> Avalon used to be the top of my sh*t list, as it routinely made changes
> that broke everybody who depended on it. Now, thanks to Peter, it has
> turned around 180 degrees - it deprecates interfaces, proactively works
> with other projects to mitigate necessary changes, and provides a
> mechanism for developers to substitute their choice of version of key
> dependencies.
Yay Peter!
>
> Now Turbine is the top of my sh*t list. The *only* build errors on
> http://jakarta.apache.org/builds/gump/2001-04-01/ are due to Turbine
> changes. In fact, the number of errors reported by Turbine changes
> increased from 66% percent last night.
Boo Turbine!
> If Commons goes down that path, I will do what I can to pull the plug on
> this little community, as Turbine may have a raison d'etre outside of
> its usage by other jakarta projects, code in "commons" that actively
> snubs their user community doesn't deserve to have disk space here,
> IMHO.
Gaa! I think you are missing what I wanted here.
1) I agree 100% that cross-gumping to illuminate such problems is a good
thing - necessary and valuable.
2) They shouldn't happen in the first place.
2) This has nothing to do with what I want, which was to make getting
the build going easily...
I just want to make it easy to get the build started.
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
