> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> 1) package naming convention
> We have decided to use
>
> org.apache.${mainproject}.${subproject}
>
> for imports (starting on only new packages).
As much as I'd like that, it will not work. The thing is that whenever
you have a flat project structure you get namespace collisions.
We must allow:
org.apache.${mainproject}.${subproject}.${sub-subproject}. ...
If I create a new naming context as a project, should I not put it in:
org.apache.avalon.excalibur.naming.<something>
?
Since we have
org.apache.avalon.excalibur.naming.memory
and
org.apache.avalon.excalibur.naming.rmi
?
Why should I have to put it in org.apache.avalon.excalibur.${projectname} ?
Decouple the package and project structures - they need not be the same.
> 2) subproject naming convention
> We have a lot of friction on this. Peter is (and always has been)
> in favor of abstract names. Leo Sutic (since we have two Leos)
> brought up some good points about too many abstract names.
>
> We do have to come to some balance. Excalibur already has something
> like 30 sub projects, and if each one of them had an abstract name,
> we would quickly have a mess on our hands. However some packages
> don't really satisfy the simple name thing.
>
> So what's the balance?
I'd say: No abstract names unless absolutely necessary. I can not think of
any use cases where an abstract name is needed, but I do not rule
out the existence of such cases.
Abstract names just confuse users.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
