[jdom-interest] JDOMBean

[Jason Hunter]

> contrib is a testing ground, that in essence will determine if something
> goes into the core, or stays in, for example, org.jdom.util. So things
> in contrib should be in the package where they would reside if accepted,
> like org.jdom.util for your class, or even org.jdom.output. There
> shouldn't be an org.jdom.contrib package, because that doesn't mean
> anything to me or anyone else. Everything was contributed... why a
> package for some of it?

When packages are destined for core inclusion, I agree keeping the same
package has a certain appeal, but putting non-core classes into the core
package is going to cause big problems -- technically and politically. 
I believe an "import org.jdom.*" should only import core JDOM classes,
no mixing core with non-core.  The technical problem is this greatly
increases the risk that someone will accidentally depend on non-core
classes not realizing they are, and breaking portability.  Maybe
"contrib" isn't the right name for it, although "contrib" is nice
because it indicates the classes are non-core and possibly developed and
maintained elsewhere.  Politically, I'd be very upset if someone hosting
code elsewhere put classes into org.jdom itself; it would look like
official work done by this project!

> > For instance, the current division between "examples" and "output"
> > makes absolutely no sense if I'm looking for JTree code, especially
> > because the arbitrary division of "examples" from "output" separates
> > the two source files having to do with JTree!
> 
> I totally disagree.

Problem is when you look at the output directory and see JTreeOutputter,
you don't quickly realize there's an example associated with it.  (I
know I didn't.)

> We classify not by type, but by purpose. Most complete "sub-projects"
> will actually span org.jdom.input, org.jdom.output, and org.jdom
> (possibly). We divide the whole project among input/use/output, so I
> think that's sound. We may eventually add org.jdom.process, but we'll
> see...

In my opinion, the first level of organization should be by sub-project
(org.jdom.contrib.subproject) rather than role.  In other words, with
powerpoint and word files I collect my "Project1" files under one
directory and my "Project2" files under another.  I think that's better
than separating powerpoint from word.

> Jason is trying to get at letting people commit to contrib but not the
> core, which I think is a good idea (although not one I support ;-) ). I
> think contrib is sort of (excuse the reference) JDOM purgatory, and
> since we (committers to the core) decide what gets sent there (again,
> excuse the extended religious metaphor here!), then we need to be doing
> those commits. Eventually, if people are making contribs that go core,
> they would get core commit access (IMO).

I want to make the contrib a thriving place with many committers.  I
don't want to be a gatekeeper.

-jh-