cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <>
Subject Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Date Sat, 31 Dec 2011 13:26:38 GMT
On 29/12/2011 12:02, Thorsten Scherler wrote:
> On Sat, 2011-12-24 at 17:33 +0100, Francesco Chicchiriccò wrote:
>> On 01/12/2011 21:47, Simone Tripodi wrote:
>>> 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.
>> Hi all,
>> first of all, apologies for delay :-)
>> Here it follows some results from my investigation of our current SVN
>> repository ("from root to branches" someone would have said...) and also
>> a proposal of mine for making things a bit easier to work with.
>> I'll take the current structure at
>> as reference and base URL.
>> */branches/*
>> Move current /trunk/ under here as BRANCH_2_2_X (similar to BRANCH_2_1_X
>> and others, already present) so that any further activity on C2.2 can
>> take place here.
>> */cocoon3/*
>> Move /cocoon3/trunk as /trunk/ (Simone restructuring as presented above
>> will take place here) and /cocoon3/tags/** under /tags, possibly
>> refactoring paths like as
>> /cocoon3/tags/cocoon-archetype-block/cocoon-archetype-block-3.0.0-alpha-3/
>> to simpler /tags/cocoon-archetype-block-3.0.0-alpha-3/
>> */site/*
>> Merge this with current /cocoon3/trunk/cocoon-docs
>> */tags/*
>> As said above for /cocoon3, move /cocoon3/tags/* here, possibly
>> refactoring paths
>> */trunk/*
>> As said above for /cocoon3, move /cocoon3/trunk/* here.
>> Then, copy current trunk/subprojects/ (i.e.
>> /branches/BRANCH_2_2_X/subprojects/ after refactoring):
>> cocoon-block-deployment/
>> cocoon-configuration/
>> cocoon-jnet/
>> cocoon-servlet-service/
>> cocoon-xml/
>> Next, copy some modules from current trunk/tools/ (i.e.
>> /branches/BRANCH_2_2_X/tools/ after refactoring):
>> cocoon-it-fw/
>> cocoon-maven-plugin/
>> cocoon-rcl/
>> Finally, copy from current trunk/blocks/cocoon-serializers/ (i.e. /branches/BRANCH_2_2_X/blocks/cocoon-serializers/
after refactoring):
>> cocoon-serializers-charsets/
>> All modules involved with C3 should have now their places under /trunk/subprojects/
or /trunk/tools. If there is any module missing please let me know.
>> We will need, of course, to adapt all pom.xml's for working in the new structure.
>> WDYT?
> Not 100% sure.
> ATM we have:
>    * branches/
>    * cocoon3/
>    * site/
>    * tags/
>    * trunk/
>    * whiteboard/
> Which IMO should become:
> branches/ (2.X)
> site/
> tags/
> trunk/ (cocoon3/)
> whiteboard/
> subprojects/
> tools/
> Where within subproject/tools we would apply the branches|tags|trunk structure. This
way we can have a tag/branch for e.g. the cocoon-spring-configurator for the 2.2 deps and
sub-trunk against our main-trunk. Further that would allow us to extract common code to a
module in tools/subproject. Makes sense?

Yes, it does, indeed ;-)
Fine for me.

> Regarding site see David comment. The main problem here is that we have a wide range
of build tools which originally build our docu (mainly forrest till now). However I am uncertain
how we can manage the docu for the different versions.

I would say to just keep safe copy of legacy stuff and find a way to put 
here also current /cocoon3/trunk/cocoon-docs.

Anyway, when would you like this re-organization to take place? I have 
personally nothing against starting ASAP; it would help if we can make 
some sort of live teamwork (gtalk? skype?) here because as fas as it 
seems it would imply quite a nice amount of work, and very risky work ;-)


Francesco Chicchiriccò

Apache Cocoon Committer and PMC Member

View raw message