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]
