"Craig R. McClanahan" wrote:
>
> On Wed, 11 Apr 2001, Geir Magnusson Jr. wrote:
>
> > Jeff Turner wrote:
> > >
> > > Are these characterizations right?
> > >
> > > - If Ant isn't bundled, then there's no shell files, and build.xml and
> > > build.properties can be dropped in the project root, just like Makefiles.
> > > Nice, simple and intuitive.
> >
> > Except you punted the entire issue by making people install Ant.
> >
> > > - If Ant isn't bundled, then dependencies becomes a hassle.
> >
> > Seems so.
> >
>
> 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).
But when I think about this, I break it up in my head into two parts :
1) non-functional requirements - things like Ant and Velocity (for
Anakia), just to get things rolling. If we go back a few weeks now, I
suggested we keep one copy 'at the top' for all commons components to
use to 'bootstrap' their build process. And for a regular developer who
has Ant in their path / CP / environment, things work normally.
2) Then Ant can tell the user about *functional* requirements (like
object pooling for DBCP), so the user can get them. This means that we
don't bake in the version binding problems (that Sam correctly fights
against).
> 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.
>
sure. I like the build.properties file.
> > > - 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! ...
>
I suggested that a long time ago - why bother with all this 'jar' stuff
anyway. Royal pain. You work at Sun - help us on this - we should just
roll the whole jakarta source tree into the J2SDKEE, require a signed
NDA with 3 affidavits from non-relatives, and ship it with each new copy
of Microsoft NT 2000 XP Enterprise Data Center ME!.
The other extreme would be give users a ROM burner, a soldering iron,
and the GOF patterns book, hoping they came up with something.
> Reducto ad absurbum, but the point is that at some point we're going to
> have to assume that the target user has done SOMETHING to get ready.
Right. And now we require them to do EVERYTHING to get ready. I believe
there's a middle which doesn't inconvenience anyone, is transparent to
developers, easy to first-timers, and won't require endless amounts of
cvs JAR checkins / updates, and doesn't inflict static version binding.
> 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.
Ok - suppose for whatever reason, maybe the product you sell is
dependent upon it, you need to have JUnit 7.9 on your machine. Now, we
in Commons require JUnit 8.0. What do you do?
Or, what happens when component A needs version X and component B needs
version Y?
> 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.
I agree. You convinced me of that a while ago. The amount of 'crap' can
be limited to Ant and a few others at the top level.
Even better, just Ant - and we build a lightweight CJAN-like facility
where Ant can go fetch anything it needs and can't find.
> > > Otherwise it's back to bundling Ant, script files, "build" directories, etc,
> > > which would be sad.
> >
> > Come on. Its so easy, and makes it so easy for users.... Is this some
> > urban legend? Has anyone really run into great difficulties with this?
> >
>
> 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).
I know, I know. You changed my mind on this issue a while ago, hence
the CJAN-lite idea...
I think there's a middle that respects existing developer configuration,
avoids functional version binding, makes it easy for newbies, and
doesn't affect the broadband-challenged...
geir
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
