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/