Scott Sanders wrote:
>
> The files attached should probably rest in antoher proposal
> for now, but I wanted to continue using Sam's project
> definitions. The only changes I made were very simple, such
> as adding a basedir attribute to the ant tag. When the file
> was something like build/build.xml, I changed it to have a
> basedir of build and a file of build.xml. Nothing too
> complicated.
The project definitions should probably reside in a separate CVS tree
entirely, with a wider range of committers (generally all release leads
from the various other projects, and perhaps some other volunteers).
The first order of business is to agree on a common DTD. Jeff has already
taken a stab at it, and I have made a few comments, but we really need to
focus on this as a group. Just curious, do you plan to go to ApacheCon?
I know Jeff will be there (he is presenting) and I will be too.
I haven't taken a look at your proposal in detail yet, but I will continue
to do so. My first question is: why did you add a cvs tag to
xml-stylebook2 but not xml-xalan2?
> The idea of my implementation is that you start the script via
> build.py, and then everything goes from there.
It looks like your dependency on python is minimal. My preference would be
to either make python the target (instead of Ant) or to limit the
"bootstrapping" scripts to the native ones available on the platform
(bat/sh).
Python would make a great target.
> The projects are merged, and then sorted, no different from Sam's,
> and then I create ant files for each and every project, and then
> run them in the dependency order. The files get from CVS, check
> dependencies, and then build. The XSL is a little wacked, but I
> think I have the major points in there. In the master ant file,
> I actually use the <java/> tag instead of the <ant/> tag, so that
> a build failure won't fail the whole system. I am also usig
> Saxon right now, as Saxon is my realm of knowledge, and I use a
> few tricks that I haven't boned up on in Xalan yet, like multiple
> output files...
Unfortunately, multiple output files is a non-standard extension. Xalan
has one too. :-(
So far, I've done this by repeated invocations of the xslt translator.
> The system uses fails to test for succesful building of
> dependencies, and ALMOST works.
>
> I got down to adding the dependent jars to the classpath, and that
> is where I am currently. The status html stuff needs a lot of work
> (it is barely started), but here it is.
>
> I would like to get this in CVS for all to work on, but I would
> like to see this in such a way so as to use Sam's project
> definitions, and eventually Alexandria's. There is no need to
> have another copy of those around ;-)
I'll look into checking it in incrementally, starting with the project
defitions. If it can peacefully co-exist, I'll check it in alongside of
gump, otherwise I'll recommend that you start another proposal.
> Also, I would like to add the nag stuff to the project definitions
> themselves, so the build can fire off an email based on the result.
> Any thoughts on that?
I've agonized over this. At the moment, my feeling is that the nag stuff
is not a property of the workspace definition. The workspace defines what
the files out on disk ARE, in term of how it takes to produce them. The
nagging is unrelated to this.
Another way to explain: I can imagine other people wanting to copy my
workspace definition, but I can't imagine (and don't want for that matter)
other people copying my nag list.
> I am happy to continue working on this, either here or personally.
> I will let you guys decide.
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
