You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by co...@eng.sun.com on 2000/02/23 20:13:50 UTC
Re: Patterns for addXXX ( was: Re: discussion: build file format)
> OK, fixed.
>
> BTW - I tried to generate some discussion on this on this mailing list, but
> didn't get any takers.
I filter ant mails in a different folder, and never got time to read all
of it...
I think we are talking about a very important and common problem, how
to map xml into java objects.
It is clear that we can use some simple pattern like addXXX or createXXX
and the Java type system/hierarchy to create extremly easy to use
mappings, and ant is a perfect example.
In tomcat we also try to deal with the same problem - it would be a good
idea to try to merge the 2 helpers ( XmlMapper and ProjectHelper ).
Costin
>
> At the moment, one can have any number of nested <include> and <exclude>
> tags under any MatchingTask, and each nested construct can be processed
> conditional on the presence (or lack there of) of a class by a given name
> in the classpath. I implemented these both because they were useful, and
> allowed me to explore the possibilities that a richer description could
> support.
>
> I encourage people to try these out, build upon what I started, and give
> feedback.
>
> - Sam Ruby
>
Re: Proposal: XML output from ant tasks
Posted by Erik Meade <em...@geekfarm.org>.
Yes. This is just the kind of stuff I would like to be able to log so I
can generate some measurements for myself. I was just planning
on parsing it out from a file, xml would help there!
Erik Meade
At 11:54 AM 2/23/00 -0800, you wrote:
>Hi,
>
>Right now ant has a very nice file format and works great, but if you
>build a large project you'll probably get a lot of messages - some of them
>are warnings ( deprecated methods ), some are important info ( time to
>build, non-critical failures ).
>
>Also, with conditional compilation we will have some very important
>messages describing what was actualy build into the dist.
>
>The problem is that it takes time to extract the information, and it is
>hard to automate it.
>
>One possible solution is ( guess what? ) xml. If we convert all logs to
>display well-formed XML it will be easy to post-process the results
>and even have a nice format.
>
>The price is not big - the output will still be readable. It can be an
>incremental job, with log() changed to wrap everything in a generic
><log:ant > tag with the source and level, and then we can add format to
>the most important messages ( like deprecations, not-fatal warnings,
>conditional compilations, etc).
>
>What do you think?
>
>Costin
>
Re: Proposal: XML output from ant tasks
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> That's not true if you use an XSLT transformator based on SAX.. ;)
> The problem is that there's nothing like that _currently_ avalialbe.
And since we live in the real world, we should code to what is.. :) Oh I
wish that there was XSLT on SAX based stuff out there.
.duncan
Re: Proposal: XML output from ant tasks
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
James Duncan Davidson wrote:
>
> 2) An XML document isn't complete till it's finished, so doing
> a transform to display out to terminal would have to wait
> till the entire build was done which isn't terribly useful
> for interactive use
That's not true if you use an XSLT transformator based on SAX.. ;)
The problem is that there's nothing like that _currently_ avalialbe.
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Proposal: XML output from ant tasks
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> The end goal is not to reduce clutter, but to allow post-processing.
Ah. Got it. So let me make a counter proposal --
.log(String msg) goes to an XML based .log file
.message(String msg) goes to the console
This lets human readable messages go to the console and machine readable
messages go to a log file. This lets the task do a few things
1) reduce the amount of clutter sent to the console
2) give a "Stopping because of fatal error, see log" type message
The .log file should be very verbose to give the kind of info that you want
in post-processing nightly builds, etc -- and because of this, the console
messages can get tighter.
How's that sound?
.duncan
Re: Proposal: XML output from ant tasks
Posted by co...@eng.sun.com.
> 1) XML isn't nice to read -- and doesn't really belong on an
> output window
> If the end goal is to reduce clutter out to the user when running (like not
> seeing each and every file get copied), then I'd rather see more effort
> being placed into logleveling the messages with the default loglevel seen
> set pretty high.
The end goal is not to reduce clutter, but to allow post-processing.
If every task report it's messages in it's own way.
Think about tools - ant is extensible and that means it will be very hard
to automate it ( not only "nightly", but
also for GUI tools ). Parsing ant output is almost imposible - it's a mix
of various formats, each task has it's own message style and no pattern.
( I know that having ant in a GUI is still far away :-)
The real problem is that we are losing important informations when we log-
and we can't recover the lost. It may be possible to strip the
structure and display plain text, but the reverse is much more dificult.
I know, all tools have text output and (maybe) a parser that understand
the a part of the output ( gcc,javac, sendmail, httpd, etc). Most of the
time it's very hard to work with those tools, and it's much harder to
write code that parse the output produced by arbitrary tasks ( some
probably not even known in advance) than to strip some <> or even read
XML.
Costin
Re: Proposal: XML output from ant tasks
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> One possible solution is ( guess what? ) xml. If we convert all logs to
> display well-formed XML it will be easy to post-process the results
> and even have a nice format.
I'm actually not so hot on this. The reasons being
1) XML isn't nice to read -- and doesn't really belong on an
output window
2) An XML document isn't complete till it's finished, so doing
a transform to display out to terminal would have to wait
till the entire build was done which isn't terribly useful
for interactive use
If the solution is set up so that plain text was output with the option of
sending the data to an XML file (useful for automated builds for sure) I'd
be supportive of that.
If the end goal is to reduce clutter out to the user when running (like not
seeing each and every file get copied), then I'd rather see more effort
being placed into logleveling the messages with the default loglevel seen
set pretty high.
.duncan
Re: Proposal: XML output from ant tasks
Posted by co...@eng.sun.com.
> I see _lots_ of design problems though:
>
> 1) a log schema must be established and this is the log format used by
> ant itself. To avoid collisions, we should create namespaces for each
> task... even if this makes XSLT processing more painful.
Same as in ant - each task can define it's own schema, and we can live
without a DTD for a while. Yes, it's not perfect - but it might work
(same as in ant case).
> 2) how do we trigger this? I mean, logs cannot follow the inversion of
> control tasks do: ant is called by the log methods, not the other way
> around. So there is no way to _force_ the output to be structured but it
> depends on task behavior.
My opinion was to just output xml - having both xml and text is far too
complicated. A task can output an xml fragment instead of it's plain
text, without any pain ( using the current log method ).
It's a choice - each alternative have advantages.
One possible ( but complex ) solution would be to have a:
log( String tag , Hashtable attributes, String body )
Most tasks will just use
log( String tag, String body )
The logger can add few standard attributes to tag ( like timestamp ).
It's not that difficult, and we can still output text.
Costin
Re: Proposal: XML output from ant tasks
Posted by Stefano Mazzocchi <st...@apache.org>.
costin@eng.sun.com wrote:
>
> Hi,
>
> Right now ant has a very nice file format and works great, but if you
> build a large project you'll probably get a lot of messages - some of them
> are warnings ( deprecated methods ), some are important info ( time to
> build, non-critical failures ).
>
> Also, with conditional compilation we will have some very important
> messages describing what was actualy build into the dist.
>
> The problem is that it takes time to extract the information, and it is
> hard to automate it.
>
> One possible solution is ( guess what? ) xml. If we convert all logs to
> display well-formed XML it will be easy to post-process the results
> and even have a nice format.
>
> The price is not big - the output will still be readable. It can be an
> incremental job, with log() changed to wrap everything in a generic
> <log:ant > tag with the source and level, and then we can add format to
> the most important messages ( like deprecations, not-fatal warnings,
> conditional compilations, etc).
>
> What do you think?
I think we already agreed on this... in fact it's already in the todo
list :) (you guys don't read the todo list, do you?)
Anyway, having _just_ XML output would be kinda painful to look at from
the command line... but I agree that something like -xmllog should
trigger the generation of structured content directly from the source.
I see _lots_ of design problems though:
1) a log schema must be established and this is the log format used by
ant itself. To avoid collisions, we should create namespaces for each
task... even if this makes XSLT processing more painful.
2) how do we trigger this? I mean, logs cannot follow the inversion of
control tasks do: ant is called by the log methods, not the other way
around. So there is no way to _force_ the output to be structured but it
depends on task behavior.
I'd hate to see something like this
if (project.log.isXML()) {
project.log("<blah>prrrr!</blah>");
} else {
project.log("[blah] prrrr!");
}
using the above example, the answer should be something like
project.log("blah", "prrrr!");
and the logger takes care of it.... the problem is there are so many
different "log message schemas" that this is not exactly viable....
Another thing would be something like generating DOM fragments and have
compiled in stylesheets that do to-text transformations... but it's
getting far too complex.
When I proposed the idea I thought it was great and simple... after some
reasoning, I don't think implementing something like that is piece of
cake....
What do you think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Proposal: XML output from ant tasks
Posted by co...@eng.sun.com.
Hi,
Right now ant has a very nice file format and works great, but if you
build a large project you'll probably get a lot of messages - some of them
are warnings ( deprecated methods ), some are important info ( time to
build, non-critical failures ).
Also, with conditional compilation we will have some very important
messages describing what was actualy build into the dist.
The problem is that it takes time to extract the information, and it is
hard to automate it.
One possible solution is ( guess what? ) xml. If we convert all logs to
display well-formed XML it will be easy to post-process the results
and even have a nice format.
The price is not big - the output will still be readable. It can be an
incremental job, with log() changed to wrap everything in a generic
<log:ant > tag with the source and level, and then we can add format to
the most important messages ( like deprecations, not-fatal warnings,
conditional compilations, etc).
What do you think?
Costin