Sam Ruby wrote:
>
> Geir Magnusson Jr. wrote:
> >
> > I understand what you are saying, but how does making the user go
> > 'fetch' solve anything if that user wants to build two components of the
> > Commons package, and they require different versions of Ant? Should we
> > ask the user to go download and install *two* different versions of
> > Ant? And then force them to diddle with their classpath for each
> > component build step?
>
> Read what Craig wrote. Or what I wrote.
I was responding to what craig wrote, and I just reread what you wrote,
and I still don't see why, again, just to build, we want to either
assume something about the users environment, or make them go off
finding specific versions of the utility that we use to build when we
can just include it.
> Nobody said that a downloadable tgz or zip should be incomplete. Take a
> look at the downloadable builds of tomcat_4.0 or avalon.
Are we saying that our nightly snapshots of the CVS tree will be
complete with specific jars needed to build? Great. That's all I
wanted. Just easy for people who need to get a snapshot, build it, and
use it. (First time users, itinerant consultants, etc...)
>
> > I believe that if you are depending
> > upon a specific released version of a jar
>
> ....Important bulletin: we interrup this quote to bring you the preferred
> completion of this sentence:
>
> DON'T.
Are you kidding? Didn't Craig just say that a component might require
Ant-1.3 vs Ant-1.2 to build?
Didn't you just seem to agree above that that was fine and dandy?
All we are talking about is getting the basics to build the project
lying around to make it easy. I am not suggesting that all external and
cross functional dependencies be satisfied in some global top-level
bag-o-jars. Just ant, xerces, and maybe Velocity if the Anakia style
documentation / site building technique is used.
>
> If we want to build a composable system we can't affort to have brittle and
> early-bound dependencies.
Neither can you afford always working with a random CVS-of-the-moment
snapshot of something else. I agree 100% with what I call your 'Gump
Philosophy', that there is real value and real benefit in always
cross-testing over and over the various interependencies between
projects.
However, I think for the the basics of building the project or
documentation, making a fire-and-forget build isn't a bad idea.
Again, I am not talking about real functional interdependencies. I just
want to build.
Functional dependencies can be dealt with in the Ant script : if
something is needed, nicely tell the user what that is, and where to get
it.
try the jar-j2ee build target in Velocity to see what I mean.
Start in the jakarta-velocity directory. Then
cd build
./build.sh jar-j2ee
read the message...
geir
>
> The place to start is with Commons.
>
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
