> -----Original Message-----
> From: Scott Sanders [mailto:[EMAIL PROTECTED]]
> > mm...I didn't pay attention to the change that were done in
> this xsl.
>
> I use merge.xsl and sortdep.xsl from the real Gump, so I watch Sam's
> commits pretty closely.
Did not interfer so far, I think I have used the latest from CVS this
morning.
However since we are at it maybe we could also switch to xalan with the
redirect extension. I saw that when antgump was released that Sam was
teasing you about using Saxon instead of Xalan :-)
Since we are supposed to eat our own food, we just have to change the
stylesheet element to:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0"
xmlns:lxslt="http://xml.apache.org/xslt"
xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect"
extension-element-prefixes="redirect">
and use redirect as follows:
<redirect:write file="{$output.dir}/myfile.html">
...the xsl stuff redirected ...
</redirect:write>
As you can see, it is very similar to saxon, no big deal here, but not that
much documented in xalan doc unfortunately :-(
> > This is not the case right now since the ant call via specify
> > failonerror="no", thus whatever happens, you will have a 'success'.
>
> The failonerror=no is in the master build script, as I want
> to continue
> attempting to build other stuff. But the project-specific
> build should
> not be affected by this, correct? If it is, I might need to
> change to a
> <java> that calls ant, and not use <ant> itslef.
Misunderstanding here. In antgump-all, this is ok, there is a forked call to
ant via <java> which is needed. In antgump-each.xsl, there is a java call to
ant, here it should be a failonerror=yes (or a <ant> call) since we want to
crash this build layer when it fails, otherwise whatever happens the
'success' replace will always be performed on the html.
> I'll look into that ;-0 Just remember that I wrote most of AntGump
> under many doses of coffee in the early am, and only changed what was
> needed to actually see some output. I am positive that many
> things need to change because of this. But hey, that is the XP way,
right?
Absolutely. There is no need to apologize about errors, I perfectly
understand.
You can only be blamed for being the first one to do it using Ant :-)
I was doing the same kind of work here at a more harcoded level since I was
expecting to plug GUMP from above, I was trying to find the kind of build I
needed to generate and how to get the information from all builds but I was
going to a different direction. Every project I was building was logged to a
xml file using -listener (this is also what I would like to change in ant
gump instead of using txt log) and I was using a
document($buildfile)/build/@error to check for error, build time and so
on...
Unfortunately it only works if the file is available since xsl processors
are free to do what they want when document() fails to load the document,
and I did not have time to create an additional ant file that was
prechecking and postchecking, so let me know what you think about this.
Maybe we could drop the file status once this is stable and use the log of
each 'gump build' for determining success/failure, the log xml should give
us the benefit of additional information immediately available for
processing.
Personnally I'm somewhat in need of this approach since I need to post
process lots of information and I will need to generate many different
'builds' for different goals:
1) output from build (build failed ? / time taken to build )
2) output from unit tests (build failed ? build results summary from the xml
(junitreport task), + report generation to framed html)
3) output from unit test coverage (failed ? coverage results (like average
coverage / JProbe Coverage task + report generation to html)
4) output from source code audit (failed ? source code errors on project ?
Metamata Audit task + report generation to framed html)
5) output from source code metrics (failed ? project metrics ? TBD)
JProbe Coverage does not yet have the report in XML, but it should be no big
deal since I should be able to convert it to XHTML without problems and
getting the necessary info. As of now, the only output is in HTML so I can
not fully manage this information.
Metamata Audit generates XML from its task, so it's OK, I can get a quick
summary from it and generate a fully framed HTML report for all classes.
Metamata Metrics is on the way, but as Metamata was acquired by Webgain and
that they are releasing their quality analyzer as a single product (audit,
metrics, cover) I will see how to integrate all this since we will probably
buy a copy of it once it is released.
I personally do not have much time for all this, but I have a trainee that
is working on all this build environment for 2 weeks now and for about 6
months. I'm watching closely his job, and he did a good job so far jumping
into GUMP, Ant, Java, XML, XSL, build problematics, Source control and so on
without knowing all this before.
Sam, if you read this, I also would like to submit you some questions about
the gump dtd:
- Say I have a couple of projects that have the same 'home' source (all in
the same directory, for example redistribuable libs such as javamail,
activation, etc...) Is it possible to do location grouping for a set of
projects without specifying n times the 'srcdir' in each project file ?
- What do you think about tagging projects and specifying 'buildable'
projects or (nested workspace ?) . In the report this could allow to put
some filters about what belongs to a specific 'workspace' (ie Jakarta,
Exolab, 'binaries only', etc..) (maybe it already exists though)
Cheers,
--
Stéphane Bailliez
Software Engineer, Paris - France
iMediation - http://www.imediation.com
Disclaimer: All the opinions expressed above are mine and not those from my
company.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
