Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
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
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
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 ;-) Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
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/
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Francesco Chicchiriccò wrote: */site/* Merge this with current /cocoon3/trunk/cocoon-docs I reckon that this site stuff should just stay where it is. The */site/site/* is the current generated docs for the various versions and the top-level. This is an SVN checkout on the people.apache.org machine at /www/cocoon.apache.org/ The */site/* remainder is the old source docs for the top-level. -David
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
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? -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
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. WDYT? Many thanks in advance and sorry for the delay! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Nov 29, 2011 at 5:07 PM, Andreas Hartmann andr...@apache.org wrote: Am 27.11.11 00:58, schrieb Thorsten Scherler: On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote: On 25/11/2011 10:34, Thorsten Scherler wrote: [...] Unfortunately, there are quite some dependencies that I guess were initially thought for C2.2, then used for C3 and now getting old like as: * cocoon-spring-configurator: think that I had to put replacement of Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2] * cocoon-rcl-webapp-wrapper * cocoon-xml: think that I had to put ParamSAXBuffer extending SAXBuffer in cocoon-sax [3] I think we should decide how to cope with this. IMO we should either create a new version of them only compatible with c3 or update c2.2. IMO All above mentioned should have new versions and work with c3. What if we just make some nice svn copy of above mentioned cocoon subprojects (and more: servlet-service, for example), as cocoon3 modules? Then we can start updating their POMs and possibly adding / extending source code, and making C3 parent POM pointing to these. I do not see a problem with that, but they do not need to become modules IMO. We can update/maintain them where they are under a new release version. IMO the current SVN structure is not really transparent. Trunk (2.2) and cocoon3/trunk are conflicting versions. Maybe the following would make sense? branches/ cocoon-2.2/ cocoon-3/ … subprojects/ cocoon-jnet … Of course this would imply that the subprojects have a well-defined API and functionality which is independent from any particular functionality in any of the Cocoon branches. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
On 27/11/2011 00:58, Thorsten Scherler wrote: On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote: On 25/11/2011 10:34, Thorsten Scherler wrote: [...] Unfortunately, there are quite some dependencies that I guess were initially thought for C2.2, then used for C3 and now getting old like as: * cocoon-spring-configurator: think that I had to put replacement of Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2] * cocoon-rcl-webapp-wrapper * cocoon-xml: think that I had to put ParamSAXBuffer extending SAXBuffer in cocoon-sax [3] I think we should decide how to cope with this. IMO we should either create a new version of them only compatible with c3 or update c2.2. IMO All above mentioned should have new versions and work with c3. What if we just make some nice svn copy of above mentioned cocoon subprojects (and more: servlet-service, for example), as cocoon3 modules? Then we can start updating their POMs and possibly adding / extending source code, and making C3 parent POM pointing to these. I do not see a problem with that, but they do not need to become modules IMO. We can update/maintain them where they are under a new release version. In this way we would easily manage everything in one place - including Sonar, JIRA, Jenkins and Maven artifacts. Actually I really dislike that we have two different instance of jira for cocoon. IMO one is more then enough. So having one for our project and all our components would not force us to move them. Further in the end ALL our codebase (2.1 and 2.2 incl.) is our concern as project. We need to find time to apply patches not only for c3. For example I am ATM basing a big project on c3 but we have as well 2.2 and 2.1 based projects in maintenance so like me we have devs that are using cocoon in the different versions. We as project should concern about them. Of course, we would loose the separation among Cocoon own stuff and Cocoon stuff that can be used even when not using Cocoon: do you retain such distinction still necessary, these days? Actually cocoon spring configurator is a nice peace of standalone code and if we do not need to have deps on c3 modules we should not enforce that components can only be used in conjunction with c3. The less deps cocoon and any of its modules has the better. In general I am for svn cp and create a new version. Well, at the moment the components named above (but others are missing: cocoon-jnet, for example) are spread across different folders in svn repository, so an idea could be to define a subfolder of /trunk (say 'subprojects') and start svn cp-ing all of such components under /trunk/subprojects. Then we would need some INFRA tasks like as: * add (when needed) all of these as components in JIRA (under COCOON or COOON3?) * add to Sonar * add to Jenkins (including SNAPSHOT maven artifact deployment) * .. Can you prepare a vote, please? Hum, I am not sure whether this issue is mature for voting: I'd rather understand what exactly has to be put on vote: anyone else interested on this topic? -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Am 27.11.11 00:58, schrieb Thorsten Scherler: On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote: On 25/11/2011 10:34, Thorsten Scherler wrote: [...] Unfortunately, there are quite some dependencies that I guess were initially thought for C2.2, then used for C3 and now getting old like as: * cocoon-spring-configurator: think that I had to put replacement of Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2] * cocoon-rcl-webapp-wrapper * cocoon-xml: think that I had to put ParamSAXBuffer extending SAXBuffer in cocoon-sax [3] I think we should decide how to cope with this. IMO we should either create a new version of them only compatible with c3 or update c2.2. IMO All above mentioned should have new versions and work with c3. What if we just make some nice svn copy of above mentioned cocoon subprojects (and more: servlet-service, for example), as cocoon3 modules? Then we can start updating their POMs and possibly adding / extending source code, and making C3 parent POM pointing to these. I do not see a problem with that, but they do not need to become modules IMO. We can update/maintain them where they are under a new release version. IMO the current SVN structure is not really transparent. Trunk (2.2) and cocoon3/trunk are conflicting versions. Maybe the following would make sense? branches/ cocoon-2.2/ cocoon-3/ … subprojects/ cocoon-jnet … Of course this would imply that the subprojects have a well-defined API and functionality which is independent from any particular functionality in any of the Cocoon branches. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote: On 25/11/2011 10:34, Thorsten Scherler wrote: [...] Unfortunately, there are quite some dependencies that I guess were initially thought for C2.2, then used for C3 and now getting old like as: * cocoon-spring-configurator: think that I had to put replacement of Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2] * cocoon-rcl-webapp-wrapper * cocoon-xml: think that I had to put ParamSAXBuffer extending SAXBuffer in cocoon-sax [3] I think we should decide how to cope with this. IMO we should either create a new version of them only compatible with c3 or update c2.2. IMO All above mentioned should have new versions and work with c3. What if we just make some nice svn copy of above mentioned cocoon subprojects (and more: servlet-service, for example), as cocoon3 modules? Then we can start updating their POMs and possibly adding / extending source code, and making C3 parent POM pointing to these. I do not see a problem with that, but they do not need to become modules IMO. We can update/maintain them where they are under a new release version. In this way we would easily manage everything in one place - including Sonar, JIRA, Jenkins and Maven artifacts. Actually I really dislike that we have two different instance of jira for cocoon. IMO one is more then enough. So having one for our project and all our components would not force us to move them. Further in the end ALL our codebase (2.1 and 2.2 incl.) is our concern as project. We need to find time to apply patches not only for c3. For example I am ATM basing a big project on c3 but we have as well 2.2 and 2.1 based projects in maintenance so like me we have devs that are using cocoon in the different versions. We as project should concern about them. Of course, we would loose the separation among Cocoon own stuff and Cocoon stuff that can be used even when not using Cocoon: do you retain such distinction still necessary, these days? Actually cocoon spring configurator is a nice peace of standalone code and if we do not need to have deps on c3 modules we should not enforce that components can only be used in conjunction with c3. The less deps cocoon and any of its modules has the better. In general I am for svn cp and create a new version. Can you prepare a vote, please? salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
