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
> https://svn.apache.org/repos/asf/cocoon/ 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?
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.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
