At 08:45 11/4/01 -0700, Craig R. McClanahan wrote:
>Ant bundling only solves one dependency problem - when Ant itself needs an
>external package to function. You're going to have dependency issues in
>any case when a particular package depends on others (e.g. DBCP depends on
>object pooling).
It also solves version incompatabilities, screwy classpath issues etc.
>Note that build.properties files deal with this second type of dependency
>issue by assuming that you've downloaded them separately -- just tell Ant
>where they live. The existence or absence of build.sh/build.bat scripts
>makes no difference.
build.properties don't require that you have to go out of your way to
dowload a bunch of junk just to try something - however it does give you a
chance to overide it. For instance in avalon I set up all the properties so
that they point to
mylib.jar=${lib.dir}/mylib.jar.
You can still overide this by property and use your own but novice users
still have a simple time. It is simply a CVS update followed by "ant" (or
build.[sh|bat]).
>> > - The dependency problem can be solved by a commons/lib directory,
containing
>> > optional.jar, junit.jar, xerces1.2.2.jar, etc. The INSTALL doc then
tells
>> > people to drop this stuff in $ANT_HOME/lib, if it's not already there.
>>
>> Maybe. I don't think we should make people drop things into what could
>> be part of their working environment to play with our stuff. I mean, if
>> you depended upon your current ant configuration for your daily work (
>> and you probably do...) would you want to drop arbitrary things in there
>> to play with some software?
>>
>
>By that argument, we should include the JDK in the "all in
>one" download. But wait! You need an OS first! Add Linux to the
>mix! ...
err... nice red herring there.
>I want to use my previously installed one-and-only-one copy of JUnit (just
>to pick an example), so that when the next version comes out I can update
>ONE entry (in ${user.home}/build.properties) and I'm magically using it
>for all my projects. I'm willing to configure my development tools
>appropriately because *I* know which versions of each *I* trust.
So *you* know what you are diong ... most people don't. You would make them
suffer instead - sounds great. You can still update one entry in
${user.home}/build.properties and magically be using all the correct jars
anyway - it is irrelevent whether they are included in CVS.
>This has nothing to do with whether someone could make available
>all-in-one-download distributions with everything you need. Just don't
>make me download all that redundant crap simply to compile something from
>CVS.
yer - make the newbies go scrounge and suffer - that'll make em more
willing to contribute to your project - right on!
>Try doing a "cvs update" across a modem and see how user-friendly it is to
>force bundling of everything (jakarta-site2 makes a good case in point).
less painful than running around to collect N jars, reading install sheets,
editing scripts/properties, just to compile something.
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
