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 >
