> -----Original Message-----
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
<snip>
> > 2) Unified packaging requirements. Again, blocks will require some
> > consistency
> > in regards to packaging requirements. Things like the standard
> > MANIFEST.MF
> > tags, locations of configuration files, etc. We can create an ANT
> > task to do
> > all this, but then you also have to worry about getting people to
> > install and
> > use it.
>
> sorry, I don't get it. <copy> and <zip> can do everything we need. The
> block metadata files will have to be human edited anyway.
I was curious about this a few weeks ago so I did an experiment in
automating the build of a Fins (the charting package) block into Cocoon.
I'll include my build.xml for context. The experiment was mostly successful
(though I've never heard back from the Fins developers I sent it to), with a
couple of caveats. I'm sure Blocks: The Next Generation will be more
complicated than the current blocks but the techniques at the ANT level will
undoubtedly be similar.
Basically I automated as best I could the Fins install instructions at
http://www.sidimar.ipzs.it/fins011/docs/install.html. I used ANT to get and
unzip the JFreeChart jars that Fins requires. I used xpatch to modify the
block metadata files. I tried to use the patch task in ANT to modify
blocks.properties. There isn't a Java (i.e. portable) implementation of
patch available, though, so the ANT task depends on an executable.
There's one big question at the core of this, at least for the Fins example.
That is, is it allowable by JFreeChart's LGPL license to code an automated
build like this? I believe that it is, but I'm no licensing expert and I
recognize that there are differences in interpretation. (Context: Fins is
Apache/BSD and JFreeChart is LGPL; Fins provides the Cocoon interface to JFC
which is a standalone Java charting package)
Warning, if anyone attempts to make use of the enclosed build...
1) The patch of blocks.properties doesn't work
2) The xpatch of blocks-build.xsl is commented out because xpatch wasn't
treating my XPath expressions correctly (I believe) and wouldn't match my
target node (if anyone wants to help with this I'd be grateful!)
3) The build-dist doesn't work correctly--I can't seem to get the folders
zipped up in the correct locations (also could use help here)
4) You need the other files (xpatch files, etc.) for this to work (I didn't
want to include all the files without warning, though they are very small.
If anyone thinks they're worth posting I can do so.)
Comments on the propriety of this sort of build grabbing LGPL code?
Improvements on the mechanism? Any other projects that can benefit from this
until Blocks 2.0 are ready for prime time?
Jeff Ramsdale
<!--
build.xml
Description:
Build system for the Fins project. It downloads the jars for jfreechart
and jcommon via http and moves all Fins files into Cocoon. It also changes
Cocoon's block configuration files. In addition it can build a distribution
file (.zip or .tar.gz).
Usage:
ant [target] (from the root directory of the fins download)
External Targets: (to be called by user)
build-block - Compile Fins and install the block into Cocoon
build-dist - Build a distribution file (.zip or .tar.gz, depending on OS)
Internal Targets: (used by this build)
init - Initialize properties for other targets
get-chart-jars - Get jfreechart and jcommon .jar files via http
compile - Compile Fins code using jfreechart, jcommon, and Cocoon jars
History:
18/02/03 Luca Morandini Original coding
15/07/03 Luca Morandini Added the building of a block directory, ready for
deploying with Cocoon 2.1
20/09/03 Jeff Ramsdale Refactor to automagically build block into Cocoon
-->
<project name="Fins"
default="build-block"
basedir=".">
<!--
The "init" target initializes the properties used by the other targets
in this build file. In addition the "xpatch" Ant task is defined (from
Cocoon) so that the block descriptors in Cocoon can be automatically
updated.
-->
<target name="init">
<!-- PROPERTIES THAT MAY REQUIRE MANUAL CHANGES FOLLOW -->
<!-- Set Cocoon root directory -->
<property name="cocoon.dir"
value="C:/eclipse2.1/workspace/cocoon-2.1" />
<!-- Set Library Version Properties -->
<property name="jfreechart.version"
value="jfreechart-0.9.11" />
<property name="jcommon.version"
value="jcommon-0.8.6" />
<property name="cocoon.version"
value="cocoon-2.1.1-dev"/>
<!-- END COMMONLY CHANGED PROPERTIES -->
<!-- Project properties -->
<property name="name"
value="fins"/>
<property name="version"
value="0.1.1"/>
<property name="package.dir"
value="it/ipzs/charts"/>
<!-- Directory locations -->
<property name="src.dir"
value="."/>
<property name="build.dir"
value="./build"/>
<property name="zip.dir"
value="."/>
<!-- TODO test OS for .zip or .tar.gz extension -->
<property name="file.extension" value=".zip" />
<!-- Add XPatch taskdef -->
<taskdef name="xpatch" classname="XConfToolTask" classpath="${cocoon.dir}/tools/anttasks"/>
</target>
<!--
The "get-chart-jars" target grabs the jfreechart and jcommon .zip files
via http and the all-important .jar file for each is extracted. These
are then available for compiling Fins and can be installed in Cocoon by
the "build-block" target.
-->
<target name="get-chart-jars" depends="init">
<!-- Have to have a dir for the files to go -->
<mkdir dir="${build.dir}/fins/lib" />
<!-- Get jfreechart -->
<get src="http://www.jfree.org/jfreechart/${jfreechart.version}${file.extension}";
dest="${build.dir}/${jfreechart.version}${file.extension}"
verbose="true" usetimestamp="true"/>
<!-- unzip doesn't support the flatten mapper, which I'd like to use here
to get the .jar out without its parent directory -->
<unzip src="${build.dir}/${jfreechart.version}${file.extension}"
dest="${build.dir}" overwrite="false" >
<patternset>
<include name="**/${jfreechart.version}.jar"/>
</patternset>
</unzip>
<copy todir="${build.dir}/fins/lib"
file="${build.dir}/${jfreechart.version}/${jfreechart.version}.jar" />
<!-- Get jcommon -->
<get src="http://www.jfree.org/jcommon/${jcommon.version}${file.extension}";
dest="${build.dir}/${jcommon.version}${file.extension}"
verbose="true" usetimestamp="true"/>
<!-- unzip doesn't support the flatten mapper, which I'd like to use here
to get the .jar out without its parent directory -->
<unzip src="${build.dir}/${jcommon.version}${file.extension}"
dest="${build.dir}" overwrite="false" >
<patternset>
<include name="**/${jcommon.version}.jar"/>
</patternset>
</unzip>
<copy todir="${build.dir}/fins/lib"
file="${build.dir}/${jcommon.version}/${jcommon.version}.jar" />
</target>
<!--
The "compile" target compiles the Fins classes against the jfreechart
and jcommon jars as well as a selection of jars shipped with Cocoon.
-->
<target name="compile"
depends="init,get-chart-jars,prep-build">
<mkdir dir="${build.dir}/classes" />
<path id="classpath">
<fileset dir="${cocoon.dir}/build/${cocoon.version}">
<include name="cocoon.jar"/>
</fileset>
<fileset dir="${cocoon.dir}/lib/core">
<include name="avalon-framework-4.1.4.jar"/>
<include name="excalibur-component-1.1.jar"/>
<include name="excalibur-logger-1.0.1.jar"/>
<include name="excalibur-pool-1.2.jar"/>
<include name="excalibur-sourceresolve-20030715.jar"/>
<include name="excalibur-xmlutil-20030520.jar"/>
<include name="logkit-1.2.jar"/>
</fileset>
<fileset dir="${build.dir}">
<include name="${jfreechart.version}/${jfreechart.version}.jar"/>
<include name="${jcommon.version}/${jcommon.version}.jar"/>
</fileset>
<fileset dir="${cocoon.dir}/src/blocks/batik/lib">
<include name="batik-all-1.5.jar"/>
</fileset>
<fileset dir="${cocoon.dir}/lib/endorsed">
<include name="xalan-2.5.1.jar"/>
<include name="xercesImpl-2.4.0.jar"/>
<include name="xml-apis.jar"/>
</fileset>
</path>
<javac srcdir="${build.dir}"
destdir="${build.dir}/classes"
deprecation="true">
<classpath refid="classpath"/>
</javac>
</target>
<!--
The "prep-build" target copies all the Fins files to the build directory
to prepare the file set for building the distribution or the block.
-->
<target name="prep-build"
depends="init" >
<copy todir="${build.dir}/fins" >
<fileset dir=".">
<exclude name="**/${name}-${version}.zip" />
<exclude name="build/**" />
</fileset>
</copy>
</target>
<!--
The "build-dist" target zips up all the base Fins files into a
distribution file.
-->
<target name="build-dist"
depends="init,prep-build" >
<!-- Makes the distribution zipfile -->
<zip destfile="${zip.dir}/${name}-${version}.zip" >
<zipfileset dir="${build.dir}/fins" prefix="fins/test/test/test">
<include name="**" />
<exclude name="lib/**" />
</zipfileset>
</zip>
</target>
<!--
The "build-block" target copies all necessary Fins files to Cocoon
and modifies the Cocoon configuration files that need to know about
the new Fins block. After running this target the user will need to
rebuild Cocoon for the new block to be available. It should be noted
by the user that Cocoon must already have been built in order for
this build to work. This is due to the need to compile against the
cocoon.jar. (TODO: Can this be changed so they can build against a
fresh Cocoon CVS checkout?)
-->
<target name="build-block" depends="init,get-chart-jars,prep-build">
<copy todir="${cocoon.dir}/src/blocks/fins">
<fileset dir="${build.dir}/fins">
<exclude name="*.*" />
</fileset>
</copy>
<!-- Copy Batik .jar to Fins block -->
<copy todir="${cocoon.dir}/src/blocks/fins/lib"
file="${cocoon.dir}/src/blocks/batik/lib/batik-all-1.5.jar" />
<!-- Patch Cocoon configuration files -->
<xpatch file="${cocoon.dir}/lib/jars.xml"
srcdir="."
includes="*-xpatch-jars.xml" />
<xpatch file="${cocoon.dir}/gump.xml"
srcdir="."
includes="xpatch-gump.xml" />
<!-- Gives an error... XPATH may not handle namespaces well?
<xpatch file="${cocoon.dir}/tools/src/blocks-build.xsl"
srcdir="."
includes="xpatch-blocks-build.xml" />
-->
<!-- Looks like patch task may require a separate install of patch.exe?! -->
<patch patchfile="blocks.properties.diff"
originalfile="${cocoon.dir}/blocks.properties" />
</target>
</project>
