On Sat, Dec 08, 2001 at 11:12:41AM -0500, Berin Loritsch wrote: > Peter Donald wrote: > > >On Sat, 8 Dec 2001 01:17, Berin Loritsch wrote: > > > >>I realized my last post should have had a new title so as not to be lost. > >>Please come up with issues for Avalon Framework--and we will decide if it > >>is a showstopper, a minor but allowable change (spelling/correction of > >>documentation), or something that will be placed on hold. > >> > >>The CVS should have 100% back compatible code. If this is not the case, > >>please alert me ASAP. > >> > > > >Oh - we still have a show stopper. The tools code is still included in > >source distributions. We need to fix this prior to release. > > > I have the fix in CVS now (hopefully).
Not including tools/ is going to cause lots of problems for users of the source distribution: 1) Half the targets in the src distro won't work. Targets like 'dist' and 'docs' *require* jars from tools/lib 2) We can't have this fancy Ant 1.5-specific stuff in build.xml, because we can't reasonably expect end users to have Ant 1.5. 3) Our build.xml must work with AND without the tools directory. This leads to a hack-filled build.xml. An example: tools/ext/logkit.jar is copied to lib/ in the src distro. But it still doesn't build, because elsewhere, lib/logkit*.jar is explicitly excluded.. 4) We now need two BUILDING files, containing two different sets of instructions. The CVS version says "type ./build.sh"; the src distro one says "download Ant 1.4 and type 'ant'". I think overall, this counts as a showstopper; we *at least* need a resolution to 3), because otherwise the src distro is plain broken. I have a Cunning Plan (tm) for how to solve most of these problems in a clean way... :) Fact: if we don't include tools/, we need to lose some of the functionality from build.xml. No way around it. Simple solution: maintain two build.xml files, one a cut-down version for the source distribution. But that's horrible, because we have to maintain near-identical two build files. So... How about we keep our one build.xml, and in it's 'src-dist' target, apply a stylesheet to build.xml *itself*, and remove all targets that would break without tools/. Ie, we have: <property name="build2srcbuild" value="${tools.dir}/stripbuild.xsl"/> .. <style style="${build2srcbuild}" in="build.xml" out="${src.dist.dir}/build.xml"/> Then in 'stripbuild.xsl', we strip targets like 'dist' and 'docs'. We can also convert from Ant 1.5 syntax to Ant 1.4. That's the basic idea. Now for a nice refinement... Instead of just removing those targets that rely on tools/, we can print a message saying "Please download the Avalon Tools distribution from ..., and extract to the 'tools' directory". We then have Avalon-tools-1.4.tar.gz somewhere for users to download. That way, if users want the extra targets, they can have them if they download the extra package. For example, our 'stripbuild.xsl' file would replace the 'docs' target with the following: <target name="tools_check"> <condition property="tools.present"> <available file="${tools.dir}" type="dir"/> </condition> </target> <target name="notools_msg" unless="tools.present"> <echo message="--------------------------------------------------------------"/> <echo message="This target requires extra jars in order to run. These may be "/> <echo message=" downloaded from ${tools.url}. Please extract these jars to "/> <echo message=" the ${tools.dir} directory, and re-run this target. "/> <echo message="--------------------------------------------------------------"/> </target> <target name="docs" depends="tools_check, notools_msg" if="tools.present"> ... (same contents as before) </target> So I think it's a pretty neat compromise :) - We only need to maintain one build.xml - The source distribution is small by default, and contains only the tasks that a casual user needs to build. - If the casual user wants to run a fancier target, they have a clear upgrade path. We could even automate it with a HTTP get task. What do people think? In particular, what do we do now? Three options: 1. Go with this proposed solution (needs writing an xsl, lots of testing) 2. Re-add the tools/ directory for this release 3. Work around the problem for now; fix the critical bugs, document that half the targets won't work, etc. I obviously prefer 1, and would help write it. If we choose 3, I can help with that too. --Jeff -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>