cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <>
Subject Re: [PATCH] new build targets
Date Thu, 24 Jan 2002 09:12:44 GMT
From: "David Crossley" <>

> Hi Ken, today i added your next set of patches
> for the new targets "interactive" and "patchqueue*".
> - move stylesheets from tools/src/ to tools/resources/stylesheets/
> - replace ascii art with simple header

Thank you, I saw the commits :-)

> There were some things that i did not add because i was
> getting out of my depth. You were also renaming some
> classes in tools/src/ and corresponding changes in the
> main build.xml
> Please discuss that issue separately on the list first.

Yes. The "issue" is very simple.
I renamed the tasks in tools/src so that they all had a name ending in Task:
SitemapTool  ->  SitemapToolTask
XConfTool  -> XConfToolTask
UserInput   ->  UserInputTask
ClassAvailable   ->  ClassAvailableTask

The reason is that it got me confused seeing "Tool" and thought it wasn't a
task but a new ant feature, so I changed the name since I controlled that
there are no dependencies in the code other than build-*.xml and since a
cleaning of tools/src was in place.
I also changed the names used in the build to use xml-type convention
instead of the javaType one.
<ClassAvaliable/>   ->  <class-available/>

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

Yes, you're right. The problem is a chicken and egg one. :-!
If I make build.xml call build-i.xml I cannot use it, because the
interactive target must call targets from the original build (didn't work)
or call again ant on build.xml (ant doesn't allow it).
If I do the opposite, like now, the init variables must be in build-i.xml
also; if I keep them in build-i.xml, build.xml becomes dependant on it,
which is unwanted.
The two solutions are: incorporate build-[i&s].xml in build.xml or use
external references.
Personally I wouldn't mind using external references to "modularize" the
build, which is now monolithic.

> In the "interactive build" build-i.xml you had an option for
> "patchqueue". I removed that because we do not want to
> make it easy for users to run that build target.

The really dangerous target is patchqueue-notify, patchqueue just updates
local patchqueue.
Maybe it's just better to put patchqueue-xdocs?

> There is one final thing that needs to be done, but i did
> not understand what you mean. In Bugzilla you say
> something about moving build-*.xml into a new directory
> tools/builds/ and "corrected inter-references". I am not
> clear on what you want done here. Please explain.

I tried to move the other builds in a subdir of tools (to clean the root dir
which IMHO is a mess), but it complained it couldn't find classes, even if I
changed path in taskdev.
Let's leave it out 4 now.

> When that is done we can close the Bugzilla entry, as
> i think that your main functionality is in there now.
> Of course your documentation is still to come :-)

Since the docs build didn't work I didn't submit a file that I wasn't sure
was 100% ok.
Anyway, I will submit the new doc patch ASAP.

Nicola Ken Barozzi       
These are the days of miracle and wonder...
 don't cry baby, don't cry...
                                                  Paul Simon

To unsubscribe, e-mail:
For additional commands, email:

View raw message