jakarta-taglibs-dev 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 Wed, 07 Mar 2001 15:27:28 GMT
> 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. 

I would disagree... people that use ANT should be specifying those items in
their ANT build.xml files so that they can run.

> Having to set 3 extra env variables is just going to
> annoy these people. It only takes one -1 vote to kill a proposal ;)

fair enough. people shouldn't be forced to do that any more than I should be
forced to set a classpath. :-)

> 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).

sure, but we should do this INSIDE ant, making use of ANT 1.3's ability to
see environment variables, rather than having any batch or shell scripts do
the work.  we could do this first by using the available task.

> > 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 :)

glad you agree! I'd be happy to do the revisions to the build.xml files, but
I'll have to mail it to someone with checkin capability. I'd probably update
one and send it out to see if people agreed with the direction.

how hard would it be on the community to do the upgrade?  everybody would
have to upgrade or they woudln't be able to build.  

> How about using the preset CLASSPATH as a fallback, to be 
> relied on only after printing a dire warning?

again, if we drop the .bat and .sh files and just do this in ANT, we can use
the <available> task.

    <classpath>
      <pathelement path="${classpath}"/>
      <pathelement location="${log4j.jar}"/>
    </classpath>
    <available property="log4j.available"
               classname="org.apache.log4j.Category" />

inside the init target, and have a checkDependencies target which depends on
checkLog4j as well as others.

  <target name="checkLog4j" unless="log4j.available">
    <fail message="log4j was not found. please ensure that the log4j.jar is
available in your CLASSPATH, or set a LOG4J_JAR environment variable. see
http://jakarta.apache.org/log4j to download log4j if necessary." />
  </target>

If we really wanted to allow defaults such as ..\jakarta-log4j\log4j.jar, we
could update the checkLog4j target to echo a message then add the default to
the classpath.

Would this work?

Tim

Mime
View raw message