Proposal 1: package naming for 4.x
----------------------------------
We adopt a system where packages contain a default
implementation, and nothing more, where the default
implementation is the first. The default
implementation classes use a prefix of "Default".
Subsequent implementations go into subpackages of that
package. A descriptive name for the subpackage is
chosen if this is practical, otherwise we use a
nondescriptive name.
This is done for new and unreleased components,
and for released components when feasible.
ie:
org.apache.avalon.excalibur.${package}.Default${packageImpl}
org.apache.avalon.excalibur.${package}.${alternative}.${Alternative}${packag
eImpl}
example:
org.apache.avalon.excalibur.component.DefaultComponentManager
org.apache.avalon.excalibur.component.caching.CachingComponentManager
org.apache.avalon.excalibur.component.dagger.DaggerComponentManager
Note: alternatives to "Default" could be "Standard" or
"Excalibur". However, I feel "Default" is most descriptive.
Also, "Excalibur" to me implies that this is _the_
component provided by excalibur implementing a specific
interface, instead of _a_ component.
Proposal 2: package naming for 5.x
----------------------------------
As above, but without the "avalon" in the package
name, and for all components, released and unreleased.
ie:
org.apache.excalibur.${package}.Default${packageImpl}
org.apache.excalibur.${package}.${alternative}.${Alternative}${packageImpl}
example:
org.apache.excalibur.component.DefaultComponentManager
org.apache.excalibur.component.caching.CachingComponentManager
org.apache.excalibur.component.dagger.DaggerComponentManager
regards,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
