Francesco Chicchiriccò | 3 Jan 09:22 2012
Picon

Fwd: [jira] [Risolta] (INFRA-4261) Latest Cocoon-trunk builds fail with NPE

Now things should be working again...

-------- Original Message -------- Subject: Date: From: To:
[jira] [Risolta] (INFRA-4261) Latest Cocoon-trunk builds fail with NPE
Tue, 3 Jan 2012 08:08:21 +0000 (UTC)
Olivier Lamy (Resolved) (JIRA) <jira <at> apache.org>
ilgrosso <at> apache.org


/* Changing the layout to use less space for mobiles */ <at> media screen and (max-device-width: 480px), screen and (-webkit-min-device-pixel-ratio: 2) { #email-body { min-width: 30em !important; } #email-page { padding: 8px !important; } #email-banner { padding: 8px 8px 0 8px !important; } #email-avatar { margin: 1px 8px 8px 0 !important; padding: 0 !important; } #email-fields { padding: 0 8px 8px 8px !important; } #email-gutter { width: 0 !important; } }
Olivier Lamy resolved INFRA-4261 as Fixed

should be fixed with using a jenkins snapshot until 1.447 release
Change By: Olivier Lamy (03/Jan/12 08:06)
Risoluzione: Fixed
Assegnatario: Olivier Lamy
Stato: Open Resolved
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Francesco Chicchiriccò | 3 Jan 09:47 2012
Picon

Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]

