date:20080730


David Crossley wrote:

I propose Thorsten Scherler as a new Cocoon committer
and PMC member.

Thorsten already has commit access to Cocoon by virtue
of being a committer at Apache Lenya and Apache Forrest.

This will formalise his status at Cocoon and enable
him to be a PMC member.

Thorsten has been participating at the Cocoon dev and users
mail lists since late 2002. He has recently been making
some docs edits and participating in dev discussions and
making suggestions for improvements and providing some
patches.

http://cocoon.markmail.org/search/?q=scherler

Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04

So please cast your votes.

-David


+1 and welcome

--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.

Re: [Vote] Jasha Joachimsthal as new Cocoon committer


Andrew Savory wrote:

Hi,

It's my pleasure to propose Jasha Joachimsthal as a new committer on
the Apache Cocoon project.

Jasha has been active on the Cocoon mailing lists since the start of
2006 (http://cocoon.markmail.org/search/?q=Joachimsthal). He has
contributed extensively on the user list and do the dev list. He has
also done a talk on Cocoon at Apachecon EU and at the Cocoon
GetTogether. During his work at Hippo he has become an expert on all
things Cocoon!  I believe he would make an excellent addition to the
project.

Please cast your votes.

Here's mine: +1.


Andrew.
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
http://www.andrewsavory.com/


+1 and welcome

--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.

Re: [vote] Andreas Hartmann as new Cocoon committer


David Crossley wrote:

I propose Andreas Hartmann as a new Cocoon committer
and PMC member.

Andreas already has commit access to Cocoon by virtue 
of being a committer at Apache Lenya.


This will formalise his status at Cocoon and enable
him to be a PMC member.

Andreas has been participating at the Cocoon dev and users
mail lists since late 2001. He has recently been participating
in dev discussions and providing comments to issues and
some patches.

http://cocoon.markmail.org/search/?q=hartmann

Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04

So please cast your votes.

-David


+1 and welcome

--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.

Re: [vote] Luca Morandini as new Cocoon committer


David Crossley wrote:

I would like to propose Luca Morandini as a new Cocoon committer
and PMC member.

Luca participates at the Cocoon dev and users mail lists
since 2001, being more active again recently.

http://cocoon.markmail.org/search/?q=morandini
shows that there are many contributions to the lists
and to code and docs.

He also uses Cocoon as part of the Fins and Geoid
projects.

Voting ends one week from today, i.e. midnight UTC on Monday 2008-08-04

So please cast your votes.

-David


+1 and welcome

--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.

[jira] Closed: (COCOON-1835) Deployment bundle


 [ 
https://issues.apache.org/jira/browse/COCOON-1835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz closed COCOON-1835.
--

Resolution: Won't Fix

> Deployment bundle
> -
>
> Key: COCOON-1835
> URL: https://issues.apache.org/jira/browse/COCOON-1835
> Project: Cocoon
>  Issue Type: New Feature
>  Components: - OSGi integration
>Reporter: Reinhard Poetz
>Assignee: Reinhard Poetz
>
> Write a bundle that can install, start, update and stop Cocoon blocks. It is 
> configured by a deployment descriptor.
> Internally it works based on the OSGi configuration service.
> Some notes:
> - go through the tutorial of PDE development in "Eclipse Rich Client Platform"
> - read Jeff McAffer on [EMAIL PROTECTED]: Installing bundles by reference 
> (Feb 2006)
> - make it configureable which bundles you want to install
>   a) create an OSGi application
>   b) create a WAR file that internally uses OSGi
> - make the deployer check if all contracts are fullfilled (mail on [EMAIL 
> PROTECTED] by Jeff McAffer, 30th of August)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (COCOON-1827) Howto: How to get OSGi-based Cocoon running?


 [ 
https://issues.apache.org/jira/browse/COCOON-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz closed COCOON-1827.
--

Resolution: Won't Fix

> Howto: How to get OSGi-based Cocoon running?
> 
>
> Key: COCOON-1827
> URL: https://issues.apache.org/jira/browse/COCOON-1827
> Project: Cocoon
>  Issue Type: Sub-task
>  Components: - OSGi integration
>Reporter: Reinhard Poetz
>Assignee: Reinhard Poetz
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (COCOON-1828) Tutorial: Rewrite the blocks tutorials


 [ 
https://issues.apache.org/jira/browse/COCOON-1828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz closed COCOON-1828.
--

Resolution: Fixed

done in the meantime

> Tutorial: Rewrite the blocks tutorials
> --
>
> Key: COCOON-1828
> URL: https://issues.apache.org/jira/browse/COCOON-1828
> Project: Cocoon
>  Issue Type: Sub-task
>  Components: - OSGi integration
>Reporter: Reinhard Poetz
>Assignee: Reinhard Poetz
>
> - developing a block (using Maven 2 and Eclipse)
> - assemble blocks using Maven 2 and the deployer

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (COCOON-1834) Integrate OSGi extensions into build system


 [ 
https://issues.apache.org/jira/browse/COCOON-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz closed COCOON-1834.
--

Resolution: Won't Fix

> Integrate OSGi extensions into build system
> ---
>
> Key: COCOON-1834
> URL: https://issues.apache.org/jira/browse/COCOON-1834
> Project: Cocoon
>  Issue Type: New Feature
>  Components: - OSGi integration
>Reporter: Reinhard Poetz
>Assignee: Reinhard Poetz
>
> Make Cocoon block artifacts valid OSGi bundles at build time (of course using 
> Maven 2)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [vote] Luca Morandini as new Cocoon committer

2008-07-30 Thread Luca Morandini


Vadim Gritsenko wrote:

On Jul 29, 2008, at 1:33 PM, Luca Morandini wrote:

Besides, I've heard Apache committers have special discounts on the 
entire Mercedes-Benz range of models... what ? That was just a joke ? 
Oh my... :(


You do get a discount on ApacheCon... 


It's not *exactly* the same thing :|



See you in New Orleans?


Hmm... enticing, but I'm inclined to answer in the negative: in November 
I will be utterly busy renovating my new home... moreover, 
Washington-New Orleans it's 4cm, while Rome-New Orleans it's an 
eye-popping 18cm... measured on my kids's globe, that is ;)


Regards,


   Luca Morandini
www.lucamorandini.it

Re: Find a new name for Corona

2008-07-30 Thread Luca Morandini


Bertrand Delacretaz wrote:


If that's the plan (and I like it), why not keep the "project Corona"
name for now?

That would be just a project name, not a product name, so we don't
need to care about conflicts, the full name would be "Apache Cocoon -
project Corona".


In my, very humble, opinion, this makes a lot of sense.

Moreover, I like the Corona name: it was the codename for the first 
family of spy satellites (actually, it was spelled "project CORONA", in 
uppercase)... quite an endeavor at the time [1].


Regards,

[1] http://en.wikipedia.org/wiki/Corona_(satellite)


   Luca Morandini
www.lucamorandini.it

Re: Can somebody explain to me the tags / POM versioning / release scheme?

2008-07-30 Thread Mark Lundquist



On Jul 30, 2008, at 1:23 AM, Grzegorz Kossakowski wrote:

Any chance for you to create a similar page documenting your new  
approach? I'm sure that there would be a people benefiting from a  
nice cook-book document.


Gladly.  Once I get it worked out, I'll document it (maybe Daisy would  
be the place for that).



[...snip]
Interesting. I'm not sure but when we have discussed Git advantages  
over svn on infrastructure lists that point has not been discussed.


Even if only for that purpose it makes sense to provide Git clones  
of Apache repositories.


I agree!

This morning I was worried that I gave too much background in my  
email.  I thought "nobody will care enough to read through all this  
crap!"  I'm glad people seem to recognize this as a valid use case,  
not just some goof-ball cowboy idea...



Anyway, I hope there will be other use-cases for Git at Apache...


Me, too... I think it's inevitable :-)


I would like to add only one note to Reinhard's answer:
Various parts of Cocoon are now released independently so version  
numbers can be completely different. Anyway, in most cases it's ok  
if you just checkout certain module and patch it.


Right. I still have to figure out how I'm going to handle that in my  
git setup, but I think you and Reinhard have set me on the right track  
here.


Fortunately, repositories provided by Jukka track all these branches  
and tags for different modules so you will have no trouble with such  
setup.


Yes.


thanks a _lot_,
Mark


No problem. Next time it's better to discuss such things publicly  
(yes, I'm sorry that I didn't respond to your e-mail - as usual lack  
of free time). :-)


Actually, the only reason I emailed you first was specificatlly that I  
didn't know how "publicized" Jukka wanted this to be.  I mean it's no  
big secret, he posted it on infra, but... still I didn't want to be  
the one to say "hey everybody... git party at Jukka's server!" :-)  I  
guess he did say he could probably handle a few hundred users...


cheers,
—ml—



smime.p7s
Description: S/MIME cryptographic signature

[jira] Subscription: COCOON-open-with-patch

2008-07-30 Thread jira

Issue Subscription
Filter: COCOON-open-with-patch (108 issues)
Subscriber: cocoon


Key Summary
COCOON-2228 StripNameSpacesTransformer does not strip namespace prefix of 
attributes
https://issues.apache.org/jira/browse/COCOON-2228
COCOON- Add SaxParser configuration properties
https://issues.apache.org/jira/browse/COCOON-
COCOON-2217 HttpServletResponseBufferingWrapper throws NPE when response body 
is empty
https://issues.apache.org/jira/browse/COCOON-2217
COCOON-2216 IncludeCacheManager can not perfom parallel includes
https://issues.apache.org/jira/browse/COCOON-2216
COCOON-2212 jx:attribute does not check name is correct before proceeding
https://issues.apache.org/jira/browse/COCOON-2212
COCOON-2211 Support for jx:element
https://issues.apache.org/jira/browse/COCOON-2211
COCOON-2210 The field 'type' in GenerateNode in corona-sitemap should not be 
final
https://issues.apache.org/jira/browse/COCOON-2210
COCOON-2197 Making the cocoon-auth-block acegi-security-sample work
https://issues.apache.org/jira/browse/COCOON-2197
COCOON-2173 AbstractCachingProcessingPipeline: Two requests can deadlock each 
other
https://issues.apache.org/jira/browse/COCOON-2173
COCOON-2162 [PATCH] Fix for Paginator when accessing out of bounds Pagination 
page
https://issues.apache.org/jira/browse/COCOON-2162
COCOON-2137 XSD Schemas for CForms Development
https://issues.apache.org/jira/browse/COCOON-2137
COCOON-2114 fix sorting in TraversableGenerator
https://issues.apache.org/jira/browse/COCOON-2114
COCOON-2108 xmodule:flow-attr Does not accept document objects
https://issues.apache.org/jira/browse/COCOON-2108
COCOON-2104 [PATCH] Add base URI fixup support to XIncludeTransformer
https://issues.apache.org/jira/browse/COCOON-2104
COCOON-2100 Retrieving mimeType returned by pipeline executed from Flow
https://issues.apache.org/jira/browse/COCOON-2100
COCOON-2071 Option to turn off pooling for components (probably faster on new 
JVMs and simpler debugging)
https://issues.apache.org/jira/browse/COCOON-2071
COCOON-2041 WebDAV Returns improper status on PUT
https://issues.apache.org/jira/browse/COCOON-2041
COCOON-2040 Union widget does not work with booleanfield set as case widget
https://issues.apache.org/jira/browse/COCOON-2040
COCOON-2037 New DynamicGroup widget
https://issues.apache.org/jira/browse/COCOON-2037
COCOON-2035 NPE in the sorter of the EnhancedRepeater
https://issues.apache.org/jira/browse/COCOON-2035
COCOON-2032 [PATCH] Sort order in paginated repeater
https://issues.apache.org/jira/browse/COCOON-2032
COCOON-2030 submit-on-change doesn't work for a multivaluefield with 
list-type="checkbox"
https://issues.apache.org/jira/browse/COCOON-2030
COCOON-2018 Use thread context class loader to load custom binding classes
https://issues.apache.org/jira/browse/COCOON-2018
COCOON-2017 More output beautification options for serializers
https://issues.apache.org/jira/browse/COCOON-2017
COCOON-2015 Doctype added twice because root element (html) is inlined
https://issues.apache.org/jira/browse/COCOON-2015
COCOON-2002 HTML transformer  only works with latin-1 characters
https://issues.apache.org/jira/browse/COCOON-2002
COCOON-1974 Donating ContextAttributeInputModule
https://issues.apache.org/jira/browse/COCOON-1974
COCOON-1973 CaptchaValidator: allow case-insensitive matching
https://issues.apache.org/jira/browse/COCOON-1973
COCOON-1964 Redirects inside a block called via the servlet protocol fail
https://issues.apache.org/jira/browse/COCOON-1964
COCOON-1963 Add a redirect action to the browser update handler
https://issues.apache.org/jira/browse/COCOON-1963
COCOON-1960 Pipeline errors for "generator/reader already set" should provide 
more information
https://issues.apache.org/jira/browse/COCOON-1960
COCOON-1949 [PATCH] load flowscript from file into specified Rhino context 
object
https://issues.apache.org/jira/browse/COCOON-1949
COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes 
and showing cform templates
https://issues.apache.org/jira/browse/COCOON-1946
COCOON-1943 [Patch] Parameters in blocks-protocol URIs get decoded too early
https://issues.apache.org/jira/browse/COCOON-1943
COCOON-1932 [PATCH] correct styling of disabled suggestion lists
https://issues.apache.org/jira/browse/COCOON-1932
COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2
https://issues.apache.org/jira/browse/COCOON-1929
COCOON-1917 Request Encoding problem: multipart/form vs. url encoded
https://issues.apache.org/jira/browse/COCOON-1917
COCOON-1915 Nullable value with addi

Re: Find a new name for Corona

Peter Hunsberger wrote:
On Wed, Jul 30, 2008 at 10:53 AM, Bertrand Delacretaz 
<[EMAIL PROTECTED] > wrote:

On Wed, Jul 30, 2008 at 5:28 PM, Reinhard Pötz <[EMAIL PROTECTED]
> wrote:
 > :-( that's bad. Any other suggestions?

I still think that Cocoon 3.0 could be the name, if people are going
to invest a significant effort in what's Corona today. For Sling we'd
like to use the pipelines implementation, so some of us Sling folks
are planning to contribute and help maintain that. I am not interested
in the other parts at the moment.

I think that at the moment Corona is far too much of an experiment to be 
considered 3.0.  Parts of it or all may become 3.0 but who knows?

Almost any name we choose will overlap with an existing product to some 
extent.  If it's not trademarked I'm ok with the overlap.  As such I 
think "Silk" is still one of the best options I've seen suggested..

Borland hasn't trademarked "silk" but only some variants of it. See 
http://tinyurl.com/5bkw9d

"Silk" was trademarked by a company called mentis: 
http://tess2.uspto.gov/bin/showfield?f=doc&state=pgshps.20.117

The name that we would use is "Cocoon Silk". So I tend to think that it 
isn't a problem.

WDOT?

--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: Find a new name for Corona

2008-07-30 Thread Peter Hunsberger

On Wed, Jul 30, 2008 at 10:53 AM, Bertrand Delacretaz <
[EMAIL PROTECTED]> wrote:

> On Wed, Jul 30, 2008 at 5:28 PM, Reinhard Pötz <[EMAIL PROTECTED]>
> wrote:
> > :-( that's bad. Any other suggestions?
>
> I still think that Cocoon 3.0 could be the name, if people are going
> to invest a significant effort in what's Corona today. For Sling we'd
> like to use the pipelines implementation, so some of us Sling folks
> are planning to contribute and help maintain that. I am not interested
> in the other parts at the moment.
>

I think that at the moment Corona is far too much of an experiment to be
considered 3.0.  Parts of it or all may become 3.0 but who knows?

Almost any name we choose will overlap with an existing product to some
extent.  If it's not trademarked I'm ok with the overlap.  As such I think
"Silk" is still one of the best options I've seen suggested..

-- 
Peter Hunsberger

Re: Find a new name for Corona

2008-07-30 Thread Rainer Pruy

Just my 0,02 cents...

I always considered "Cocoon" to mean more than pipelines, sitemap and alike
Thus I don't think using Cocoon 3.0 being an apropriate name.

What about

Cocoon Pipe  (ok, not exaktly)

or

Cocoon Bones

Rainer

Reinhard Pötz schrieb:
> Bertrand Delacretaz wrote:
>> On Wed, Jul 30, 2008 at 5:28 PM, Reinhard Pötz <[EMAIL PROTECTED]>
>> wrote:
>>> :-( that's bad. Any other suggestions?
>>
>> I still think that Cocoon 3.0 could be the name, if people are going
>> to invest a significant effort in what's Corona today. For Sling we'd
>> like to use the pipelines implementation, so some of us Sling folks
>> are planning to contribute and help maintain that. I am not interested
>> in the other parts at the moment.
>>
>> We already have 2.1 and 2.2 which are fairly different products,
>> Cocoon 3.0 would be a lightweight embeddable thing that captures the
>> essence of Cocoon in a way that's better suited to many of today's
>> environments. Clearly an evolution, even though some parts will be
>> missing, as those new environments provide them.
> 
> I'm still not convinced that we should name it Cocoon 3.0 _now_ (quoting
> myself from a few days ago):
> 
> [...] Before we make the decision if Corona should become Cocoon 3.0 we
> should learn more what other people think about it. (Currently it's only
> 3 people who use it!) IMO the best way to find this out is by shipping
> alpha releases under a codename. This gives us the freedom to decide
> later without spoiling version numbers. [...]
> 
> When Corona is able to attract a stable community proves itself useable
> to a wider audience, we can start to ship it as Cocoon 3.0.
> 
> Or is it only me who needs to be convinced of shipping Corona as Cocoon
> 3.0?
>

Re: Find a new name for Corona

2008-07-30 Thread Bertrand Delacretaz

On Wed, Jul 30, 2008 at 6:04 PM, Reinhard Pötz <[EMAIL PROTECTED]> wrote:

> ...I'm still not convinced that we should name it Cocoon 3.0 _now_ (quoting
> myself from a few days ago):..

I knew someone had said something about that, couldn't find that thread ;-)

> ...When Corona is able to attract a stable community proves itself useable to 
> a
> wider audience, we can start to ship it as Cocoon 3.0

If that's the plan (and I like it), why not keep the "project Corona"
name for now?

That would be just a project name, not a product name, so we don't
need to care about conflicts, the full name would be "Apache Cocoon -
project Corona".

-Bertrand

Re: Find a new name for Corona


Bertrand Delacretaz wrote:

On Wed, Jul 30, 2008 at 5:28 PM, Reinhard Pötz <[EMAIL PROTECTED]> wrote:

:-( that's bad. Any other suggestions?


I still think that Cocoon 3.0 could be the name, if people are going
to invest a significant effort in what's Corona today. For Sling we'd
like to use the pipelines implementation, so some of us Sling folks
are planning to contribute and help maintain that. I am not interested
in the other parts at the moment.

We already have 2.1 and 2.2 which are fairly different products,
Cocoon 3.0 would be a lightweight embeddable thing that captures the
essence of Cocoon in a way that's better suited to many of today's
environments. Clearly an evolution, even though some parts will be
missing, as those new environments provide them.


I'm still not convinced that we should name it Cocoon 3.0 _now_ (quoting 
myself from a few days ago):


[...] Before we make the decision if Corona should become Cocoon 3.0 we 
should learn more what other people think about it. (Currently it's only 
3 people who use it!) IMO the best way to find this out is by shipping 
alpha releases under a codename. This gives us the freedom to decide 
later without spoiling version numbers. [...]


When Corona is able to attract a stable community proves itself useable 
to a wider audience, we can start to ship it as Cocoon 3.0.


Or is it only me who needs to be convinced of shipping Corona as Cocoon 3.0?

--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: Find a new name for Corona

2008-07-30 Thread Bertrand Delacretaz

On Wed, Jul 30, 2008 at 5:28 PM, Reinhard Pötz <[EMAIL PROTECTED]> wrote:
> :-( that's bad. Any other suggestions?

I still think that Cocoon 3.0 could be the name, if people are going
to invest a significant effort in what's Corona today. For Sling we'd
like to use the pipelines implementation, so some of us Sling folks
are planning to contribute and help maintain that. I am not interested
in the other parts at the moment.

We already have 2.1 and 2.2 which are fairly different products,
Cocoon 3.0 would be a lightweight embeddable thing that captures the
essence of Cocoon in a way that's better suited to many of today's
environments. Clearly an evolution, even though some parts will be
missing, as those new environments provide them.

-Bertrand

Re: RFC: Using icu4j for number formatting

2008-07-30 Thread Joerg Heinicke

Jeremy Quinn  apache.org> writes:

> Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor  
> (the baseclass for all Number Formatting convertors), uses  
> java.text.DecimalFormat internally, without exposing the class to the  
> outside (except for one protected Method).
> 
> If I were to re-implement FormattingDecimalConvertor using icu4j,  
> should I leave the old one alone and create a new  
> icu4jFormattingDecimalConvertor, or work with the original class?

Please see [1].

> If this solves the problem, this would be the only decimal convertor  
> that would work properly with Dojo, so it would seem pointless to  
> leave the old one around, leading to confusion .

But Dojo is not the only option. And considering the differences between icu4j
and java.text people might want to have the option to switch. I don't know if
Sylvain ever did what he wanted to do (last mail in mentioned thread).

Joerg

[1] http://marc.info/?t=11096654551&r=1&w=4

Re: Find a new name for Corona


:-( that's bad. Any other suggestions?

Ralph Goers wrote:
Silk is the shorthand name for SilkTest and SilkPerformer. 
http://www.borland.com/us/products/silk/index.html.


Carsten Ziegeler wrote:

Reinhard Pötz wrote:


 . Apache Cocoon Fiber
 . Apache Cocoon Silk
 . Apache Fiber
 . Apache Silk

Any other suggestions?

I agree with the others that we should leave "Cocoon" in the name. We 
have a very strong brand which we should use.


I don't like "Fiber" - it reminds me of the German word (Fieber) for 
fever - and I can imagine many lame jokes on that one. :)


Between the original spelling Fibre and Silk I prefer Silk.

So +1 for Cocoon Silk.

Carsten


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: RFC: Using icu4j for number formatting

2008-07-30 Thread Antonio Gallardo


Jeremy Quinn escribió:

Dear All

Background:

While working on validating number fields for CForms, I am finding 
that there is a huge number of discrepancies between Dojo's localised 
number formatting and the ones built-in to Java. These discrepancies 
are breaking Dojo's ability to perform client-side validation for many 
Locales.


@see http://blog.fiveone.org/2008/07/number-format-hell.html

I mention a few ideas for solutions in the comments, but I think I 
came up with a better one ..


com.ibm.icu.* provides equivalents to java.text.DecimalFormat, 
java.util.Currency etc. that are built using the same CLDR (Common 
Locale Data Repository) dataset that Dojo is built from. @see 
http://www.unicode.org/cldr/ .


Specifically, Dojo 1.1.1 (current release) uses CLDR 1.5.1 that comes 
in icu4j version 3.8.1 and Dojo 1.2 will use CLDR 1.6 which comes in 
icu4j 4.0 (clear upgrade path).


If this works, the benefit would be that number formatting would be 
consistent regardless of the JVM you are using (above 1.4 the minimum 
icu needs to run).


Question:

Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor 
(the baseclass for all Number Formatting convertors), uses 
java.text.DecimalFormat internally, without exposing the class to the 
outside (except for one protected Method).


If I were to re-implement FormattingDecimalConvertor using icu4j, 
should I leave the old one alone and create a new 
icu4jFormattingDecimalConvertor, or work with the original class?


If this solves the problem, this would be the only decimal convertor 
that would work properly with Dojo, so it would seem pointless to 
leave the old one around, leading to confusion .


I ask this because when it comes to Date Convertors, we do have 
separate ones for icu4j and the built-in date formatters.

I agree, it is pointless to have the old around.

Thanks Jeremy for your effort!

Best Regards,

Antonio Gallardo.

[continuum] BUILD FAILURE: Cocoon - Apache Cocoon [build root] - Build Def:

2008-07-30 Thread [EMAIL PROTECTED]


Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=105409&projectId=51

Build statistics:
 State: Failed
 Previous State: Failed
 Started at: Wed 30 Jul 2008 07:42:45 -0700
 Finished at: Wed 30 Jul 2008 07:54:05 -0700
 Total time: 11m 20s
 Build Trigger: Schedule
 Build Number: 310
 Exit code: 1
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version : 
 java version "1.4.2_15"

 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02)
 Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode)
   
 Builder version :

 Maven version: 2.0.8
 Java version: 1.4.2_15
 OS name: "linux" version: "2.6.20-16-server" arch: "i386" Family: 
"unix"
   


SCM Changes:

Changed: felixk @ Wed 30 Jul 2008 05:03:25 -0700
Comment: Reflect adding the cdocs-it collection to daisy
Files changed:
 /cocoon/trunk/blocks/cocoon-it/pom.xml ( 680992 )
 /cocoon/trunk/parent/pom.xml ( 680992 )


Dependencies Changes:

No dependencies changed



Build Defintion:

POM filename: pom.xml
Goals: clean install   
Arguments: --batch-mode -P allblocks,it

Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: DEFAULT_SCHEDULE
Profile Name: Java 1.4, Large Memory
Description: 



Test Summary:

Tests: 373
Failures: 0
Total time: 130.04597

Re: Cocoon-jms-sample requires Java >= 1.5

2008-07-30 Thread Peter Hunsberger

On Wed, Jul 30, 2008 at 8:47 AM, Felix Knecht <[EMAIL PROTECTED]> wrote:

>
>  Then I think the solution is rather clear: we need to migrate to 1.5. If
>> Sun is not supporting Java 1.4 then I don't want to support it as well in
>> our _trunk_.
>>
>> People that need to stick to Java 1.4 still have a choice: We have
>> released 2.2 that works with Java 1.4.
>>
>> Therefore I propose to switch to 1.5 and focus on getting real work done.
>>
>>  But when switching the version why don't switch to 1.6 (I think it's on
> MacOSX now also available). Otherwise we have to switch again in 1 year or
> so (see http://java.sun.com/products/archive/eol.policy.html). EOL for 1.5
> is  October 2009.
>
>> WDYT?
>>
>>
>
There might be people who can't run 1.6 yet.  In particular we know some
people are still stuck on old versions of Websphere and similar.  We've had
this discussion before and I'm on the side that we can't support legacy code
forever.  However, I do feel that a jump to 1.6 might be a bit premature. We
just had this discussion internally over the last couple of weeks and we
found several 1.6 incompatibilities forcing us to stay on 1.5 for the
moment.  If we do have a need to move to 1.6 in the future it shouldn't be
that much of an issue to change at that point?

-- 
Peter Hunsberger

Re: Find a new name for Corona

2008-07-30 Thread Ralph Goers

Silk is the shorthand name for SilkTest and SilkPerformer. 
http://www.borland.com/us/products/silk/index.html.


Carsten Ziegeler wrote:

Reinhard Pötz wrote:


 . Apache Cocoon Fiber
 . Apache Cocoon Silk
 . Apache Fiber
 . Apache Silk

Any other suggestions?

I agree with the others that we should leave "Cocoon" in the name. We 
have a very strong brand which we should use.


I don't like "Fiber" - it reminds me of the German word (Fieber) for 
fever - and I can imagine many lame jokes on that one. :)


