[jira] Closed: (COCOON-1889) [PATCH] Tiny typo in JavaScriptJXPathBinding

[ http://issues.apache.org/jira/browse/COCOON-1889?page=all ] Antonio Gallardo closed COCOON-1889. Fix Version/s: 2.2-dev (Current SVN) 2.1.10-dev (current SVN) Resolution: Fixed Thanks for the patch. Feel free to reopen

Re: ok to update license headers in pom.xml ?

Jorg Heymans wrote: Hi, Can I go ahead and update all license headers in our poms to: Yes. That is the same license header that i will be adding to all files. It is differently formatted, but that will not matter. -David !-- Licensed to the Apache Software Foundation (ASF) under one

Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository

Jorg Heymans wrote: I've rereleased the archetype as 1.0.0-M2. Unfortunatly the archetype creates a pom with SNAPSHOT dependencies. This has to be fixed with another release. We really need a staging repository ... -- Reinhard Pötz Independent Consultant, Trainer (IT)-Coach

Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository

Our getting started guide states You need to build the trunk of Cocoon in order to get your local repositories filled with the necessary artifacts. I guess we can remove this as m1 is released to the repos, right? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de

Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository

Carsten Ziegeler wrote: Our getting started guide states You need to build the trunk of Cocoon in order to get your local repositories filled with the necessary artifacts. I guess we can remove this as m1 is released to the repos, right? yes -- Reinhard Pötz Independent Consultant,

Re: How to hook up another block?

Rice Yeh wrote: Hi, I have done the step in http://cocoon.zones.apache.org/daisy/documentation/g1/1159.html. Then, how do I hook up other blocks like cocoon-forms except adding the dependence on pom.xml. basically that's it. There are 2 articles

Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository

Reinhard Poetz wrote: Jorg Heymans wrote: I've rereleased the archetype as 1.0.0-M2. Unfortunatly the archetype creates a pom with SNAPSHOT dependencies. This has to be fixed with another release. We really need a staging repository ... I've released 1.0.0-M3 now. Can somebody please

[jira] Reopened: (COCOON-1687) [PATCH] JXPATHBinding : when saving the form, remove xml elements if the value of the widget is null

[ http://issues.apache.org/jira/browse/COCOON-1687?page=all ] Marc Portier reopened COCOON-1687: -- The applied patch introduces an undesired side-effect: suppose you have a binding that looks like fb:context path=elem fb:value id=x path=@x /

Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository

Reinhard Poetz wrote: Jorg Heymans wrote: I've rereleased the archetype as 1.0.0-M2. Unfortunatly the archetype creates a pom with SNAPSHOT dependencies. This has to be fixed with another release. We really need a staging repository ... woops sorry about that :-( (i'll get started on

Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository

Jorg Heymans wrote: Reinhard Poetz wrote: Jorg Heymans wrote: I've rereleased the archetype as 1.0.0-M2. Unfortunatly the archetype creates a pom with SNAPSHOT dependencies. This has to be fixed with another release. We really need a staging repository ... woops sorry about that :-(

Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository

Reinhard Poetz wrote: I've released 1.0.0-M3 now. Can somebody please check if I did it right? i'll have a look tonight. thanks! I wonder if whether naming our releases milestones makes much sense considering this case ... I have to say that I'm not perfectly happy with it. Do we

Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository

Reinhard Poetz wrote: I've released 1.0.0-M3 now. Can somebody please check if I did it right? looks good to me. Jorg

Staging Repository (was Re: Cocoon 2.2 M1 artifacts in m2-ibiblio-rsync-repository)

Reinhard Poetz wrote: (i'll get started on setting up that staging repository now) great, desperatly needed! I've setup a staging repo on the zones, http://cocoon.zones.apache.org/cocoon-staging-release-repository/. It's configured in the root pom so any release:perform action will be

Re: Staging Repository

Jorg Heymans wrote: I've setup a staging repo on the zones, http://cocoon.zones.apache.org/cocoon-staging-release-repository/. It's configured in the root pom so any release:perform action will be going there instead of people.a.o. The idea is that we can verify releases from there *before* we

Fwd: Flow concurrency (was Re: Action Vs Logicsheet)

Hi, I posted this on the users list a few days ago, but never got a definitive answer (I did find out that this is *not* the case for javaflow :-), but that's not really an answer... I want to know if it *is* the case for flowscript). cheers, —ml— Begin forwarded message: From: Mark

Re: Fwd: Flow concurrency (was Re: Action Vs Logicsheet)

Mark Lundquist wrote: Hi, I posted this on the users list a few days ago, but never got a definitive answer (I did find out that this is *not* the case for javaflow :-), but that's not really an answer... I want to know if it *is* the case for flowscript). cheers, —ml— Begin forwarded

Re: Staging Repository

Reinhard Poetz wrote: The only thing i'm still unsure about is how to do the sync between the zone and people.a.o, rsync might not work too well given the metadata that's involved. Why do you think so? As long there is no other process that manipulates Cocoon artifacts in the Apache

Cocoon 2.2 and Java 5

What do people think about making Java 5, which was released almost _2 years ago_, the minimum requirement for trunk? Quoting Bruno from the Daisy list, I'd say that we can benefit from some new features too: ... we can make use of features like generics, the enhanced for loop, the