avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [VOTE] Merge Cadastre into Excalibur
Date Wed, 08 Aug 2001 12:36:43 GMT
Peter Donald wrote:
> On Wed,  8 Aug 2001 06:30, Berin Loritsch wrote:
> 
>>I would like to merge cadastre into Excalibur, and make the package
>>named:
>>
>>org.apache.avalon.excalibur.naming
>>
>>As there is little confusion for Java developers as to what that means,
>>and it follows the patterns set up for the Excalibur package as a whole.
>>
> 
> I don't mind the rename ... though give me a bit so I can update all my 
> code ;)

+1

> However I do have a problem with the length of import statements. A direct 
> convertion will mean the length of our import statements are pushing 60 
> characters !!!! Not sure how to deal with this just yet thouygh ;)

The only way I can see doing this--and supporting our naming structure is
to drop "org.apache" from the package name.  I don't know how that would
fly with the other apache projects here.  With that change, our new imports
would be:

import avalon.excalibur.naming;

>>I think we need to only deal with Realy Cool Names (RCN) when there is
>>a new project to be had.  
> 
> I am not sure I agree with that ... it works when there is one instance of 
> component but fails when you get duplicates. Currently I have two other 
> packages in excalibur package waiting for me to actually commit them or throw 
> them out. One is a pool but different from our current version (an object 
> pool rather than component pool). Another is a simplified CLI parser ... 
> consequently they have the odd names excalibur.opool for object pool (thought 
> about opul or opal) and xcli for extended CLI services (when in reality it is 
> a simplified CLI ;]).
> 
> I guess in most cases I like simple names ... not sure. I think we should at 
> least be open to different ways.

The excalibur.pool package _is_ object pooling.  The excalibur.component package
extends it and creates the component pooling.  Now, if you have an improved pooling
algorithm that is thread safe--I would be very happy to see it.  But it should be
in the excalibur.pool package.

As for your improved/simplified CLI services, I am all for ease of use.  I wouldn't
use excalibur.xcli if it doesn't provide more services.  The word "extended" implies
the ability to do _more_ than what is already available.  Perhaps "ecli" for Easy
CLI or "scli" for Simplified CLI?


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


Mime
View raw message