Return-Path: <jeff@socialchange.net.au>
Mailing-List: contact taglibs-user-help@jakarta.apache.org; run by ezmlm
Delivered-To: mailing list taglibs-user@jakarta.apache.org
Delivered-To: moderator for taglibs-user@jakarta.apache.org
Received: (qmail 76713 invoked from network); 6 Mar 2001 12:07:40 -0000
Received: from p214-tnt5.syd.ihug.com.au (HELO socialchange.net.au)
 (203.173.136.214)
  by h31.sny.collab.net with SMTP; 6 Mar 2001 12:07:40 -0000
Received: (qmail 1340 invoked by uid 500); 6 Mar 2001 12:06:05 -0000
Date: Tue, 6 Mar 2001 23:06:05 +1100
From: Jeff Turner <jeff@socialchange.net.au>
To: taglibs-dev@jakarta.apache.org, taglibs-user@jakarta.apache.org
Cc: Tim Dawson <tdawson@is.com>
Subject: Re: [PATCH] building too hard!
Message-ID: <20010306230605.A1065@socialchange.net.au>
References: <F483AD0DB13BD411A38300104B2E651E46F732@valkyrie.is.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.15i
In-Reply-To: <F483AD0DB13BD411A38300104B2E651E46F732@valkyrie.is.com>;
 from tdawson@is.com on Tue, Mar 06, 2001 at 03:00:26AM -0600
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

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:pierre.delisle@sun.com]
> Sent: Tuesday, February 27, 2001 6:32 PM
> To: taglibs-user@jakarta.apache.org; taglibs-dev@jakarta.apache.org;
> jeff@socialchange.net.au
> 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?

--