> While handling classpaths for tasks such as checkstyle makes the build > file a bit more complex, it does make the build process itself easier > IMHO. Do we really want to force everyone who wants to build Cactus from > source maintain a Cactus-specific Ant installation?
As someone who's struggled with the cactus build, I side with Chris on this one. Cheers, nick > -----Original Message----- > From: Christopher Lenz [mailto:[EMAIL PROTECTED]] > Sent: Monday, December 16, 2002 6:59 AM > To: Cactus Developers List > Subject: Re: cvs commit: jakarta-cactus/documentation > build.properties.sample build.xml > > > Vincent Massol wrote: > >>Vincent Massol wrote: > >> > >>>Hi Chris, > >>> > >>>Not sure what is the benefit of putting stylebook.jar in the > >>>build.properties. It looks more complex than just putting it in > >>>anthome/lib. I guess you want to keep your anthome/lib clean? > >> > > (However > > > >>>stylebook does not interfere with anything else). However, I don't > >> > > mind! > > > >>>:-) > >> > >>Yeah, I know it doesn't really matter for Stylebook, I'm just trying > > > > to > > > >>move towards what I personally consider a better practice for Ant > > > > build > > > >>systems: not requiring the user to copy any libraries in > > > > $ANT_HOME/lib. > > > >>More important than Stylebook is Checkstyle. Since the version of > >>Checkstyle I need to build Cactus is so bleeding-edge and incompatible > >>with the previous released versions, I can't use the same > > > > checkstyle.jar > > > >>for builds of Cactus and build of my other projects. But because the > >>Cactus build requires checkstyle.jar on java.class.path, I sort of > > > > need > > > >>to keep 2 separate installations of Ant. > > > > > > Agreed. This is exactly what I have. Actually I have several installs of > > Ant (which isn't a problem for me): > > > > jakarta-ant-1.5.1 > > jakarta-ant-cactus-1.5 > > jakarta-ant-cactus-1.4 > > > > Then, in my project I have an ant.bat file with: > > > > @echo off > > > > set ANT_HOME=c:\apps\jakarta-ant-1.5-cactus > > set PATH=%ANT_HOME%\bin;%PATH% > > > > call %ANT_HOME%\bin\ant.bat %1 %2 %3 %4 %5 %6 %7 %8 %9 > > That's not exactly what I'd call the optimal solution :-P > [BTW, you could probably achieve the same by just setting up the > CLASSPATH in the script before invoking Ant] > > While handling classpaths for tasks such as checkstyle makes the build > file a bit more complex, it does make the build process itself easier > IMHO. Do we really want to force everyone who wants to build Cactus from > source maintain a Cactus-specific Ant installation? > > In my "private" projects I tend to have a 'lib' directory at the root > level. The build file has default locations for all the required jars, > which are simply ./lib/<name-of-jar-in-distro>. To get the build going, > you just need to drop all the required jars in the lib directory and > type "ant". Obviously, some JARs still need to be installed in > $ANT_HOME/lib. Xalan is an example, Clover also doesn't work when placed > elsewhere. > > >>>Anyway, there is still a problem I think with the current > >> > > implementation > > > >>>of stylebook.jar in the build.xmls. The stylebook jar that is > >> > > specified > > > >>>in the global build.properties will *not* get passed to the > >>>documentation subproject build. This is slightly complex to do as it > >>>must be passed only if stylebook.jar is defined. > >> > >>Hmm, not sure I understand. Why doesn't it get passed? > > > > > > <ant target="dist" antfile="documentation/build.xml" > > inheritAll="false"> > > > > <property file="build.properties" /> > > <property file="${user.home}/build.properties" /> > > </ant> > > > > inheritAll is false (voluntarily). > > But the properties get passed by the nested <property file="..."> > element, not? > > -chris > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
