maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Digulla <>
Subject Re: POM rewriting with DecentXML
Date Tue, 05 Aug 2008 19:15:20 GMT
Stuart McCulloch schrieb:

>> 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.
> ouch, there's a reason to use private fields, etc. - if you open everything
> up then you don't know what people are using and can't be sure that you
> don't break them when you change or refactor your implementation

That's a non-issue for OSS software. If a user used something from 1.1
that's gone in 1.2, he has three options:

1. He can chose *not* to upgrade. Nothing forces him to.

2. He can backport the changes he needs from 1.2

3. He can modify his code to work with 1.2.

Of course, with closed software, you have no choice but #3.

That said, I of course try to make no breaking changes and the
information that I offer is basic. It can't be broken down further or
aggregated in any useful way with other information, so even if I have
to change some internal details, this information will be still around.

>> 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).
> *any* parser sucks? does that include DecentXML? ;)

It sucks least. For me. :)

>> As of right now, there are two reasons not to use XML:
>> 1. You documents are huge (10MB and more)
> kind of orthogonal to choosing a parser - besides I can write large
> documents in any format

Well, all parsers that build context for you (so you don't have to track
it yourself), need the memory to keep the whole document in memory.

That said, I haven't tried DecentXML with a big document yet. I've tried
to make it memory conservative (I'm an old C64 guy; I hate to waste
bytes), so it won't allocate memory for a lot of things until it has to
(for example, if your elements don't have attributes, each element will
only need 4-8 bytes for the null pointer)

> 2. You must be compliant to some API.
> I actually like APIs, because it gives me confidence I can swap in other
> implementations later on

You still believe that? ;) Okay ... have you ever tried to replace
Xerces with Crimson or the other way around? Both are SAX parsers and
both are SAX compliant and if you do, you will have the most strange
errors plus some of your code probably won't work because you needed
that one feature which wasn't in the standard ...

Further more, there usually is one implementation which fits you need so
you will never ever do that and any minute spent of making it compatible
is most likely wasted.

As for DecentXML, I've considered to make it Duck-typing compatible to
JDOM (so you can replace the JAR and recompile and you shouldn't have
many errors). Didn't have the time nor the pressure, yet.

I also considered to make the API compatible to java.util.List to make
it more natural to work with child nodes, etc. But that would mean a
major breaking change in the API and I'm not sure it's worth the effort.


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."

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message