Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Francesco Chicchiriccò <ilgrosso <at> apache.org>
2012-01-03 08:47:54 GMT
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/
RSS Feed