cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: Planning Cocoon's future
Date Tue, 23 Nov 2004 15:42:32 GMT
Sylvain Wallez wrote:
> Reinhard Poetz wrote:
> 
>>
>> After releasing Cocoon 2.1.6 it's time to plan our future. A few month 
>> ago we
>> updated our roadmap in SVN. According to this we agreed that 2.2 is a
>> consolidated version of 2.1.
>>
>> So what are the changes and what's their current status?
>> --------------------------------------------------------
>> (based on xdocs/plan/roadmap.xml)
>>
>>  - stable Cocoon Forms
>>    the status is summarizes by Sylvain[1]
> 
> 
> 
> I need to invest more time into this...

At least a wiki summary or over-working the existing cforms roadmap entries in 
Bugzilla would be cool ;-) <hint/> ;-)

> 
>>  - Virtual Sitemap Components
>>    Vadim started with the implementation 
> 
> You have also to consider my "multi-relative" sourceresolving RT 
> (http://www.mail-archive.com/dev@cocoon.apache.org/msg24485.html)

Yep, of course!

> 
>>  - inheritable views
>>    don't know the status (I think Carsten is/was working on it)
> 
> 
> 
> Inheritable views should come as a fee bonus with VSCs, as views can 
> simply be turned into virtual serializers.
> 
>>  - deprecate XSP
>>    to be done (needs an alternative)
> 
> 
> 
> Deprecate? It's not mainstream, but used a lot in many places. The risk 
> if XSPs are deprecated and then removed is that people will start using 
> JSPGenerator to write quickly some custom generator, which IMO would be 
> a very bad thing.


I read src/documentation/xdocs/plan/roadmap.xml and there was an entry that we 
want to deprecate it. Not more, not less :-)

So if you (vadim, betrand, sylvain) tell me that we should wait for a working 
replacement I don't have a problem to drop this point.

>>    Daniel, are you working on a JXTG 2.0?
>>
>>  - Cleaning up the caching/store mess
>>    don't know, does it work now as it should?
>>
>>  - separate blocks from Core
>>    that's my job: I'm working on a block-builder and a block-deployer
>>    that will make this separation possible and will give us the chance
>>    of a smooth transition from our current monolytic system to a 
>> decentral
>>    blocks orientated system:
>>
>>       * every block get's a descriptor containing all meta information 
>> like
>>         author, license, status, block references and library references
>>         --> should as close as possible to the needs of RealBlocks
>>       * enhance jars.xml to become a repository (only needs an id 
>> attribute
>>         for all entries so they can be references and looked up)
>>       * setup the new block centric build system parallel to the 
>> existing one
>>       * when everything works fine and a vote is passed,
>>         the old build system will be removed
>>       * move blocks into [svn]/cocoon/blocks --> blocks are 
>> independant units
>>         with their own lifecycle
> 
> 
> 
> I hadn't had a chance yet to look at your job, but had some random 
> thoughts about an easier handling of blocks, buy simply allowing 
> cocoon.roles and cocoon.xconf to be split in several smaller files:
> - the role manager could search all "cocoon.roles" files present in the 
> classpath to build the main role manager
> - the root component manager could assemble all *.xconf files present in 
> WEB-INF.
> That way, a "block" (better named a "module") would be composed of a 
> xxx.jar containing a cocoon.roles snippet, and a xxx.xcconf configuring 
> that block's component definition. Adding/removing a module from Cocoon 
> would then simply a matter of moving around these two files.

Your ideas are worth to be investigated further! :-)
I'll comment on this by the end of the week in a separate thread

> 
>>  - reduce Cocoon core to a minimum
>>    to be done
>>
>>  - versioning guide
>>    done for Ccooon core; needs enhancements because of the more
>>    independant blocks and their own lifecycles
>>
>>  - rethink our distribution policy
>>    with the new block building system we can distribute Cocoon as 
>> binary again;
>>    we have to decide which blocks are part of an official Cocoon 
>> distribution
>>
>>  - new documentation system
>>    consider the efforts on users list and restructure the docs;
>>    separation of blocks also requires splitting up the docs
>>
>>
>> Could people knowing more about those points give some feedback?
>> Anything else open for 2.2?
>>
>>
>> So let's talk about a schedule ...
>> ----------------------------------
>> Many things are already done. Open issues that may take longer are:
>>
>>  - VirtualSitemapCompoents
>>  - stabelize cForms
>>  - new block building and deploying mechanism (+ transition see above)
>>  - docs
>>  - clean up
>>
>> The first three tasks have to be done before we can release a 
>> contract-stable
>> Cocoon 2.2 beta1. I plan to have implemented deployer and builder by 
>> the end of
>> January. Then we could release a beta1 in February ;-)  Is this a 
>> realistic
>> timeframe for others, especially those who work on cForms (Sylvain, 
>> Tim) and
>> virtualComponents (Vadim)?

Sylvain, as you are one of them knowing what we have to do to make cForms stable 
and implement virtual sitemap components, is this a realistic schedule (first 
contract stable beta in February 2005)?

>> Cocoon 2.3
>> ----------
>> To make it short: I want Cocoon 2.3 be based on whiteboard/kernel. 
>> AFAIK the
>> implementation of kernel is stable and "only" needs to be merged with 
>> ECM.
>>
>> Are there any reasons not to make Pier's kernel the official base of 
>> Cocoon 2.3? If not, Pier should have the "permission" to move its 
>> kernel into an offical 2.3 directory in  our SVN whenever he thinks 
>> it's time for it. (... I prepare a vote after the discussion)
> 
> If the kernel is stable, should it really be 2.3 or can it be 2.2?

I would say that we plan 2.2 without kernel and *if* Pier has finished the 
integration before we want to release our first 2.2beta (stable contracts!), we 
can talk again but we shouldn't bind us now to wait for it (I don't want to wait 
as long as we waited for 2.1).

Maybe I'm too pessimistic but if Pier integrates kernel and Cocoon 2.2 by the 
end of the year, it will take us another 5 month to be able to release a 
contract stable version.

Worst case would be that 2.3 follows 2.2 pretty soon ;-)
The drawback is that we would have different kind of blocks which would be 
incompatible to each other. But this is the same with Eclipse plugins too. 2.1 
plugins don't work in 3.0 or vice verca.

>> Cocoon 2.1
>> ----------
>> As being said, we expect further patch rleases (2.1.7 and 2.1.8), 
>> especially after cForms has become stable.
>>
>> release date of 2.1.7 (with or without a stable cForms block): 
>> February 2005?
> 
> Maybe earlier?

Why not! beginning of January?

-- 
Reinhard

Mime
View raw message