[Heads Up] Deprecation Resolution and Future Concerns

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

The Avalon team voted in favor of using a softer form of deprecation for
the org.apache.avalon.framework.component package.  The Recomposable
class remains deprecated, but this should not affect any Cocoon users.
No known container supports it, and it is a bad design that was carried
forward from the Avalon 3.x days.

What this means is that in addition to providing binary compatibility
with all your users, the deprecation messages from Javac will reflect
Cocoon deprecations.

We will be releasing the Avalon projects a step at a time.  Each step
will be compatible with the currently released versions of all the
software.  We will have a new released ECM in the very near future
(hopefully).

The new ECM will have some changes, some for the better and some that
might cause some changes for you.  One change for the better is that
we backported the *-complete-*.jar feature from Fortress.  That means
all Excalibur JARS necessary for ECM to run will be in one large JAR
file.  The CVS version does not use Excalibur Collections or Excalibur
Concurrent any longer.  The Avalon team will make one last release
of those projects with all the classes deprecated.  It will allow you
to maintain backward compatibility while pointing your users to
higher quality libraries that are maintained better.

Excalibur Collections has been merged into Commons Collections-2.1,
and as a result the class names have changed.  All the deprecation
messages point you to a compatible class.

Excalibur Concurrent has been stopped completely, and we are using
Doug Lea's Util.Concurrent library.  That is the library that will
perform the basis of the new JDK 1.5 threading primitives.  It is
in the public domain, so it should not pose any licensing issues
for anyone.

You will still have to include the JARs for projects outside the
scope of ECM's direct dependencies like SourceResolver which now
works in both ECM and Fortress environments.

If you can furnish a list of all the Cocoon dependencies to the
Avalon Developers list (avalon-dev@jakarta.apache.org) we can
incorporate them into the Excalibur Phase I release.

Your help will be greatly appreciated, and in the end will directly
help you.

            -- The Avalon Team.



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

Re: [Heads Up] Deprecation Resolution and Future Concerns

[Leo Simons <le...@apache.org>]

Noel J. Bergman wrote:
>>What this means is that in addition to providing binary compatibility
>>with all your users, the deprecation messages from Javac will reflect
>>Cocoon deprecations.
> 
> How does this impact the changes requiring Stephen to convert CM to SM for
> James?  Or doesn't it?

it doesn't at all. This change is in the javadocs only, replacing 
'@deprecated' with '<span style="color: red;"></span>'.

>>Excalibur Concurrent has been stopped completely, and we are using
>>Doug Lea's Util.Concurrent library.
> 
> Are you exposing util.concurrent, or are you hiding it underneath?

we are not exposing it. We are simply moving some avalon packages which 
used to use the avalon threadpool implementation (fortress, ECM) to use 
Doug's threadpool implementation.

> What
> impact does this have on those of us using your threadpools?

none. The current avalon-excalibur and avalon-cornerstone threadpools 
are of lower quality than Doug's, apparently (I haven't done much 
testing myself). Thus we do want to encourage people who use the 
avalon-produced threadpools to move away from them and refactor to use 
doug's library. We are still backing the avalon-produced threadpools and 
they will receive full support.

> I am familar with d.l.u.c and JSR 166.  I'm just concerned about short term
> migration issues.

If your current application works snappy with the current threadpools, 
there is nothing to worry about. You don't need to migrate in the short 
term. Long term, I'm confident a migration path can/shall be provided if 
neccessary.

cheers!

- Leo



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

Re: [Heads Up] Deprecation Resolution and Future Concerns

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

Noel J. Bergman wrote:
>>What this means is that in addition to providing binary compatibility
>>with all your users, the deprecation messages from Javac will reflect
>>Cocoon deprecations.
> 
> 
> How does this impact the changes requiring Stephen to convert CM to SM for
> James?  Or doesn't it?

SM is the direction of all future efforts.  We want people to to migrate
to SM.  However concerning the nature of the complaints from the Cocoon
crowd where they do specialized containers, we had to use a soft
deprecation so as not to unnecessarily scare their users.


>>Excalibur Concurrent has been stopped completely, and we are using
>>Doug Lea's Util.Concurrent library.
> 
> 
> Are you exposing util.concurrent, or are you hiding it underneath?  What
> impact does this have on those of us using your threadpools?

It is largely hidden underneath.  You have two choices for threadpools.
You can use the version in Excalibur, or you can use the version in
util.concurrent.

> I am familar with d.l.u.c and JSR 166.  I'm just concerned about short term
> migration issues.

We do have the library available for those projects who cannot quickly
migrate.  We do understand those issues.  The Avalon team could not
provide anything as high quality as Doug Lea's library, nor could we
effectively maintain what we had.  Our users deserve better.  To
deliver, we need to focus on our competencies.


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

RE: [Heads Up] Deprecation Resolution and Future Concerns

["Noel J. Bergman" <no...@devtech.com>]

> What this means is that in addition to providing binary compatibility
> with all your users, the deprecation messages from Javac will reflect
> Cocoon deprecations.

How does this impact the changes requiring Stephen to convert CM to SM for
James?  Or doesn't it?

> Excalibur Concurrent has been stopped completely, and we are using
> Doug Lea's Util.Concurrent library.

Are you exposing util.concurrent, or are you hiding it underneath?  What
impact does this have on those of us using your threadpools?

I am familar with d.l.u.c and JSR 166.  I'm just concerned about short term
migration issues.

	--- Noel


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