> > 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).
Sounds like a good idea.
> 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.
No. But I can see if I might change that. I would have to go
personally, and the cost is a bit prohibitive :-(
> 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?
Stupidly because as xml-stylboook2 is an option on jakarta-ant, it
gets 'executed' before stylebook, so the cvs from xml-stylebook is not
there yet. On xml-xalan2, xml-xalan1 gets executed first, so there
are no problems there. Couldn' think of another way around at the
moment, so that is what I ended up with...
> 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.
You're tempting me ;-) Seriously, the only reason I used Python is
because I personally hate writing the bat/sh scripts, and as I
actively develop on both Windoze and Linux, having one script is very
nice. So dropping the dependency is not a big deal, just not my
preference, escpecially since you have the dependency on Perl for the
naglist, which I think I can remove with Ant ;-)
> > 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. :-(
In the newest version, Saxon has already moved to the XSLT 1.1
proposed syntax of <xsl:output/>, so it will be standard, and they are
also talking about the ability for variable-based XPath expressions,
which is the other extension I use. I am under the assumption that
Saxon is compatible with the ASF?
>
> So far, I've done this by repeated invocations of the xslt
translator.
>
Yeah, just thought that kinda blew ;-)
> > The system uses fails to test for succesful building of
> > dependencies, and ALMOST works.
I meant that the system uses FILES...
> >
> > 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.
>
We could just prefix all my files with ant- or something like that,
and see where we end up. BTW, the intention with the status stuff was
to have a short xml that could then transform to other formats (HTML,
just add a stylesheet PI for IE, add to a MySQL database for rolling
24-hour builds, etc)
>
> > 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.
But I think that if your workspace is going to contain paths that are
unique to you, certainly it can contain your nagging ;-) Seriously,
as long as it is kept out of the project defs themselves, I don't
really see a problem.
Thanks for giving it a once over Sam. I can clean it up, separate it
out from Gump, and have it use Gump's project defs if that will help
you with the checkin, just let me know what I can do to help.
Scott Sanders
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
