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/