Between the original spelling Fibre and Silk I prefer Silk.

So +1 for Cocoon Silk.

Carsten

Re: svn commit: r680992 - in /cocoon/trunk: blocks/cocoon-it/pom.xml parent/pom.xml


Felix Knecht schrieb:

Reinhard Pötz schrieb:

Felix Knecht wrote:
So far I suppose this needs also the creation of a new Daisy site. I 
think that I've all done I can do in Daisy (added a new document for 
tests [1]) but I'm not able to create the new site on 
c.z.a.o:/.../daisywikidata/sites


What's the document id of the navigation document and the index 
document? (Then I can create the site for you.)


I thought it to be 
http://cocoon.zones.apache.org/daisy/cdocs/1465.html , but I'm not 
sure if I did everything right as I'm doing it the first time and have 
no big idea how all the things are working. Of course reading the docs 
helped me to solve some problems :-)




I forgot: Of course it would be nice if you could create the site :-)

BTW: Does this also makes it appear in Daisy's root page 
(http://cocoon.zones.apache.org/daisy/)?


Thanks
Felix

Re: Cocoon-jms-sample requires Java >= 1.5



Then I think the solution is rather clear: we need to migrate to 1.5. 
If Sun is not supporting Java 1.4 then I don't want to support it as 
well in our _trunk_.


People that need to stick to Java 1.4 still have a choice: We have 
released 2.2 that works with Java 1.4.


Therefore I propose to switch to 1.5 and focus on getting real work done.

But when switching the version why don't switch to 1.6 (I think it's on 
MacOSX now also available). Otherwise we have to switch again in 1 year 
or so (see http://java.sun.com/products/archive/eol.policy.html). EOL 
for 1.5 is  October 2009.

WDYT?

Re: Cocoon-jms-sample requires Java >= 1.5

Reinhard Pötz pisze:
Now we have the problem that the ActiveMQ version that we use was built
with Java 5:

According to
http://activemq.apache.org/can-i-use-activemq-5x-or-later-on-java-14.html
there is no version built for 1.4.

What shall we do?

Actually, this is a part of bigger picture. Let me explain.

Due to refactorings in Servlet Service Framework and Spring Configurator (thanks Reinhard for doing
that!) they are not back compatible anymore so we will need to release 2.0.0 of both projects.

Now Cocoon Core (of version 2.2.0) depends on these projects so Core itself becomes not back
compatible anymore. Therefore we'll need to release 2.3.0 of Cocoon Core to keep things clean.

Then, if we are going to release 2.3.0 I think it's valid to bump Java version requirement.
Especially if you look at this message from Sun:

J2SE 1.4.2 is in its Java Technology End of Life (EOL) transition period. The EOL transition period
began Dec, 11 2006 and will complete October 30th, 2008, when J2SE 1.4.2 will have reached its End
of Service Life (EOSL).

[...]

Customers interested in continuing to receive critical fixes, are encouraged to consider the
following options:

* Migrate to the latest Java SE release
* Migrate to Java SE for Business 1.4.2

(the source: http://java.sun.com/j2se/1.4.2/download.html)

Then I think the solution is rather clear: we need to migrate to 1.5. If Sun is not supporting Java
1.4 then I don't want to support it as well in our _trunk_.

People that need to stick to Java 1.4 still have a choice: We have released 2.2 that works with Java
1.4.

Therefore I propose to switch to 1.5 and focus on getting real work done.

WDYT?

--
Grzegorz Kossakowski

Re: Cocoon-jms-sample requires Java >= 1.5


Felix Knecht wrote:

Reinhard Pötz schrieb:


According to 
http://activemq.apache.org/can-i-use-activemq-5x-or-later-on-java-14.html 
there is no version built for 1.4.


What shall we do?

Can't we use the enforcer plugin that the jms block is only build and 
added when using 1.5 or higher and make a note in the docs that jms 
block needs at least 1.5?


Actually it's the jms-sample module only (we want to use an embedded 
ActiveMQ instance), not the impl.


Having a profile that is activated by a minimum Java version seems to be 
the best idea.


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

RE: Webdav and link-rewrite

2008-07-30 Thread Ard Schrijvers


> 
> > Apart from the link-rewrite block he will also migrate the 
> > webdav block. 
> > Any thoughts or recommendations on this? The plan is that all 
> > Avalon components are migrated to Spring and that Jackrabbit 
> > is used as webdav server.
> > 
> > I remember Jasha and Jereon have started to work on this in 
> > Rome last year. Any comments from you?
> 
> Jeroen has looked further at the WebDAV block after the Rome 
> GT. The problem was the imcompatibility between HttpClient 2 
> (used in Slide) and HttpClient 3 (used in the WebDAV block). 
> Jeroen still has an open Jira issue for this [1], but he's 
> enjoying a well deserved holiday now. 
> 
> Ard, do you know how far the WebDAV implementation in Jackrabbit is?

Jackrabbit does not supply a webdav client, only a server without the
DASL possibility AFAIK

-Ard

> 
> [1] https://issues.apache.org/jira/browse/COCOON-2153
> 
> Jasha Joachimsthal 
> 
> www.onehippo.com
> Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam 
> +31(0)20-5224466 
> San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma 
> CA 94952-3329 +1 (707) 773-4646
> 
>

Re: Cocoon-jms-sample requires Java >= 1.5


Reinhard Pötz schrieb:


According to 
http://activemq.apache.org/can-i-use-activemq-5x-or-later-on-java-14.html 
there is no version built for 1.4.


What shall we do?

Can't we use the enforcer plugin that the jms block is only build and 
added when using 1.5 or higher and make a note in the docs that jms 
block needs at least 1.5?

Re: Cocoon-jms-sample requires Java >= 1.5

2008-07-30 Thread Lukas Lang


Hey,

this came out of my head. Currently, I'm using three different Java versions on 
my PC.
I'm sorry for that. As Reinhard already stated,
there won't be a solution in the near future, except using the Retrotranslator.
I could suggest to introduce a profile, activated when using Java 5 or higher.

What do you think?

Regards,
Lukas

Andrew Savory schrieb:

Hi,

2008/7/30 Reinhard Pötz <[EMAIL PROTECTED]>:

Now we have the problem that the ActiveMQ version that we use was built with
Java 5:

[ERROR] BUILD FAILURE

According to
http://activemq.apache.org/can-i-use-activemq-5x-or-later-on-java-14.html
there is no version built for 1.4.

What shall we do?


Is this 2.2? If so, why not set our minimum JDK to 1.5?
I know I still need to revert or fix the 2.1 patches I added a while
back, too. Short of time at the moment :-(


Andrew.
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
http://www.andrewsavory.com/

Re: Cocoon-jms-sample requires Java >= 1.5

2008-07-30 Thread Andrew Savory

Hi,

2008/7/30 Reinhard Pötz <[EMAIL PROTECTED]>:
> Now we have the problem that the ActiveMQ version that we use was built with
> Java 5:
>
> [ERROR] BUILD FAILURE
>
> According to
> http://activemq.apache.org/can-i-use-activemq-5x-or-later-on-java-14.html
> there is no version built for 1.4.
>
> What shall we do?

Is this 2.2? If so, why not set our minimum JDK to 1.5?
I know I still need to revert or fix the 2.1 patches I added a while
back, too. Short of time at the moment :-(


Andrew.
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
http://www.andrewsavory.com/

Cocoon-jms-sample requires Java >= 1.5

Now we have the problem that the ActiveMQ version that we use was built 
with Java 5:


[ERROR] BUILD FAILURE
[INFO] 


[INFO] Compilation failure
/home/continuum/data/working-directory/51/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/jms/SimpleTextMessagePublisher.java:[22,-1] 
cannot access org.apache.activemq.command.ActiveMQTextMessage
bad class file: 
/home/continuum/.m2/repository/org/apache/activemq/activemq-core/5.1.0/activemq-core-5.1.0.jar(org/apache/activemq/command/ActiveMQTextMessage.class)

class file has wrong version 49.0, should be 48.0

/home/continuum/data/working-directory/51/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/jms/SimpleTextMessagePublisher.java:[22,-1] 
cannot access org.apache.activemq.command.ActiveMQTextMessage
bad class file: 
/home/continuum/.m2/repository/org/apache/activemq/activemq-core/5.1.0/activemq-core-5.1.0.jar(org/apache/activemq/command/ActiveMQTextMessage.class)

class file has wrong version 49.0, should be 48.0


According to 
http://activemq.apache.org/can-i-use-activemq-5x-or-later-on-java-14.html 
there is no version built for 1.4.


What shall we do?

--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: [vote] Luca Morandini as new Cocoon committer

2008-07-30 Thread Vadim Gritsenko


On Jul 29, 2008, at 1:33 PM, Luca Morandini wrote:

Besides, I've heard Apache committers have special discounts on the  
entire Mercedes-Benz range of models... what ? That was just a  
joke ? Oh my... :(


You do get a discount on ApacheCon... See you in New Orleans?

Vadim

Re: svn commit: r680992 - in /cocoon/trunk: blocks/cocoon-it/pom.xml parent/pom.xml


Reinhard Pötz schrieb:

Felix Knecht wrote:
So far I suppose this needs also the creation of a new Daisy site. I 
think that I've all done I can do in Daisy (added a new document for 
tests [1]) but I'm not able to create the new site on 
c.z.a.o:/.../daisywikidata/sites


What's the document id of the navigation document and the index 
document? (Then I can create the site for you.)


I thought it to be http://cocoon.zones.apache.org/daisy/cdocs/1465.html 
, but I'm not sure if I did everything right as I'm doing it the first 
time and have no big idea how all the things are working. Of course 
reading the docs helped me to solve some problems :-)

Re: Webdav and link-rewrite


Grzegorz Kossakowski wrote:

Reinhard Pötz pisze:

Grzegorz Kossakowski wrote:

Reinhard Pötz pisze:


I had a brief look at the link-rewrite block and think now that the 
migration of the LinkrewriterTransformer will be difficult because 
of its configuration can't be easily converted to Spring.


What kind of obstacles you can see here?


What's your suggestion for a configuration like this:

src="org.apache.cocoon.transformation.LinkRewriterTransformer">

  
reloadable="true" />

  
  

  

//[EMAIL PROTECTED]'
']/@href
  



I have no suggestion but only to remove support for such stuff. These 
days, when you define components as Spring beans you don't need to 
support configuration passed from one component to another. At least I 
don't see any need for supporting that kind of configuration.


If we remove this, then of course we'll have to release 2.0 of link 
rewriter block but I have no problem with it.


I agree with you that we shouldn't support such stuff but what features 
do we want to see in a new LinkRewriteTransformer? (... hence my 
suggestion that we start with a ServletLinkRewriteTransformer because we 
know that we need it.)



--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

[continuum] BUILD FAILURE: Cocoon - Apache Cocoon [build root] - Build Def:

2008-07-30 Thread [EMAIL PROTECTED]


Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=105399&projectId=51

Build statistics:
 State: Failed
 Previous State: Failed
 Started at: Wed 30 Jul 2008 05:03:21 -0700
 Finished at: Wed 30 Jul 2008 05:17:44 -0700
 Total time: 14m 23s
 Build Trigger: Schedule
 Build Number: 310
 Exit code: 1
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version : 
 java version "1.4.2_15"

 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02)
 Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode)
   
 Builder version :

 Maven version: 2.0.8
 Java version: 1.4.2_15
 OS name: "linux" version: "2.6.20-16-server" arch: "i386" Family: 
