Summary of naming issues

[Berin Loritsch <bl...@avalon.org>]

1) package naming convention
We have decided to use 

org.apache.${mainproject}.${subproject}

for imports (starting on only new packages).


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?


"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
                - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Summary of naming issues

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Berin Loritsch [mailto:bloritsch@avalon.org]
> 
> 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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>