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]
