I agree with the statement that the Jakarta Commons charter needs an update and there is also nothing against becoming a TLP and reporting directly to the board.

But we should keep the Jakarta brand. Jakarta as the main java entry point at Apache and as a provider for the java news/download is important I think. (see also [EMAIL PROTECTED])

I think a lot of people think "Jakarta" when you ask for java from apache. The jakarta-commons is then a logical place for all reusable java components. (and yes I think the java components in db-commons would benefit from moving to jakarta-commons)

As for other languages joining, look at xerces.
They have separate mailing list for each language.
So the simplest split would be:
commons-j-dev  => jakarta-commons
commons-c-dev
commons-p-dev

For starting up new cross language initiatives a better medium can be found. A shared wiki, newsletter, ...

Once a component has multiple implementations in multiple languages it is probably large enough to become a TLP itself (like log4j).


-- Dirk



Henri Yandell wrote:


[partially fantasy land/future ideas]

The Jakarta Commons charter basically views Commons as a supplier of
Jakarta projects, and not Apache projects in general.

With many of the Jakarta sub-projects moving to TLP status [ie)
ant.apache.org etc], this is increasingly untrue. Jelly's main customer
is Maven for example, quite a few XxxxUtils classes in Commons came from
Ant, and a lot of code came from a partial merger with Avalon's Excalibur.

There are two easy solutions [to think of]. The first is to change the
charter to match reality, ie) any ASF TLP is considered a client of
Jakarta Commons. The other is for Jakarta Commons to become a TLP.

I'd like to speak for the latter suggestion, I'd also then like to suggest
a more radical [flame-likely], though obvious next step.

Pluses I see for becoming a TLP:

* Currently we're viewed as a bit of an odd project in that we're an
umbrella project child of an umbrella project.  Removing one of these
layers will improve the view that we have strong awareness of what's going
on and we would report directly to the board.

* It helps get us into the ASF community. We're a bit hidden away from new
TLP Java projects, such as the currently incubating Directory project, and
a TLP placement would lead to more involvement and a larger community
spread as new Java projects arrive there.

* There's community interest in a TLP Commons, and as a community we have
a large amount of knowledge we can bring to the table.

The last point suggests an obvious next step, which is some kind of
merging with the Apache Commons project. I would like to suggest that the
way we do this is that, J-C goes to TLP, with all its current rules and
community, A-C projects join J-C [currently just Serf, though a
*libtool project that's something to do with compiling C is likely to join
A-C too], J-C removes its Java-centric view and allows any language to
join.

The things I believe we should push for is that our current J-C group
should not try to de-java ourselves, but that we allow the A/J-C community
to choose its own delineations over time and not try and set them up to
begin with. Our mail lists would stay the same and they would join, and
over time we would decide, much like httpclient in the past, whether we
need new mail lists.

The PMC for such a thing would be based on all active committers, so no
real change than the current way in which the J-C bazaar is handled.

I think the ASF infrastructure group are going to want ASF projects to be
using subversion rather than cvs at some point in the future, and the
current A-C community has good subversion understanding with which to help
us if that should come to pass.

There are also obvious ties when similar domain products, serf/httpclient,
are able to communicate more openly and easily.

---

Does anyone have any negatives/positives of such a thing? Does it make any
sense for the future? Does it harm/help J-C?

Or am I just suggesting evil thoughts?

Hen




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to