On 31/12/2011 14:26, Francesco Chicchiriccò wrote:
> 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
>>> 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?
>
> 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 ;-)
Hi all,
since there seems to be no objections against this reviewed proposal so
far, I'll start drafting out the actual reorganization following the
guidelines defined above.
I would still be glad if anyone is willing to join me in a live session
for fixing all details involved (pom changes, JIRA, Sonar, Jenkins,
Sonatype, ...).
Anyway, because of the effects of such reorganizations, I'll ask here
for confirmation before committing.
Regards.
--
Francesco Chicchiriccò
Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/
