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 scherler@gmail.com designates
 209.85.216.44 as permitted sender)
Message-ID: <1325156570.11045.15.camel@mcKenny>
Subject: Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection
 in target of blocks]
From: Thorsten Scherler <scherler@gmail.com>
To: dev@cocoon.apache.org
Date: Thu, 29 Dec 2011 12:02:50 +0100
In-Reply-To: <4EF5FECB.4080503@apache.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>
	 <CAAqLGLNrguBix5bUNqohBW3hOvYAPDXaUfT+5u9411GK==r3Lg@mail.gmail.com>
	 <4EF5FECB.4080503@apache.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Mime-Version: 1.0

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/