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
