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

Reply via email to