"unix"
   


SCM Changes:

Changed: reinhard @ Wed 30 Jul 2008 04:07:22 -0700
Comment: explicitly set version numbers because of the Maven 2 - Java 1.4 bug 
(that has hit us s many times)
Files changed:
 /cocoon/trunk/parent/pom.xml ( 680974 )


Dependencies Changes:

No dependencies changed



Build Defintion:

POM filename: pom.xml
Goals: clean install   
Arguments: --batch-mode -P allblocks,it

Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: DEFAULT_SCHEDULE
Profile Name: Java 1.4, Large Memory
Description: 



Test Summary:

Tests: 373
Failures: 0
Total time: 132.82301

Re: svn commit: r680992 - in /cocoon/trunk: blocks/cocoon-it/pom.xml parent/pom.xml


Felix Knecht wrote:
So far I suppose this needs also the creation of a new Daisy site. I 
think that I've all done I can do in Daisy (added a new document for 
tests [1]) but I'm not able to create the new site on 
c.z.a.o:/.../daisywikidata/sites


What's the document id of the navigation document and the index 
document? (Then I can create the site for you.)


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: svn commit: r680992 - in /cocoon/trunk: blocks/cocoon-it/pom.xml parent/pom.xml

So far I suppose this needs also the creation of a new Daisy site. I 
think that I've all done I can do in Daisy (added a new document for 
tests [1]) but I'm not able to create the new site on 
c.z.a.o:/.../daisywikidata/sites


