Jim Moore wrote:
> I've built what's in CVS (log4j 1.1) on both Linux and Win2K boxes simply by
> typing "ant jar" from the build directory without a hitch. I purposely
> don't have a CLASSPATH env variable set, and it still worked fine, so
> assuming you have ant set up correctly, the rest seems to work. And since
> the build skips non-necessary targets if it can't find the support jars, it
> handles lack of the optional stuff elegantly.
as i said i haven't got 1.1 but since Ceki invited comments i thought i'd
share...
log4j's build feels a little different, that's all.
i do think that the build skipping's a neat feature.
> As for the stuff that can be redistributed, there's no need to include them
> in the log4j CVS -- have ant grab it directly from the source with its ftp
> task. So you could have a task called "get.support.jars" or somesuch.
from a straw poll of jakarta stuff on my machine, turbine + ecs ship with the
jars required to build.
tomcat 4 doesn't ship with any jars - they use environmental variables for the
required stuff.
(this can be a bit of a pain, though, if you have incompatible versions.)
an ant task? why not?
IMHO the main thing is to have the system log4j uses well documented in the
build files and in a README.
> I'm missing the reason why a shell-script would be a good thing, as that's
> system dependant. Why not have ant handle classpath issues and the like?
> Is there something that's needed for log4j that a shell script can do but
> ant can't?
a lot of other jakarta stuff (eg. turbine, ecs, tomcat 4) have build.sh that
sets up the classpath to include ant and the other support jars required to run
ant - and then it runs ant. (they also includes some cygwin stuff.)
i think it's much easier to start a shell script rather get the java -classpath
xxx ant correct.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
