cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Getting rid of deprecated Interfaces/Classes/Methods
Date Thu, 26 Sep 2002 13:37:52 GMT
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> 
>> Stefano Mazzocchi wrote:
>>  
>>
>>> -1 for 2.1, no question about it.
>>>

<snip/>

>>> Let me repeat this for those worried guys that are reading this thread:
>>>
>>> WE WILL NOT CHANGE FUNDAMENTAL CONTRACTS UNDER YOUR FEET
>>>
>>>   
>>
>> Couldn't have said this better - and really don't mean this ironically.
>>
>> So, let's put this with the blocks on our new list for 2.2.
>>  
>>
> 
> +1. Same feeling about Stefano's answer : we *need* stability, or nobody 
> will want to use Cocoon for a large or long-lived project.

We (at Avalon) will provide you with it.  I agree that you need to get
2.1 out the door.  No issues with that.  In the mean time, while you
take care of Cocoon 2.1, we will be preparing for the release of
Fortress 1.0.  That process will require the release of all the packages
it relies on before hand.  That release includes documentation,
testcases, etc.  The Documentation has four main focuses: What (is it?),
When (to use it), Why (it was developed), and How (to use it).  The
first of such releases will occur soon (for the Event Package).

Looking forward to the Fortress release, here is what you can expect:

* One big jar with all of its dependencies included.
* ANT and utility class enabled migration of ECM RoleManager config
   files to Fortress Config files.
* ANT and utility class enabled migration of ECM configuration files
   to Fortress Config files.
* Easier migration from *needing* a ComponentSelector to not needing
   one.
* Faster execution and more efficient pool management.  NO NEED TO
   EXPLICITLY SET POOL SIZES!!!
* An additional lifestyle: per-thread.  That means each thread of
   execution has its own component, which is shared with any component
   requesting it.  It works really nicely in Servlet environments...
* Good documentation
* Well tested environment.
* Ability to extend and create your own containers with relative ease.

The only things left in this list is the conversion utilities, and
documentation.  There might be a couple more testcases to write, but
the system has been thoroughly tested.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


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


Mime
View raw message