[1] http://cocoon.zones.apache.org/daisy/cdocs/1465.html

[EMAIL PROTECTED] schrieb:

Author: felixk
Date: Wed Jul 30 05:03:25 2008
New Revision: 680992

URL: http://svn.apache.org/viewvc?rev=680992&view=rev
Log:
Reflect adding the cdocs-it collection to daisy

Modified:
cocoon/trunk/blocks/cocoon-it/pom.xml
cocoon/trunk/parent/pom.xml

Modified: cocoon/trunk/blocks/cocoon-it/pom.xml
URL: 
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-it/pom.xml?rev=680992&r1=680991&r2=680992&view=diff
==
--- cocoon/trunk/blocks/cocoon-it/pom.xml (original)
+++ cocoon/trunk/blocks/cocoon-it/pom.xml Wed Jul 30 05:03:25 2008
@@ -34,6 +34,7 @@
   
 Integration test suite for Cocoon.
   
+  http://cocoon.apache.org/${docs.m.it.relPath}
 
   

 
@@ -51,6 +52,37 @@
 
   
 
+  

+
+  website
+  ${docs.deploymentBaseUrl}/${docs.m.it.relPath}
+
+  
+
+  
+Cocoon Integration Tests
+${docs.m.it.version}
+  
+
+  
+
+  daisy
+  
+
+  
+org.daisycms
+daisy-maven-plugin
+
+  1465
+  cdocs-it
+  
true
+
+  
+
+  
+
+  
+
   
 
   

