1) Is your project a child of an existing Jakarta project [see jelly]? Or a plan for adoption [see hivemind]. If yes: Jakarta Commons. If no: Continue.
2) Is your project a child of a DB project [some component of OJB]? If yes: DB Commons. If no: Continue.
3) Apache Commons.
Except...Xml Commons should be in there too. Also, Jelly is a child of Maven, and yet Maven is no longer a Jakarta project.
What other options of input are there?
That's pretty much what I'd see as the litmus test. Ideally, I would like to see a strong relationship with the 'children' residing in *-commons. Those without such strong relationships belong in Commons.
I don't buy that thread pools belong in Jakarta Commons. I'd believe that servlet containers belong in Jakarta Commons though. There's a qualitative difference. If people don't see that difference, then...
Note that the HTTP Server PMC rejected serf because it's a client not a server. I realize tight scopes of projects is unusual to people outside of httpd-land, but it works for some of us. =)
But Commons *is* a separate TLP which sets its own goals.
Ooo. A worthy advantage, Apache Commons is at a higher level in the ASF realm :)
Exactly. I believe the oversight within Commons TLP would be much stronger than *-commons. One primary difference would be that Commons would be specifically tailored for smaller projects.
Tricky. A lot of code begins as one-man components, so do we just stick our fingers in our ears and ignore it until it becomes two-men components, ignoring the loss of cvs history, comments, and backup ability. Plus it makes it harder for the one-man to share.
I wouldn't have a problem with the following procedure:
1) Committer proposes new project idea on [EMAIL PROTECTED] 2) PMC member decides to sponsor new project via email to PMC 3) If no one in PMC objects, committer can start project in commons repository
This allows one-man projects to start, but it has to pass the sanity check of the Commons PMC. If the Commons PMC thinks it is a idea destined for failure, they'll say so and reject it.
I don't know how that'll work in practice, but that's my suggestion. -- justin
