Re: svn commit: r682901 - /cocoon/trunk/tools/pom.xml
[EMAIL PROTECTED] pisze: Author: reinhard Date: Tue Aug 5 12:42:45 2008 New Revision: 682901 URL: http://svn.apache.org/viewvc?rev=682901view=rev Log: back in snapshot mode Modified: cocoon/trunk/tools/pom.xml Modified: cocoon/trunk/tools/pom.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/pom.xml?rev=682901r1=682900r2=682901view=diff == --- cocoon/trunk/tools/pom.xml (original) +++ cocoon/trunk/tools/pom.xml Tue Aug 5 12:42:45 2008 @@ -26,7 +26,7 @@ parent groupIdorg.apache.cocoon/groupId artifactIdcocoon/artifactId -version7/version +version5-SNAPSHOT/version relativePath../parent/relativePath Development version is lower than released one. Is it intended? -- Grzegorz Kossakowski
Re: [summary] [vote] Thorsten Scherler as new Cocoon committer
On Tue, 2008-08-05 at 12:58 +1000, David Crossley wrote: David Crossley wrote: I propose Thorsten Scherler as a new Cocoon committer and PMC member. During the time period there were no negative votes, and more than 3 positive votes. Thank you very much all of you, it is a big honor for me to be now official part of the great cocoon community. To introduce myself to the community: I am a German freelancer living in Spain and started to use cocoon back in 2002 when I was working for a company in Paderborn while I studied (Carsten will know the town ;)). I used it to generate reports of some telemarketing databases that I programmed this days. As well in this days I got in contact with the former version of Apache Lenya, was able to contribute to the project and got elected as committer. Then I entered the incubator with Lenya in 2003 and became part of the great Apache community. A year later I started with Forrest and since then I am using the three projects for my customer projects. Lately I have finished a high traffic web page for the regional government based on cocoon 2.2 and I am exited to keep on working with cocoon in the future (let us see when I can have my first Corona ;)). Since you are already an ASF committer via Lenya and Forrest, we just need to add you to the svn authorization list for cocoon. One of us will do that soon. Thanks. If you want to join the Apache Cocoon PMC, just say so and one of us will commence the procedure to add you. Yes, please, start the procedure. -David Thank you very much David for starting this vote. Kind regards salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: [Vote] Jasha Joachimsthal as new Cocoon committer
Andrew Savory wrote: It's my pleasure to propose Jasha Joachimsthal as a new committer on the Apache Cocoon project. +1 from me. -David
Is it necessary to increase the development version number (SNAPSHOT) after a release?
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: reinhard
Date: Tue Aug 5 12:42:45 2008
New Revision: 682901
URL: http://svn.apache.org/viewvc?rev=682901view=rev
Log:
back in snapshot mode
Modified:
cocoon/trunk/tools/pom.xml
Modified: cocoon/trunk/tools/pom.xml
URL:
http://svn.apache.org/viewvc/cocoon/trunk/tools/pom.xml?rev=682901r1=682900r2=682901view=diff
==
--- cocoon/trunk/tools/pom.xml (original)
+++ cocoon/trunk/tools/pom.xml Tue Aug 5 12:42:45 2008
@@ -26,7 +26,7 @@
parent
groupIdorg.apache.cocoon/groupId
artifactIdcocoon/artifactId
-version7/version
+version5-SNAPSHOT/version
relativePath../parent/relativePath
Development version is lower than released one. Is it intended?
yes, I was too lazy to touch nearly every POM file in our repository
just to increase the version number of our parent POMs. I haven't done
this for the last release either and AFAICT, no problem occurred.
Does anybody know if it can cause problems if the development version
number isn't increased after a release?
--
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: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Reinhard Pötz pisze: yes, I was too lazy to touch nearly every POM file in our repository just to increase the version number of our parent POMs. I haven't done this for the last release either and AFAICT, no problem occurred. Hmmm, find, xargs and sed should do this work within one minute. :-) Does anybody know if it can cause problems if the development version number isn't increased after a release? I would say that it's at least confusing. So how does this work now? We have a new version of parent pom but we reference to the old one. Which version is chosen finally? -- Grzegorz Kossakowski
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Reinhard Pötz schrieb: Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: reinhard Date: Tue Aug 5 12:42:45 2008 New Revision: 682901 URL: http://svn.apache.org/viewvc?rev=682901view=rev Log: back in snapshot mode Modified: cocoon/trunk/tools/pom.xml Modified: cocoon/trunk/tools/pom.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/pom.xml?rev=682901r1=682900r2=682901view=diff == --- cocoon/trunk/tools/pom.xml (original) +++ cocoon/trunk/tools/pom.xml Tue Aug 5 12:42:45 2008 @@ -26,7 +26,7 @@ parent groupIdorg.apache.cocoon/groupId artifactIdcocoon/artifactId -version7/version +version5-SNAPSHOT/version relativePath../parent/relativePath Development version is lower than released one. Is it intended? yes, I was too lazy to touch nearly every POM file in our repository just to increase the version number of our parent POMs. I haven't done this for the last release either and AFAICT, no problem occurred. Does anybody know if it can cause problems if the development version number isn't increased after a release? At least I find it intuitive for the one releasing the next version when he can rely on the snapshot version than doing a search in the maven remote repository to find the next version number for a release. Just my 0.02 CHF
Re: Webdav and link-rewrite
Reinhard Pötz wrote:
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:
map:transformer name=linkrewriter
src=org.apache.cocoon.transformation.LinkRewriterTransformer
input-module name=book-raw
file src=cocoon://samples/linkrewriter/bookdemo/linkmap
reloadable=true /
/input-module
input-module name=book
input-module name=book-raw
file src={src} reloadable=true /
/input-module
prefix//[EMAIL PROTECTED]'/prefix
suffix']/@href/suffix
/input-module
/map:transformer
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.)
Any comments, otherwise I still believe that we only need a
ServletLinkRewriteTransformer and will advise Lukas to go towards this
direction.
--
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]
Daisy Account
Hello, can someone please change my Daisy account (username: lukaslang) role, so that I can add block documentation. Thanks in advance, Lukas
Re: Daisy Account
Lukas Lang pisze: Hello, can someone please change my Daisy account (username: lukaslang) role, so that I can add block documentation. Added you to doc-editors role. You should be able to edit documentation. Thanks for your work Lukas. -- Grzegorz Kossakowski
[vote] Cocoon 3.0
Following the result of our recent discussion about the future of
Corona, I propose Corona to become Cocoon 3.
This means that any reference on Corona in source files, package names,
artifact ids, group ids or anywhere else will be dropped and the
standard Cocoon namespace org.apache.cocoon will be used.
This majority vote stays open for 72 hours.
Please cast your votes.
Here is my +1
--
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]
[vote] Release of servlet-service-impl-1.1.0, spring-configurator-2.0.0, jnet-1.0.0, block-deployment-1.0.0, cocoon-maven-plugin-1.0.0-M3
I've prepared the artifacts for the release of our four subprojects:
Cocoon Servlet-Service Framework Impl 1.1.0
~~~
The most important change is that it doesn't depend on the Cocoon source
resolver any more. Custom protocols (e.g. block-context) can still be
used by registering them with JNet.
Cocoon Spring Configurator 2.0.0
A major release is necessary because the block deployment functionality
was rewritten and moved into the separate Block-Deployment module.
Apart from this there have been some minor bug fixes and improvements.
Cocoon JNet 1.0.0
~
Cocoon JNet allows the dynamic registration of URLStreamHandler
factories with your JVM. That's a feature that isn't supported by Java
itself.
This module was donated to the Apache Commons project and will hopefully
be released there sooner or later.
That's the first release of this module.
Cocoon Block-Deployment 1.0.0
~
The Block-Deployment module provides a Java servlet context listener,
that unpacks all blocks into the temp directory of the current servlet
context.
Previously this functionality was part of the Spring Configurator but
was considered to be too Cocoon specific.
That's the first release of this module.
- o -
Additionally I've prepared the artifacts for the release of the
Cocoon Maven Plugin 1.0.0-M3
The only difference to M2 is that it was compiled with Spring 2.5.5
because M2 causes some wired exceptions when it is used with Spring 2.5.2.
As always, the release of the Cocoon Maven Plugin also makes the release
of the cocoon-rcl-webapp-wrapper and cocoon-rcl-spring-reloader necessary.
Cocoon Parent POM - Version 7 Cocoon Tools Modules - Version 7
In order to use the most recent dependency and plugin versions in the
subprojects and the Maven plugin, I had to create a new release of the
Cocoon Parent POM and the Cocoon Tools Modules.
- o -
Currently the proposed artifacts can only be tested either with latest
trunk or Corona.
For that purpose add a 'cocoon-staging' profile to your Maven settings.xml:
profile
idcocoon-staging/id
repositories
repository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
/repository
/repositories
pluginRepositories
pluginRepository
idcocoon.staging/id
nameCocoon staging repository/name
urlhttp://people.apache.org/builds/cocoon/url
/pluginRepository
/pluginRepositories
/profile
and use the proposed artifacts instead of SNAPSHOT versions.
- o -
You can find the staged files for all modules (sources, binaries,
javadocs, checksums, gpg signatures) at
- http://people.apache.org/builds/cocoon/
(Maven 2 repo)
- http://people.apache.org/~reinhard/cocoon-staging/
(Standard release artifacts)
SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/tags/.
This majority vote stays open for 72 hours.
Please cast your votes.
Here is my +1 (after successfully testing with Cocoon trunk and Corona).
--
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] Cocoon 3.0
Reinhard Pötz schrieb: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. +1 Felix
Re: [vote] Cocoon 3.0
Hi 2008/8/6 Reinhard Pötz [EMAIL PROTECTED]: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. +1 (The king is dead, long live the king!) Andrew. -- [EMAIL PROTECTED] / [EMAIL PROTECTED] http://www.andrewsavory.com/
Re: [vote] Cocoon 3.0
Reinhard Pötz skrev: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. +1 /Daniel
Re: [vote] Cocoon 3.0
On Wed, 2008-08-06 at 13:19 +0200, Reinhard Pötz wrote: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. +1 salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: [vote] Cocoon 3.0
+1 Carsten Reinhard Pötz wrote: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. This majority vote stays open for 72 hours. Please cast your votes. Here is my +1 -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Reinhard Pötz wrote: yes, I was too lazy to touch nearly every POM file in our repository just to increase the version number of our parent POMs. I haven't done this for the last release either and AFAICT, no problem occurred. Does anybody know if it can cause problems if the development version number isn't increased after a release? I think we shouldn't change the version number just for the sake of changing it. If the pom doesn't change why should we increase the version number? I think we should simply drop the parent relationship from all modules and use the current parent poms just as reactor poms. Every real module pom directly has our root pom as the parent. This makes releasing imho much easier as there is no release of any intermediate pom required anymore. We're using this approach for a very long time now and it has made things much easier. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Carsten Ziegeler wrote:
Reinhard Pötz wrote:
yes, I was too lazy to touch nearly every POM file in our repository
just to increase the version number of our parent POMs. I haven't done
this for the last release either and AFAICT, no problem occurred.
Does anybody know if it can cause problems if the development version
number isn't increased after a release?
I think we shouldn't change the version number just for the sake of
changing it.
I was releasing cocoon-parent because I wanted to use the latest
versions of some plugins and some dependencies (e.g. Spring).
If the pom doesn't change why should we increase the version number?
sure, in that case there is no need
I think we should simply drop the parent relationship from all modules
and use the current parent poms just as reactor poms. Every real module
pom directly has our root pom as the parent. This makes releasing imho
much easier as there is no release of any intermediate pom required
anymore. We're using this approach for a very long time now and it has
made things much easier.
+1, exept for cocoon-core-modules because this allows a release of all
of our core modules in one go (multi-module release).
--
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: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Reinhard Pötz wrote: I was releasing cocoon-parent because I wanted to use the latest versions of some plugins and some dependencies (e.g. Spring). Ah yes, ok - Personally I would not change the references of all modules to the latest snapshot of the parent pom after a release. The modules should be indepedent. Now comes the problematic part: As soon as you end up with two modules referencing different parent pom with a dependency management, and let's say the older parent pom references a lib or plugin in version X while the newer parent pom references the same lib or plugin in a different version Y, all modules are build with one or the other version in a multi project build. Which version is used for the whole build depends on the order how maven reads the poms (and it seems that this order is not deterministic as we had problems on some machines while it worked on others because of a different order). And obviously if just one version is used for the whole build this might cause build problems - which look very strange as all your poms are correct! Ok, long story, because of this maven bug (or is it by design?) it's much safer to make a search/replace after releasing the parent pom and update *all* modules to the new trunk version. Or, which is the slightly better but more difficult option, do this after you apply the first change to the parent pom after a release. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Grzegorz Kossakowski wrote:
Reinhard Pötz pisze:
yes, I was too lazy to touch nearly every POM file in our repository
just to increase the version number of our parent POMs. I haven't done
this for the last release either and AFAICT, no problem occurred.
Hmmm, find, xargs and sed should do this work within one minute. :-)
it's a bit more difficult but in general yes.
Actually we already have such a script (tools/pom-updater) but still I
always managed to break the build.
Does anybody know if it can cause problems if the development version
number isn't increased after a release?
I would say that it's at least confusing. So how does this work now? We
have a new version of parent pom but we reference to the old one. Which
version is chosen finally?
All our POMs in snapshot mode refer to the (not-changing) cocoon-parent POM.
After writing this I see the potential problem: If we want to use some
of our own modules in their released versions, they would pull in the
released cocoon-parent POM. This could lead to some unwanted side-effects.
This means that if we want to use released versions of our own modules,
we have to increase the version number of cocoon-parent and should
follow Carsten's proposal and remove all intermediary POMs
(tools-modules, blocks-modules) except core-modules.
--
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]
Cocoon GT 2008
Dear Devs Nearly a month ago I have asked on the user list if there is any news about the Cocoon GT in 2008. Since I did not have any response I repost my question to the dev-list. I would really appreciate to meet the community again this year. So do we will have a Cocoon GT this year? For your feedback many thanks in advance Raffaele
RE: [vote] Cocoon 3.0
-Original Message- From: Reinhard Pötz [mailto:[EMAIL PROTECTED] Sent: woensdag 6 augustus 2008 13:20 To: dev@cocoon.apache.org Subject: [vote] Cocoon 3.0 Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. +1 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: [vote] Java 1.5 as minimal requirement for trunk
-Original Message- From: Grzegorz Kossakowski [mailto:[EMAIL PROTECTED] Sent: dinsdag 5 augustus 2008 15:08 To: Cocoon's dev mailing list Subject: [vote] Java 1.5 as minimal requirement for trunk Hello, As discussed in thread Cocoon-jms-sample requires Java = 1.5[1] there are more and more problems with keeping Java 1.4 compatibility in trunk. After a while it turned out that everybody agrees on the need for dropping Java 1.4 compatibility and in that case, switching to Java 1.5 as minimal required version seems to be the best solution. In order to do that, we need a formal vote that I'm calling now. Please cast your votes: +1 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: [vote] Cocoon 3.0
On Wed, Aug 6, 2008 at 6:19 AM, Reinhard Pötz [EMAIL PROTECTED] wrote: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. +1 Seems a little weird but I certainly don't have any better alternatives. -- Peter Hunsberger
Re: [vote] Cocoon 3.0
+1 Reinhard Pötz wrote: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. This means that any reference on Corona in source files, package names, artifact ids, group ids or anywhere else will be dropped and the standard Cocoon namespace org.apache.cocoon will be used. This majority vote stays open for 72 hours. Please cast your votes. Here is my +1
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Reinhard Pötz wrote: Grzegorz Kossakowski wrote: [EMAIL PROTECTED] pisze: Author: reinhard Date: Tue Aug 5 12:42:45 2008 New Revision: 682901 URL: http://svn.apache.org/viewvc?rev=682901view=rev Log: back in snapshot mode Modified: cocoon/trunk/tools/pom.xml Modified: cocoon/trunk/tools/pom.xml URL: http://svn.apache.org/viewvc/cocoon/trunk/tools/pom.xml?rev=682901r1=682900r2=682901view=diff == --- cocoon/trunk/tools/pom.xml (original) +++ cocoon/trunk/tools/pom.xml Tue Aug 5 12:42:45 2008 @@ -26,7 +26,7 @@ parent groupIdorg.apache.cocoon/groupId artifactIdcocoon/artifactId -version7/version +version5-SNAPSHOT/version relativePath../parent/relativePath Development version is lower than released one. Is it intended? yes, I was too lazy to touch nearly every POM file in our repository just to increase the version number of our parent POMs. I haven't done this for the last release either and AFAICT, no problem occurred. Does anybody know if it can cause problems if the development version number isn't increased after a release? I'm actually working on a fix to maven for this at the moment. It would allow you to put versionMAVEN_PARENT_VERSION/version in the pom instead of an actual version number. Don't get your hopes up though. I've been working on this for the last few weeks in the precious little available time I have right now. The thing that makes it difficult is that when your pom gets installed or deployed it has to have a real version number in it. Ralph
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
Ralph Goers wrote I'm actually working on a fix to maven for this at the moment. It would allow you to put versionMAVEN_PARENT_VERSION/version in the pom instead of an actual version number. Don't get your hopes up though. I've been working on this for the last few weeks in the precious little available time I have right now. The thing that makes it difficult is that when your pom gets installed or deployed it has to have a real version number in it. And how does this work, if you just check out a single module instead of the whole tree? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [vote] Cocoon 3.0
Reinhard Pötz reinhard at apache.org writes: Following the result of our recent discussion about the future of Corona, I propose Corona to become Cocoon 3. +1 Joerg
Re: [vote] Java 1.5 as minimal requirement for trunk
Grzegorz Kossakowski grek at tuffmail.com writes: switching to Java 1.5 as minimal required version +1 Joerg
Re: Is it necessary to increase the development version number (SNAPSHOT) after a release?
It uses the relative path so you will need the parent also. Carsten Ziegeler wrote: Ralph Goers wrote I'm actually working on a fix to maven for this at the moment. It would allow you to put versionMAVEN_PARENT_VERSION/version in the pom instead of an actual version number. Don't get your hopes up though. I've been working on this for the last few weeks in the precious little available time I have right now. The thing that makes it difficult is that when your pom gets installed or deployed it has to have a real version number in it. And how does this work, if you just check out a single module instead of the whole tree? Carsten
[jira] Subscription: COCOON-open-with-patch
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
[GSoC] Proposal modification
Hello, after investing some time in the WebDAV block and meeting Reinhard today, none of us can spot a way to migrate this block to Spring easily and provide integration tests with embedded Jackrabbit. Migration process originally aimed at removing Slide specific dependencies. Due to lack of DASL capabilities of Jackrabbit, this becomes impossible in an easy way. To proceed, I would have to a) fix the HTTPClient version incompatibility issue [1] b) find a way to get rid of Slide specific stuff c) implement DASL capabilities using JCR (JSR-170 [2]) By the way, Reinhard suggested to deal with the cocoon-jcr block instead. If no one objects, I would proceed to do so, as SoC time already is advanced. Regards, Lukas [1] https://issues.apache.org/jira/browse/COCOON-2153 [2] http://jcp.org/en/jsr/detail?id=170