Modified: cocoon/trunk/parent/pom.xml
URL: 
http://svn.apache.org/viewvc/cocoon/trunk/parent/pom.xml?rev=680992&r1=680991&r2=680992&view=diff
==
--- cocoon/trunk/parent/pom.xml (original)
+++ cocoon/trunk/parent/pom.xml Wed Jul 30 05:03:25 2008
@@ -3343,6 +3343,8 @@
 
2.2/maven-plugins/maven-plugin/${docs.m.maven-plugin.version}/
 1.0
 
2.2/maven-plugins/it-fw/${docs.m.it-fw.version}/
+1.0
+
2.2/maven-plugins/it/${docs.m.it.version}/
   
 
   

@@ -3607,6 +3609,10 @@
 cdocs-it-fw
 ${docs.m.it-fw.relPath}
   
+  
+cdocs-it
+${docs.m.it.relPath}
+  
 
   
   org.apache.cocoon

RFC: Using icu4j for number formatting

2008-07-30 Thread Jeremy Quinn

Dear All

Background:

While working on validating number fields for CForms, I am finding
that there is a huge number of discrepancies between Dojo's localised
number formatting and the ones built-in to Java. These discrepancies
are breaking Dojo's ability to perform client-side validation for many
Locales.

@see http://blog.fiveone.org/2008/07/number-format-hell.html

I mention a few ideas for solutions in the comments, but I think I
came up with a better one ..

com.ibm.icu.* provides equivalents to java.text.DecimalFormat,
java.util.Currency etc. that are built using the same CLDR (Common
Locale Data Repository) dataset that Dojo is built from. @see http://www.unicode.org/cldr/
.

Specifically, Dojo 1.1.1 (current release) uses CLDR 1.5.1 that comes
in icu4j version 3.8.1 and Dojo 1.2 will use CLDR 1.6 which comes in
icu4j 4.0 (clear upgrade path).

If this works, the benefit would be that number formatting would be
consistent regardless of the JVM you are using (above 1.4 the minimum
icu needs to run).

Question:

Currently, o.a.c.forms.datatype.convertor.FormattingDecimalConvertor
(the baseclass for all Number Formatting convertors), uses
java.text.DecimalFormat internally, without exposing the class to the
outside (except for one protected Method).

If I were to re-implement FormattingDecimalConvertor using icu4j,
should I leave the old one alone and create a new
icu4jFormattingDecimalConvertor, or work with the original class?

If this solves the problem, this would be the only decimal convertor
that would work properly with Dojo, so it would seem pointless to
leave the old one around, leading to confusion .

I ask this because when it comes to Date Convertors, we do have
separate ones for icu4j and the built-in date formatters.

Many thanks for any suggestions

regards Jeremy

Re: Webdav and link-rewrite


Reinhard Pötz pisze:

Grzegorz Kossakowski wrote:

Reinhard Pötz pisze:


I had a brief look at the link-rewrite block and think now that the 
migration of the LinkrewriterTransformer will be difficult because of 
its configuration can't be easily converted to Spring.


What kind of obstacles you can see here?


What's your suggestion for a configuration like this:

src="org.apache.cocoon.transformation.LinkRewriterTransformer">

  
reloadable="true" />

  
  

  

//[EMAIL PROTECTED]'
']/@href
  



I have no suggestion but only to remove support for such stuff. These days, when you define 
components as Spring beans you don't need to support configuration passed from one component to 
another. At least I don't see any need for supporting that kind of configuration.


If we remove this, then of course we'll have to release 2.0 of link rewriter block but I have no 
problem with it.


WFYT?

TBH, that's one of the most horrible pieces of configuration I've ever 
seen.


I'm only not sure if I agree with "the most" part of your sentence. ;-)

--
Grzegorz Kossakowski

Re: Webdav and link-rewrite


Grzegorz Kossakowski wrote:

Reinhard Pötz pisze:


I had a brief look at the link-rewrite block and think now that the 
migration of the LinkrewriterTransformer will be difficult because of 
its configuration can't be easily converted to Spring.


What kind of obstacles you can see here?


What's your suggestion for a configuration like this:

src="org.apache.cocoon.transformation.LinkRewriterTransformer">

  
reloadable="true" />

  
  

  

//[EMAIL PROTECTED]'
']/@href
  


TBH, that's one of the most horrible pieces of configuration I've ever seen.

--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

RE: Webdav and link-rewrite

2008-07-30 Thread Jasha Joachimsthal

> -Original Message-
> From: Reinhard Pötz [mailto:[EMAIL PROTECTED] 
> Sent: woensdag 30 juli 2008 13:29
> To: dev@cocoon.apache.org
> Subject: Webdav and link-rewrite
> 

> Apart from the link-rewrite block he will also migrate the 
> webdav block. 
> Any thoughts or recommendations on this? The plan is that all 
> Avalon components are migrated to Spring and that Jackrabbit 
> is used as webdav server.
> 
> I remember Jasha and Jereon have started to work on this in 
> Rome last year. Any comments from you?

Jeroen has looked further at the WebDAV block after the Rome GT. The problem 
was the imcompatibility between HttpClient 2 (used in Slide) and HttpClient 3 
(used in the WebDAV block). Jeroen still has an open Jira issue for this [1], 
but he's enjoying a well deserved holiday now. 

Ard, do you know how far the WebDAV implementation in Jackrabbit is?

[1] https://issues.apache.org/jira/browse/COCOON-2153

Jasha Joachimsthal 

www.onehippo.com
Amsterdam - Hippo B.V. Oosteinde 11 1017 WT Amsterdam +31(0)20-5224466 
San Francisco - Hippo USA Inc. 101 H Street, suite Q Petaluma CA 94952-3329 +1 
(707) 773-4646

Re: Webdav and link-rewrite


Reinhard Pötz pisze:


I had a brief look at the link-rewrite block and think now that the 
migration of the LinkrewriterTransformer will be difficult because of 
its configuration can't be easily converted to Spring.


What kind of obstacles you can see here?

Since the main use case for the LinkrewritingTransformer is rewriting 
servlet: links, I think that the best compromise is that Lukas 
implements a specialized ServletLinkRewritingTransformer that could be 
put into the servlet-service-fw-components block. This will satisfy our 
main goal of getting rid of the linkrewrite dependency in the 
servlet-service-fw-components block.


I have mixed feelings about this proposal. I really like to reuse components if it's possible. Two 
components doing more or less the same doesn't sound good to me.


In the case that one needs the more advanced use cases, the already 
existing transformer can be used by adding the link-rewrite block.


Or are there any better suggestions?


Since Lukas is going to migrate link-rewrite block to Spring anyway (at least that's how I read your 
e-mail) I fail to understand why we can't use migrated block?


--
Grzegorz Kossakowski

Webdav and link-rewrite



I had a brief look at the link-rewrite block and think now that the 
migration of the LinkrewriterTransformer will be difficult because of 
its configuration can't be easily converted to Spring.


Since the main use case for the LinkrewritingTransformer is rewriting 
servlet: links, I think that the best compromise is that Lukas 
implements a specialized ServletLinkRewritingTransformer that could be 
put into the servlet-service-fw-components block. This will satisfy our 
main goal of getting rid of the linkrewrite dependency in the 
servlet-service-fw-components block.


In the case that one needs the more advanced use cases, the already 
existing transformer can be used by adding the link-rewrite block.


Or are there any better suggestions?

- o -

Apart from the link-rewrite block he will also migrate the webdav block. 
Any thoughts or recommendations on this? The plan is that all Avalon 
components are migrated to Spring and that Jackrabbit is used as webdav 
server.


I remember Jasha and Jereon have started to work on this in Rome last 
year. Any comments from you?


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: svn commit: r680974 - /cocoon/trunk/parent/pom.xml


[EMAIL PROTECTED] pisze:

Author: reinhard
Date: Wed Jul 30 04:07:22 2008
New Revision: 680974

URL: http://svn.apache.org/viewvc?rev=680974&view=rev
Log:
explicitly set version numbers because of the Maven 2 - Java 1.4 bug (that has 
hit us s many times)


I believe this is fixed in 2.0.9. I wanted to switch to this version earlier[1] but only then I 
realized that we'll need an updated Maven on Continuum.


Not sure how hard is to achieve this.

[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/78065

--
Grzegorz Kossakowski

Re: [continuum] BUILD FAILURE: Cocoon - Apache Cocoon [build root] - Build Def:

I've just committed a fix for this Maven 2 / Java 1.4 related error. 
Here is the relevant part of the error message:


[INFO] 


[INFO] Building Cocoon JMS Block Implementation
[INFO]task-segment: [clean, install]
[INFO] 


[INFO] [clean:clean]
[INFO] Deleting directory 
/home/continuum/data/working-directory/51/blocks/cocoon-jms/cocoon-jms-impl/target
[INFO] Deleting directory 
/home/continuum/data/working-directory/51/blocks/cocoon-jms/cocoon-jms-impl/target/classes
[INFO] Deleting directory 
/home/continuum/data/working-directory/51/blocks/cocoon-jms/cocoon-jms-impl/target/test-classes
[INFO] Deleting directory 
/home/continuum/data/working-directory/51/blocks/cocoon-jms/cocoon-jms-impl/target/site

[INFO] [enforcer:enforce-once {execution: enforce-maven}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading: 
http://repo1.maven.org/maven2/org/springframework/spring-jms/2.5.5/spring-jms-2.5.5.pom

2K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/springframework/spring-context-support/2.4.1/spring-context-support-2.4.1.pom
Downloading: 
http://people.apache.org/~gkossakowski/maven2/repository/org/springframework/spring-context-support/2.4.1/spring-context-support-2.4.1.pom
Downloading: 
http://repo1.maven.org/maven2/org/springframework/spring-jms/2.5.5/spring-jms-2.5.5.jar

184K downloaded
Downloading: 
http://people.apache.org/~gkossakowski/maven2/repository/org/springframework/spring-context-support/2.4.1/spring-context-support-2.4.1.jar
Downloading: 
http://repo1.maven.org/maven2/org/springframework/spring-context-support/2.4.1/spring-context-support-2.4.1.jar
[INFO] 


[ERROR] BUILD ERROR
[INFO] 


[INFO] Failed to resolve artifact.

Missing:
--
1) org.springframework:spring-context-support:jar:2.4.1

  Try downloading the file manually from the project website.

  Then, install it using the command:
  mvn install:install-file -DgroupId=org.springframework 
-DartifactId=spring-context-support -Dversion=2.4.1 -Dpackaging=jar 
-Dfile=/path/to/file


  Alternatively, if you host your own repository you can deploy the 
file there:
  mvn deploy:deploy-file -DgroupId=org.springframework 
-DartifactId=spring-context-support -Dversion=2.4.1 -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]


  Path to dependency:
1) org.apache.cocoon:cocoon-jms-impl:jar:1.0.0-SNAPSHOT
2) org.springframework:spring-jms:jar:2.5.5
3) org.springframework:spring-context-support:jar:2.4.1

