----- Original Message -----
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, April 01, 2001 6:11 PM
Subject: Re: [PROPOSAL] build structure jakarta-commons
> 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.
>
Why don't we include these external jars in, say, the nightly snapshots ? Or
in a SDK version ? Then newcomers can download this all-in-one version. This
prevents from including the jars in the CVS and still has the advantage of
simplicity for novice end-users that want everything packaged. For
developers, they use the version they want on their system, updating it as
frequently as they want and GUMP always use the latest versions.
> geir
>
Vincent
