cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Date Sat, 26 Nov 2011 23:58:29 GMT
On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote:
> On 25/11/2011 10:34, Thorsten Scherler wrote:
> > [...]
> >> Unfortunately, there are quite some dependencies that I guess were
> >> initially thought for C2.2, then used for C3 and now getting old like as:
> >>
> >>    * cocoon-spring-configurator: think that I had to put replacement of
> >> Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2]
> >>    * cocoon-rcl-webapp-wrapper
> >>    * cocoon-xml: think that I had to put ParamSAXBuffer extending
> >> SAXBuffer in cocoon-sax [3]
> >>
> >> I think we should decide how to cope with this.
> > IMO we should either create a new version of them only compatible with
> > c3 or update c2.2. IMO All above mentioned should have new versions and
> > work with c3.
> What if we just make some nice "svn copy" of above mentioned cocoon 
> subprojects (and more: servlet-service, for example), as cocoon3 
> modules? Then we can start updating their POMs and possibly adding / 
> extending source code, and making C3 parent POM pointing to these.

I do not see a problem with that, but they do not need to become modules
IMO. We can update/maintain them where they are under a new release

> In this way we would easily manage everything in one place - including 
> Sonar, JIRA, Jenkins and Maven artifacts.

Actually I really dislike that we have two different instance of jira
for cocoon. IMO one is more then enough. So having one for our project
and all our components would not force us to move them. Further in the
end ALL our codebase (2.1 and 2.2 incl.) is our concern as project. 

We need to find time to apply patches not only for c3. For example I am
ATM basing a big project on c3 but we have as well 2.2 and 2.1 based
projects in maintenance so like me we have devs that are using cocoon in
the different versions. We as project should concern about them.

> Of course, we would loose the separation among Cocoon "own stuff" and 
> Cocoon "stuff that can be used even when not using Cocoon": do you 
> retain such distinction still necessary, these days?

Actually cocoon spring configurator is a nice peace of standalone code
and if we do not need to have deps on c3 modules we should not enforce
that components can only be used in conjunction with c3. The less deps
cocoon and any of its modules has the better.

In general I am for 

svn cp 

and create a new version.

Can you prepare a vote, please?

Thorsten Scherler <>
codeBusters S.L. - web based systems
<consulting, training and solutions>

View raw message