Thanks for the feedback! Sorry for the late response, I've been on vacation
since the 2nd. Responses inline...
> -----Original Message-----
> From: Jeff Turner [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, May 05, 2001 11:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: resubmit: build process without .bat and .sh files
>
>
>
> This is one of the neatest build systems I've ever seen.
> Clean, simple.. way
> that projects can "hook" into the generic build process with pre and
> post-targets is just beautiful :)
>
> Enough with being nice ;) I had a good play, and have a few
> questions..
>
> > GOAL1: eliminate the .bat and .sh scripts
> >
> > To solve #1, I had to replace the two major pieces of
> functionality within
> > the .bat and .sh scripts: (1) extract environment variables
> and pass them
> > into java, and (2) ensure that Xalan and Xerces are in the
> Ant runtime so
> > that the <style> tags in the documentation target will run.
>
> 1) Would it be possible/desirable to eliminate environment variables
> altogether, and just require the user to edit a properties
> file (with entries
> like "servlet.jar=/var/tomcat/lib/servlet.jar")?
>
> Environment variables have the disadvantages that:
> - they're ephemeral, lost when the terminal/DOS box closes
> (unless stored in
> .bash_profile, etc)
> - the notion of an environment variable isn't portable across OSes
>
> Env variables -> properties would be a trivial change in common.xml.
I agree, it would be trivial. My only hesitancy about using a physical
properties file (such as config-local.properties) to look in would be that
local changes to it might accidentally get checked in... I figured that
environment variables would never get checked in.
On most our projects here we started off with the local properties file, got
rid of that and switched to environment variables, then dumped that as well
when the list of dependencies got longer than 2 jar files. Right now our
projects are using the lib/ approach that James Strachan advocated. It took
a lot of convincing for me to want to put jar files (the moral equivalent of
a binary executable) in to our source control system, but eventually I came
around, because relying on being able to download old versions of dependent
libs from external sites is pretty risky.
>
>
> 2) For Xerces, a grep indicates that there are no direct
> dependencies in the
> source. Recent version of Ant come with crimson.jar instead
> of xerces.jar.
> Crimson is functionally identical, so why insist on Xerces?
no reason, just following an already-established pattern.
>
> 3) For Xalan, the class looked for
> (org.apache.xalan.xslt.Stylesheet) does not
> exist in recent versions of Xalan. However, this vintage of xalan is
> *required* for the xsl taglib. The only jar I could find was
> xalan_1_2_2.jar
> from Cocoon. When I put this in my ANT_HOME/lib, Ant died,
> with the following
> error:
>
> BUILD FAILED
>
> /home/jeff/apache/jakarta/jakarta-taglibs/application/build.xm
> l:91:
> javax.xml.transform.TransformerFactoryConfigurationError:
> java.lang.ClassNotFoundException:
> org.apache.xalan.processor.TransformerFactoryImpl
> --- Nested Exception ---
> javax.xml.transform.TransformerFactoryConfigurationError:
> java.lang.ClassNotFoundException:
> org.apache.xalan.processor.TransformerFactoryImpl
> at
> javax.xml.transform.TransformerFactory.newInstance(Transformer
> Factory.java:121)
> at
> org.apache.tools.ant.taskdefs.optional.TraXLiaison.<init>(TraX
> Liaison.java:87)
>
>
> This is because later versions of Ant (I'm using 1.4a) default to a
> TraX-compliant processor, which xalan_1_2_2.jar isn't. No,
> this can't be fixed
> with the "processor" attribute. The solution is to have
> *both* versions of
> xalan.jar in the classpath or $ANT_HOME/lib directory.
>
> Overall, I've come to think that it isn't the job of a
> project build.xml to
> enforce the existence of jars which core Ant tasks require. I
> want to be able
> to use *any* JAXP-compliant parser, not just Xalan (whichever
> version).
> Likewise with xerces/crimson -- it's not common.xml's job to
> enforce which I
> use. In fact it *cannot* do so reliably, as the above
> problems illustrate.
>
> So I say remove the Xerces and Xalans checks from common.xml
> totally. Because
> xalan1.2.2 is directly required by the xsl taglib, the check
> currently in
> common.xml can be moved to a "checkRequirements.pre" target
> in the xsl's
> build.xml.
I'd love to do that -- frankly if a CORE ant task requires a jar file, Ant
should ship with that Jar file, or at the very least provide its own failure
message that's more descriptive the ClassNotFoundException.
The reason I put the Xerces and Xalan requirements in there was to avoid the
problem with the current/old build system that you didn't always know why it
wouldn't build. I wanted the error to be as explicit as possible. If we can
have Ant 1.4 fix that problem, then I'd be willing to jump on the bandwagon
and make the Ant build script rely on 1.4 (sorta like it currently relies on
1.3 for the environment stuff).
As a sidebar - this is probably more appropriate for ant-dev - I think it
would be nice to be able to specify in your build script a minimum version
of Ant, so that if we do require 1.4, and someone tries to use an earlier
version that won't work, Ant can give a decent explanation and direct users
to how to upgrade their Ant version.
>
>
> There, I've had my rant.. just one more point :)
>
> When building the documentation, I get this warning:
>
> documentation:
>
> default.pre:
> [copy] Copying 1 file to
> /home/jeff/apache/jakarta/build/taglibs/application-doc/WEB-INF
> [style] DEPRECATED - the style attribute should be
> relative to the project's
> [style] basedir, not the tasks's basedir.
> [style] Transforming into
> /home/jeff/apache/jakarta/build/taglibs/application-doc
> ..
>
> This is because I'm using bleeding-edge Ant. After a bit of digging, I
> unearthed the thinking behind this here:
> http://marc.theaimsgroup.com/?t=98477438800011&w=2&r=1
>
> It's simple enough to fix this in common.properties:
>
> 20c20
> < taglibs.xsl = ../../../src/doc/stylesheets/taglibs.xsl
> ---
> > taglibs.xsl = ${basedir}/../src/doc/stylesheets/taglibs.xsl
>
Nice catch! I haven't tried 1.4 yet so I had no idea...
> Anyway, this "fix the build process" thread has been kicking
> around for ages.
> I hope this excellent system finally gets implemented.
>
> --Jeff
I hope so too! Should we move for a vote?
Tim
