tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Delisle <>
Subject Re: [PATCH] building too hard!
Date Wed, 07 Mar 2001 17:44:38 GMT
Jeff Turner wrote:

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

I see your point that some developers might be annoyed with having to set
these env variables. However I bet the majority of them would
eventually set these environment variables just to get rid of the
*even direr warning* that would show up everytime they build :-)

> 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 and build.bat files
> > -- and use ANT directly!
> No build scripts would be *very* cool :)


And from the latest posting from Tim, it looks like this is doable.

Tim Dawson wrote:
> 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.

This would be awesome. I'll be happy to review (as many others I'm sure).
Please post to the list.

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

We could coordinate this as follows:
    - Agree on a new build standard (following discussions on build.xml
      to be submitted by Tim)
    - Assign a coordinator for the new build procedure
      (if Tim is interested, we could vote him as a committer. If no one
       else volunteers, I could do it)
    - have each taglib owner update their build.xml locally
      (coordinator and other committers could pickup the ones that won't 
       be done by their owners)
    - have all build.xml sent to the coordinator by a specific date
    - coordinator tests the full build procedure and makes required changes
    - coordinator commits to the tree.

[Or if coordinator does not mind, he could handle all modifications to the
taglibs himself]

Looking forward to the new build.xml!

    -- Pierre

View raw message