Re: Resurrecting some removed components

[Antonio Gallardo <ag...@agssa.net>]

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.

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

Best Regards,

Antonio Gallardo.


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

Re: Resurrecting some removed components

[Berin Loritsch <bl...@d-haven.org>]

Antonio Gallardo wrote:

>> Now which did you want to hear about, i18n or caching?
>
>
> i18n, please. :-)


Ok, the predictability I refered to has to do with classloader issues.  
Isn't that always the case?

The static ResourceBundleFactory would try to do classloader magic to 
find the proper resource bundle for your component.  Added a few extra 
conventions, and eliminated any possible reuse between component 
resource bundles.  No commonalities between them.  I'm on my way out the 
door right now, so I'll answer any further questions later.


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

Re: Resurrecting some removed components

[Antonio Gallardo <ag...@agssa.net>]

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

Re: Resurrecting some removed components

[Berin Loritsch <bl...@d-haven.org>]

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