From: "David Crossley" <[EMAIL PROTECTED]>
> 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
JTidyTask
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/>
etc.
> 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 [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]
