avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: excalibur package naming
Date Sat, 06 Apr 2002 11:52:39 GMT

> From: Leo Simons [mailto:leosimons@apache.org]
> > Not neccesarily, but the fact that you *do* get namespace collisions
> > that you must solve by using non-descriptive names indicates
> > that a flat structure does not scale too well.
> It can scale extremely far, though...Java API again is an example.

Yes, but the number of different implementations for the same interface
is small, and whenever you see them it is solved with subpackages.

> > > Quoting the Java API once more, it contains many packages in
> > > java.* and javax.* (certainly more than excalibur), with peer
> > > package dependencies.
> >
> > And whenever there is multiple implementations of one interface
> > that is solved by putting the implementations in subpackages:
> > javax.swing.plaf.*
> 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


Dropping avalon from the name. I would prefer:


though - just to get the Avalon name in there.


No need to put in 'default' there. (default is a reserved word,
so you'd end up with 'defaultimpl' or something).


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. 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.


Phoenix is a project in itself and not a subproject of Excalibur.


Yes. For component managers in Excalibur. Phoenix CMs would
be as above.

> However, there will still be "bla" in there somewhere. And
> "bla" is not always "caching" or "ejb". It might be "merlin"
> or "fortress".


> "Use a flat structure" should then be redefined as "use a not
> completely normalized tree structure until we get scalability problems",
> and everyone's happy.


> Note that I think (and think I have said) under the current
> 'system', that we should replace "completely descriptive" with
> "as completely descriptive as possible while avoiding
> namespace collissions".


> This is workable for me. Does it satisfy your needs?

Yes. If you *did* say that then I missed it.

> The question is how much to normalize.

I'm sure we can take that as we go. My main problem was making
names like 'merlin' (org.apache.phoenix.component.EmbeddedComponentManager?)
the norm, with descriptive names being the exception.

The proposal above is "descriptive when possible, otherwise use common

Common sense: For 'merlin', for example, I would choose:


and not:


to at least give a hint to someone seeing


that it is somthing component-related.


Doesn't really hint it for me.


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message