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 Thu, 29 Dec 2011 11:02:50 GMT
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.

Not 100% sure.

ATM we have:

      * branches/
  * cocoon3/
  * site/
  * tags/
  * trunk/
  * whiteboard/

Which IMO should become:
branches/ (2.X)
trunk/ (cocoon3/)

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?

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.

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

View raw message