> > for us that would mean:
> >
> > org.apache.framework.${interfacepackage}.${SomeInterface}
> > org.apache.excalibur.${interfaceimplementationpackage}.${specifici
> > mplementat
> > ion}.${SomeInterfaceImplementation}
> >
> > leading to:
> >
> > org.apache.avalon.framework.component.ComponentManager
> > org.apache.avalon.framework.component.DefaultComponentManager
> > org.apache.avalon.excalibur.component.default.DefaultComponentManager
> >
> org.apache.avalon.excalibur.component.excalibur.ExcaliburComponentManager
> > org.apache.avalon.excalibur.component.phoenix.PhoenixComponentManager
> > org.apache.avalon.excalibur.component.{bla}.{Bla}ComponentManager
>
> I am extremely nitpicking here, but as I understand it, it would be
>
> org.apache.framework.component.ComponentManager
> org.apache.framework.component.DefaultComponentManager
>
> Dropping avalon from the name. I would prefer:
>
> org.apache.avalon.component.ComponentManager
> org.apache.avalon.component.DefaultComponentManager
>
> though - just to get the Avalon name in there.
this will have to wait until avalon 5 for compatibility issues
'n stuff.
> org.apache.excalibur.component.DefaultComponentManager
>
> No need to put in 'default' there. (default is a reserved word,
> so you'd end up with 'defaultimpl' or something).
>
well, you'd be really 'favoring' these. I'm okay with that tho'.
But, if you have the system
org.apache.${subproject}.${subsubproject}.${someimpl}.SomeImplClasses
that is easier for stuff like dep checking, etc, than using
org.apache.${subproject}.${subsubproject}.DefaultImplClasses
org.apache.${subproject}.${subsubproject}.${someimpl}.SomeImplClasses
> org.apache.excalibur.component.ExcaliburComponentManager
>
> Let's say that the project itself does not have to repeat its own name
> for implementation, unless there is a need for it or it makes sense
> to put it in a excalibur subpackage.
There is no sense in calling ExcaliburComponentManager
ExcaliburComponentManager. There's a Default one, and then there
is an alternative one. It is not _the_ excalibur one. You are
right tho'.
> For example, if we knew that
> there would be many implementations it would make sense to put it
> in a subpackage. If we feel confident that only one implementation
> will exist, or that only one implementation will be in the
> 'all' project, with other implementations being in subprojects,
> then I say we skip the subpackage.
If you don't know this stuff beforehand and you want to change it
later, that means waiting for a major version change. Anyhow, I'll
hammer out a votable proposal from this.
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
