You mean this?
> [jakarta-commons] shall create and maintain packages written
> in the Java language, intended for use in server-related
> development, and designed to be used independently of any
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> larger product or framework.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
That seems like a pretty straightforward requirement. It doesn't really
speak to the dependencies, but rather to use: I could have, for example, a
commons component that depends upon Struts or Turbine, it seems to me, as
long as the are usable outside of Struts or Turbine. Otherwise it's pretty
silly to put it in commons.
For a concrete example, in theory one could create an implementation of
commons-pool that uses the avalon-excalibur pool implementation. The
commons-pool interface, and generic implementations of it, remains usable
outside of avalon/excalibur. Only if I want to use that particular pool
implementation do I need to bundle avalaon-exaclibur with my client code.
- Rod
-----Original Message-----
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 8:27 AM
To: Jakarta General List
Subject: Re: Database Subproject Discussion : creation of DBCommons ?
On 5/3/02 8:24 AM, "Waldhoff, Rodney" <[EMAIL PROTECTED]> wrote:
> Berin wrote:
>
>> There are some things we have in Excalibur that we *can't*
>> donate to Commons because the charter does not allow it
>> (I think its something about the project can't rely on
>> non-commons projects or something).
>
> What gives you that idea? Many if not most commons projects rely upon
> non-commons projects (check out the gump descriptors). There's no mention
> of anything like this in the commons charter
> (http://jakarta.apache.org/commons/charter.html). I'm pretty confident
that
> no proposed commons component has been rejected because of its
dependencies
> on non-commons projects.
I think he was referring to the idea that the commons component should be
'mostly independent' ("He's mostly dead"), relying only upon common
platforms.
Having subproject specific bits (like Struts-only or Turbine-only) is
contrary to some of the non-binding guidelines we came up with in the
beginning. The whole idea was to bring "productizable" things *out* of the
subprojects...
It also keeps things on an even keel, tribe-wise :)
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
[EMAIL PROTECTED]
+1-203-247-1713
