Sam Ruby wrote:
>
> Geir Magnusson Jr. wrote:
> >
> > Ok. Just to be clear, the issue that got this started was :
> >
> > " 2) jakarta-commons/build/lib
> >
> > contains common jars used for building."
>
> Perhaps that's the issue for you.
That is what started the thread, and what craig and others responded to,
I think. It's what they quoted anyway...
>
> > And isn't this a bit much to avoid putting an Ant jar in the top level
> > directory of jakarta-commons' CVS?
>
> Sigh.
>
> I still maintain that you are missing what I am saying:
No. I get what you are saying. I even agree with it.
> Can you quote an e-mail on this thread where I have objected to putting
> an Ant jar in the top level directory of jakarta-commons?
You actually haven't mentioned it, and it was the issue that seemed to
bring some discussion from Craig. There seemed to be some confusion
about if I was talking about functional dependencies such as how Cocoon
is dependant upon Turbine, which I wasn't, versus non-functional
dependencies, like having an Ant.jar in the build/lib directory of the
Velocity CVS so first time users can build.
I tried to clear that up.
Later on, there was this bit :
Geir :
> I believe that if you are depending
> upon a specific released version of a jar
Sam:
> ....Important bulletin: we interrup this quote to bring you the
preferred
> completion of this sentence:
>
> DON'T.
And I believe you will state below that you want to 'gump' the
automation of things with "exact versions" of dependant jars...
If you are doing exact versions anyway, from tagged CVS, what's the
point? What changes from day to day?
so I either we go into a long debate about the differences between the
intent behind "specific released version" of a jar versus a jar
repeatedly created from an "exact version" in CVS, or it appears that on
some level we agree and are talking about the same thing.
> In fact, I
> think I have gotten out of my way to indicate that what I am trying to
> discuss is *not* related to that issue. [should you ever ask my opinion
> on that subject, I will simply indicate that I will never use that jar,
> and that I don't believe that the top level directory is the right place
> for it anyway]
First, I never suggested a jar in the top level directory. That would be
the wrong place, I believe as well. I refer to the 'top level' jar
meaning in the top-level build/lib (tools/lib). And the point was to
simply make it easy for all components to share a copy of ant to make it
easy, or keep what the needed in their own build/lib (tools/lib) if
different.
Second, I keep agreeing with what you want to do, and then bring back
the discussion to my point, but I seem to be unable to do that.
I think what we want are two different things that can happily coexist
with little to no downside.
>
> Back to the topic that I would like discuss:
>
> I would like to upload daily a set of files which are useful. I am
> willing to aggregate, subset, or otherwise produce files which maximizes
> their usefulness.
+1 for maximal usefulness.
>
> 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?
That would be great! I agree. I'll even help if you'll let me.
But to focus in and discuss what you want to talk about, and put aside
what I want to talk about for a moment :
I assume that you are going to Gump everything in Commons with the usual
paradigm of testing against the
CVS head of each dependency as well. This is good, and should be done.
And I have a question :
Given that you would be rebuilding the dependant jars from a tagged CVS
to get an 'exact version', what would you be testing? How well Ant
works? Where is the benefit versus having a canned set of jars of
'exact' versions?
So, if you are doing 'exact versions' anyway, from tagged CVS, what will
change from day to day? The project source will change, but thats a
given, and isn't the point.
The downside I see is that the user download isn't a CVS snapshot, and
the CVS tree what the developers would have on their machines.
----
Ok. Now can we get back to what I wanted to talk about?
Just for giggles, I decided to go take a look and see if what I was
proposing was such a revolutionary and 'out there' idea, namely
'including a few jars in CVS'.
I am sure that sentence above will bring down more exasperated sighing
from Sam as I believe this is what he is trying to avoid, but since we
don't have a solution yet, or the solution appears to be homomorphic to
having jars in CVS, and I am both fearless and stupid, I continue...
Ant : /lib contains crimson.jar and jaxp.jar
Hmm.
Avalon : /lib contains bytecode.jar, logkit.jar and xerces.jar /tools
contains ant.jar, optional.jar, stylebook.jar, testlet.jar, xalan.jar
Avalon-cornerstone : /lib contains avalonapi.jar, logkit.jar,
phoenix-client.jar
Alexandria : /lib contains a few
...
James : /lib has 10
Jetspeed : /lib has 13 jars
Tomcat : /bin has 2
Tomcat-4.0 : /lib has 2 jars
...
And this is stuff they depend upon for correct operation, it seems. Not
sure though.
All I wanted was something to make an easier build process where the
users' codebase matched the developer CVS.
If no one else is interested, I give up for now... off to code, and
paperwork. The tax man cometh!
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
