----- Original Message -----
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, April 01, 2001 8:41 PM
Subject: Re: [PROPOSAL] build structure jakarta-commons
> Vincent Massol wrote:
> >
> > ----- Original Message -----
> > From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
>
> > [snip]
> > > > The full list of dependent jars is:
> > > > - junit
> > > > - stylebook and thus xerces and xalan
> > > > - servlet.jar for Servlet API 2.2 and/or servlet.jar for Servlet API
2.3
> > >
> > > and if you add an Ant-based build / test infrastructure, you will need
> > > Ant as well, as I noted earlier.
> > >
> >
> > right, but Ant is different. It is an application, not just some jars.
>
> Well, I do agree with this a some level, but being truthful, it's 'just
> some jars'. Just like stylebook, xerces and Velocity-Anakia.
not exactly true. You also need a bunch of batch files (shell scripts).
These are mostly needed for tasks such as <exec>, which are system dependent
but still I hate to make a hack ... If you look at the Ant installation
documentation, you'll see that it needs to be installed with a bin directory
containing the scripts, a lib directory containing the jars, ... To tell the
truth, I was using Ant exactly the same way you're mentionning a few weeks
ago. And then I found, by discussing with several persons here, that I was
using it the wrong way (i.e. not the orthogonal way) and that in the end it
was much simpler to use it the correct way. For example, if you don't use
Ant as an application then you'll also need to provide batch files to start
it (in order to set the classpath, verify environment variables like
JAVA_HOME, ...). You'll have to make sure your script works on Win98, WinNT,
Win 2000, Unix, .... I can tell you it's a nightmare ... but the worse is
that it has already been addressed by the guys doing Ant (thanks guys by the
way !) ...
>
> > Nevertheless you are right, installing Ant is part of the requirements.
> > Moreover for Cactus to work (either the build for functional tests or
for
> > the runtime) you also need to install one or several servlet engine(s)
but I
> > won't bundle the engine in the Cactus lib directory.
>
> It just seems odd to me that we would require the installation of Ant,
> when it can be so easily included.
yes, but installing Ant is only unzipping a zip file in a given directory.
If you think it is really needed, we can always package a version of Ant
when we deliver the "standalone" version of our framework/application. But I
would hate to tear apart Ant by just pulling the jars out.
>
> As for the other stuff, sure - you are probably focused on working with
> this in conjunction with the servlet engine you are already familiar
> with, so that makes sense.
>
> >
> > > so maybe two ant jars, junit, stylebook, xerces, xalan,
servlet-2.2.jar
> > > and servlet-2.3.jar.
> > >
> > > That's 8 jars we would suggest the user go off and find...
> > >
> >
> > yes, that's why I packaged them in a zip for ease of use.
>
> :)
>
> (I think you are proving my point...)
>
:) I agree on making it easy for beginners.
> > > > In order to make it easy for newcomers I provide a
> > cactus-dependencies.zip
> > > > file containing the copy of these jar that I use on my computer.
These
> > are
> > > > built using a 'dependencies' target. On my machine, I have the CVS
trees
> > for
> > > > all these dependencies and from time to time I do an update and
rebuild.
> > My
> > > > build.properties points to these other projects dist directory. And
GUMP
> > > > always use the latest version of these dependencies doing it's
nightly
> > runs,
> > > > which is the really cool part ... :)
> > >
> > > So you have the jars 'in CVS', only you bound them in a zip. No
> > > difference. You made it easy for a user to get started. I like that.
+1
> > >
> >
> > the jars are *not* in CVS. There are built by the ant build scripts of
the
> > other frameworks.
>
> Sorry - didn't the above sentence read
>
> "In order to make it easy for newcomers, I provide a
> cactus-dependencies.zip file containing the copy of these jar that I use
> on my computer."
>
> ?
This zip file is generated by an Ant target when you build Cactus. It lives
only on my local computer until when I copy it to the release area or the
file server.
>
> If you wanted to move the entire project to Jakarta, you would have to
> put that .zip in the CVS, right?
>
> > > >
> > > > Note: Some of these external jars are needed for Ant to run (such as
> > > > stylebook, junit). For these I copy them to $ANT_HOME/lib so that
they
> > are
> > > > added to the Ant classpath automatically. For the jars that are
needed
> > by
> > > > the code (not by Ant itself), I leave them in their dist directories
and
> > > > point to them. Concerning Cactus, there is only one : servlet.jar
> > >
> > > Ok. So now, if you want to play with Cactus, you have to possibly
> > > overwrite things in an existing configuration, your ANT_HOME/lib,
> > > risking breaking other things you already have. -1
> > >
> >
> > again, Ant is an application. So yes, you need it installed.
>
> That's not true. You don't need it 'installed'. Look at Velocity (and
> others). We include ant so you can build - the only requirement to
> build velocity is the JDK.
>
> No problems. Two jars in the build/lib directory.
>
> > But you don't
> > have several installations to do. Just one.
>
> But what if you want to use Ant 1.3 and I have Ant 1.2? Then what?
Yes, this problem always arise. Nothing prevent you from installing several
versions of Ant on your computer. You'll just need to make sure you call the
correct ant.bat (or ant shell script). You can even install a specific
version of Ant inside your project directory if you wish. That's the point I
like, to let the user be able to do whatever he wishes. I personally prefer
to always run all the builds with the latest version of Ant and tell/help
the developers if their build file is not compliant. If their build.xml
fails with my version (it has never happened to me but I'm sure it is a
possibility) then I can always install the required version. The real
problem as I see it is to let each project bundle it's own version of Ant
... this will tend to create problem as developer will write against that
version, even if it is an old version thus creating dependencies with it. I
prefer the XP approach of discovering problems early and always being up to
date.
>
> I make my living with my computer. I would prefer that I don't have to
> make a mess of it to build 'Cactus'.
>
> > If you use the junit task, put
> > the junit jar in the $ANT_HOME/lib, same for stylebook and others. I
don't
> > think you need several setups for different projects.
>
> That's my business, isn't it? What about version differences? What if
> you want version X of JUnit and I want version Y for my everyday work?
> Or a custom version?
>
> geir
Vincent
