On Tue, 20 Mar 2001, Incze Lajos wrote:
> > If we impose on the developer only that he has the right "ant" or
> > "ant.bat" script available in his or her PATH, do we care anything about
> > Ant's internal organization? It seems to me that the Ant environment
> > should take care of finding its own pieces.
> >
> > Craig
> >
>
> Everything used to work seemlessly until somebody comes up
> with some dependent ant tasks and supposes a "normal" ant
> dist environment. This can be avoided but there is a pretty
> strong coherence in the apache group and sometimes these
> dependencies remain in the scripts. E.g. the current build
> script contains the servlet.jar at it's usual jakarta project
> place and if you don't have this jar at that place, the build
> will fail (as the target compile.library does not include
> the system classpath. (I routinely issued - almost every day -
> an 'ant clean; ant dist' command with my preset classpath, and
> experianced that the clean build fail. Ok, I could override
> the servlet.jar with ant -D) Build.sh contains the usual _HOME
> dirs and places things at their usual relative places.
>
> So, I wholehartedly support the bare ant command, just wanted
> to raise the exclam mark that in general these properties can't
> suppose the "normal" HOME dir layout. Users can gather their
> common parsers, jars etc. (I used to fail - now have 15 xalan.jars
> 23 xerces.jars, 17 parser.jars, etc.) We should have classpath
> properties independent form .home properties, etc. incze
>
It seems to me this is what "build.properties" will take care of for
you. For example, a "build.properties" for Struts would include my local
definitions for "catalina.home", "servlet.jar", "tomcat.home", and
"xerces.home". If my directory structure happens to match the default
value for or more of these, I could omit them (or, more likely leave my
own copy in place, in case the default changed later).
The only restriction would be where the Struts build.xml looked for
build.properties. My proposal would be that it should be in the same
directory that build.xml is (but, as mentioned earlier, *not* checked in
to CVS). That way, you can have different sets of build properties for
your different projects without having to continually modify environment
variables.
Essentially, "build.properties" replaces having to set all the environment
variables required by the current "build.sh" and "build.bat" scripts, but
gives you the same flexibility to use whichever components *you* want to,
without impacting which ones *I* am using (and vice versa). Am I missing
something?
Craig
