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
2) JAXP
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
else:
print dire warning
if sensible default (../jakarta-ant/lib/ant.jar) exists:
append it to user-specified classpath
else:
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
distros).
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 build.sh and build.bat files
> -- and use ANT directly!
No build scripts would be *very* cool :)
--Jeff
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> :)
also,
<insert grandiose visions of a unified jakarta build procedure here> ;)
> -- Tim
>
>
> -----Original Message-----
> From: Pierre Delisle [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 27, 2001 6:32 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> 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?
--