--
1 required artifact is missing.

for artifact:
  org.apache.cocoon:cocoon-jms-impl:jar:1.0.0-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  gkossakowski-maven2 
(http://people.apache.org/~gkossakowski/maven2/repository),

  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)

[EMAIL PROTECTED] wrote:
Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=105380&projectId=51 



Build statistics:
 State: Failed
 Previous State: Failed
 Started at: Wed 30 Jul 2008 03:37:32 -0700
 Finished at: Wed 30 Jul 2008 03:47:12 -0700
 Total time: 9m 39s
 Build Trigger: Schedule
 Build Number: 310
 Exit code: 1
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version :  java version "1.4.2_15"
 Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2_15-b02)

 Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode)
Builder version :
 Maven version: 2.0.8
 Java version: 1.4.2_15
 OS name: "linux" version: "2.6.20-16-server" arch: "i386" 
Family: "unix"
   
 


SCM Changes:
 


Changed: reinhard @ Wed 30 Jul 2008 03:07:35 -0700
Comment: COCOON-2223
. remove obsolete dependencies
. move JMSEventMessageListener to event-cache
Files changed:
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/pom.xml ( 
680956 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java 
( 680956 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/resources/META-INF/cocoon/spring/cocoon-eventcache.xml 
( 680956 )


Changed: reinhard @ Wed 30 Jul 2008 03:13:35 -0700
Comment: COCOON-2229

apply Lukas' patch with some minor modifications

. don't depend on hsqldb anymore
. don't depend on self-written JMS connection code (Spring provides 
anything we need)

. Spring migration of the remaining code
Files changed:

[continuum] BUILD FAILURE: Cocoon - Apache Cocoon [build root] - Build Def:

2008-07-30 Thread [EMAIL PROTECTED]


Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=105380&projectId=51

Build statistics:
 State: Failed
 Previous State: Failed
 Started at: Wed 30 Jul 2008 03:37:32 -0700
 Finished at: Wed 30 Jul 2008 03:47:12 -0700
 Total time: 9m 39s
 Build Trigger: Schedule
 Build Number: 310
 Exit code: 1
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version : 
 java version "1.4.2_15"

 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_15-b02)
 Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode)
   
 Builder version :

 Maven version: 2.0.8
 Java version: 1.4.2_15
 OS name: "linux" version: "2.6.20-16-server" arch: "i386" Family: 
"unix"
   


SCM Changes:

Changed: reinhard @ Wed 30 Jul 2008 03:07:35 -0700
Comment: COCOON-2223
. remove obsolete dependencies
. move JMSEventMessageListener to event-cache
Files changed:
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/pom.xml ( 680956 
)
 
/cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/java/org/apache/cocoon/caching/impl/JMSEventMessageListener.java
 ( 680956 )
 
/cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/resources/META-INF/cocoon/spring/cocoon-eventcache.xml
 ( 680956 )

Changed: reinhard @ Wed 30 Jul 2008 03:13:35 -0700
Comment: COCOON-2229

apply Lukas' patch with some minor modifications

