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/
