[jdom-interest] Should we Move JDOM to Apache Jakarta ?

[Jason Hunter]

Some random thoughts on the idea...

As Sean pointed out, a JDOM type project would indeed go to 
xml.apache.org rather than jakarta.apache.org.

In the early days we considered working within Apache but didn't for two 
main reasons.  First, xml.apache.org was undergoing some internal 
strife.  I think that's been resolved.  Second, despite being an Apache 
member myself, I think Philipp has a good point that Apache projects 
tend to grow plentiful in features.  The Apache collaborative 
development model was organically grown for the purpose of collaborating 
on externally defined specs and APIs (i.e. HTTP).  It can work for API 
design but it's not known for creating elegant, focused APIs.  It 
encourages development in many directions and usually relies on the spec 
or API to limit "sprawl".  One of the goals with JDOM has been to avoid 
sprawl.

The appeal of the Apache idea is that the JDOM code needs a bit more 
energy to keep it going to 1.0.  Would putting it within Apache bring 
that energy?   Tough to know.  We already have a great community here 
and people who answer questions and fix bugs.  Our issue I think is that 
JDOM as built today solves most everyone's problem.  It surely solves 
mine.  That's a good thing, but the need to scratch the itch just isn't 
there.  We have a few little things before 1.0 but the JSR thing has 
kept us from just pushing 1.0 final, and no one's wanted to step up to 
lead in my stead.  The better solution probably is to 1.0 it here, then 
if Apache would want to work on 1.1 or 2.0 that'd be excellent.  A new 
set of feature ideas would grow a good community there.  If it were to 
get more complicated there's always 1.0 for people who like simple.

The most difficult aspect of an Apache donation is that we haven't been 
collecting contributor agreements.  We'd have to get signatures from all 
significant contributors allowing the donation.  That's what 
SpamAssassin just had to go through 
(http://article.gmane.org/gmane.mail.spam.spamassassin.general/31618).

-jh-