. don't depend on hsqldb anymore
. don't depend on self-written JMS connection code (Spring provides anything we 
need)
. Spring migration of the remaining code
Files changed:
 /cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/pom.xml ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/acting/JMSPublisherAction.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/AbstractMessageListener.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/AbstractMessagePublisher.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/JMSConnection.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/JMSConnectionEventListener.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/JMSConnectionEventNotifier.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/JMSConnectionImpl.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/JMSConnectionManager.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/components/jms/JMSConnectionManagerImpl.java
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/samples
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-jms.xconf
 ( 680957 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/resources/org/apache/cocoon/components/jms/jms.roles
 ( 680957 )

Changed: reinhard @ Wed 30 Jul 2008 03:18:02 -0700
Comment: COCOON-2229

. provide JMS samples that use embedded ActiveMQ
. configure RCL for direct usage
Files changed:
 /cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/pom.xml ( 680958 )
 /cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/rcl.properties ( 680958 )
 /cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java ( 680958 )
 /cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org ( 680958 )
 /cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache ( 
680958 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon
 ( 680958 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/acting
 ( 680958 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/acting/JMSEventMessageListener.java
 ( 680958 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/jms
 ( 680958 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/jms/SimpleMessageListener.java
 ( 680958 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/jms/SimpleTextMessagePublisher.java
 ( 680958 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/samples
 ( 680958 )
 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-sample/src/main/java/org/apache/cocoon/samples/jms
 (from 
/cocoon/trunk/blocks/cocoon-jms/cocoon-jms-impl/src/main/java/org/apache/cocoon/samples/jms:680934)
 ( 680958 )

Re: Missing Sitemap component documentation in Daisy


Felix Knecht wrote:

Felix Knecht schrieb:


After hours trying to download miscelleanous poms the 
tools/sitemaptags2daisy has built now and I can see that

New documents: 7
Updated documents: 123
Unmodified documents: 147

I'll try now to update daisy and hope it works and I'm not causing 
any troubles or documentation breaks 


Can somebody with more karma please create the collection [1] causing 
this error on daisy?


I created a new collection [1] in daisy and now it works, but I'm not 
sure if this is all or if also a navigation document (or even more) 
should be created ...


For now it's good enough (I think). I wanted to provide some docs about 
the integration-test plugin and the integration-test framework but never 
got started :-(


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Eventcache and JMS block



I've just applied Lukas' work on the event-cache and the jms blocks. The 
main tasks were the migration to Spring providing integration tests.


There isn't much to say about the event-cache migration but that we 
decided to remove the dependency on the JMS block. IMO the concept of 
events in Cocoon is more general than JMS which Lukas and I consider 
being one particular implementation.


The work on the JMS block consisted of two main parts: Cocoon provided 
it's own JMS connection implementation. Since we heavily use Spring in 
2.2, it doesn't make sense to keep them any longer because the Spring 
implemention is more advanced and better maintained than ours. The 
second part was adding an embedded ActiveMQ message broker to the JMS 
samples instead of using OpenJMS which had to be configured separately 
in order to run the samples.


@Lukas:

. I've applied your patches with only some minor modifications. I moved 
the hsqldb dependency of jms-impl to jms-sample because I don't see any 
reason for having the related code in the impl block.


. Can you please prefix all the Spring beans in the samples with a 
unique namespace, e.g org.apache.cocoon.blocks.jms.sample.


. Can you provide changes.xml files for the two blocks. See e.g. the 
forms block as example.


. Please fix the wrong comment in 
JMSEventMessageListener#eventFromTextMessage()


. When you provide documentation (Daisy) I consider the two blocks as done.


Lukas, thank you very much for your good work. It's good to have you around!

--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: Missing Sitemap component documentation in Daisy


Felix Knecht schrieb:


After hours trying to download miscelleanous poms the 
tools/sitemaptags2daisy has built now and I can see that

New documents: 7
Updated documents: 123
Unmodified documents: 147

I'll try now to update daisy and hope it works and I'm not causing 
any troubles or documentation breaks 


Can somebody with more karma please create the collection [1] causing 
this error on daisy?


I created a new collection [1] in daisy and now it works, but I'm not 
sure if this is all or if also a navigation document (or even more) 
should be created ...




Exception in thread "Main Thread" java.lang.Exception: Error trying to 
get or create the collection cdocs-it
   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.updateCollections(SitemapTagsToDaisy.java:503) 

   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.createDocument(SitemapTagsToDaisy.java:550) 

   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.run(SitemapTagsToDaisy.java:145) 

   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.main(SitemapTagsToDaisy.java:82) 

Caused by: org.outerj.daisy.repository.RepositoryException: The 
current user is not allowed to create collections.
   at 
org.outerj.daisy.repository.commonimpl.CommonCollectionManager.createCollection(CommonCollectionManager.java:51) 

   at 
org.outerj.daisy.repository.commonimpl.CollectionManagerImpl.createCollection(CollectionManagerImpl.java:35) 

   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.updateCollections(SitemapTagsToDaisy.java:498) 




[1] http://cocoon.apache.org/1223_1_1.html

Thanks
Felix

[jira] Closed: (COCOON-2223) Fix block and migrate Avalon components to Spring


 [ 
https://issues.apache.org/jira/browse/COCOON-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz closed COCOON-2223.
--

Resolution: Fixed

patch applied. thanks!

> Fix block and migrate Avalon components to Spring
> -
>
> Key: COCOON-2223
> URL: https://issues.apache.org/jira/browse/COCOON-2223
> Project: Cocoon
>  Issue Type: Task
>  Components: Blocks: Event Cache
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lukas Lang
>Assignee: Reinhard Poetz
>Priority: Minor
> Attachments: patch.c2223.20080716.txt
>
>
> Subject says all.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (COCOON-2229) Migrate JMS block to Spring


 [ 
https://issues.apache.org/jira/browse/COCOON-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz closed COCOON-2229.
--

Resolution: Fixed

patch applied. thanks!

> Migrate JMS block to Spring
> ---
>
> Key: COCOON-2229
> URL: https://issues.apache.org/jira/browse/COCOON-2229
> Project: Cocoon
>  Issue Type: Task
>  Components: Blocks: JMS
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lukas Lang
>Assignee: Reinhard Poetz
>Priority: Minor
> Attachments: patch.c2229.20080729-parentpom.txt, 
> patch.c2229.20080729.txt, patch.c2229.20080730.txt
>
>
> Task consists of removing Avalon components, adding an ActiveMQ broker in 
> embedded mode and setting up unit and component tests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (COCOON-2229) Migrate JMS block to Spring


 [ 
https://issues.apache.org/jira/browse/COCOON-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz reassigned COCOON-2229:
--

Assignee: Reinhard Poetz

> Migrate JMS block to Spring
> ---
>
> Key: COCOON-2229
> URL: https://issues.apache.org/jira/browse/COCOON-2229
> Project: Cocoon
>  Issue Type: Task
>  Components: Blocks: JMS
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lukas Lang
>Assignee: Reinhard Poetz
>Priority: Minor
> Attachments: patch.c2229.20080729-parentpom.txt, 
> patch.c2229.20080729.txt, patch.c2229.20080730.txt
>
>
> Task consists of removing Avalon components, adding an ActiveMQ broker in 
> embedded mode and setting up unit and component tests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (COCOON-2230) Write integration tests for JMS block


 [ 
https://issues.apache.org/jira/browse/COCOON-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz closed COCOON-2230.
--

Resolution: Fixed

thanks, patch applied

> Write integration tests for JMS block
> -
>
> Key: COCOON-2230
> URL: https://issues.apache.org/jira/browse/COCOON-2230
> Project: Cocoon
>  Issue Type: Task
>  Components: Blocks: JMS
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lukas Lang
>Assignee: Reinhard Poetz
>Priority: Minor
> Attachments: patch.c2230.20080730.txt, patch.c2330.20080729.txt
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (COCOON-2230) Write integration tests for JMS block


 [ 
https://issues.apache.org/jira/browse/COCOON-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz reassigned COCOON-2230:
--

Assignee: Reinhard Poetz

> Write integration tests for JMS block
> -
>
> Key: COCOON-2230
> URL: https://issues.apache.org/jira/browse/COCOON-2230
> Project: Cocoon
>  Issue Type: Task
>  Components: Blocks: JMS
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lukas Lang
>Assignee: Reinhard Poetz
>Priority: Minor
> Attachments: patch.c2230.20080730.txt, patch.c2330.20080729.txt
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Missing Sitemap component documentation in Daisy



After hours trying to download miscelleanous poms the 
tools/sitemaptags2daisy has built now and I can see that

New documents: 7
Updated documents: 123
Unmodified documents: 147

I'll try now to update daisy and hope it works and I'm not causing any 
troubles or documentation breaks 


Can somebody with more karma please create the collection [1] causing 
this error on daisy?


Exception in thread "Main Thread" java.lang.Exception: Error trying to 
get or create the collection cdocs-it
   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.updateCollections(SitemapTagsToDaisy.java:503)
   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.createDocument(SitemapTagsToDaisy.java:550)
   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.run(SitemapTagsToDaisy.java:145)
   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.main(SitemapTagsToDaisy.java:82)
Caused by: org.outerj.daisy.repository.RepositoryException: The current 
user is not allowed to create collections.
   at 
org.outerj.daisy.repository.commonimpl.CommonCollectionManager.createCollection(CommonCollectionManager.java:51)
   at 
org.outerj.daisy.repository.commonimpl.CollectionManagerImpl.createCollection(CollectionManagerImpl.java:35)
   at 
org.apache.cocoon.documentation.daisy.SitemapTagsToDaisy.updateCollections(SitemapTagsToDaisy.java:498)



[1] http://cocoon.apache.org/1223_1_1.html

Thanks
Felix

Re: Missing Sitemap component documentation in Daisy


Felix Knecht schrieb:

Hi

I doubt that the (monthly?) generated and published documentation 
contains all info that we have. I.e. for several
classes the @cocoon.sitemap.component.documentation annotation (maybe 
others as well) doesn't seems to processed into

daisy, i.e. for [1] - but it exists [2] at least since 2007-12-19.

Could it be that the sitemaptags2daisy tool isn't run also monthly?

[1] http://cocoon.apache.org/2.2/core-modules/core/2.2/913_1_1.html
[2] 
/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/generation/CSVGenerator.java

[3] http://cocoon.zones.apache.org/daisy/documentation/g3/1066.html

Any ideas on this?
After hours trying to download miscelleanous poms the 
tools/sitemaptags2daisy has built now and I can see that

New documents: 7
Updated documents: 123
Unmodified documents: 147

I'll try now to update daisy and hope it works and I'm not causing any 
troubles or documentation breaks 




Regards
Felix

Missing Sitemap component documentation in Daisy


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi

I doubt that the (monthly?) generated and published documentation contains all 
info that we have. I.e. for several
classes the @cocoon.sitemap.component.documentation annotation (maybe others as 
well) doesn't seems to processed into
daisy, i.e. for [1] - but it exists [2] at least since 2007-12-19.

Could it be that the sitemaptags2daisy tool isn't run also monthly?

[1] http://cocoon.apache.org/2.2/core-modules/core/2.2/913_1_1.html
[2] 
/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/generation/CSVGenerator.java
[3] http://cocoon.zones.apache.org/daisy/documentation/g3/1066.html

Any ideas on this?

Regards
Felix
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiQMUUACgkQ2lZVCB08qHFpOQCgr/HGnQ/WqPbhFtJErmmFuB4v
xLIAn1/3+Z/+mvBN99s2tLhFJKwB9eZ9
=0uUx
-END PGP SIGNATURE-

Running in Eclipse (was Re: request encoding conundrum)

2008-07-30 Thread Andrew Savory

Hi Grzegorz,

2008/7/27 Grzegorz Kossakowski <[EMAIL PROTECTED]>:

> Actually, time passed since our last meeting and I learned how to do things
> in damn easy way. So here goes the instructions:
> 1. Grab Eclipse from www.eclipse.org (I use 3.3 but newest 3.4 should work
> as well)
> 2. Install run jetty run plug-in for eclipse from:
> http://code.google.com/p/run-jetty-run/
>   This will enable you to start Cocoon 2.2 from within Eclipse thus many
> fancy things will be possible (details below)
> 3. Checkout Cocoon's trunk from
> https://svn.eu.apache.org/repos/asf/cocoon/trunk/
> 4. Watch following video to see what else should be done:
>   http://people.apache.org/~gkossakowski/cocoon/cocoon-dev.avi
> 5. *Before* you start mvn eclipse:eclipse command do following:
>   (assuming you are in the root directory of Cocoon checkout)
>   $ cd
> blocks/cocoon-ajax/cocoon-ajax-impl/src/main/resources/org/apache/cocoon/dojo/resources/
>   $ unzip dojo-0.4.3-ajax.zip
>   $ mv dojo-0.4.3-ajax/* .
>   $ rm -r dojo-0.4.3-ajax
>
>   Then return to the root directory and continue with the video. If you
> wonder why this ugly thing is needed: We are cheating here a little bit.
> It's a build that takes care of unpacking dojo and placing it at the right
> location but we don't want to rebuild right?
> 7. Once you are finished with the video you should be able to hack 2.2
> *without* any rebuilds.
>
>
> Now NOTES:
> 1. Thanks to the fact that Eclipse knows about Cocoon projects you can
> easily debug Cocoon. Just use debugging button instead of Run. Nice thing is
> that it even supports HotSwap so if you change a java class while debugging
> it will get redeployed. This is what we call RAD, right?
> 2. I had to modify (touch) forms-samples-styling.xsl file because
> Cocoon/XSLT processor does not detect changes to the included files. Anyway,
> AFAIR the same problem is in 2.1.

Excellent instructions and useful video - many thanks!

One thing I have noticed is that if you run on windows but have your
source and run maven on a remote linux box, and mount the drive and
open the source in eclipse, and you have m2eclipse installed, you're
not able to change the M2_REPO classpath variable (at least, I think
that's the reason).


Andrew.
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
http://www.andrewsavory.com/

Re: Find a new name for Corona

2008-07-30 Thread Carsten Ziegeler


Reinhard Pötz wrote:


 . Apache Cocoon Fiber
 . Apache Cocoon Silk
 . Apache Fiber
 . Apache Silk

Any other suggestions?

I agree with the others that we should leave "Cocoon" in the name. We 
have a very strong brand which we should use.


I don't like "Fiber" - it reminds me of the German word (Fieber) for 
fever - and I can imagine many lame jokes on that one. :)


Between the original spelling Fibre and Silk I prefer Silk.

So +1 for Cocoon Silk.

Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]

Re: Broken build due to eventcache block


Grzegorz Kossakowski wrote:

Hi,

Continuum reported broken[1] build that I can confirm on my computer. 
Since I don't know that much about eventcache block I don't have an idea 
how to fix it.


Lukas, as you are working now on this stuff, can you give us some advice?

PS. Answer to the Cocoon's dev mailing.

[1] 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=105274&projectId=51&projectGroupId=23 


It's probably my fault. I'm going to fix this right now.

--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: Can somebody explain to me the tags / POM versioning / release scheme?

Mark Lundquist pisze:

Hi Devs,

Hi Mark,

I need some help understanding the temple of mystery that is
http://svn.apache.org/repos/asf/cocoon/tags/. If I wanted to build my
own 2.2 artifacts, how would I do that?

Some background, I'll *try* to make it as short as possible :-/ (and
while it involves git, you don't need to understand git to be able to
follow it)...

I use Cocoon to implement dozens of customer web sites/applications. I
develop on my laptop when possible, and we have a development server for
staging and some content updates, and a production server. A few years
ago, I realized that I needed to be able to maintain the Cocoon source
tree (the parts of it I needed) in my own Subversion repository. The
main reason for this was to be able to upgrade projects to new versions
of Cocoon in a controlled way, as smoothly as possible. Also, on rare
occasions I would find a bug and submit a patch for the fix, and I
needed the ability to push that fix into production in the version of
Cocoon that my project builds were using. To make all this possible, I
developed an application of the "Vendor Branch Strategy" described in
the Subversion book, and documented it here:
http://wiki.apache.org/cocoon/CocoonVendorBranch.

Any chance for you to create a similar page documenting your new approach? I'm sure that there would
be a people benefiting from a nice cook-book document.

It's a chance to make Git more popular which is always a benefit, right? :-)

Unfortunately, that technique still turned out to be too
labor-intensive, to the point where it failed to accomplish its main
goal of giving me an easy way to upgrade Cocoon versions. Meanwhile...
the lack of merge tracking and offline commits in Subversion was making
it harder and harder to get work done, so I started using SVK
(http://svk.bestpractical.com) as my front-end to Subversion on my
laptop. After a little bit of experience with SVK, I realized that it
provided the ability to radically simplify my "vendor branch" strategy.
All I needed to do was to create a local SVK mirror of the ASF Cocoon
repository and I would be off and running. Unfortunately... it didn't
work, the mirror sync operation would always fail with a low-level error
in the Subversion layer. So I gave up for a while. Then, last month I
started researching the problem again, and learned that the problem had
been due to the Apache "mod_dontdothat" policy implemented by Apache
infra in order to thwart some kind of abuse that had been going on.
Sadly, this also made it impossible for SVK to mirror the repository.
About that time, Grzegorz was running into the same problem, but he was
trying create a git-svn mirror of the repository. That was fortuitous
for me, because I was getting seriously interested in git (having
experienced that SVK is broken, and come to the realization that the
whole concept is lipstick on a pig). There was this whole long
discussion on the infra list, and they finally reached a compromise
where mod_dontdothat would be turned off... but only on
eu.svn.apache.org, and only in the https:// scheme, which would then be
subject to authentication — so, this was available to committers only.
There was actually a brief window of time when mod_dontdothat was turned
off for Europe, and during that time I was able to 'git-svn clone' the
repository. But a few weeks later, I tried to rebase my git-svn mirror
(like doing "svn up") and it failed because by then eu infra had closed
off non-mod_dontdothat'd access on http://, so... back where I started.

BUT THEN... one of the Apache committers put a lot of work into figuring
out how to create a git-clonable, public git-svn mirror of an Apache
project... and he did it, and published mirrors of a bunch of Apache
projects, including Cocoon. It's brilliant. It took me 20 minutes to
git-clone the mirror, vs. the 40 hours of running time to make my own
(short-lived) git-svn mirror. I just rebased to pick up the last week's
worth of changes to the repo, and it just took a couple of seconds. And
in my local git repository, I can do *anything* that's possible in git.
I really think this is the answer to my problem.

Interesting. I'm not sure but when we have discussed Git advantages over svn on infrastructure lists
that point has not been discussed.

Even if only for that purpose it makes sense to provide Git clones of Apache repositories. Anyway, I
hope there will be other use-cases for Git at Apache...

NOW... I want to start porting all my Cocoon projects, which are all
stuck on Cocoon 2.1, to a Cocoon build based on the 2.2 release. This
would be 2.2 + a couple of minor bug fixes which did not make it into
the 2.2 release, so it needs to be from my own local (git) branch...
plus, this puts me on the right path to do everything I originally was
trying to do with "subversion vendor branch", i.e. controlled Cocoon
upgrades in the future w/ min

Re: [continuum] BUILD FAILURE: Cocoon - Apache Cocoon [build root] - Build Def:


Reinhard Pötz pisze:

Grzegorz Kossakowski wrote:

Reinhard, are you aware of this problem?

I had a quick look into source and I cannot understand why it fails or 
more precisely how you changes made it to fail.


Yes, I'm aware but I have no idea either. Let's see what will happen 
after the next CI cycle.


But there _is_ a problem. I have exactly the same error on my computer.

I only fail to understand how applying Lukas' patches could cause this problem.

--
Grzegorz Kossakowski

Broken build due to eventcache block


Hi,

Continuum reported broken[1] build that I can confirm on my computer. Since I don't know that much 
about eventcache block I don't have an idea how to fix it.


Lukas, as you are working now on this stuff, can you give us some advice?

PS. Answer to the Cocoon's dev mailing.

[1] 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=105274&projectId=51&projectGroupId=23

--
Grzegorz

Re: [continuum] BUILD FAILURE: Cocoon - Apache Cocoon [build root] - Build Def:


Grzegorz Kossakowski wrote:

Reinhard, are you aware of this problem?

I had a quick look into source and I cannot understand why it fails or 
more precisely how you changes made it to fail.


Yes, I'm aware but I have no idea either. Let's see what will happen 
after the next CI cycle.


--
Reinhard Pötz   Managing Director, {Indoqa} GmbH
 http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member  [EMAIL PROTECTED]

Re: Find a new name for Corona (was: [proposal] Corona: A Cocoon subproject)

2008-07-30 Thread Andrew Savory

Hi,

2008/7/30 Reinhard Pötz <[EMAIL PROTECTED]>:

> ok, that's much better IMO. Provided that we are allowed to have a
> subproject without "Cocoon" in the name, the current list of suggested names
> includes:
>
>  . Apache Cocoon Fiber
>  . Apache Cocoon Silk
>  . Apache Fiber
>  . Apache Silk
>
> Any other suggestions?

I'd argue strongly in favour of the original spelling, Fibre, and not Fiber.


Andrew.
--
[EMAIL PROTECTED] / [EMAIL PROTECTED]
http://www.andrewsavory.com/

[jira] Updated: (COCOON-2230) Write integration tests for JMS block

2008-07-30 Thread Lukas Lang (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Lang updated COCOON-2230:
---

Attachment: patch.c2230.20080730.txt

Apply this patch to the cocoon-core directory.

> Write integration tests for JMS block
> -
>
> Key: COCOON-2230
> URL: https://issues.apache.org/jira/browse/COCOON-2230
> Project: Cocoon
>  Issue Type: Task
>  Components: Blocks: JMS
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lukas Lang
>Priority: Minor
> Attachments: patch.c2230.20080730.txt, patch.c2330.20080729.txt
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (COCOON-2229) Migrate JMS block to Spring

2008-07-30 Thread Lukas Lang (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lukas Lang updated COCOON-2229:
---

Attachment: patch.c2229.20080730.txt

Apply this patch to your cocoon-jms folder.

> Migrate JMS block to Spring
> ---
>
> Key: COCOON-2229
> URL: https://issues.apache.org/jira/browse/COCOON-2229
> Project: Cocoon
>  Issue Type: Task
>  Components: Blocks: JMS
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lukas Lang
>Priority: Minor
> Attachments: patch.c2229.20080729-parentpom.txt, 
> patch.c2229.20080729.txt, patch.c2229.20080730.txt
>
>
> Task consists of removing Avalon components, adding an ActiveMQ broker in 
> embedded mode and setting up unit and component tests.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [continuum] BUILD FAILURE: Cocoon - Apache Cocoon [build root] - Build Def:


[EMAIL PROTECTED] pisze:
Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=105274&projectId=51 



Build statistics:
 State: Failed
 Previous State: Ok
 Started at: Tue 29 Jul 2008 07:40:41 -0700
 Finished at: Tue 29 Jul 2008 08:09:59 -0700
 Total time: 29m 18s
 Build Trigger: Schedule
 Build Number: 310
 Exit code: 1
 Building machine hostname: vmbuild.apache.org
 Operating system : Linux(unknown)
 Java Home version :  java version "1.4.2_15"
 Java(TM) 2 Runtime Environment, Standard Edition (build 
1.4.2_15-b02)

 Java HotSpot(TM) Client VM (build 1.4.2_15-b02, mixed mode)
Builder version :
 Maven version: 2.0.8
 Java version: 1.4.2_15
 OS name: "linux" version: "2.6.20-16-server" arch: "i386" 
Family: "unix"
   
 


SCM Changes:
 


Changed: reinhard @ Tue 29 Jul 2008 06:54:14 -0700
Comment: COCOON-2223

Apply Lukas' patch that
. migrates eventcache from Avalon to Spring
. adds some pipeline for integration tests
Files changed:
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/pom.xml ( 
680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/java/org/apache/cocoon/acting/CacheEventAction.java 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/java/org/apache/cocoon/caching/impl/EventAwareCacheImpl.java 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/java/org/apache/cocoon/caching/impl/StoreEventRegistryImpl.java 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/java/org/apache/cocoon/generation/EventCacheGenerator.java 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/java/org/apache/cocoon/samples/EventAwareGenerator.java 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-eventcache.xconf 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-impl/src/main/resources/META-INF/cocoon/spring/cocoon-eventcache.xml 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-sample/src/main/resources/COB-INF/it 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-sample/src/main/resources/COB-INF/it/it.xml 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-sample/src/main/resources/COB-INF/it/sitemap.xmap 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-sample/src/main/resources/COB-INF/sitemap.xmap 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-sample/src/main/resources/META-INF/cocoon/spring/cocoon-eventcache-sample-blockServlet.xml 
( 680697 )
 /cocoon/trunk/blocks/cocoon-eventcache/cocoon-eventcache-sample/src/main/resources/META-INF/cocoon/spring/cocoon-eventcache-sample.xml 
( 680697 )


Changed: reinhard @ Tue 29 Jul 2008 07:03:17 -0700
Comment: COCOON-2224

add IT for eventcache
Files changed:
 /cocoon/trunk/core/cocoon-webapp/src/test/java/org/apache/cocoon/it/blocks/eventcache 
( 680699 )
 /cocoon/trunk/core/cocoon-webapp/src/test/java/org/apache/cocoon/it/blocks/eventcache/EventAwareCacheTest.java 
( 680699 )


Changed: reinhard @ Tue 29 Jul 2008 07:13:29 -0700
Comment: remove unnecessary (and sometimes problematic) include
Files changed:
 /cocoon/trunk/core/cocoon-webapp/pom.xml ( 680705 )


Reinhard, are you aware of this problem?

I had a quick look into source and I cannot understand why it fails or more precisely how you 
changes made it to fail.


--
Grzegorz

Re: Find a new name for Corona