cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Date Thu, 01 Dec 2011 20:47:53 GMT
Hi all guys!

Apologies for the lack of participations but looks like contributing
in more ASF communities requires a lot of time! :)

My position are:

* +1 on migrating old components - that's true that we could maintain
them in their proper branch, but at the same time they would need an
update to be more compliant with C3 - moreover, since we agreed on
migrating to Java6, it would worth started getting advantage from the
new platform - that would imply "subprojects" actualization.

* +1 on restructuring the svn, I would like to restructure anyway the
C3 first: IMHO having all the modules in a flat structures starts
being a little confusing, even to me that I'm involved, I would
suggest to move to a different hierarchical structure, grouping
modules by technology/extension type/application type.
Moreover IMHO the 'optional' module should be split, it contains now a
lot of good reusable - more that at the begin - stuff that we could
consider as a collection of modules.
Of course, we have to pay attention to not overengineering.
I would suggest as well to open a Sandbox open to all ASF committers
to experiment new modules.

My proposal is considering the two topics separately, I would like
Francesco lead the topic #1, I can prepare during the weekend a
proposal on how to restructure the SVN.

Many thanks in advance and sorry for the delay!

On Tue, Nov 29, 2011 at 5:07 PM, Andreas Hartmann <> wrote:
> Am 27.11.11 00:58, schrieb Thorsten Scherler:
>> 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
>>>>> 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
>> version.
> IMO the current SVN structure is not really transparent. Trunk (2.2) and
> cocoon3/trunk are conflicting versions. Maybe the following would make
> sense?
> branches/
>  cocoon-2.2/
>  cocoon-3/
>  …
> subprojects/
>  cocoon-jnet
>  …
> Of course this would imply that the subprojects have a well-defined API and
> functionality which is independent from any particular functionality in any
> of the Cocoon branches.
> -- Andreas
> --
> Andreas Hartmann, CTO
> BeCompany GmbH
> Tel.: +41 (0) 43 818 57 01

View raw message