See intermixed.
Jon Stevens wrote:
> Hi All,
>
> I spent a few hours last night mucking with the build process and found out
> that the main problem primarily stems from the fact that the Ant build
> scripts are not written to take advantage of Ant 1.2's new features with
> regards to setting up the classpath.
>
Yep -- the basic scripts were constructed before Ant 1.1 was released. Now that
we've got 1.2, it's time to take advantage of the new capabilities.
>
> The issue is that it currently isn't trivial to setup a system within Tomcat
> that uses relative paths to find the correct .jar files because Tomcat needs
> to have the ability to be built on a per-product level (there are several
> products within Tomcat...ie: Catalina, Jasper and Webapps) as well as on a
> global level from the top level build file which simply makes calls to the
> lower level build files. In other words, you don't ever know if you are
> going to be relative one directory down or if you are going to be relative
> two directories down.
>
> I spent a ton of time last night rewriting the build.sh script to attempt to
> deal with this more cleanly only to find out that it really isn't possible
> to do it easily that way. UG!
>
Told ya it wasn't that easy :-).
>
> So, what I propose is to replace the use of environment variables with the
> use of properties files that define the path to the .jar files. Therefore,
> you will have a system that first tries to look for relative paths to the
> jar files in property files sitting in your home directory and then if those
> files don't exist, attempt to use the default ones in Tomcat.
>
> ie:
>
> First look for absolute paths to the jar files in these files:
> ${HOME}/.ant.catalina.properties
> ${HOME}/.ant.jasper.properties
> ${HOME}/.ant.webapps.properties
>
Just as something to keep in mind, we need this to work on Windows platforms as
well.
>
> If the above files do not exist, then attempt to look for relative paths
> (ie: ../../jakarta-servletapi) to the .jar files here:
>
> /jakarta-ant
> /jakarta-servletapi
> /jsse*
> /jmx*
> /jakarta-tomcat-4.0/catalina/.ant.catalina.properties
> /jakarta-tomcat-4.0/jasper/.ant.jasper.properties
> /jakarta-tomcat-4.0/webapps/.ant.webapps.properties
>
Shouldn't these also have ${HOME} or something like that before them? Not
everyone is going to have access to the root directory on their Unix boxes.
>
> Ant will then dynamically build up the classpath and compile things using
> that methodology instead of passing environment variables around.
>
> By doing things this way, it will make it transparent for people who setup
> their directory structure in a defined way and if they want to use their own
> directory structure, then they can simply define their own .properties files
> giving the same level of control that is currently in the build system.
>
> I wouldn't be adverse to putting it into a a single .properties file either.
> I'm just doing it this way in the example for clarity.
>
It might be easier to have a single ".ant.tomcat.properties" -- I'm not sure
there are many circumstances where you'd be using different sets of packages for
these things. With three files, you'd have a lot of duplication.
>
> Lastly, the idea of putting the .jar files into CVS is a major favorite of
> mine. Especially given that Sun stupidly thinks that it can't export the
> JMX.jar files to Berkeley, CA (where I live),
Thank your local area power companies for bouncing power to servers up and down
a *lot* over the last few days, and breaking the verifier mechanism.
> but the issue with that is
> that the .jar files that Tomcat depends on are under license agreements from
> Sun to not be distributed. Therefore, we can't put them into CVS legally.
> Maybe one day the execs at Sun will wake up and get a clue and realize that
> they should just make these things easily downloadable because they are
> hurting their customer base instead of helping and override whatever the
> silly legal department of Sun thinks.
>
> thanks,
>
> -jon
Craig
