tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [PATCH] building too hard!
Date Tue, 06 Mar 2001 12:06:05 GMT
On Tue, Mar 06, 2001 at 03:00:26AM -0600, Tim Dawson wrote:
> I agree 100% -- #3 is a GREAT approach.  Relying on the classpath is quite
> dangerous, and the defaults specified are probably very infrequently used.

Well.. please don't get me wrong, I hate classpaths as much as the next
battle-scarred programmer, but I suspect that *forcing* people to set env
variables would annoy some.

For instance, jakarta-taglib's external dependencies are:

1) Ant
3) JAXP-compliant parser (xerces)
4) Xalan (for the <style> elements).

I would tentatively suggest that many developers have 1, 2 and 3 permanently
set in a global classpath, because Ant and JAXP (and hence Xerces) are validly
"cross-project" jars. Having to set 3 extra env variables is just going to
annoy these people. It only takes one -1 vote to kill a proposal ;)

How about using the preset CLASSPATH as a fallback, to be relied on only after
printing a dire warning? Eg, one could have the following system (taking Ant as
an example):

if $ANT_JAR set && `$ANT_JAR` exists:
	use it
elseif $ANT_HOME set && `$ANT_HOME/lib/ant.jar` exists:
	 use $ANT_HOME/lib/ant.jar
	print dire warning
	if sensible default (../jakarta-ant/lib/ant.jar) exists:
		append it to user-specified classpath
		print even direr warning
		use user-specified classpath and hope they included ant.jar

This makes clear to the user that setting an env variable is preferable, but
doesn't *force* them to. In truth, this involves just 3 additions to the
current system:

1) Introduces a new variable, $<package>_JAR (eg $ANT_JAR). Why bother? Because
   notice that how we get from the more general $<project>_HOME to the jar is
   hardcoded ("/lib/"), and therefore possibly wrong (eg, between source and binary

2) Prints a warning each time an expectation is violated.

3) Checks whether jars exist before using them (using "exists" keyword for
   .bat, and "-e" test in .sh)

Does this seem sensible?

Anyway, I'll modify build.(sh|bat) again to reflect the above scheme, and post
here so people can review the real thing.

> We should also probably movfe to ANT 1.3 now that it is released, so that we
> can make use of its ability to get environment variables directly out of the
> environment, and then we can do away with the and build.bat files
> -- and use ANT directly!

No build scripts would be *very* cool :)


PS: Btw, Pierre, I replied with great enthusiasm to your original reply, but mail
server problems prevented it (and a repost) getting to the list :/ So..

<insert enthusiasm and intense agreement here> :)


<insert grandiose visions of a unified jakarta build procedure here> ;)

> -- Tim
> -----Original Message-----
> From: Pierre Delisle []
> Sent: Tuesday, February 27, 2001 6:32 PM
> To:;;
> Subject: Re: [PATCH] building too hard!
> Jeff,
> Totally agree with you regarding the complexity of the build process
> of jakarta-taglibs. Thanks for documenting what you went through
> to make the community aware of the current flaws.
> Here is my .02 on how I believe we could fix the issues
> you raised in a clean and consistent way. 
> Comments please...
>     -- Pierre
> ----
> I think that the major issue in the current build process
> is that we have three different types of assumptions regarding
> how 'required' jar files are accessed so that the build
> process can be successfull:
> 1) Library already in the developer's classpath 
>    This is the current assumption for a JAXP compliant parser.
> 2) Environment variable can *optionally* be set to access the 
>    jar file. If it is not set, a default value is used which assumes
>    that the 'taglibs' build directory structure includes this 
>    other apache project.
>    This is the current assumption for:
>          ANT_HOME        ../jakarta-ant
>          BSF_JAR         ../xml-xalan/bsf.jar
>          BSFENGINES_JAR  ../xml-xalan/bsfengines.jar
>          SERVLET_JAR     ../jakarta-servletapi/lib/servlet.jar
>          XALAN_JAR       ../xml-xalan/xalan.jar
>          XERCES_JAR      ./.xml-xalan/xerces.jar
> 3) Environment variable *must* be set to access the library.
>    This is the case for JAVA_HOME to get access to tools.jar.
>    Please note that execution of ant is done using 'java' (and
>    not $JAVA_HOME/bin/java).
> To make it much easier for "off the shelf" builds to succeed
> for everyone (whithout event having to read the README), 
> I would personally like to see us enforce access
> to 'core' jar files with 3).
> I.e. environment variables must be set to access the 'core' jar files.
> [No assumptions on the developer's classpath (*not* 1), as well as
> no assumptions on a build directory structure (*not 2)].
> If the env variable associated with a required jar file is not
> specified, then the build stops with an explicit error message
> telling the user how to get access to the 'missing' project.
> For example:
>    ERROR: You must set ANT_HOME to point at your 'ant' installation
> directory.
>    The library $ANT_HOME/dist/ant.jar will be added to the classpath
>    of the build process. You may download a binary distribution of
>    'ant' at the following url: ..."
> With respect to 'non-core' jar files, i.e. jar files that are only required
> for specific taglibs, I'd suggest a warning message telling the developer
> that specific taglibraries won't be built because the specific environment
> variable is not set. For example:
>    WARNING: Tag libraries 'x', 'y', and 'z' require access to the 
>    'REGEXP' installation directory. Since environment variable 
>    'REGEXP_HOME' is not specified, these tag-libararies will not
>    be built. You may download a binary distribution of
>    'regexp' at the following url: ..."
> This would allow us to have a clean "self-documented" build process.
> Comments?


View raw message