cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francesco Chicchiriccò <ilgro...@apache.org>
Subject Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Date Tue, 29 Nov 2011 08:54:22 GMT
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/


Mime
View raw message