These are just my off-the-cuff thoughts. However, I did spend time going
through the jakarta.apache.org and xml.apache.org sites, and authoring a
roadmap for developers (see:
www.softwaresummit.com/2002/speakers/bergman.htm), so I think I have some
notion of the perspective of developers who are more concerned with making
use of Jakarta technologies than in how Apache manages itself internally.
Good things could come from a reorg, but my own view as a non-insider is
that the interests of outside users (e.g, the potential consuming
developers) should be incorporated into any reorg that is visible on the web
site(s).
If there were to be a reorg, I'd want thought put into semantic
relationships. Yes, things like taglibs and struts can be used with other
servlet engines than Tomcat, but we need to make it easy for people to find
things and pull them together related technologies. As Serge noted,
increased visibility for specific projects could be a good thing for the
right project(s), but too broad a tree makes it harder to see the forest for
the trees.
FWIW, it might be nice if there were a matchers/mailets sub-project of James
similar to the taglib (sub-)project. But that can be dealt with after we
address the classloading issues.
Questions:
Is there any real infrastructure related issue for reorganizing?
If so, what?
Does the fact that Tomcat isn't on the list reveal an underlying
"jealousy" that Tomcat is the perceived BMOC on the Jakarta
campus, and some people want more mindshare?
Is this reorg being considered to encourage some projects to
stay, rather than jump ship after having established themselves?
What would the reorg impose upon projects?
--- Noel
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
