tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Dawson <tdaw...@is.com>
Subject RE: [PATCH] building too hard!
Date Tue, 06 Mar 2001 09:00:26 GMT
I agree 100% -- #3 is a GREAT approach.  Relying on the classpath is quite
dangerous, and the defaults specified are probably very infrequently used.

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!

-- 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?

Mime
View raw message