jhunter at collab.net
Wed Jun 21 14:53:16 PDT 2000
> > Looks slick, Alex. I'll be happy to put it in the contrib directory.
> > Could you please complete the Javadoc comments (including adding the
> > usage to the class Javadoc entry), put it under our standard license,
> > and send it to me?
> OK. I'll do that soon.
> Any opinions on whether I should rename it to, say, "JDOMCacheBean" or
I don't like either of those names. JDOMBean works for me.
> It's up to you, but since it's not JSP-specific -- you can use it in
> servlets, applications, or from other beans in your favorite bean IDE
> -- I'd prefer it just go in org.jdom.contrib.
Agreed o.j.c.jsp doesn't fit. I also agree that we need a better
organization for things like jtree. I think o.j.c.jtree would be very
nice, with examples and such under there, better than o.j.c containing a
mix of all contributed projects. Opinions on
org.jdom.contrib.projectname for little subprojects? o.j.c.jtree,
o.j.c.bean (that's you Alex), o.j.c.xpath, and o.j.c.xslt are possible
> And if and when a contributed project becomes core, it could then be
> cleanly re-integrated into the core package hierarchy.
Right, remove "contrib" from the import and you're real.
> > I'm thinking it might be smart to make a jdom-contrib module with write
> > access for people involved in contributed projects. We're already
> > planning a jdom-test module to host the testing effort. Any opinions?
> Do you mean a separate set of users/permissions? Again, why
> overcomplicate? Committers should, by definition, be responsible
> enough not to check in code where it doesn't belong.
Committers are traditionally given commit status because they're
interested in the role, they've proven their worth through consistently
good patches and contributions, and are trusted by the existing
committers. Access to jdom-contrib can be granted with a lower level of
trust; I'd be willing to grant perms to relative strangers.
More information about the jdom-interest