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 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.
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?
-Jim Moore
-----Original Message-----
From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 7:50 PM
To: LOG4J Users Mailing List
Subject: Re: Build log4j is a PITA
First, I should like to mention that the ANT build scripts changed quite a
bit between log4j 1.0.4 and 1.1. There is no build.inc anymore (merged back
into build.xml) and build.xml moved to the build/ directory. Log4j now
relies completely on ANT to do all steps related to building an actual
distribution, compilation, generating javadocs, building the jar files, tar
and zip the actual distribution, and so on.
Coming back to the issue of a log4j build (shell) script, it would require
the inclusion of ant.jar, some-xml-parser.jar and bunch of other jars in the
CVS repository. The full log4j build is based on:
mail.jar (for javamail-1.2)
activation.jar (JAF required by JavaMail API)
junit.jar (for JUnit)
xerces.jar or jaxp.jar+parser.jar (for ANT and XML parts of log4j)
jms.jar (for the JMSAppender)
jndi.jar (for the JMSAppender)
ant.jar
In my conservative opinion, that's a lot of binaries to put in a CVS rep but
not a show stopper. I think that some of the files cannot be re-distributed
due to licensing restrictions. I'll have to dig into this.
All in all, I think that adding a build shell script would make log4j
builder's life easier and that's obviously good. Ceki
At 00:18 13.03.2001 +0000, Robert Burrell Donkin wrote:
>Jason van Zyl wrote:
>
>> Ceki Gülcü wrote:
>>
>> > Jason,
>> >
>> > And I thought that the ANT build file was OK... Could you share your
unpleasant experience so that we can avoid others the same pain? Cheers,
Ceki
>> >
>
>funny - just before this was posted to the list, i just had to hack the ant
build file to make it work...
>(BTW these comments are based on log4j 1.0.4)
>
>>
>> > ps: Cleaning up the build file is appreciated. However, it is still not
clear what is wrong with it in the first place.
>
>IMHO, it should be more like turbine's build script, so i got mine working
by changing it until it was.
>
>the major changes i made to get it to run were:
>1. to create a shell script to start ant (mostly the shell scripts used to
start ant are very, very similar - so i used one from turbine)
>2. i modified the build.inc to use an internal ant classpath variable (this
is how the turbine scripts are organised) rather than the classpath
>enironment variable. IMHO, this eliminates so many problems!
>
>Other observations on build.inc?
>i do like the usage printout but the scripts used by turbine etc are a lot
more readable since the have really, really unmissably large comments,
>
>> Hi Ceki,
>>
>> First, of all there is no shell script provided to fire up ant. This is
something
>> that I am accustomed to as we do it in Turbine and Velocity. It makes
things
>> very convenient.
>
>IMHO a build.sh is a must.
>
>> Second, the ${classpath} variable in the build file doesn't have a value
unless
>> you explicity set a -Dclasspath=$CLASSPATH option when invoking java.
>> This isn't very clear. I'm used to going into a build directory and
invoking the
>> script and everything builds. That classpath value should probably be
>> taken from the system classpath. Maybe that was the intention but with
>> the ant 1.3 jar I used this isn't what happened.
>
>IMHO classpath used by the script should be computed internally rather than
using the environment variable. the build worked well once i'd replaced the
>${classpath} envirionment variable with a calculated ant path variable.
>
>> Third, the basedir is ".." which isn't very convenient if you are using
>> relative paths for your classpath. Again this is just something I do
because
>> I usually place the JAR that I am using for a build in a lib directory
inside
>> the build dir. So I was constructing a classpath from the JAR files in
the
>> build/lib directory but because the basedir was ".." the classpath I
constructed
>> didn't work.
>
>at the very least, this should be something that should be in a README.
making the basedir '..' makes sense if you've doing the build in a
>subdirectory.
>
>> So what I would like to do is:
>>
>> 1) provide a simple shell script
>> 2) make the build relative to "."
>> 3) either provide the JAR files necessary to build log4j
>> or
>> 4) use an ant task to download the necessary jar files
>>
>> I don't think you like 3) if I remember from the lists. This is just what
I
>> am used to with Turbine and Velocity and it works very well. We've never
>> had any complaints about building. But 4) is fine with me.
>>
>> All I would like to do is provide a dead simple way for people to check
>> out log4j from CVS and build it. I think everything should be provided,
if
>> not the dependent jars then some way to pull them down.
>
>most other projects seem to include the jars you need to build, if only
since this ensures that you always use the correct versions. This is another
>good reason for using internal ant path variables rather than environment
variables.
>
>(if it's any use to anyone i can post the altered scripts i have *but* they
are very rough...)
>
>- robert
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
I hope to see you at my ApacheCon 2001 presentation
entitled "Log4j, A Logging Package for Java".
See http://ApacheCon.Com/2001/US/ for more details.
----
Ceki Gülcü Web: http://qos.ch
av. de Rumine 5 email: [EMAIL PROTECTED] (preferred)
CH-1005 Lausanne [EMAIL PROTECTED]
Switzerland Tel: ++41 21 351 23 15
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
