commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: XML Im-/Ex-porter into Commons Sandbox
Date Thu, 07 Oct 2004 22:27:39 GMT
One of the key items in the commons charter is allowing different solutions
to the same problem. So far, we have tended to avoid this (for example, I
took a conflicting primitives design elsewhere) however we should not block
this.

What is being requested at this point is to factor out some code from
another project (Slide) to commons. This is IMHO perfectly good and what
commons is for. The code is going to the sandbox where we can all determine
whether it is a good addition to the commons-proper fold. (eg. performance
tests, code design, documentation). Who knows maybe the ideas will end up as
digester 2! IMO thats what the sandbox is for.

BTW, I don't disagree with the comments about bad dependency management
below, I just disagree that that necessarily implies only ever supporting
digester.

Finally, the name ;-)
xmlio  (ie. xml io)
sax
saxio

Typically, the commons project is named after the technology it works on.
Without having seen the code its also difficult to judge what a good name
would be ;-) I quite like xmlio myself.

Stephen

----- Original Message -----
From: "David Graham" <grahamdavid1980@yahoo.com>
> This will create bloat problems for clients that use Digester.  For
> example:  Struts uses Digester for xml parsing.  In the future Struts may
> want to use the new i18n component.  However, if i18n uses XML Im-Exporter
> then Struts must drag that along too despite already having a perfectly
> fine xml parser in its dependency list.
>
> Struts is just one example.  It will be even worse for inter-commons
> project dependencies.
>
> Bad dependency management has plagued commons components and it's just
> recently started to get better.  If all commons components use Digester
> then we can avoid having to duplicate functionality and bloat
> dependencies.
>
> I don't understand what's wrong with Digester that necessitates a new
> parsing library.  I've been able to write complex parsing rules in a
> matter of minutes.
>
> David
>
> --- Oliver Zeigermann <oliver.zeigermann@gmail.com> wrote:
>
> > Folks,
> >
> > on the request of Daniel Florey I'd like to create at least one new
> > sandbox component for a tool that allows easy import / export of XML
> > into / from Java. It is used by Jakarta Slide and in the components
> > Daniel introduced.
> >
> > I know this is a bit delicate as there already is Digester around in
> > commons. However, the audience for my tool is different from
> > Digester's. XML Im-/Exporter is geared towards high performance use
> > for people who are very familiar with XML. It is just a little bit
> > more than pure SAX. It also has a different philosohie than Digester.
> >
> > Having said that I hope not to cause any inconvenience with this...
> >
> > Preparing this now  and cheers,



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message