cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject structure and split the build (Was: [PATCH] new build targets)
Date Fri, 25 Jan 2002 03:12:07 GMT
Nicola Ken Barozzi wrote:
> > David Crossley wrote:
> > > You were also adding a copy of the "init" target from
> > > build.xml into build-i.xml and build-s.xml ... why?
> > > This seems like a maintenance nightmare for the release
> > > manager, as he would need to update release info in 3 places.
> 
> This is also related to what IMHO is another "problem"; the size
> of the build.

I agree, the build.xml is huge and the top-level xml-cocoon2/
directory is also becoming cluttered.

> To correct my hack of duplicating properties in builds for not
> requring dependency, I have succesfully put the init target in
> another file and have all builds reference it as an external
> system entity.
> 
> <?xml version="1.0"?>
> <!DOCTYPE project [
> <!ENTITY init-target SYSTEM "init.xpart">
> ]>
> 
> and
> 
>   &init-target;  <!-- external reference to init.xpart -->

I like this approach, which utilises the power of XML.

> Before submitting any further patch, I would propose to
> split the build as follows:
> 
> build.xml (main build entry; contains following targets
>             as SYSTEM entities and compilation+jar-war generation)
> /tools/build/init.xpart (init target)
> /tools/build/optional.xpart (optional components related targets)
> /tools/build/xml2java.xpart (xml2java generation related targets)
> /tools/build/docs.xpart (documentation+javadoc generation targets)
> /tools/build/dev.xpart (dists+patchqueue+fixsrclf targets)
> /tools/build/interactive.xpart (interactive target)
> /tools/build/scratchpad.xpart (scratchpad target)
> /tools/build/try.xpart (new targets to try)
> 
> For scratchpads, I propose that each scratchpad subdir
> represents a scratchpad project, as schecoon does.
> Each sub-dir should have its own independent build.xml
> that can be run as a try target (see current build.xml as an
> example) and, when ready, included in interactive scratchpad
> builds for all to test.

Well i like this arrangement. However, with the 2.0.1 release
just around the corner, perhaps it should wait. On the other
hand, it would be better to clean up the top-level xml-cocoon2/
directory immediately, so that users do not get confused by
many build*.xml

--David Crossley

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message