excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Re: Resurrecting some removed components
Date Sat, 17 Dec 2005 21:28:29 GMT
Antonio Gallardo wrote:

> Hi Berin,
>
> Please read comments between lines.... :-)
>
> Berin Loritsch wrote:
>
>> Sasvata (Shash) Chatterjee wrote:
>>
>>> All,
>>>
>>> We briefly brought this topic up, but the discussion around the release
>>> overwhelmed this topic.
>>> Can we get a bit of feedback on this?
>>>
>>> I'd like to see the following removed libraries resurrected into the
>>> deprecated modules directory, so we can bring them up to the latest
>>> Framework/Logkit JARs.  Users should have no expectation of ongoing
>>> maintenance, beyond compatibility with the other JARs.  But, if someone
>>> were to contribute patches occasionally, I really don't see much 
>>> harm in
>>> adding those in either.  I know the goal is to encourage projects to
>>> move to Apache commons or other libraries, but for projects that 
>>> haven't
>>> yet, or cannot afford to for some reason, it'd be nice to have this
>>> (similar reason to why we did the Excalibur project in the first 
>>> place).
>>>
>>> Here's my list:
>>>
>>> excalibur-i18n
>>> excalibur-io
>>> excalibur-naming
>>> excalibur-cache
>>> excalibur-configuration
>>>  
>>>
>> Isn't IO incorporated into Commons IO?
>>
>> Naming is now in Codehaus--it being Peter D's code and all.  There 
>> shouldn't be any need for compatibility changes as I don't even think 
>> it uses framework.
>
>
> Can you point to the project. I was unable to find it. I will like to 
> switch it cocoon.

http://spice.codehaus.org/jndikit/apidocs/overview-summary.html

It's part of spice.

>> Caching is something that was started and never finished or validated 
>> from what I recall.  The sole developer on that component has been 
>> unavailable for many moons.
>>
>> The configuration and i18n modules I can't remember too much about, 
>> however using standard J2SE calls to resource bundles is actually a 
>> bit more reliable.
>
>
> Can you explain more about it?
>

Let's put it this way, Cocoon's current caching mechanism is more mature 
and maintained.  The Caching library was not (to my knowlege) ever 
inforporated or tested with anything.

Now which did you want to hear about, i18n or caching?


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


Mime
View raw message