Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of simone.tripodi@gmail.com
 designates 209.85.213.179 as permitted sender)
MIME-Version: 1.0
Sender: simone.tripodi@gmail.com
In-Reply-To: <jb2vv5$6m3$1@dough.gmane.org>
References: <1322145959.4932.25.camel@mcKenny>
	<4ECF4E0D.2010200@apache.org>
	<1322213658.9894.6.camel@mcKenny>
	<4ED0FB57.3050204@apache.org>
	<1322351909.5218.14.camel@mcKenny>
	<jb2vv5$6m3$1@dough.gmane.org>
Date: Thu, 1 Dec 2011 21:47:53 +0100
Message-ID: 
 <CAAqLGLNrguBix5bUNqohBW3hOvYAPDXaUfT+5u9411GK==r3Lg@mail.gmail.com>
Subject: Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection
 in target of blocks]
From: Simone Tripodi <simonetripodi@apache.org>
To: dev@cocoon.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.

WDYT?
Many thanks in advance and sorry for the delay!
Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Tue, Nov 29, 2011 at 5:07 PM, Andreas Hartmann <andreas@apache.org> wrot=
e:
> Am 27.11.11 00:58, schrieb Thorsten Scherler:
>
>> On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiricc=C3=B2 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:
>>>>>
>>>>> =C2=A0 =C2=A0* cocoon-spring-configurator: think that I had to put re=
placement of
>>>>> Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2]
>>>>> =C2=A0 =C2=A0* cocoon-rcl-webapp-wrapper
>>>>> =C2=A0 =C2=A0* cocoon-xml: think that I had to put ParamSAXBuffer ext=
ending
>>>>> 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 an=
d
>>>> 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/
> =C2=A0cocoon-2.2/
> =C2=A0cocoon-3/
> =C2=A0=E2=80=A6
> subprojects/
> =C2=A0cocoon-jnet
> =C2=A0=E2=80=A6
>
> Of course this would imply that the subprojects have a well-defined API a=
nd
> functionality which is independent from any particular functionality in a=
ny
> of the Cocoon branches.
>
> -- Andreas
>
>
> --
> Andreas Hartmann, CTO
> BeCompany GmbH
> http://www.becompany.ch
> Tel.: +41 (0) 43 818 57 01
>