excalibur-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: Resurrecting some removed components
Date Sat, 17 Dec 2005 22:25:53 GMT
Berin Loritsch wrote:

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

I suspected of spice. Thanks for the hint. :-)

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

Yep. We never used the excalibur-cache.jar or at least it is not 
currently in the cocoon lib repo. ;-) Sorry for not deleting the cache 
part in my initial mail. By leaving this part made the mail less clear. :-(

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

i18n, please. :-)

Best Regards,

Antonio Gallardo.

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

View raw message