With the new ability of the X!ConfPatch Task to take parameters from Ant's build.properties, we have developed handy new ways to structure projects that we are developing with Cocoon. I will outline our approach here.



Project Structure

Our Project Folders look something like this:

The Build Process

We have several Ant Targets:

While a developer is working on the Java Classes of a project, the typical Ant Target they will use is test. When their tests are passed, the developer will restart Cocoon and can immediately access the Project in their Browser.

While a developer is working on XML, XSLT, CSS, FlowScript etc. They do not need to use any build targets, because Cocoon is serving the Project live out of the Project's webapp folder.

When a developer wishes to update from CVS their copy of Cocoon, once Cocoon is re-built, they only need to invoke the install target, to ready Cocoon for this Project again.

The Projects build.xml

The init target

{{{<target name="init">

</target> }}} This target loads up the Ant Properties for the project and defines the xpatch task as using XConfToolTask.

The install target

{{{<target name="install" depends="compile, customise-webapp">

</target> }}} This target copies over any .jars in our /lib/ folder, plus our Hibernate files

The customise target

{{{<target name="customise" depends="init">

</target> }}} This target applies all of our X!ConfPatch files which prepare Cocoon for serving our Project.

The test target

{{{<target name="test" depends="install">

</target> }}} This target runs any jUnit tests we may have in our Project's Class Hierarchy.

The compile target

{{{<target name="compile" depends="init">

</target> }}} This target compiles our Project's Java Classes directly into Cocoon's WEB-INF/classes.

I will leave the other targets as an exercise for the reader ....

The Patch files.

Patching the !SiteMap mount-point

file: project.xmap {{{<xmap xpath="/sitemap/pipelines/pipeline"

<!-- Mount the Project -->

</xmap> }}}

Depending on your Project's needs, you may also need patches to add input-modules, datasources, components, etc. to Cocoon's cocoon.xconf, and maybe add a databse driver to Cocoon's web.xml.

See the patch files that come with Cocoon for further examples. (Each block has a set).

Build Properties

Finally we have the Project's build.properties file. This provides all of the Properties referenced above, that are able to be localised for each developer's needs (because everyone keeps things in different places).

Here is a subset of ours:

{{{# NOTE: don't modify this file directly but copy the properties you need # to modify over to a file named 'local.build.properties' and modify that.

# WEBAPP - the webapp you are testing in # get the directory of Cocoon from a command-line parameter, supplied by build.sh cocoon=${env.COCOON_HOME} # the location of the running webapp within the Cocoon directory cocoon.webapp=build/webapp # put them together cocoon.webapp.home=${cocoon}/${cocoon.webapp}

# BUILD # where to find Cocoon's Ant XPatch Task tools.tasks.dest=${cocoon}/tools/anttasks

# PROJECT - properties specific to this webapp # this project's folder within the webapp project.mount=my-project-name # source directory src.dir=src # this project's patch files to modify the webapp customconf=${src.dir}/confpatch }}}

How could this be better?

Well, we are pretty happy with the adaptability of the scheme so far, but one of the issues we are thinking about is how to use this with IDEs that can use Ant, like Eclipse, NetBeans IDEA etc.

I believe one of the issues we need to deal with is to find a way to make the build.xml file work when it is called directly from Ant, rather than by invoking build.sh. We need to find the right way to setup the java.endorsed.dirs parameter..

What do you think?

2003-11-22 Updated JeremyQuinn: Now using Ant's built-in ability to retrieve Environment Variables, thanks to a suggestion by Upayavira.

ProjectBuilding (last edited 2009-09-20 23:41:57 by localhost)