You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Simons <le...@apache.org> on 2002/04/06 14:45:45 UTC
[VOTE] future standard for Excalibur package naming
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] future standard for Excalibur package naming
Posted by Paul Hammant <Pa...@yahoo.com>.
Leo
-1
This is not complete yet.
--> Interface impl separation, which _includes_ packages and the hint
that different jarring scenarios is possible must IMHO be included.
org.apache.excalibur.thing.Thing (interface)
org.apache.excalibur.thing.impl.DefaultThing
Swap 'impl' for some better work if you like.
- Paul
>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: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] future standard for Excalibur package naming
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> this is what I sort of expected to be your response.
> So, now we have a -1 against nondescriptive and a -1
> against descriptive. Deadlock. I'll go get the
> rulebook :(
>
> I have tried to find a path which will suit both of
> you, which will apparantly not happen. Shame.
>
> Anyone see a mutually satisfying solution?
Unless this has to be decided, let it drop for now. No decision.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] future standard for Excalibur package naming
Posted by Leo Simons <le...@apache.org>.
this is what I sort of expected to be your response.
So, now we have a -1 against nondescriptive and a -1
against descriptive. Deadlock. I'll go get the
rulebook :(
I have tried to find a path which will suit both of
you, which will apparantly not happen. Shame.
Anyone see a mutually satisfying solution?
- Leo
Pete:
> -1
>
> Doesn't work with existing components and unlikely to work with future
> components. The people who are actually writing the code in question have
> already decided anyways.
>
> On Sat, 6 Apr 2002 22:45, Leo Simons wrote:
> > 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}.${Alternativ
> e}${packa
> >g 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}${pac
> kageImpl}
> >
> > example:
> >
> > org.apache.excalibur.component.DefaultComponentManager
> > org.apache.excalibur.component.caching.CachingComponentManager
> > org.apache.excalibur.component.dagger.DaggerComponentManager
> >
> > regards,
> >
> > - Leo
>
> --
> Cheers,
>
> Pete
>
> ---------------------------------------------------
> "If you don't know where you want to go, we'll make
> sure you get taken."
> Microsoft ad slogan, translated into Japanese.
> ---------------------------------------------------
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] future standard for Excalibur package naming
Posted by Peter Donald <pe...@apache.org>.
-1
Doesn't work with existing components and unlikely to work with future
components. The people who are actually writing the code in question have
already decided anyways.
On Sat, 6 Apr 2002 22:45, Leo Simons wrote:
> 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}${packa
>g 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
--
Cheers,
Pete
---------------------------------------------------
"If you don't know where you want to go, we'll make
sure you get taken."
Microsoft ad slogan, translated into Japanese.
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] future standard for Excalibur package naming
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Leo Simons [mailto:leosimons@apache.org]
>
> 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
^^^^^^^^^^
Make that "package or subpackage".
> 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}.${Alternativ
> e}${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}${pac
> kageImpl}
>
> example:
>
> org.apache.excalibur.component.DefaultComponentManager
> org.apache.excalibur.component.caching.CachingComponentManager
> org.apache.excalibur.component.dagger.DaggerComponentManager
>
Exceptions are handled via standard +3/-0 concensus voting.
> regards,
>
> - Leo
>
>
+1, but only with modifications as given.
I further propose this voting is extended until Monday, at least
1200 GMT, even if we get +3 before that so that it is not something
that slipped past during the weekend.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>