On 31/12/2011 14:26, Francesco Chicchiriccò wrote:
> On 29/12/2011 12:02, Thorsten Scherler wrote:
>> On Sat, 2011-12-24 at 17:33 +0100, Francesco Chicchiriccò wrote:
>>> On 01/12/2011 21:47, Simone Tripodi wrote:
>>>> 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.
>>> Hi all,
>>> first of all, apologies for delay :-)
>>>
>>> Here it follows some results from my investigation of our current SVN
>>> repository ("from root to branches" someone would have said...) and
>>> also
>>> a proposal of mine for making things a bit easier to work with.
>>>
>>> I'll take the current structure at
>>> https://svn.apache.org/repos/asf/cocoon/ as reference and base URL.
>>>
>>> */branches/*
>>> Move current /trunk/ under here as BRANCH_2_2_X (similar to
>>> BRANCH_2_1_X
>>> and others, already present) so that any further activity on C2.2 can
>>> take place here.
>>>
>>> */cocoon3/*
>>> Move /cocoon3/trunk as /trunk/ (Simone restructuring as presented above
>>> will take place here) and /cocoon3/tags/** under /tags, possibly
>>> refactoring paths like as
>>> /cocoon3/tags/cocoon-archetype-block/cocoon-archetype-block-3.0.0-alpha-3/
>>>
>>> to simpler /tags/cocoon-archetype-block-3.0.0-alpha-3/
>>>
>>> */site/*
>>> Merge this with current /cocoon3/trunk/cocoon-docs
>>>
>>> */tags/*
>>> As said above for /cocoon3, move /cocoon3/tags/* here, possibly
>>> refactoring paths
>>>
>>> */trunk/*
>>> As said above for /cocoon3, move /cocoon3/trunk/* here.
>>> Then, copy current trunk/subprojects/ (i.e.
>>> /branches/BRANCH_2_2_X/subprojects/ after refactoring):
>>> cocoon-block-deployment/
>>> cocoon-configuration/
>>> cocoon-jnet/
>>> cocoon-servlet-service/
>>> cocoon-xml/
>>> Next, copy some modules from current trunk/tools/ (i.e.
>>> /branches/BRANCH_2_2_X/tools/ after refactoring):
>>> cocoon-it-fw/
>>> cocoon-maven-plugin/
>>> cocoon-rcl/
>>> Finally, copy from current trunk/blocks/cocoon-serializers/ (i.e.
>>> /branches/BRANCH_2_2_X/blocks/cocoon-serializers/ after refactoring):
>>> cocoon-serializers-charsets/
>>>
>>> All modules involved with C3 should have now their places under
>>> /trunk/subprojects/ or /trunk/tools. If there is any module missing
>>> please let me know.
>>>
>>> We will need, of course, to adapt all pom.xml's for working in the
>>> new structure.
>>>
>>> WDYT?
>> Not 100% sure.
>>
>> ATM we have:
>>
>>    * branches/
>>    * cocoon3/
>>    * site/
>>    * tags/
>>    * trunk/
>>    * whiteboard/
>>
>> Which IMO should become:
>> branches/ (2.X)
>> site/
>> tags/
>> trunk/ (cocoon3/)
>> whiteboard/
>> subprojects/
>> tools/
>>
>> Where within subproject/tools we would apply the branches|tags|trunk
>> structure. This way we can have a tag/branch for e.g. the
>> cocoon-spring-configurator for the 2.2 deps and sub-trunk against our
>> main-trunk. Further that would allow us to extract common code to a
>> module in tools/subproject. Makes sense?
>
> Yes, it does, indeed ;-)
> Fine for me.
>
>> Regarding site see David comment. The main problem here is that we
>> have a wide range of build tools which originally build our docu
>> (mainly forrest till now). However I am uncertain how we can manage
>> the docu for the different versions.
>
> I would say to just keep safe copy of legacy stuff and find a way to
> put here also current /cocoon3/trunk/cocoon-docs.
>
> Anyway, when would you like this re-organization to take place? I have
> personally nothing against starting ASAP; it would help if we can make
> some sort of live teamwork (gtalk? skype?) here because as fas as it
> seems it would imply quite a nice amount of work, and very risky work ;-)

Hi all,
since there seems to be no objections against this reviewed proposal so
far, I'll start drafting out the actual reorganization following the
guidelines defined above.

I would still be glad if anyone is willing to join me in a live session
for fixing all details involved (pom changes, JIRA, Sonar, Jenkins,
Sonatype, ...).

Anyway, because of the effects of such reorganizations, I'll ask here
for confirmation before committing.

Regards.

--

-- 
Francesco Chicchiriccò

Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/

Francesco Chicchiriccò | 3 Jan 10:28 2012
Picon

JIRA "unification" proposal

Hi devs,
as you all know, you currently have two separate projects on Apache JIRA, COCOON and COCOON3.

Since there is currently a plan for restructuring the SVN tree [1], what if we unify these two projects on JIRA as well?
AFAIK, this should involve:
1. create new versions and components on COCOON
2. move all tickets from COCOON3 to COCOON
3. close COCOON3

WDYT?

Regards.

[1] http://old.nabble.com/Re%3A--C3--Import-subprojects-proposal--WAS%3A-Re%3A--c3--Log4j-injection-in-target-of-blocks--td32880500.html
-- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Francesco Chicchiriccò | 3 Jan 10:41 2012
Picon

[C3] cocoon-sample / cocoon-archetype-block and rcl

Hi devs,
cocoon-sample and cocoon-archetype-block do use cocoon-maven-plugin to prepare and deploy a block to a local jetty, featuring some class reloading feature.

It could be an idea to remove cocoon-maven-plugin and profit from class reloading features of Tomcat 7 [1] (for instance) with support of Cargo for managing and configuring Tomcat instance.

We may, of course, continue (actually, start again) support for cocoon-maven-plugin. but I have more a feeling that we could better concentrate on C3 development, instead.

WDYT?

Regards.

[1] http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#Common_Attributes
[2] http://cargo.codehaus.org/Tomcat+7.x -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Thorsten Scherler | 3 Jan 11:35 2012
Picon

Re: svn commit: r1226702 - /cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/TextSerializerTest.java

Upps, sorry!

I need to configure my eclipse workspace!

salu2
On Tue, 2012-01-03 at 08:26 +0000, ilgrosso <at> apache.org wrote:
> Author: ilgrosso
> Date: Tue Jan  3 08:26:19 2012
> New Revision: 1226702
> 
> URL: http://svn.apache.org/viewvc?rev=1226702&view=rev
> Log:
> Missing license header: rat plugin was failing
> 
> Modified:
>     cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/TextSerializerTest.java
> 
> Modified: cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/TextSerializerTest.java
> URL: http://svn.apache.org/viewvc/cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/TextSerializerTest.java?rev=1226702&r1=1226701&r2=1226702&view=diff
> ==============================================================================
> ---
cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/TextSerializerTest.java (original)
> +++
cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/TextSerializerTest.java
Tue Jan  3 08:26:19 2012
>  <at>  <at>  -1,3 +1,19  <at>  <at> 
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *     http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
>  package org.apache.cocoon.sax.component;
>  
>  import java.io.ByteArrayOutputStream;
> 
> 

--

-- 
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/

Thorsten Scherler | 3 Jan 11:45 2012
Picon

Re: [C3] cocoon-sample / cocoon-archetype-block and rcl

On Tue, 2012-01-03 at 10:41 +0100, Francesco Chicchiriccò wrote:
> Hi devs,
> cocoon-sample and cocoon-archetype-block do use cocoon-maven-plugin to
> prepare and deploy a block to a local jetty, featuring some class
> reloading feature.
> 
> It could be an idea to remove cocoon-maven-plugin and profit from
> class reloading features of Tomcat 7 [1] (for instance) with support
> of Cargo for managing and configuring Tomcat instance.
> 
> We may, of course, continue (actually, start again) support for
> cocoon-maven-plugin. but I have more a feeling that we could better
> concentrate on C3 development, instead.
> 
> WDYT?
> 

Actually I think Igor has made a cut on the rcl using spring rcl
instead. I would rather not force to use tomcat and bound us there.
However if we can extract Igors work in this area I would be +1 to drop
our own stuff in favor for spring.

salu2

> Regards.
> 
> [1]
> http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html#Common_Attributes
> [2] http://cargo.codehaus.org/Tomcat+7.x 
> -- 
> Francesco Chicchiriccò
> 
> Apache Cocoon Committer and PMC Member
> http://people.apache.org/~ilgrosso/

--

-- 
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/

Jasha Joachimsthal | 3 Jan 11:59 2012

Re: JIRA "unification" proposal

Merging those projects is good, but only if we clean up COCOON. There is a long list of issues with patches (there used to be a weekly mail with them) and an even longer list of unresolved issues. If we keep these issues open, it will be harder to see what we're working on and what we're dragging with us for years. IMO we can close the 2.1 and 2.2 issues that were created in 2010 or earlier with resolution "won't fix". They can always be reopened (or re-created) when someone is actually going to work on them.

 
Jasha Joachimsthal

Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)

www.onehippo.com



2012/1/3 Francesco Chicchiriccò <ilgrosso <at> apache.org>
Hi devs,
as you all know, you currently have two separate projects on Apache JIRA, COCOON and COCOON3.

Since there is currently a plan for restructuring the SVN tree [1], what if we unify these two projects on JIRA as well?
AFAIK, this should involve:
1. create new versions and components on COCOON
2. move all tickets from COCOON3 to COCOON
3. close COCOON3

WDYT?

Regards.

[1] http://old.nabble.com/Re%3A--C3--Import-subprojects-proposal--WAS%3A-Re%3A--c3--Log4j-injection-in-target-of-blocks--td32880500.html
-- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/

Thorsten Scherler | 3 Jan 12:00 2012
Picon

Community day for cleanup (was Re: [C3] Import subprojects proposal)

On Tue, 2012-01-03 at 09:47 +0100, Francesco Chicchiriccò wrote:
...
> 
> Hi all,
> since there seems to be no objections against this reviewed proposal so
> far, I'll start drafting out the actual reorganization following the
> guidelines defined above.
> 
> I would still be glad if anyone is willing to join me in a live session
> for fixing all details involved (pom changes, JIRA, Sonar, Jenkins,
> Sonatype, ...).
> 
> Anyway, because of the effects of such reorganizations, I'll ask here
> for confirmation before committing.

Yeah, I think we should be at least 3-5 committer with enough rights in
the different parts to update and a couple of devs to do the hot
testing.

Formally we had a community day where we meet on IRC (with bot which
committed the chat to a svn file, to make the work transparent for the
whole community). 

So who is up for a community day for spring cleaning of the project?

Which day best fits?

salu2
--

-- 
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/

Francesco Chicchiriccò | 3 Jan 12:15 2012
Picon

Re: Community day for cleanup (was Re: [C3] Import subprojects proposal)

On 03/01/2012 12:00, Thorsten Scherler wrote:
> On Tue, 2012-01-03 at 09:47 +0100, Francesco Chicchiriccò wrote:
> ...
>> Hi all,
>> since there seems to be no objections against this reviewed proposal so
>> far, I'll start drafting out the actual reorganization following the
>> guidelines defined above.
>>
>> I would still be glad if anyone is willing to join me in a live session
>> for fixing all details involved (pom changes, JIRA, Sonar, Jenkins,
>> Sonatype, ...).
>>
>> Anyway, because of the effects of such reorganizations, I'll ask here
>> for confirmation before committing.
> Yeah, I think we should be at least 3-5 committer with enough rights in
> the different parts to update and a couple of devs to do the hot
> testing.
>
> Formally we had a community day where we meet on IRC (with bot which
> committed the chat to a svn file, to make the work transparent for the
> whole community). 

Wow, I did not know this. It sounds very nice.

> So who is up for a community day for spring cleaning of the project?

Of course I am :-)

> Which day best fits?

I'd prefer this week or possibly early next week.

Regards.

--

-- 
Francesco Chicchiriccò

Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/

Cédric Damioli | 3 Jan 12:18 2012

Re: JIRA "unification" proposal

Hi,

I will actually work soon on 2.1 issues (at least those I've opened). I also want to have a look to all existing 2.1 issues, to measure the distance to an eventual 2.1.12 release in a near future. So please don't close all 2.1 entries right now.

It is IMHO a good thing to merge the two JIRA projects, but we should take care to the various components spread accross different versions. Cocoon 2.1 blocks are for instance a non sense for Cocoon 3, as well as Cocoon 3 components does not mean anything for Cocoon 2.x
We could maybe rename such components with a prefix indicating their version ?

Cédric

Le 03/01/2012 11:59, Jasha Joachimsthal a écrit :
Merging those projects is good, but only if we clean up COCOON. There is a long list of issues with patches (there used to be a weekly mail with them) and an even longer list of unresolved issues. If we keep these issues open, it will be harder to see what we're working on and what we're dragging with us for years. IMO we can close the 2.1 and 2.2 issues that were created in 2010 or earlier with resolution "won't fix". They can always be reopened (or re-created) when someone is actually going to work on them.
 
Jasha Joachimsthal

Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466
US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free)

www.onehippo.com



2012/1/3 Francesco Chicchiriccò <ilgrosso <at> apache.org>
Hi devs,
as you all know, you currently have two separate projects on Apache JIRA, COCOON and COCOON3.

Since there is currently a plan for restructuring the SVN tree [1], what if we unify these two projects on JIRA as well?
AFAIK, this should involve:
1. create new versions and components on COCOON
2. move all tickets from COCOON3 to COCOON
3. close COCOON3

WDYT?

Regards.

[1] http://old.nabble.com/Re%3A--C3--Import-subprojects-proposal--WAS%3A-Re%3A--c3--Log4j-injection-in-target-of-blocks--td32880500.html
-- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/


--
a:link{text-decoration:underline;color:#1768B0;} a:visited{text-decoration:underline;color:#1768B0;} a:hover{text-decoration:underline;color:#1768B0;}

www.anyware-services.com

Inscrivez-vous à notre newsletter

Cédric Damioli
Directeur technique
cedric.damioli <at> anyware-services.com
Tel : +33(0)5 62 19 19 07
Mob : +33(0)6 87 03 61 63
Fax : +33(0)5 61 75 84 12
Adresse : Innopole 13 - 254 avenue de l'Occitane - B.P 97672 - 31676 LABEGE CEDEX - France

Ametys: Smart Web CMS
www.ametys.org
Ce message et toutes les pièces jointes (le "Message") sont confidentiels et établis à l'intention exclusive de ses destinataires.
Toute modification, édition, utilisation ou diffusion non autorisée est interdite.
Anyware Services décline toute responsabilité au titre de ce Message s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation.

Gmane