Quoting Jochen Wiedmann <[EMAIL PROTECTED]>:
As for patching it: StAX is a standard API (JSR-173). How big are my chances
that the standard API is going to be extended to allow the features I need?
No API forbids extending.
In Java, APIs are written by paranoid control freaks ;) Just try to
add a line number to org.jdom.Element... It *ought* to be possible ...
maybe with a little bit of reflection, setAccessible(true) and a smart
classloader ...
In the case of a StAX parser, one could by
default supply and accept the standard event types. However, in a
particular mode, one could supply and accept additional events. In the
case of white space around attributes, you could offer an extension of
the Attribute interface that informs about whitespace to the left and
to the right.
That's great. Can I also add new getters to the Attribute interface? ;)
Sorry. I've written code with about any XML parser out there and none
of them would even get close to what DecentXML can do. In DecentXML,
there are no private fields or methods. Everything is meant to be
extended or reused. It's meant to be useful instead of limiting what
you can do.
As I said: My parser is probably not so useful as a general purpose
replacement for POM *reading* in general. It ought to be used in the Maven
artifact plugin and any other code which *writes* POM files.
Unfortunately, these can hardly be separated. At least from a software
architects point of view, I'd strongly argue against two completely
different approaches for reading POM files.
You gave the answer to that yourself:
Look, that's why there's rules, understand? So that you think before
you break 'em.
As long as the current standard XML tools can't do what we need, we
need a second tool.
That said, I haven't thought about building Maven on DecentXML and get
rid of StAX. Pull parsers are a step forward to what we had before
(SAX&DOM) but they still suck (any parser sucks, pull parsers just
suck a bit less).
I haven't tried to write a XML->OO mapper with DecentXML, yet, but
it'll probably be more simple to do than with anything else in the
market. One of the reasons is that you can extend and override methods
in XMLParser, so you could call the parser and get a Document back
whose root element is a Project object. Or have Project extend Document.
That would allow you to merge the XML and the OO API into one. Not
sure if that was smart but at least, you have the choice.
Or you could use the XML tokenizer directly to slurp in the POM.
Another choice which might make sense in 1% of all the situations.
Most people will never do that, of course, but the 1% sure will be
happy to be able to without having to invent the wheel again.
AFAIK, DecentXML is also the only XML parser out there which allows
you to access the class which turns a byte stream into unicode (see
XMLInputStreamSource).
As of right now, there are two reasons not to use XML:
1. You documents are huge (10MB and more)
2. You must be compliant to some API.
Regards,
--
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://www.pdark.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
