From: "David Crossley" <[EMAIL PROTECTED]>
[...]
> 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
I'm going to submit a last patch to make the final arrangement.
Here is the structure for the 2.0.1 release, where only new build targets
and init were moved out of top level dir:
build.xml (main build)
- used in build.xml as SYSTEM entities
tools/build/init.xpart (init target)
tools/build/interactive.xpart (interactive target)
tools/build/scratchpad.xpart (scratchpad target)
- used in build.xml as child targets
tools/build/try.xml (new targets to try)
The new targets are now:
build interactive
build scratchpad
build try -Dtry.task=[task to try]
Currently, I left the "all" target as the default one for consistent
behaviour, but to make things easier for users, I propose that we make the
"interactive" target the default one.
It would be cool if scratchpad users start using the scratchpad build to
"publicize" their work with the community.
As for the split of the build TBD after release, I propose that build.xml
contains parts only as external entities.
Current build.xml could be split again as follows:
tools/build/compile.xpart (optional components related targets)
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/testcases.xpart (junit testcase targets)
tools/build/util.xpart (generic util and message printing targets)
it could be like this:
<!-- Initialization target (external reference to
tools/targets/init.xtarget )-->
&init-target;
<!-- Interactive target (external reference to
tools/targets/compile.xtarget )-->
&compile-target;
<!-- Scratchpad target (external reference to
tools/targets/optional.xtarget)-->
&optional-target;
...etc...
Also, why not move announcement.xml under xdocs? There's already the README
file that contains basically the same info.
database.properties could be moved under src/resources or under
tools/resources.
todo.xml and changes.xml seem to be there just for convenience; we could
move them under xdocs or unify them in a single xml called status.xml.
Thoughts?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
