Re: AW: Developer Survey Results
During the past years, I always felt it was somehow my duty as chair to write reports, ensure someone answers to incoming requests, etc... So yes it is formally a simple secretarial role, but as a someone only involved in a now-retired-version (2.1), I think it'd be good for the project that the chair is actually involved in the current live branch. So good news if you're willing to take the hat :) My 2 cents, Cédric Le 29/02/2024 à 16:48, Christofer Dutz a écrit : Hi all, Admittedly the Chair position is a simple secretarial role. So, if this is the problem nobody wants to take on … I’d be willing to do that paperwork for a while. Chris *Von: *Torsten Curdt *Datum: *Donnerstag, 29. Februar 2024 um 01:19 *An: *dev@cocoon.apache.org *Betreff: *Developer Survey Results The Developer survey is now open for 9 days. We have received 10 responses. 5 were from PMC members. Here are the results https://app.edkimo.com/results/ewevipve My takeaways: - 7 disagree to retire - only 10 responses is discouraging - but 6 say they can make time and imagine to continue work on Cocoon - I really hope the person that can imagine to be PMC chair will step forward - 2.1 is still the most widely used version (and I am curious how this can be merged into a single path forward) cheers, Torsten
Re: AW: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
+1
Cédric
Le 23/01/2024 à 17:25, Christofer Dutz a écrit :
Yeah … I also think that possibly making them read-only (and
additionally prefixing them with a “retired/” prefix should be enough.
Chris
*Von: *Cédric Damioli
*Datum: *Freitag, 12. Januar 2024 um 20:48
*An: *dev@cocoon.apache.org
*Betreff: *Re: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
Why should retired branches be deleted ?
Shouldn't they instead be somehow put in read-only state but kept
available for anyone needing them ?
My 2 cents,
Cédric
Le 09/01/2024 à 14:40, Christofer Dutz a écrit :
So, I guess the deletion of the “retired” branches should probably
be done by a PMC member.
I’m happy to help with migrating 2.3.x to git as soon as the old
stuff is buried, if the project wants this to happen.
Chris
*Von: *Christofer Dutz
<mailto:christofer.d...@c-ware.de>
*Datum: *Montag, 18. Dezember 2023 um 20:25
*An: *dev@cocoon.apache.org
<mailto:dev@cocoon.apache.org>
*Betreff: *AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
How about a Mexican style funeral party at Community Over Code? ;-)
Cocoon 2.1 was such a big part of my early IT carreer …
Chris
*Von: *Cédric Damioli
<mailto:cdami...@apache.org>
*Datum: *Montag, 18. Dezember 2023 um 19:40
*An: *dev@cocoon.apache.org
<mailto:dev@cocoon.apache.org>
*Betreff: *[RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
The vote is now over and successful with 4 binding +1 and no -1 :
* Francesco Chicchiriccò
* Peter Hunsberger
* Jörg Heinicke
* Cédric Damioli
The PMC is now tasked to do what is needed to effectively retire
2.1/3.0.
As discussed before, it's now time for volunteers to step up to do
whatever is needed to actively maintain a now-refocused Cocoon
project (migration to Git, dependencies upgrades, ...).
Farewell, good old 2.1 :)
Regards,
Cédric
Le 13/12/2023 à 15:00, Cédric Damioli a écrit :
Hi,
Following and according to last weeks' discussions, it seems
that the general consensus would be to retire 2.1 (too old to
be maintained) and 3.0 (too alpha to be maintained), and keep
2.x around for now.
If I try to summarize what have been said, refocusing on a
single product would give the project a chance to 1) provide a
clear upgrade path to existing 2.1 users and 2) gather renewed
interest.
For the still many existing 2.1 users, this would give a clear
signal that it's time to consider other options.
It's now time to formally vote:
[ ] +1 accept (retire and officially stop the maintenance of
2.1/3.0 branches, only keeping 2.x)
[ ] -1 reject (explanation required)
A minimum of 3 binding +1 votes and more binding +1 than
binding -1 are required to pass.
This vote will be open for at least 72 hours.
Best regards,
Cédric
Re: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
Why should retired branches be deleted ? Shouldn't they instead be somehow put in read-only state but kept available for anyone needing them ? My 2 cents, Cédric Le 09/01/2024 à 14:40, Christofer Dutz a écrit : So, I guess the deletion of the “retired” branches should probably be done by a PMC member. I’m happy to help with migrating 2.3.x to git as soon as the old stuff is buried, if the project wants this to happen. Chris *Von: *Christofer Dutz *Datum: *Montag, 18. Dezember 2023 um 20:25 *An: *dev@cocoon.apache.org *Betreff: *AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x How about a Mexican style funeral party at Community Over Code? ;-) Cocoon 2.1 was such a big part of my early IT carreer … Chris *Von: *Cédric Damioli *Datum: *Montag, 18. Dezember 2023 um 19:40 *An: *dev@cocoon.apache.org *Betreff: *[RESULT][VOTE] Retire 2.1/3.0 and keep 2.x The vote is now over and successful with 4 binding +1 and no -1 : * Francesco Chicchiriccò * Peter Hunsberger * Jörg Heinicke * Cédric Damioli The PMC is now tasked to do what is needed to effectively retire 2.1/3.0. As discussed before, it's now time for volunteers to step up to do whatever is needed to actively maintain a now-refocused Cocoon project (migration to Git, dependencies upgrades, ...). Farewell, good old 2.1 :) Regards, Cédric Le 13/12/2023 à 15:00, Cédric Damioli a écrit : Hi, Following and according to last weeks' discussions, it seems that the general consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha to be maintained), and keep 2.x around for now. If I try to summarize what have been said, refocusing on a single product would give the project a chance to 1) provide a clear upgrade path to existing 2.1 users and 2) gather renewed interest. For the still many existing 2.1 users, this would give a clear signal that it's time to consider other options. It's now time to formally vote: [ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, only keeping 2.x) [ ] -1 reject (explanation required) A minimum of 3 binding +1 votes and more binding +1 than binding -1 are required to pass. This vote will be open for at least 72 hours. Best regards, Cédric
[ANN] Apache Cocoon 2.1 and 3.0 retired
Apache Cocoon 2.1 and 3.0 retired - After the recent release of Cocoon 2.3.0, the Apache Cocoon Community has decided to retire both 2.1 and 3.0 versions, to focus on further developments of the 2.3 branch The 2.1 branch was first released more than 20 years ago and is now considered obsolete. The 3.0 version was an attempt to rewrite Cocoon from scratch, but was never finalized. Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built around the concepts of separation of concerns and component-based development. Cocoon implements these concepts around the notion of component pipelines, each component on the pipeline specializing on a particular operation. 2.3.0 is the continuation of Cocoon 2.2 for contemporary Java versions. Apache Cocoon 2.3.0 may be downloaded from https://cocoon.apache.org/mirror.html For more information about Apache Cocoon, please go to https://cocoon.apache.org
[RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
The vote is now over and successful with 4 binding +1 and no -1 : * Francesco Chicchiriccò * Peter Hunsberger * Jörg Heinicke * Cédric Damioli The PMC is now tasked to do what is needed to effectively retire 2.1/3.0. As discussed before, it's now time for volunteers to step up to do whatever is needed to actively maintain a now-refocused Cocoon project (migration to Git, dependencies upgrades, ...). Farewell, good old 2.1 :) Regards, Cédric Le 13/12/2023 à 15:00, Cédric Damioli a écrit : Hi, Following and according to last weeks' discussions, it seems that the general consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha to be maintained), and keep 2.x around for now. If I try to summarize what have been said, refocusing on a single product would give the project a chance to 1) provide a clear upgrade path to existing 2.1 users and 2) gather renewed interest. For the still many existing 2.1 users, this would give a clear signal that it's time to consider other options. It's now time to formally vote: [ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, only keeping 2.x) [ ] -1 reject (explanation required) A minimum of 3 binding +1 votes and more binding +1 than binding -1 are required to pass. This vote will be open for at least 72 hours. Best regards, Cédric -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: [VOTE] Retire 2.1/3.0 and keep 2.x
Here is my +1: [X] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, only keeping 2.x) Cédric Le 13/12/2023 à 15:00, Cédric Damioli a écrit : Hi, Following and according to last weeks' discussions, it seems that the general consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha to be maintained), and keep 2.x around for now. If I try to summarize what have been said, refocusing on a single product would give the project a chance to 1) provide a clear upgrade path to existing 2.1 users and 2) gather renewed interest. For the still many existing 2.1 users, this would give a clear signal that it's time to consider other options. It's now time to formally vote: [ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, only keeping 2.x) [ ] -1 reject (explanation required) A minimum of 3 binding +1 votes and more binding +1 than binding -1 are required to pass. This vote will be open for at least 72 hours. Best regards, Cédric -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: Probably first user-question since many years ;-)
Don't know for 2.3, but in 2.1 there is an abstraction of the request/response model, allowing to have eg. CommandLineRequest/CommandLineResponse to achieve your needs. It's actually very useful, I use it frequently to call Cocoon pipelines from random threads, not linked to an actual http request. I've developed my own BackgroundRequest/BackgroundResponse more suiting my needs, but the concept is the same. Cédric Le 14/12/2023 à 08:50, Christofer Dutz a écrit : Hi all, as we’re thinking of giving 2.3 another try … I’m trying to make the ideas I had a bit more concrete … As some of you might know, I’m working mainly in the Industrial IoT area … here we have loads of data in odd data-structures and in general industial IoT consists of converting one odd format into another odd format. Currently most use some super tricky conversion tools …. I would love to try setup Cocoon pipelines, that validate and transform this information. So, my question is: Can Cocoon also be run as a pure xml pipelining framework that doesn’t necessarily serve Web-clients? Chris -- Cédric Damioli CMS - Java - Open Source www.ametys.org
[VOTE] Retire 2.1/3.0 and keep 2.x
Hi, Following and according to last weeks' discussions, it seems that the general consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha to be maintained), and keep 2.x around for now. If I try to summarize what have been said, refocusing on a single product would give the project a chance to 1) provide a clear upgrade path to existing 2.1 users and 2) gather renewed interest. For the still many existing 2.1 users, this would give a clear signal that it's time to consider other options. It's now time to formally vote: [ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, only keeping 2.x) [ ] -1 reject (explanation required) A minimum of 3 binding +1 votes and more binding +1 than binding -1 are required to pass. This vote will be open for at least 72 hours. Best regards, Cédric
Re: [DISCUSS] Retiring 2.1.x ? (Was: Re: Future of the Cocoon project)
Le 01/12/2023 à 18:13, Cédric Damioli a écrit : We'd like to know whether you'd prefer: [ ] retiring Cocoon 2.1.x [ ] reviving/maintaining Cocoon 2.1.x, meaning that you volunteer to be somehow involved I'd vote +/-0 here ... Definitively the toughest for me ... I still heavily use Cocoon 2.1 core, but I recognize that it's an very old piece of software, and that maintaining it here would demand more and more work. Perhaps it could be wiser to also let it go, and then fork the core elsewhere if needed with a new build system, without all block stuff, ... I'm curious to see what will others say about it. Cédric
Re: [DISCUSS] Retiring 2.x ? (Was: Re: Future of the Cocoon project)
Le 01/12/2023 à 18:00, Cédric Damioli a écrit : We'd like to know whether you'd prefer: [ ] retiring Cocoon 2.x [ ] reviving/maintaining Cocoon 2.x, meaning that you volunteer to be somehow involved I'd vote +0 for retiring 2.x, holding my thoughts until the result of this thread. I personally don't use it nor plan to use it, but with my PMC member hat on, I see that there's still some interest around here. The current PMC and committers roster is not sufficient to keep the project alive, but with new volunteers, why not ... Cédric
Re: [DISCUSS] Retiring 3.0 ? (Was: Re: Future of the Cocoon project)
Le 01/12/2023 à 17:41, Cédric Damioli a écrit : We'd like to know whether you'd prefer: [ ] retiring Cocoon 3.0 [ ] reviving/maintaining Cocoon 3.0, meaning that you volunteer to be somehow involved I'd vote +1 for retiring Cocoon 3.0, as during the past 10+ years, I had seen no thread, no questions about it. I personally have never tried it. Cédric
[DISCUSS] Retiring 2.1.x ? (Was: Re: Future of the Cocoon project)
Hi, Last thread to discuss about Cocon 2.1.x branch, with 2.1.13 released 3 years ago. Cocoon 2.1 has no dependencies to Maven/Spring and rely on the old Avalon stuff instead. Its build system is way outdated, there's no dependency management and many blocks rely on obsolete/unmaintained 3rd party libs, but its core is still reliable. Unfortunately, there's no easy way to migrate from Cocoon 2.1 to 2.2, that's why this branch still exists. We'd like to know whether you'd prefer: [ ] retiring Cocoon 2.1.x [ ] reviving/maintaining Cocoon 2.1.x, meaning that you volunteer to be somehow involved Please note that the above proposal is not a formal vote, but more like a open poll, so that everyone could speak out. Cédric Le 30/11/2023 à 19:53, Cédric Damioli a écrit : Dear Cocoon users and developers, Sorry for crossposting here, I wanted to be sure that all involved people were aware of the ongoing discussions. We recently pushed a new release of Cocoon, 11 years after the previous one. This release gathers all changes made in between as well as two security fixes discovered last year. The journey to roll this release out was definitively not an easy one, and it's now time to think about what should be next for the project. We currently officially maintain 3 branches, not compatible with each others and having evolved differently over the years : 2.1.x, 2.2/2.3 and 3.0, and we do not have enough active developers to be able to continue to properly and correctly maintain them. For a project as old as Cocoon (21 years!), there may be many users around here still using one branch or another, which could be interested to step up, contribute and try to revive the project, or at least some parts of it. I will soon start 3 threads on the developers list to decide what to do about each of the 3 branches (retiring or not), so I encourage volunteers to bring their voices. Best regards, Cédric, on behalf of the Apache Cocoon PMC -- Cédric Damioli CMS - Java - Open Source www.ametys.org
[DISCUSS] Retiring 2.x ? (Was: Re: Future of the Cocoon project)
Hi, Second thread to discuss about Cocon 2.x branch, with the latest release, 2.3.0, just being rolled out. Cocoon 2.2 was initially meant to implements all stuff developed during the 2.1 cycle on top of Spring and Maven, to drop old Avalon dependencies. We'd like to know whether you'd prefer: [ ] retiring Cocoon 2.x [ ] reviving/maintaining Cocoon 2.x, meaning that you volunteer to be somehow involved Please note that the above proposal is not a formal vote, but more like a open poll, so that everyone could speak out. Should we continue the project and this branch particularly, there are recent threads on this list proposing to switch to Git, to upgrade dependencies, build system, ... Cédric Le 30/11/2023 à 19:53, Cédric Damioli a écrit : Dear Cocoon users and developers, Sorry for crossposting here, I wanted to be sure that all involved people were aware of the ongoing discussions. We recently pushed a new release of Cocoon, 11 years after the previous one. This release gathers all changes made in between as well as two security fixes discovered last year. The journey to roll this release out was definitively not an easy one, and it's now time to think about what should be next for the project. We currently officially maintain 3 branches, not compatible with each others and having evolved differently over the years : 2.1.x, 2.2/2.3 and 3.0, and we do not have enough active developers to be able to continue to properly and correctly maintain them. For a project as old as Cocoon (21 years!), there may be many users around here still using one branch or another, which could be interested to step up, contribute and try to revive the project, or at least some parts of it. I will soon start 3 threads on the developers list to decide what to do about each of the 3 branches (retiring or not), so I encourage volunteers to bring their voices. Best regards, Cédric, on behalf of the Apache Cocoon PMC -- Cédric Damioli CMS - Java - Open Source www.ametys.org
[DISCUSS] Retiring 3.0 ? (Was: Re: Future of the Cocoon project)
Hi, First of the sub-project to be discussed, the Cocoon 3 project. Never released, it only reached the alpha status 12 years ago. Its goal was to provide a pure Java API on top of pipelines and sitemaps concept, to be able to easily implements lightweight REST applications. We'd like to know whether you'd prefer: [ ] retiring Cocoon 3.0 [ ] reviving/maintaining Cocoon 3.0, meaning that you volunteer to be somehow involved Please note that the above proposal is not a formal vote, but more like a open poll, so that everyone could speak out. Cédric Le 30/11/2023 à 19:53, Cédric Damioli a écrit : Dear Cocoon users and developers, Sorry for crossposting here, I wanted to be sure that all involved people were aware of the ongoing discussions. We recently pushed a new release of Cocoon, 11 years after the previous one. This release gathers all changes made in between as well as two security fixes discovered last year. The journey to roll this release out was definitively not an easy one, and it's now time to think about what should be next for the project. We currently officially maintain 3 branches, not compatible with each others and having evolved differently over the years : 2.1.x, 2.2/2.3 and 3.0, and we do not have enough active developers to be able to continue to properly and correctly maintain them. For a project as old as Cocoon (21 years!), there may be many users around here still using one branch or another, which could be interested to step up, contribute and try to revive the project, or at least some parts of it. I will soon start 3 threads on the developers list to decide what to do about each of the 3 branches (retiring or not), so I encourage volunteers to bring their voices. Best regards, Cédric, on behalf of the Apache Cocoon PMC -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Future of the Cocoon project
Dear Cocoon users and developers, Sorry for crossposting here, I wanted to be sure that all involved people were aware of the ongoing discussions. We recently pushed a new release of Cocoon, 11 years after the previous one. This release gathers all changes made in between as well as two security fixes discovered last year. The journey to roll this release out was definitively not an easy one, and it's now time to think about what should be next for the project. We currently officially maintain 3 branches, not compatible with each others and having evolved differently over the years : 2.1.x, 2.2/2.3 and 3.0, and we do not have enough active developers to be able to continue to properly and correctly maintain them. For a project as old as Cocoon (21 years!), there may be many users around here still using one branch or another, which could be interested to step up, contribute and try to revive the project, or at least some parts of it. I will soon start 3 threads on the developers list to decide what to do about each of the 3 branches (retiring or not), so I encourage volunteers to bring their voices. Best regards, Cédric, on behalf of the Apache Cocoon PMC
Re: AW: [ANN] Apache Cocoon 2.3.0 Released
There's even a @Cocoon3 account on X/Twitter, but I don't know who's behind. Cédric Le 28/11/2023 à 14:27, Christofer Dutz a écrit : Anyone sharing this on LinkedIn and X? Chris *Von: *Cédric Damioli *Datum: *Dienstag, 28. November 2023 um 14:17 *An: *us...@cocoon.apache.org , dev@cocoon.apache.org , annou...@apache.org *Betreff: *[ANN] Apache Cocoon 2.3.0 Released Apache Cocoon 2.3.0 Released - The Apache Cocoon Community is proud to announce the release of Cocoon 2.3.0. Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built around the concepts of separation of concerns and component-based development. Cocoon implements these concepts around the notion of component pipelines, each component on the pipeline specializing on a particular operation. This release, 11 years after 2.2.0, gathers all changes made since then, along with security fixes. The minimum Java version was also upgraded to 1.8 Apache Cocoon 2.3.0 may be downloaded from https://cocoon.apache.org/1284_1_1.html For more information about Apache Cocoon, please go to https://cocoon.apache.org -- Cédric Damioli CMS - Java - Open Source www.ametys.org
[ANN] Apache Cocoon 2.3.0 Released
Apache Cocoon 2.3.0 Released - The Apache Cocoon Community is proud to announce the release of Cocoon 2.3.0. Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built around the concepts of separation of concerns and component-based development. Cocoon implements these concepts around the notion of component pipelines, each component on the pipeline specializing on a particular operation. This release, 11 years after 2.2.0, gathers all changes made since then, along with security fixes. The minimum Java version was also upgraded to 1.8 Apache Cocoon 2.3.0 may be downloaded from https://cocoon.apache.org/1284_1_1.html For more information about Apache Cocoon, please go to https://cocoon.apache.org
Re: [DISCUSS] Switching to GIt?
I know my answer will be sort of chicken-egg issue, but I'd like to be sure that there is enough manpower to revive and/or continue to maintain the project, before putting efforts to move to Git. My 2 cents, Cédric Le 20/11/2023 à 15:43, Christofer Dutz a écrit : Hi all, I know that we currently have a mirror of the SVN in Github, however still the root repository is SVN, I would like to propose switching to using Git as the main repo. This would allow us to start using the normal GitHub Pull-Request workflow and possibly make it a lot easier for new contributors to contribute. Also, would I propose to start using GitHub Actions, GitHub Issues and GitHub discussions as in other projects this has proven to lower the barriers for new contributors (And it avoids the Jira account approving nightmare). With the changes in the messaging defaults, that I recently deployed, mirroring GitHub activity to the dev-list should allow everyone to participate. What do the others think? Chris
Re: Now that the release is out, what's next?
Hi, On top of that, as a community, we now have to formally answer to the below question (going or not to the Attic) not only once, but three times, one time for each subproject we still officially maintain since more than 10 years : - Cocoon 2.1.x (pre-Spring, pre-Maven). Last release 2.1.13 was rolled out 3 years ago. - Cocoon 2.2x (now 2.3.x). Last release these days. - Cocoon 3.0.x. Last release 3.0.0-alpha-3 back in 2011 Those 3 versions are not compatible with each other, are not meant as drop-in replacements, and have evolved differently over the years. The community could either decide to stop the project as-is and go to the Attic, or start over maintaining only one or two branches. Cédric Le 19/11/2023 à 18:20, Christofer Dutz a écrit : Hi folks, So, it seems that we finally have finished the last missing steps to formally get the release out the door. Now I think comes a time where we should reflect and discuss, what should happen with the Project. So instead of simply saying: Releasing it was such a struggle (not technically, but from a participation side) I wouldn’t say this project is healthy and we should discuss a move into the Attic. However, I could also imagine that the changes I implemented in the build might encourage some folks to give it another go. I know when I was doing projects with Cocoon as part of my day-job 20 years ago, Cocoon 2.2 sort of completely broke my flow. Not only my inexperience with Maven, but also that of Spring and the versioning scheme where all sorts of cocoon modules had different versions just made me give up at that time and switch to Adobe Flex ;-) Now (15 years later) Maven and Spring have evolved and with the cleanups in the build, it should be a lot simpler to work with Cocoon and with all modules sharing the same version, also this should be a lot simpler. So, I would like to ask you folks: * Should we aim directly for the Attic? * Does anyone want to revive the project? (I’m intentionally not only addressing committers and PMC members, but also people wanting to keep the project alive) Chris -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
- signature ok - checksum ok - Build ok (Windows, java 17) - Jetty launch ok - A few samples tested ok (I've not tested all samples, nor I am able to test this RC in a real world app, I don't use any Cocoon 2.2) Here's my +1 Cédric Le 29/10/2023 à 12:55, Christofer Dutz a écrit : Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote on accepting it for release. All Maven artifacts are available under [1]. Voting will be open for 72hr. A minimum of 3 binding +1 votes and more binding +1 than binding -1 are required to pass. Release tag:https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/ <https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/> Director revision of the tag: 1913422 Per [3] "Before voting +1 PMC members are required to download the signed source code package, compile it as provided, and test the resulting executable on their own platform, along with also verifying that the package meets the requirements of the ASF policy on releases." You can achieve the above by following the guide of a fellow Apache project [4]. [ ] +1 accept (indicate what you validated - e.g. performed the non-RM items in [4]) [ ] -1 reject (explanation required) <https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release> -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: [VOTE] Apache Cocoon 2.3.0 RC1
Hi Christofer, First of all, many thanks for the huge work you made so far for helping us finally rolling out a release. Which is the target JVM for this release ? On my Windows laptop, I can't compile with JDK 8, due to external dependencies being only JDK11+ And I also can't compile with JDK11+, due to XSP block complaining that it can't find tools.jar Cédric Le 24/10/2023 à 20:50, Christofer Dutz a écrit : Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote on accepting it for release. All Maven artifacts are available under [1]. Voting will be open for 72hr. A minimum of 3 binding +1 votes and more binding +1 than binding -1 are required to pass. Release tag: https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/ Director revision of the tag: 1913280 Per [3] "Before voting +1 PMC members are required to download the signed source code package, compile it as provided, and test the resulting executable on their own platform, along with also verifying that the package meets the requirements of the ASF policy on releases." You can achieve the above by following the guide of a fellow Apache project [4]. [ ] +1 accept (indicate what you validated - e.g. performed the non-RM items in [4]) [ ] -1 reject (explanation required) [1] https://repository.apache.org/content/repositories/orgapachecocoon-1006 <https://repository.apache.org/content/repositories/orgapachecocoon-1006> [2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc1/ <https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc1/> [3] https://www.apache.org/dev/release.html#approving-a-release <https://www.apache.org/dev/release.html#approving-a-release> [4] https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release <https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release> -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: svn commit: r1878905 - /cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/generation/StreamGenerator.java
coon/branches/BRANCH_2_1_X/src/webapp/WEB-INF/cocoon.xconf?view=markup#l363
Also check the place when we add to the manager the parser that is set
in cocoon.xconf:
http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/java/org/apache/cocoon/Cocoon.java?view=markup#l298
I think, there should be a way to configure the new parser in
cocoon.xconf instead of hard coding it in the stream generator. Please
note the same code using the line:
parser = (SAXParser)this.manager.lookup(SAXParser.ROLE);
is used in many place in the coocon code.
+ }
+
+ SAXParser parser = factory.newSAXParser();
+ XMLReader xmlReader = parser.getXMLReader();
+ xmlReader.setContentHandler(super.xmlConsumer);
+ xmlReader.setProperty(
"http://xml.org/sax/properties/lexical-handler;, super.xmlConsumer );
+ xmlReader.setFeature(
"http://xml.org/sax/features/namespaces;, true );
+
+ xmlReader.parse(this.inputSource);
+
I am afraid that with the above code, we loose this control and
perhaps we are creating a vector to shutdown the server by sending too
many instances that create a lot of parsers.
} catch (IOException e) {
getLogger().error("StreamGenerator.generate()", e);
throw new ResourceNotFoundException("StreamGenerator
could not find resource", e);
@@ -161,9 +183,7 @@ public class StreamGenerator extends Ser
} catch (Exception e) {
getLogger().error("Could not get parser", e);
throw new ProcessingException("Exception in
StreamGenerator.generate()", e);
- } finally {
- this.manager.release( parser);
- }
+ }
}
/**
@@ -208,7 +228,7 @@ public class StreamGenerator extends Ser
return extractCharset( contentType, idx );
}
}
-
+
protected String extractCharset(String contentType, int idx) {
String charencoding = null;
--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org
[CVE-2020-11991] Apache Cocoon security vulnerability
[CVE-2020-11991] Apache Cocoon security vulnerability Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Cocoon up to 2.1.12 Description: When using the StreamGenerator, the code parse a user-provided XML. A specially crafted XML, including external system entities, could be used to access any file on the server system. Mitigation: The StreamGenerator now ignores external entities. 2.1.x users should upgrade to 2.1.13 Example: With the following input : "file:///etc/shadow"> ]> John an attacker got the content of /etc/shadow Credit: This issue was discovered by Nassim Asrir. Regards, -- Cédric Damioli
[ANN] Apache Cocoon 2.1.13 Released
Apache Cocoon 2.1.13 Released - The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. Cocoon implements these concepts around the notion of 'component pipelines' modelled after the 'process chain' concept where each worker specializes on a particular operation. This makes it possible to use a Lego(tm)-like approach in building web solutions where these components can be hooked together into pipelines without requiring further programming. We like to think at Cocoon as "web glue" for your web application development needs. But most important, a glue that can keep concerns separate and allow parallel evolution of the two sides, improving development pace and reducing the chance of conflicts. For more information about Apache Cocoon 2.1.13, please go to http://cocoon.apache.org Changes with Apache Cocoon 2.1.13 *) Starting with 2.1.13 the minimum required Java version will be 1.6. [all] *) Cannot start Cocoon 2.1.12 on Windows [FC] *) Cannot build with Java 7 [FC] *) Use ImageIO instead of old com.sun.image.* package in ImageReader [FC] *) Apache license at the beginning cocoon's dojo widgets templates causes: dojo.widget.Parse: error: [FC] *) XSP not working with Java 8 [FC] *) Make XMLResourceBundle (and -Factory) more extensible [CD] *) XMLResourceBundles are not available outside a Request [CD] *) Escape accolades in i18n messages [CD] *) ContextSourceFactory calculates the path incorrectly when removing the protocol part [FC] *) XMLEncoder doesn't support Unicode surrogate pairs [FC] *) Content-Range and Range headers does not respect the HTTP spec [CD] *) Inconsistent Content-Length header for HEAD requests [CD] *) Cannot upload a file with name containing a '=' or a ';' [CD] *) Unsynchronized HashMap.put in ResourceReader and GeneratorSelector may lead to infinite loop. [AN] *) Update to poi-3.14 (requires Java 1.6) [AN] *) Update to fop-1.1 [AN] *) Update to commons-httpclient-3.1 [AN] *) XSP: Use javax.tools.JavaCompiler interface for Javac (available since Java 6). [AN] *) Core: Update to xalan-2.7.2 and add serializer-2.7.2 [AN] *) Enable 'java' to be found by the build and run shell scripts on a modern Mac OS X. [DC]
[RESULT][VOTE] Release Cocoon 2.1.13
The vote for the 2.1.13 release passes with the 3 following +1 : - Francesco Chicchiriccò - Torsten Curdt - Cédric Damioli No others votes were cast. I'll put the release files on the server and try to update web site. Thanks to all. Best regards, Cédric
Re: [VOTE] Release Cocoon 2.1.13
Hi Torsten, I actually added my code signing key in https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/KEYS I wasn't aware of https://downloads.apache.org/cocoon/KEYS. I'll add my key to this file when uploading release artifacts. Is it ok for you ? Cédric Le 19/07/2020 à 19:18, Torsten Curdt a écrit : I did a gpg --import KEYS.txt just to make sure, but I am still getting gpg --verify cocoon-2.1.13-src.tar.gz.asc cocoon-2.1.13-src.tar.gz gpg: Signature made Fr 17 Jul 20:05:16 2020 CEST gpg: using RSA key F9E031E290C9797C7F4CC02576ABEF9A6CDA1E88 gpg: Can't check signature: No public key Is your key maybe missing from https://downloads.apache.org/cocoon/KEYS cheers, Torsten On Sat, Jul 18, 2020 at 7:08 AM Francesco Chicchiriccò mailto:ilgro...@apache.org>> wrote: On 17/07/20 20:40, Cédric Damioli wrote: > Hi, > > More than 7 years after the 2.1.12 release, I'm glad to propose to release Apache Cocoon 2.1.13 ! > > Proposed releases artifacts are located at https://dist.apache.org/repos/dist/dev/cocoon/ > > Please check the files, verify checksums, build and run samples, and cast your votes. +1 Thanks Cédric! Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/ -- Cédric Damioli CMS - Java - Open Source www.ametys.org
[VOTE] Release Cocoon 2.1.13
Hi, More than 7 years after the 2.1.12 release, I'm glad to propose to release Apache Cocoon 2.1.13 ! Proposed releases artifacts are located at https://dist.apache.org/repos/dist/dev/cocoon/ Please check the files, verify checksums, build and run samples, and cast your votes. Here is my +1 Regards, -- Cédric Damioli
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
Le 24/06/2020 à 10:52, Francesco Chicchiriccò a écrit : On 24/06/20 09:42, Cédric Damioli wrote: Le 24/06/2020 à 08:57, Francesco Chicchiriccò a écrit : On 23/06/20 23:20, Cédric Damioli wrote: Maybe we could do as you suggest - e.g. restore the previous xalan-2.7.2.jar and strip out the indicated classes - but also renaming it somehow, e.g. xalan-2.7.2-cocoon-2.1.13.jar and adding some explanation in lib/jars.xml about how we obtained this JAR from official Xalan's JAR. Does it sound reasonable? +1 with your proposal Glad to hear this, please go on. Committed. Could you check that the build is ok on your side ? Regards, Cédric
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
Le 24/06/2020 à 08:57, Francesco Chicchiriccò a écrit : On 23/06/20 23:20, Cédric Damioli wrote: Why not, but are we sure that we won't have regressions due to downgrade of jakarta-regexp (the xalan bundled version is 1.2 AFAIU) ? From a design POV, I find it quite strange to rely on an XSLT lib (ie Xalan) to provide regexp processing. Could it be better to remove org.apache.bcel and org.apache.regexp from the xalan jar and keep the existing librairies ? I suppose that was how it has been done previously for xalan-2.7.1 It seems you are quite right. I took cocoon-2.1.12-deps.tar.gz from http://cocoon.apache.org/mirror.html then extracted lib/endorsed/xalan-2.7.1.jar and found that it is *not the same* you can download from Maven Central under https://repo1.maven.org/maven2/xalan/xalan/2.7.1/xalan-2.7.1.jar but that it matches the one you can download from http://archive.apache.org/dist/xalan/xalan-j/binaries/xalan-j_2_7_1-bin-2jars.zip because it does not contain any org.apache.bcel.* nor any org.apache.regexp.* class. So I went ahead and replaced the current lib/endorsed/xalan-2.7.2.jar in the source tree with the one contained in http://archive.apache.org/dist/xalan/xalan-j/binaries/xalan-j_2_7_2-bin-2jars.zip and all went out smoothly. Problem solved :-) Regards. It can't be that easy :) The xalan-2.7.2 you just uploaded does not contains xsltc, whereas the previous xalan-2.7.1 did contain it. And the xsltc.jar comes bundled with cled and regexp. But you're completely right, it seems we did not have an official xalan jar. My suggestion, to preserve legacy behaviour, is to remove org.apache.(bcel|regexp).* from the full xalan jar. What do you think ? Well, in this era of reproducible builds, taking another project's dist artifact, mangle it and include it our own sources looks a bit... weird. At least, the current file comes actually unchanged from Xalan's release artifact. I totally agree. But the Cocoon 2.1.x build system was made in a pre-(ivy|maven) era and I think we don't want to take the time to re-engineer it. Maybe we could do as you suggest - e.g. restore the previous xalan-2.7.2.jar and strip out the indicated classes - but also renaming it somehow, e.g. xalan-2.7.2-cocoon-2.1.13.jar and adding some explanation in lib/jars.xml about how we obtained this JAR from official Xalan's JAR. Does it sound reasonable? +1 with your proposal Regards, Cédric
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
Why not, but are we sure that we won't have regressions due to downgrade of jakarta-regexp (the xalan bundled version is 1.2 AFAIU) ? From a design POV, I find it quite strange to rely on an XSLT lib (ie Xalan) to provide regexp processing. Could it be better to remove org.apache.bcel and org.apache.regexp from the xalan jar and keep the existing librairies ? I suppose that was how it has been done previously for xalan-2.7.1 It seems you are quite right. I took cocoon-2.1.12-deps.tar.gz from http://cocoon.apache.org/mirror.html then extracted lib/endorsed/xalan-2.7.1.jar and found that it is *not the same* you can download from Maven Central under https://repo1.maven.org/maven2/xalan/xalan/2.7.1/xalan-2.7.1.jar but that it matches the one you can download from http://archive.apache.org/dist/xalan/xalan-j/binaries/xalan-j_2_7_1-bin-2jars.zip because it does not contain any org.apache.bcel.* nor any org.apache.regexp.* class. So I went ahead and replaced the current lib/endorsed/xalan-2.7.2.jar in the source tree with the one contained in http://archive.apache.org/dist/xalan/xalan-j/binaries/xalan-j_2_7_2-bin-2jars.zip and all went out smoothly. Problem solved :-) Regards. It can't be that easy :) The xalan-2.7.2 you just uploaded does not contains xsltc, whereas the previous xalan-2.7.1 did contain it. And the xsltc.jar comes bundled with cled and regexp. But you're completely right, it seems we did not have an official xalan jar. My suggestion, to preserve legacy behaviour, is to remove org.apache.(bcel|regexp).* from the full xalan jar. What do you think ? Regards, Cédric
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
Le 22/06/2020 à 15:29, Francesco Chicchiriccò a écrit : On 22/06/20 12:11, Cédric Damioli wrote: Le 22/06/2020 à 08:57, Francesco Chicchiriccò a écrit : On 21/06/20 22:11, Cédric Damioli wrote: I just tested with JDK 1.6 and it worked fine (my exact JDK version is 1.6.0_18, Windows version). Mine is 1.6.0_45 (Linux) e.g. the one you can download at the moment from Oracle. I'm a bit worried if we must change to 1.8, as Cocoon 2.1.x is supposed to be compatible with 1.6. Furthermore, javac claims about a RESyntaxException being not catched, but it's actually a RuntimeException, so I don't see the problem ... The actual issue seems to be the fact that RESyntaxException is contained either by ./lib/endorsed/jakarta-regexp-1.5.jar and ./lib/endorsed/xalan-2.7.2.jar with the former extending RuntimeException and the latter extending Exception; so it actually depends on which one is picked during build, I'd say. Since all classes from the former JAR are included by the latter JAR, I think we should remove jakarta-regexp, but this will not solve the build problem, it will only make it more consistent - which I also believe it is better. Ok, understood. I was wondering why did this never happen before ? jakarta-regexp-1.5 and xalan are used since 10+ years together I just found than Xalan has been upgraded to 2.7.2 last year. Before that, our provided xalan-2.7.1 did not embed org.apache.regexp package Did we had our own xalan version ? BTW, a similar issue was raised 15 years ago :) : https://issues.apache.org/jira/browse/COCOON-1576 I was able to build (and run some tests - not all because I had not time to look up for HTMLUnit) with the changes embedded in this commit: https://github.com/ilgrosso/cocoon/commit/c438857f594d770d865f4e8b7244b5fda026f6b2 As you can see from there, I have: * removed jakarta-regexp-1.5 and introduced CocoonRESyntaxException to wrap RESyntaxException * replaced jakarta-bcel-20040329.jar (there were compilation errors) with bcel-5.2.jar - because of some visibility change, I introduced CocoonFrame Please have a look and let me know: in case we are fine with such changes, I would svn-commit to BRANCH_2_1_X and set COCOON-1576 as fixed in 2.1.13. Regards. Why not, but are we sure that we won't have regressions due to downgrade of jakarta-regexp (the xalan bundled version is 1.2 AFAIU) ? From a design POV, I find it quite strange to rely on an XSLT lib (ie Xalan) to provide regexp processing. Could it be better to remove org.apache.bcel and org.apache.regexp from the xalan jar and keep the existing librairies ? I suppose that was how it has been done previously for xalan-2.7.1 Regards, Cédric
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
Le 22/06/2020 à 08:57, Francesco Chicchiriccò a écrit : On 21/06/20 22:11, Cédric Damioli wrote: I just tested with JDK 1.6 and it worked fine (my exact JDK version is 1.6.0_18, Windows version). Mine is 1.6.0_45 (Linux) e.g. the one you can download at the moment from Oracle. I'm a bit worried if we must change to 1.8, as Cocoon 2.1.x is supposed to be compatible with 1.6. Furthermore, javac claims about a RESyntaxException being not catched, but it's actually a RuntimeException, so I don't see the problem ... The actual issue seems to be the fact that RESyntaxException is contained either by ./lib/endorsed/jakarta-regexp-1.5.jar and ./lib/endorsed/xalan-2.7.2.jar with the former extending RuntimeException and the latter extending Exception; so it actually depends on which one is picked during build, I'd say. Since all classes from the former JAR are included by the latter JAR, I think we should remove jakarta-regexp, but this will not solve the build problem, it will only make it more consistent - which I also believe it is better. Ok, understood. I was wondering why did this never happen before ? jakarta-regexp-1.5 and xalan are used since 10+ years together I just found than Xalan has been upgraded to 2.7.2 last year. Before that, our provided xalan-2.7.1 did not embed org.apache.regexp package Did we had our own xalan version ? BTW, a similar issue was raised 15 years ago :) : https://issues.apache.org/jira/browse/COCOON-1576 Cédric
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
I just tested with JDK 1.6 and it worked fine (my exact JDK version is 1.6.0_18, Windows version). I'm a bit worried if we must change to 1.8, as Cocoon 2.1.x is supposed to be compatible with 1.6. Furthermore, javac claims about a RESyntaxException being not catched, but it's actually a RuntimeException, so I don't see the problem ... Any idea ? Have others an issue with building Cocoon 2.1.x with Java 1.6 ? Cédric Le 20/06/2020 à 15:10, Francesco Chicchiriccò a écrit : On 19/06/20 19:43, Cédric Damioli wrote: With which JVM did you try to build ? I have an Oracle JDK 1.8 and everything is ok ... You are right, I tried OpenJDK 1.8 and it worked fine. Jenkins (and my former attempts) were based on Oracle JDK 1.6. Shall I update Jenkins conf? Regards. Le 19/06/2020 à 09:37, Francesco Chicchiriccò a écrit : FYI Jenkins is now failing with same failure I have locally when trying to build 2_1_X. Messaggio Inoltrato Oggetto:Cocoon 2.1.X - Build # 141 - Still Failing Data: Thu, 18 Jun 2020 22:07:35 + (UTC) Mittente: Apache Jenkins Server Rispondi-a: dev@cocoon.apache.org A: c...@cocoon.apache.org The Apache Jenkins build system has built Cocoon 2.1.X (build #141) Status: Still Failing Check console output at https://builds.apache.org/job/Cocoon%202.1.X/141/ to view the results. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Member at The Apache Software Foundation Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail http://home.apache.org/~ilgrosso/ -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
With which JVM did you try to build ? I have an Oracle JDK 1.8 and everything is ok ... Le 19/06/2020 à 09:37, Francesco Chicchiriccò a écrit : FYI Jenkins is now failing with same failure I have locally when trying to build 2_1_X. Messaggio Inoltrato Oggetto:Cocoon 2.1.X - Build # 141 - Still Failing Data: Thu, 18 Jun 2020 22:07:35 + (UTC) Mittente: Apache Jenkins Server Rispondi-a: dev@cocoon.apache.org A: c...@cocoon.apache.org The Apache Jenkins build system has built Cocoon 2.1.X (build #141) Status: Still Failing Check console output at https://builds.apache.org/job/Cocoon%202.1.X/141/ to view the results.
Upcoming 2.1.13 release
Hi all, It's been more than 7 years since we released 2.1.12. Along the years, a few issues have been resolved (see [1]), deserving a release. I'll prepare a release in the next days, even if the Apache release process should have change a lot since then :) If some of you have waiting patches, or some stuff to commit or talk about before this release, please do! Best regards, Cédric [1] https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12324118=12310170
Re: About recent commits to 2_1_X
With a release every 6 years, we could indeed adopt a more recent Java
version :)
I could vote +1 to such a move, if all tests pass and stable blocks have
been reported to work as before.
Should we ask to users@ ?
Regards,
Cédric
Le 21/02/2019 à 12:09, Nathaniel, Alfred a écrit :
Minimum Java version is now 1.6.
That's the version needed for POI 3.14.
It also solves a (mainly academic) issue in the XSP block.
Still the question whether we shouldn't go straight to 1.8.
It's frustrating to develop and then fail the build on Jenkins.
I doubt that anyone bothering to upgrade Cocoon wouldn't want to go to a more
recent JDK.
Cheers, Alfred.
-Original Message-
From: Cédric Damioli
Sent: Mittwoch, 20. Februar 2019 19:56
To: dev@cocoon.apache.org
Subject: [External Sender] Re: About recent commits to 2_1_X
I'm a bit lost here :)
After your recent commits, what is now the minimum Java version : 1.5,
1.6, 1.8 ?
Cédric
Le 19/02/2019 à 12:25, Nathaniel, Alfred a écrit :
Thanks, it was quite a long shot to develop on Java 8 and then Jenkins on 1.5.
-Original Message-
From: Francesco Chicchiriccò
Sent: Dienstag, 19. Februar 2019 12:10
To: dev@cocoon.apache.org
Subject: [External Sender] Re: About recent commits to 2_1_X
FYI I have just updated the job to run with JDK 1.6 (it used to be 1.5).
Now it seems to be back working, cool!
Regards.
On 19/02/19 11:36, Nathaniel, Alfred wrote:
Yes, that's me although I don't know this error came into being.
Must be a time bomb set off by a deeper recompile.
I'll put in a fix.
Cheers, Alfred.
-Original Message-
From: Francesco Chicchiriccò
Sent: Dienstag, 19. Februar 2019 08:42
To: dev@cocoon.apache.org
Subject: [External Sender] About recent commits to 2_1_X
Hi guys,
glad to see some activity raising again in the old roots for 2_1_X;
please take care of what Jenkins says about that:
https://builds.apache.org/view/A-D/view/Cocoon/job/Cocoon%202.1.X/
Recent builds seem to fail due to error
compile-core:
Compiling 461 source files to
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/build/cocoon/classes
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java:665:
unreported exception org.apache.regexp.RESyntaxException; must be caught
or declared to be thrown
REProgram encodingRE = new
RECompiler().compile("^.*encoding\\s*=\\s*([^\\s]*)");
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:68: The following
error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:51: Compile failed;
see the compiler error output for details.
I have also re-enabled notifications to c...@cocoon.apache.org, hope it's
working now.
Regards.
Re: About recent commits to 2_1_X
I'm a bit lost here :)
After your recent commits, what is now the minimum Java version : 1.5,
1.6, 1.8 ?
Cédric
Le 19/02/2019 à 12:25, Nathaniel, Alfred a écrit :
Thanks, it was quite a long shot to develop on Java 8 and then Jenkins on 1.5.
-Original Message-
From: Francesco Chicchiriccò
Sent: Dienstag, 19. Februar 2019 12:10
To: dev@cocoon.apache.org
Subject: [External Sender] Re: About recent commits to 2_1_X
FYI I have just updated the job to run with JDK 1.6 (it used to be 1.5).
Now it seems to be back working, cool!
Regards.
On 19/02/19 11:36, Nathaniel, Alfred wrote:
Yes, that's me although I don't know this error came into being.
Must be a time bomb set off by a deeper recompile.
I'll put in a fix.
Cheers, Alfred.
-Original Message-
From: Francesco Chicchiriccò
Sent: Dienstag, 19. Februar 2019 08:42
To: dev@cocoon.apache.org
Subject: [External Sender] About recent commits to 2_1_X
Hi guys,
glad to see some activity raising again in the old roots for 2_1_X;
please take care of what Jenkins says about that:
https://builds.apache.org/view/A-D/view/Cocoon/job/Cocoon%202.1.X/
Recent builds seem to fail due to error
compile-core:
Compiling 461 source files to
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/build/cocoon/classes
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/src/java/org/apache/cocoon/components/flow/javascript/fom/FOM_JavaScriptInterpreter.java:665:
unreported exception org.apache.regexp.RESyntaxException; must be caught
or declared to be thrown
REProgram encodingRE = new
RECompiler().compile("^.*encoding\\s*=\\s*([^\\s]*)");
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:68: The following
error occurred while executing this line:
/home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/tools/targets/compile-build.xml:51: Compile failed;
see the compiler error output for details.
I have also re-enabled notifications to c...@cocoon.apache.org, hope it's
working now.
Regards.
--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org
Re: PGP signatures of avalon-framework
Hi Didier, The Avalon project (http://avalon.apache.org) is dead since 2004 and has moved to the Attic. It's very unlikely that there will ever be a new release. I just tested with the mentioned jar, and it seems that the signature is indeed invalid. BTW, Maven Central also hosts other avalon-framework versions, which are unsigned. And I also found well-signed versions at http://archive.apache.org/dist/excalibur/avalon-framework/binaries/, but it's not exactly the same version. Moreover, from what I found in the public Apache SVN repos, it seems that the 4.3.1 version only exist in a "excalibur-first-maven2-release" tag, maybe meaning that this version has been built only to be present on Maven Central. In any case, here at Cocoon, we don't maintain this library, we only use it. Cédric Le 26/09/2018 à 11:32, Didier Schlegel a écrit : Dear developers, after reading this article (http://branchandbound.net/blog/security/2012/03/crossbuild-injection-how-safe-is-your-build/) about cross-build injection attacks I decided to give the pgpverify-maven-plugin (https://www.simplify4u.org/pgpverify-maven-plugin/index.html) a try. We use Apache FOP in our project and two transitive dependencies of FOP 2.3 did not pass the PGP verification: - org.apache.avalon.framework:avalon-framework-api:jar:4.3.1 - org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1 both retrieved from maven central (https://repo1.maven.org/maven2/org/apache/avalon/framework/avalon-framework-impl/4.3.1/) [WARNING] org.apache.avalon.framework:avalon-framework-api:jar:4.3.1 PGP Signature ERROR KeyId: 0xD0ACAD776E6D31C6 UserIds: [Jorg Heymans (CODE SIGNING KEY) ] [WARNING] C:\Users\didier\.m2\repository\org\apache\avalon\framework\avalon-framework-api\4.3.1\avalon-framework-api-4.3.1.jar [WARNING] C:\Users\didier\.m2\repository\org\apache\avalon\framework\avalon-framework-api\4.3.1\avalon-framework-api-4.3.1.jar.asc [WARNING] org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1 PGP Signature ERROR KeyId: 0xD0ACAD776E6D31C6 UserIds: [Jorg Heymans (CODE SIGNING KEY) ] [WARNING] C:\Users\didier\.m2\repository\org\apache\avalon\framework\avalon-framework-impl\4.3.1\avalon-framework-impl-4.3.1.jar [WARNING] C:\Users\didier\.m2\repository\org\apache\avalon\framework\avalon-framework-impl\4.3.1\avalon-framework-impl-4.3.1.jar.asc According to the pgpverify plugin these two libraries are not correctly signed. Is there a way to replace them with a correctly signed version? If not and if they are considered as trustful, maybe it would be better to remove the signature file from the maven repository as it does not match. I contacted Jorg Heymans about this and he told me to contact this cocoon developer mailinglist. Sincerly, Didier Schlegel -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Content-Range and Range headers
Hi, For the first time in my long-Cocoon history, I tried to use the ResourceReader in combination with Range/Content-Range headers for video streaming. It seems to me that the implementation does not respect the HTTP spec. According to the spec, asking for a 100 bytes resource with header Range "bytes=0-" should respond Content-Range "bytes 0-99/100" where Cocoon currently responds Content-Range "0-100/100" Does someone already use this feature ? Was it working ? I could patch, but I don't want to break anything. Regards, -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Re: Content-Length header
I've searched archives but only found [1], which is only partly related. Of course, commitResponse could be overridden in HttpEnvironment to filter out some HTTP methods, but which ones ? Should we have a black list, a white list, or a mean to configure it somewhere ? I don't want to break some compatibility somewhere. BTW, maybe only HEAD requests are concerned, after all ... Cédric [1] http://cocoon.markmail.org/search/?q=content-length#query:content-length+page:4+mid:ddsqo5ezsstshh7a+state:results Le 29/03/2017 à 19:14, Peter Hunsberger a écrit : This sounds somewhat familiar, you may want to search the mailing list archives to see if this has been discussed before Can commitResponse tell what kind of request it is dealing with or if not can that be passed in so that it knows? Peter Hunsberger On Wed, Mar 29, 2017 at 10:14 AM, Cédric Damioli <cdami...@apache.org <mailto:cdami...@apache.org>> wrote: Hi, I recently noticed that, at least for 2.1.x and 2.2.x, after any request processing, Environment.commitResponse() is called which has the side effect to compute the actual response body size and then set the response content length. While this is perfectly fine for GET requests, it's obviously useless for OPTIONS and even wrong for HEAD requests. Looking at code, an immediate workaround is to disable output buffering but it's not satisfying. Did someone encountered the same issue ? I don't know exactly how to solve this without breaking legacy behaviour. Any thoughts ? Regards, -- Cédric Damioli CMS - Java - Open Source www.ametys.org <http://www.ametys.org> -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Content-Length header
Hi, I recently noticed that, at least for 2.1.x and 2.2.x, after any request processing, Environment.commitResponse() is called which has the side effect to compute the actual response body size and then set the response content length. While this is perfectly fine for GET requests, it's obviously useless for OPTIONS and even wrong for HEAD requests. Looking at code, an immediate workaround is to disable output buffering but it's not satisfying. Did someone encountered the same issue ? I don't know exactly how to solve this without breaking legacy behaviour. Any thoughts ? Regards, -- Cédric Damioli CMS - Java - Open Source www.ametys.org
Updating main Cocoon site
Hello, I've updated some details about me and my company on [1] and was trying to update the site accordingly. But when using mvn site:site, the generated HTML files does not match exactly the current site files : the menu with project info/summary/... is not the same. I'm wondering why. Do someone have an idea ? Is my command wrong ? I've not committed anything yet as I don't want to break the Cocoon site. Best regards, Cédric [1] https://svn.apache.org/repos/asf/cocoon/trunk/site/cocoon-main-site -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
[ANN] Apache Cocoon 2.1.12 Released
Apache Cocoon 2.1.12 Released - The Apache Cocoon Community is proud to announce the new release of Apache Cocoon. Apache Cocoon is a web development framework built around the concept of separation of concerns (that is: allowing people to do their job without having to step on each other toes) and component-oriented web RAD. The latest version is downloadable from http://cocoon.apache.org/mirror.cgi (Please use the mirrors to download the release - it might take a little bit more time until the latest release is available on all mirrors, so give the mirrors some time - approx. 24h to update.) This release includes many bug fixes and smaller enhancements. For more information about Apache Cocoon 2.1.12, please go to http://cocoon.apache.org. You'll find the whole list of changes at http://cocoon.apache.org/2.1/changes.html. The Apache Cocoon Project -- Cédric Damioli For more information about Apache Cocoon 2.1.12, please go to http://cocoon.apache.org Changes with Apache Cocoon 2.1.12 *) Starting with 2.1.12 the minimum required Java version will be 1.4.2. [all] *) Core: Update xml-commons-resolver to 1.2 [DC] *) Allow usage of SLF4J for traces [CD] *) I18nTranformer should consume and stop propagating start/endPrefixMapping of its namespace [CD] *) Cocoon 2.1 is not initialized when building without samples [CD] *) Serializers block: Added support of XHTML5 in the XHTMLSerializer [CD] *) Core: When interrupted, the ResourceReader may store incomplete data in the cache [CD] *) Core: Allow to override the upload parameters in CocoonServlet [CD] *) Core: Update xercesImpl to 2.11.0 and xml-apis to 1.4.01. [AG] *) Add base URI fixup support to XIncludeTransformer [JSJ] *) Repository block: WebDAV Returns improper status on PUT [JSJ] *) FOP block: Backport from FOPNGSerializer (C2.2) to FOPSerializer. Upgraded FOP dependency from 0.20.5 to 0.95. [JSJ] *) XSP block: Make SOAPHelper use https, not just http [JSJ] *) Serializer block: charset data won't load if there's a space in the path to the jar file (e.g C:\Program Files\MyApp\...) [SW] *) JCR block: Missing modCount attribute in JCR sample content. [JSJ] *) Updated ant to 1.7.1. This ant detects correctly java 1.6. [AG] *) Change HostSelector to be case-insensitive according to RFC3986 section 3.2.2. [JH] *) Handle case in ApplicationUtil.isUserInRole(..) when User is null. [JH] *) Forms: MultiValueField list-type=double-listbox does not work correctly in ajax enabled forms. [AG] *) StripNameSpacesTransformer does not strip namespace prefix of attributes [JSJ] *) ImageOp block: If parameter width or height in resize operation is zero, use the original image size. If both are zero, then handle as no-op. Set default values to zero to allow using that feature by leaving out the parameters. [AN] *) ImageOp block: Addition of allow-enlarge parameter to resize operation. [AN] *) Mail block: Allow mime-type to explicitly set a charset as in mime-type=text/html;charset=UTF-8. [AN] *) Mail block: Make a difference between plain text mails and mails that have a multi-part body. If the mail-body has set the mime-type=text/plain, then the message body isn't send as body part but as simple content. That avoids getting a plain text-message without attachment being marked as mail with attachment. [RP] *) Core: Cocoon's pipeline buffer increases from an initial buffer size of 8192 bytes to the configurable flush buffer size rather than allocating the complete buffer beforehand. [JH] *) POI Block: formatted style regions stop creating style at 2000 rows. [AG] *) Eventcache: Events are persisted and restored and sample works [AS] *) POI Block: Update to poi-3.0.2. [AN] *) HTML: Fix encoding issue in NekoHTMLTransformer. Fix similar issue in NekoHTMLGenerator when reading a request parameter value. [VG, JH] *) Forms: Fix @id handling on fi:group/fi:struct element in conjunction with AJAX requests. [JH] *) Core: Fix CachingOutputStream not caching all content or leading to ArrayIndexOutOfBoundsException when using write(byte[], int, int). [JH] *) Core: Set the default output buffer size of the pipeline to 1,048,576 (1 MB) rather than -1 (complete buffering) to avoid potential OutOfMemoryErrors on too large output. [JH] *) Core: In Cocoon 2.2 the org.apache.cocoon.environment.Session interface is deprecated, and the return type of getSession() changes to vanilla javax.servlet.HttpRequest. For migrating from Cocoon 2.1 to 2.2, replace in your custom code all calls to getSession() by getCocoonSession(). That allows for a common codebase usable on both version. [AN] *) Core: Allow multiple file uploads of the same field name. If there are multiple file uploads Request.get(String) will return a Vector. If there is only one file upload it will return the Part as it did before. This is now the same behavior as for inline parts. [JH] *) Core: Update commons
Re: How to update 2.1 website ?
Le 20/03/2013 08:52, Francesco Chicchiriccò a écrit : On 19/03/2013 21:10, Cédric Damioli wrote: Hi team, While waiting for 2.1.12 to upload to mirrors, I wanted to prepare the web site update. I've read [1] and [2] but don't know what to do now ... I don't know anything to forrest and daisy, nor to the Cocoon zone :) The Cocoon Zone [3] does not contain anything but samples from C2.1 / C2.2 / C3. I could certainly commit index.html and news.html by replacing 2.1.11 by 2.1.12 but I don't know how to re-generate e.g. changes.html [4] seems to be generated by something similar to the Maven Changes Plugin [5], so it will need some effort anyway. What do you think we should do ? Leave as is and don't try to re-generate anything ? Try to start daisy again ? My opinion: manually edit [4] and replace the 2.1.12 section with the HTML output from [6]. Besides the C2.1 web site update, it is also urgently needed to announce the release by (a) updating Cocoon website homepage and (b) sending an e-mail to (at least) annou...@apache.org / us...@cocoon.apache.org. See [7] for a text example (I would just link the changes.html page from there, though). I sent the mail to dev@c.a.o, users@c.a.o and annou...@apache.org I updated the 2.1/changes.html Todo : update the main index.html BTW : thank you all for your support in the release process ! I am available to help with such things, if you need. Regards. [1] http://wiki.apache.org/cocoon/CocoonWebsiteUpdate [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/81763 [3] http://cocoon.zones.apache.org/ [4] http://cocoon.apache.org/2.1/changes.html [5] http://maven.apache.org/plugins/maven-changes-plugin/ [6] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310170version=12312903 [7] http://cocoon.apache.org/1426_1_1.html -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/ -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
[RESULT][VOTE] Release Cocoon 2.1.12
The vote for the 2.1.12 release passes with the 6 following +1 : - Thorsten Scherler - Robby Pelssers - Javier Puerto - David Crossley - Francesco Chicchiriccò - Cédric Damioli No others votes were cast. Code freeze is now over. I'll put the release files on the server and try to update web site (I'll certainly need help at some point for that). Thanks to all. Best regards, -- Cédric Damioli
How to update 2.1 website ?
Hi team, While waiting for 2.1.12 to upload to mirrors, I wanted to prepare the web site update. I've read [1] and [2] but don't know what to do now ... I don't know anything to forrest and daisy, nor to the Cocoon zone :) I could certainly commit index.html and news.html by replacing 2.1.11 by 2.1.12 but I don't know how to re-generate e.g. changes.html What do you think we should do ? Leave as is and don't try to re-generate anything ? Try to start daisy again ? Regards, Cédric [1] http://wiki.apache.org/cocoon/CocoonWebsiteUpdate [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/81763 -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
[VOTE] Release Cocoon 2.1.12
Hi team, I've put the files at http://people.apache.org/~cdamioli/cocoon-2.1.12/ Please check the files, build and run samples, and cast your votes. Here is my +1 Regards, -- Cédric Damioli
Re: [2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
Hi, BTW, how could I have write access on the wiki ? Who are administrators ? A while ago [2] we set up with Infra some security for our wiki: if you want write access you need to be enlisted as contributor in [3]; any PMC member can also be added to [4] thus becoming administrator. Please tell me your username and I will add it to [3] or [4], as you prefer. My user name on the Wiki is CedricDamioli Thanks, Cédric Regards. Le 05/03/2013 11:18, Cédric Damioli a écrit : Hi team, Ok, does this mean we can start rolling this long-waited 2.1.12??!? Cédric, are you ready? Let's go ! We are now in the process of releasing 2.1.12 in the next few days, so please don't check anything in in the 2.1.x branch. I'll try to follow [1] as much as possible. Best regards, Cédric [1] http://wiki.apache.org/cocoon/CocoonReleaseHowTo [2] http://old.nabble.com/Re%3A-Spam-on-Cocoon-wiki---Fwd%3A--Cocoon-Wiki--Trivial-Update-of-%22FrontPage%22-by-wikimouse-p33732277.html [3] http://wiki.apache.org/cocoon/ContributorsGroup [4] http://wiki.apache.org/cocoon/AdminGroup
Re: [2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
Le 11/03/2013 17:37, Francesco Chicchiriccò a écrit : I was able to 1. download all files 2. check ASC signatures and MD5 / SHA1 hashes 3. (either for zip and tar.gz) extract src, try to build and got message about missing dependencies 4. (either for zip and tar.gz) extract deps, successfully build, run and browse samples If this was a formal vote, I would have given my +1 Nice job! Looking forward for the actual vote. Regards. Thanks for your feedback. I hope to be able to tag the SVN, rebuild the files, and launch the formal vote later today. Regards, -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
Le 11/03/2013 11:12, Francesco Chicchiriccò a écrit : On 09/03/2013 12:36, Francesco Chicchiriccò wrote: On 08/03/2013 20:28, Cédric Damioli wrote: Hello, I just uploaded the release material at http://people.apache.org/~cdamioli/cocoon/ Before starting a formal vote, could some of you download and test the files (signatures, installation, samples, ...) ? I'll do this on Monday. I cannot download almost any file (but some .asc) from the given location: 403 Forbidden ouuups, sorry This should be better now. I saw some broken samples, all related to some external sources (RSS feeds, SOAP servers, ...). I don't know if this may be considered blocker for the release. I don't think so... BTW, how could I have write access on the wiki ? Who are administrators ? A while ago [2] we set up with Infra some security for our wiki: if you want write access you need to be enlisted as contributor in [3]; any PMC member can also be added to [4] thus becoming administrator. Please tell me your username and I will add it to [3] or [4], as you prefer. Regards. Le 05/03/2013 11:18, Cédric Damioli a écrit : Hi team, Ok, does this mean we can start rolling this long-waited 2.1.12??!? Cédric, are you ready? Let's go ! We are now in the process of releasing 2.1.12 in the next few days, so please don't check anything in in the 2.1.x branch. I'll try to follow [1] as much as possible. Best regards, Cédric [1] http://wiki.apache.org/cocoon/CocoonReleaseHowTo [2] http://old.nabble.com/Re%3A-Spam-on-Cocoon-wiki---Fwd%3A--Cocoon-Wiki--Trivial-Update-of-%22FrontPage%22-by-wikimouse-p33732277.html [3] http://wiki.apache.org/cocoon/ContributorsGroup [4] http://wiki.apache.org/cocoon/AdminGroup -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
Hello, I just uploaded the release material at http://people.apache.org/~cdamioli/cocoon/ Before starting a formal vote, could some of you download and test the files (signatures, installation, samples, ...) ? I saw some broken samples, all related to some external sources (RSS feeds, SOAP servers, ...). I don't know if this may be considered blocker for the release. BTW, how could I have write access on the wiki ? Who are administrators ? Best regards, Cédric Le 05/03/2013 11:18, Cédric Damioli a écrit : Hi team, Ok, does this mean we can start rolling this long-waited 2.1.12??!? Cédric, are you ready? Let's go ! We are now in the process of releasing 2.1.12 in the next few days, so please don't check anything in in the 2.1.x branch. I'll try to follow [1] as much as possible. Best regards, Cédric [1] http://wiki.apache.org/cocoon/CocoonReleaseHowTo -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
[2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
Hi team, Ok, does this mean we can start rolling this long-waited 2.1.12??!? Cédric, are you ready? Let's go ! We are now in the process of releasing 2.1.12 in the next few days, so please don't check anything in in the 2.1.x branch. I'll try to follow [1] as much as possible. Best regards, Cédric [1] http://wiki.apache.org/cocoon/CocoonReleaseHowTo
Re: [jira] [Commented] (COCOON-2295) Integrate FOP 1.0
It seems that the bundled FOP 1.1 jar is compiled with Java 5 Francesco, have you built it yourself, or does it come from the binary distribution from FOP ? Regards, Cdric Le 04/03/2013 08:05, David Crossley a crit: Francesco Chicchiricc (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON-2295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13578204#comment-13578204 ] Francesco Chicchiricc commented on COCOON-2295: According to [1] FOP 1.1 still requires JDK 1.4. If the patch looks fine, I'd commit and close this issue. [1] http://xmlgraphics.apache.org/fop/1.1/running.html I just tried building Cocoon-2.1 using Java 1.4.2 and get complaints from the Cocoon FOP Block: -- /cocoon_2_1/src/blocks/fop/java/org/apache/cocoon/serialization/FOPSerializer.java:34: cannot access org.apache.fop.apps.FOPException bad class file: /cocoon_2_1/lib/optional/fop-1.1.jar(org/apache/fop/apps/FOPException.class) class file has wrong version 49.0, should be 48.0 Please remove or make sure it appears in the correct subdirectory of the classpath. import org.apache.fop.apps.FOPException; -- However the block is okay when using Java 5. -David Integrate FOP 1.0 - Key: COCOON-2295 URL: https://issues.apache.org/jira/browse/COCOON-2295 Project: Cocoon Issue Type: Improvement Components: Blocks: Batik, Blocks: FOP Affects Versions: 2.1.12 Reporter: ron van den branden Assignee: Francesco Chicchiricc Fix For: 2.1.12 Attachments: COCOON-2295-FOP_1_1.patch, COCOON-2295.patch, jars.patch, jars.xml Here are instructions for updating the current FOP-0.95 serializer in Cocoon-2.1.12-dev (see https://issues.apache.org/jira/browse/COCOON-2289): 1. checkout http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 from http://xmlgraphics.apache.org/fop/download.html 3. update jars in %COCOON_HOME%\lib\*: -replace %COCOON_HOME%\lib\optional\batik-all-1.6.jar with %FOP_HOME%\lib\batik-all-1.7.jar -replace %COCOON_HOME%\lib\optional\fop-0.95.jar with %FOP_HOME%\build\fop.jar -replace %COCOON_HOME%\lib\optional\xmlgraphics-commons-1.3.1.jar with %FOP_HOME%\lib\xmlgraphics-commons-1.4.jar -copy %FOP_HOME%\lib\xml-apis-ext-1.3.04.jar to %COCOON_HOME%\lib\endorsed -copy %FOP_HOME%\lib\serializer-2.7.0.jar to %COCOON_HOME%\lib\optional 4. update references to these jars in %COCOON_HOME%\lib\jars.xml (see attached file) 5. build Cocoon -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira -- www.anyware-services.com Inscrivez-vous notre newsletter Cdric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Htel Tlcom - Augustin Fresnel / 40 rue du Village d'entreprises / 31670 LABEGE Ametys: Smart Web CMS www.ametys.org Ce message et toutes les pices jointes (le "Message") sont confidentiels et tablis l'intention exclusive de ses destinataires. Toute modification, dition, utilisation ou diffusion non autorise est interdite. Anyware Services dcline toute responsabilit au titre de ce Message s'il a t altr, dform, falsifi ou dit, diffus sans autorisation.
Re: [DISCUSS] Releasing 2.1.12
Le 04/03/2013 13:30, Francesco Chicchiriccò a écrit : On 03/03/2013 06:30, David Crossley wrote: I am busy for the next two weeks, being away for the second. Now half-way through testing Forrest using the recently updated Cocoon and its FOP/Batik/etc. Will try to finish that ASAP. ...guess it's wise to wait for you to finish such tests before starting the actual release process ;-) Indeed :) Regards. I see that final touches were recently added to http://www.apache.org/dev/licensing-howto.html https://issues.apache.org/jira/browse/INCUBATOR-125 I think our recent work is still compliant with that. WDYT ? Regards, Cédric
Re: [DISCUSS] Releasing 2.1.12
Le 28/02/2013 10:04, Francesco Chicchiriccò a écrit : On 27/02/2013 22:55, Cédric Damioli wrote: Hi all, It seems there remains only one open issue, COCOON-2333, related to dependencies upgrade. With r1451136 I have enabled the generation of .md5 and .sha1 for dist packages, required by [4]: please check it to confirm that it is working correctly. The .asc files will also need to be generated, but I haven't found an easy way to to this via ANT, hence I guess we have no option but the manual way, e.g. $ gpg --armor --output cocoon-2.1.12-src.zip.asc --detach-sig cocoon-2.1.12-src.zip $ gpg --armor --output cocoon-2.1.12-src.tar.gz.asc --detach-sig cocoon-2.1.12-src.tar.gz $ gpg --armor --output cocoon-2.1.12-deps.zip.asc --detach-sig cocoon-2.1.12-deps.zip $ gpg --armor --output cocoon-2.1.12-deps.tar.gz.asc --detach-sig cocoon-2.1.12-deps.tar.gz I urge to note that the release manager for 2.1.12 will also need to be sure that his own key is contained in [5]. BTW, who is actually the release manager for 2.1.12 ? David, Francesco, others, are we ok with current dependencies? Some dependencies are obviously not on their latest versions, but IMHO, trying to upgrade all jars would be too long, and users may still upgrade one library if needed. What do you think? We have recently turned all the To be done statements from [6] into Done, hence If no specific limitations and / or bugs are known affecting the current versions of dependencies, I see no reason for keep waiting. I've made a very quick tour on samples and all seemed to work nice. I'll look at them deeper once we have a release candidate. I'd create the release 2.1.13 on JIRA, move COCOON-2333 there and start the release process for 2.1.12. +1 It'll be part of the release process. Cédric Regards. Le 22/01/2013 11:40, Francesco Chicchiriccò a écrit : On 22/01/2013 07:26, David Crossley wrote: Francesco Chicchiriccò wrote: Cédric Damioli wrote: Hi there, AFAIK the same 3 issues are still opened. Could you give me a hint about the src/bin split? COCOON-2330 - Could you please tell me (again) how to generate the source and deps packages from SVN? Thanks. Do ./build.sh dist. There will also need to be different NOTICE and LICENSE files for each package. Adding this as comment to COCOON-2330 - let's move this discussion there. Apart, there's the David issue about upgrading all dependencies. I don't know the status of it. COCOON-2333 - According to [2], there are still few deps to check. I remember I've asked David about how to contribute on this an he said something like update the JAR file an browse if samples still work See a few messages above on this list. There is more to it than that, e.g. tweak lib/jars.xml file, do the build (which does have some code tests), review the relevant samples, etc. Also the issue is about some dependencies, not all. For example FOP, Batik, etc. would be good if possible. Fine, I think I've found again such information at [3]; added this also as comment to COCOON-2333 - let's move this discussion there. And also an samples issue reopened by David. I don't know either what to do with it. COCOON-2069 - David, what should we do with this? See my issue comment. I made a workaround to fix the cause of the new misconfiguration which had broken the build for everyone. It seems that the original patch must have included some parts of some extra stuff (WSRP). I reckon forget it and just leave the workaround in-place. I've read your comment in COCOON-2069 and replied there recently: could you please take a look and reply? Thanks. Regards. Le 19/01/2013 15:11, Francesco Chicchiriccò a écrit : On 11/12/2012 12:29, Cédric Damioli wrote: [...] Hi all, is everything tracked into JIRA [1]? From my POV, yes. I've added some comments to COCOON-2330. I'm not sure what to include or exclude from the -src package. If so, we are only 3 issues away from releasing 2.1.12, wonderful! Hello there, how's the situation with C2.1.12 in 2013? Any help needed? Regards. [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20COCOON%20AND%20fixVersion%20%3D%20%222.1.12-dev%20(Current%20SVN)%22%20AND%20status%20in%20(Open%2C%20Reopened)%20ORDER%20BY%20priority%20DESC [2] http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/misc/notes/review-jars.txt [3] http://markmail.org/message/ijmy6nzd2k4yzghn#query:+page:1+mid:dbsylujycgit224q+state:results [4] http://www.apache.org/dev/release-signing.html [5] http://www.apache.org/dist/cocoon/KEYS [6] http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/misc/notes/review-jars.txt -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Le 28/02/2013 11:26, Francesco Chicchiricc a crit: On 28/02/2013 11:22, Cdric Damioli wrote: Le 28/02/2013 10:04, Francesco Chicchiricc a crit : On 27/02/2013 22:55, Cdric Damioli wrote: Hi all, It seems there remains only one open issue, COCOON-2333, related to dependencies upgrade. With r1451136 I have enabled the generation of .md5 and .sha1 for dist packages, required by [4]: please check it to confirm that it is working correctly. The .asc files will also need to be generated, but I haven't found an easy way to to this via ANT, hence I guess we have no option but the manual way, e.g. $ gpg --armor --output cocoon-2.1.12-src.zip.asc --detach-sig cocoon-2.1.12-src.zip $ gpg --armor --output cocoon-2.1.12-src.tar.gz.asc --detach-sig cocoon-2.1.12-src.tar.gz $ gpg --armor --output cocoon-2.1.12-deps.zip.asc --detach-sig cocoon-2.1.12-deps.zip $ gpg --armor --output cocoon-2.1.12-deps.tar.gz.asc --detach-sig cocoon-2.1.12-deps.tar.gz I urge to note that the release manager for 2.1.12 will also need to be sure that his own key is contained in [5]. BTW, who is actually the release manager for 2.1.12 ? Whoever wants to take this up: I was assuming you, actually ;-) Having some experience with releases (Maven-driven, actually...) I can help, if you want / need. I'm ok to do the job, if it's ok for others too ;) Having never done Apache releases, I'll certainly need help at some point, but IIRC the whole process was particularly well explained on the wiki. David, Francesco, others, are we ok with current dependencies? Some dependencies are obviously not on their latest versions, but IMHO, trying to upgrade all jars would be too long, and users may still upgrade one library if needed. What do you think? We have recently turned all the "To be done" statements from [6] into "Done", hence If no specific limitations and / or bugs are known affecting the current versions of dependencies, I see no reason for keep waiting. I've made a very quick tour on samples and all seemed to work nice. I'll look at them deeper once we have a release candidate. Fine. I'd create the release 2.1.13 on JIRA, move COCOON-2333 there and start the release process for 2.1.12. +1 It'll be part of the release process. Fine again. Regards. Le 22/01/2013 11:40, Francesco Chicchiricc a crit : On 22/01/2013 07:26, David Crossley wrote: Francesco Chicchiricc wrote: Cdric Damioli wrote: Hi there, AFAIK the same 3 issues are still opened. Could you give me a hint about the src/bin split? COCOON-2330 - Could you please tell me (again) how to generate the source and deps packages from SVN? Thanks. Do "./build.sh dist". There will also need to be different NOTICE and LICENSE files for each package. Adding this as comment to COCOON-2330 - let's move this discussion there. Apart, there's the David issue about upgrading all dependencies. I don't know the status of it. COCOON-2333 - According to [2], there are still few deps to check. I remember I've asked David about how to contribute on this an he said something like "update the JAR file an browse if samples
Re: [DISCUSS] Releasing 2.1.12
Hi all, It seems there remains only one open issue, COCOON-2333, related to dependencies upgrade. David, Francesco, others, are we ok with current dependencies ? Some dependencies are obviously not on their latest versions, but IMHO, trying to upgrade all jars would be too long, and users may still upgrade one library if needed. What do you think ? Best regards, Cédric Le 22/01/2013 11:40, Francesco Chicchiriccò a écrit : On 22/01/2013 07:26, David Crossley wrote: Francesco Chicchiriccò wrote: Cédric Damioli wrote: Hi there, AFAIK the same 3 issues are still opened. Could you give me a hint about the src/bin split? COCOON-2330 - Could you please tell me (again) how to generate the source and deps packages from SVN? Thanks. Do ./build.sh dist. There will also need to be different NOTICE and LICENSE files for each package. Adding this as comment to COCOON-2330 - let's move this discussion there. Apart, there's the David issue about upgrading all dependencies. I don't know the status of it. COCOON-2333 - According to [2], there are still few deps to check. I remember I've asked David about how to contribute on this an he said something like update the JAR file an browse if samples still work See a few messages above on this list. There is more to it than that, e.g. tweak lib/jars.xml file, do the build (which does have some code tests), review the relevant samples, etc. Also the issue is about some dependencies, not all. For example FOP, Batik, etc. would be good if possible. Fine, I think I've found again such information at [3]; added this also as comment to COCOON-2333 - let's move this discussion there. And also an samples issue reopened by David. I don't know either what to do with it. COCOON-2069 - David, what should we do with this? See my issue comment. I made a workaround to fix the cause of the new misconfiguration which had broken the build for everyone. It seems that the original patch must have included some parts of some extra stuff (WSRP). I reckon forget it and just leave the workaround in-place. I've read your comment in COCOON-2069 and replied there recently: could you please take a look and reply? Thanks. Regards. Le 19/01/2013 15:11, Francesco Chicchiriccò a écrit : On 11/12/2012 12:29, Cédric Damioli wrote: [...] Hi all, is everything tracked into JIRA [1]? From my POV, yes. I've added some comments to COCOON-2330. I'm not sure what to include or exclude from the -src package. If so, we are only 3 issues away from releasing 2.1.12, wonderful! Hello there, how's the situation with C2.1.12 in 2013? Any help needed? Regards. [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20COCOON%20AND%20fixVersion%20%3D%20%222.1.12-dev%20(Current%20SVN)%22%20AND%20status%20in%20(Open%2C%20Reopened)%20ORDER%20BY%20priority%20DESC [2] http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/misc/notes/review-jars.txt [3] http://markmail.org/message/ijmy6nzd2k4yzghn#query:+page:1+mid:dbsylujycgit224q+state:results
Re: Not able to build and run Cocoon
Hi Kiran,
With which JDK (vendor and version) are you trying to build Cocoon 2.1.11 ?
Besides, the right place for your question would certainly be the users
mailing-list: us...@cocoon.apache.org rather than the dev one, you may
have more answers there.
Regards,
Cédric
Le 11/02/2013 19:12, Kiran Rangarajan a écrit :
Hello,
I have Java and JDK set up on my system. When I build Cocoon I get the
following error. I am not able to figure out what is wrong. Can you
please help me out with it.
The errors are:
C:\Program Files\cocoon-2.1.11-src\cocoon-2.1.11build.bat
Buildfile: build.xml
prepare:
Apache Cocoon 2.1.11 [1999-2007]
Building with Apache Ant version 1.6.5 compiled on June 2 2005
Using build file C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\build.xml
Compiler options:
- debug . [on]
- optimize .. [on]
- deprecation ... [off]
compile-core:
Compiling 596 source files to C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\b
uild\cocoon\classes
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:39: error: package com.sun.image.codec.jpeg does
not exist
import com.sun.image.codec.jpeg.ImageFormatException;
^
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:40: error: package com.sun.image.codec.jpeg does
not exist
import com.sun.image.codec.jpeg.JPEGCodec;
^
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:41: error: package com.sun.image.codec.jpeg does
not exist
import com.sun.image.codec.jpeg.JPEGEncodeParam;
^
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:42: error: package com.sun.image.codec.jpeg does
not exist
import com.sun.image.codec.jpeg.JPEGImageEncoder;
^
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:326: error: cannot find symbol
JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(out);
^
symbol: class JPEGImageEncoder
location: class ImageReader
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:326: error: cannot find symbol
JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(out);
^
symbol: variable JPEGCodec
location: class ImageReader
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:327: error: cannot find symbol
JPEGEncodeParam p = encoder.getDefaultJPEGEncodeParam(curren
tImage);
^
symbol: class JPEGEncodeParam
location: class ImageReader
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:333: error: cannot find symbol
JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(bstre
am);
^
symbol: class JPEGImageEncoder
location: class ImageReader
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:333: error: cannot find symbol
JPEGImageEncoder encoder = JPEGCodec.createJPEGEncoder(bstre
am);
^
symbol: variable JPEGCodec
location: class ImageReader
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:334: error: cannot find symbol
JPEGEncodeParam p = encoder.getDefaultJPEGEncodeParam(curren
tImage);
^
symbol: class JPEGEncodeParam
location: class ImageReader
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\src\java\org\apache\cocoon\read
ing\ImageReader.java:342: error: cannot find symbol
} catch (ImageFormatException e) {
^
symbol: class ImageFormatException
location: class ImageReader
11 errors
BUILD FAILED
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\tools\targets\compile-build.xml
:68: The following error occurred while executing this line:
C:\Program
Files\cocoon-2.1.11-src\cocoon-2.1.11\tools\targets\compile-build.xml
:51: Compile failed; see the compiler error output for details.
Total time: 17 seconds
C:\Program Files\cocoon-2.1.11-src\cocoon-2.1.11
Thanks a lot for your help.
Regards
Kiran Rangarajan
--
Cédric Damioli
Ametys CMS
http://www.ametys.org
http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Hi there, AFAIK the same 3 issues are still opened. Could you give me a hint about the src/bin split? Apart, there's the David issue about upgrading all dependencies. I don't know the status of it. And also an samples issue reopened by David. I don't know either what to do with it. Regards, Cédric Le 19/01/2013 15:11, Francesco Chicchiriccò a écrit : On 11/12/2012 12:29, Cédric Damioli wrote: [...] Hi all, is everything tracked into JIRA [1]? From my POV, yes. I've added some comments to COCOON-2330. I'm not sure what to include or exclude from the -src package. If so, we are only 3 issues away from releasing 2.1.12, wonderful! Hello there, how's the situation with C2.1.12 in 2013? Any help needed? Regards. [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20COCOON%20AND%20fixVersion%20%3D%20%222.1.12-dev%20(Current%20SVN)%22%20AND%20status%20in%20(Open%2C%20Reopened)%20ORDER%20BY%20priority%20DESC -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: 2.12 Release: Additions to COCOON-2333 (list of current jars)
Le 12/12/2012 13:13, David Crossley a écrit : Francesco Chicchiriccò wrote: David Crossley wrote: insigh...@gmail.com wrote: Here are some additions to COCOON-2333 (list of current jar files). I'm also attaching a .txt file in case that's easier to use. Is the plan to upgrade the code to use the newer jar versions for the 2.12 release? Thanks, I will add some of your notes to the list. The intention was to gather some information about some of the important ones. If necessary or desirable, then we could possibly upgrade some. However there would need to be other Cocoon committers to assist with that. If you can point me to some procedure to test whether everything is working (if it was Maven I would have known how to do this check) when upgrading some JAR dependency file, I could provide some assistance. The lib/jars.xml file explains where each jar is used, e.g. which block, or perhaps core too. So doing ./build.sh to compile and run whatever code tests are included, then ./cocoon.sh and exercise the relevant Sample. IIUC, then Cocoon-2.1 will need to remain at a limited low version of Java. So that will restrict which jars can be upgraded, and to what version of their product. Agreed: 2.1.12 is a bugfix version - coming after years! - and its scope could not interfere with Java version. The Cocoon-2.1 README.txt says Java 1.3 However for example this is already in our C-2.1 SVN: lib/optional/xmlgraphics-commons-1.3.1.jar and version 1.3 is the first to require Java 1.4 http://xmlgraphics.apache.org/commons/#news-2008-06-11 -David If I remember correctly, it was decided that 2.1.12 would be the first version requiring at least a 1.4 JVM This is written in the status.xml and even the core does not compile with a JVM 1.4 We should certainly update the README.txt -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Hi, Le 11/12/2012 11:46, Francesco Chicchiriccò a écrit : On 07/12/2012 08:44, Francesco Chicchiriccò wrote: On 07/12/2012 08:14, David Crossley wrote: I spent some time to attempt to upgrade the guts of Forrest to utilise today's Cocoon-2.1.12-dev version. https://issues.apache.org/jira/browse/FOR-1240 Hooray, it works. That's very good news! As explained there it would also be good to upgrade some of the supporting products dependencies in Cocoon. Forrest has some that are newer than Cocoon and vice versa. We probably each have some that are out-of-date. It makes sense: would you like to open an issue for this? To summarize, what's missing now to release 2.1.12? Hi all, is everything tracked into JIRA [1]? From my POV, yes. I've added some comments to COCOON-2330. I'm not sure what to include or exclude from the -src package. If so, we are only 3 issues away from releasing 2.1.12, wonderful! Regards. [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20COCOON%20AND%20fixVersion%20%3D%20%222.1.12-dev%20(Current%20SVN)%22%20AND%20status%20in%20(Open%2C%20Reopened)%20ORDER%20BY%20priority%20DESC Regards, -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Hi, I've slightly modified the build files in order to separate libs from sources. I've uploaded http://people.apache.org/~cdamioli/cocoon-2.1.12-rc-src.zip and http://people.apache.org/~cdamioli/cocoon-2.1.12-rc-deps.zip to get your comments. Does these archives correspond to Apache policy ? Thanks for your feedbacks, Regards, Cédric Le 27/11/2012 12:52, Cédric Damioli a écrit : Le 27/11/2012 08:40, Francesco Chicchiriccò a écrit : On 27/11/2012 08:18, David Crossley wrote: In the past releases of Cocoon-2.1, we included the relevant versions of all supporting product dependencies. That is okay as a convenience. However we need to provide a source code package which does not contain those external JAR files, and conduct our release vote against that package. Then we can construct other convenience packages for distribution. Forrest got into the same situation. Here is some background and links to other discussion: http://s.apache.org/mCW We solved the immediate situation but still need to adjust our build system. The Cocoon-2.1 Apache Ant build system should be reasonably easy to tweak to create separate packages. Hi David, I've been involved in similar discussions a while ago and I completely agree with you. I've opened OCOON-2330 for tracking this: who is available to help? I do I'll try to modify ant tasks to separate ZIP files What we have to do is to know exactly which files are Cocoon sources and which are not Best regards, -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Le 27/11/2012 08:40, Francesco Chicchiriccò a écrit : On 27/11/2012 08:18, David Crossley wrote: In the past releases of Cocoon-2.1, we included the relevant versions of all supporting product dependencies. That is okay as a convenience. However we need to provide a source code package which does not contain those external JAR files, and conduct our release vote against that package. Then we can construct other convenience packages for distribution. Forrest got into the same situation. Here is some background and links to other discussion: http://s.apache.org/mCW We solved the immediate situation but still need to adjust our build system. The Cocoon-2.1 Apache Ant build system should be reasonably easy to tweak to create separate packages. Hi David, I've been involved in similar discussions a while ago and I completely agree with you. I've opened OCOON-2330 for tracking this: who is available to help? I do I'll try to modify ant tasks to separate ZIP files What we have to do is to know exactly which files are Cocoon sources and which are not Best regards, -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Le 22/11/2012 13:55, Francesco Chicchiriccò a écrit : On 22/11/2012 11:57, Sylvain Wallez wrote: Le 21/11/12 23:43, David Crossley a écrit : I am still around from the olden days and will try to help. However my time is very limited. Same for here! I would be happy to help where I can, but have limited time. That sounds great: with two old foxes like you things can only raise better :-) I think Cédric would need some help especially with pre-release checks and issues related to blocks he has never dealt with; Cédric, is this correct? You're right, especially for the Forms or Authentication blocks. I know Sylvain wrote a big part of the forms block (we were colleagues at that time), but it was a long time ago :) Regards. Regards, -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Hi, Le 18/11/2012 18:35, Francesco Chicchiriccò a écrit : Hi all (but Cédric in particular), by looking at JIRA [1] it seems that quite a considerable number of issues have been fixed since 2.1.11 (31) even though some are still standing (11+2). Following our recent discussion in another thread, I have some questions to Cédric (and other C2.1 devs, if there are...): 1. Do you think that the the 13 outstanding issues can be moved to 2.1.13 or there are some that need to be absolutely included in 2.1.12? 3 of them were opened by myself before gaining committership. [1] [2] [3] I could have closed them already, but was waiting for others' approval. I don't know if someone has something to say about them ... The 10 others issues are more than 2 years old There are also 74 issues with no fix for version (29 with a patch included) but affecting a 2.1.x version We should maybe ask 2.1 users if there are particular issues they want to be fixed before cutting a 2.1.12 ? 2. Is the release process clear to you? If not, who (maybe active in the past) can provide some hint? Not really. I think there was once a page written by Carsten describing the release process, but I can't find it anymore. 3. Do you need any help in the release process? If so, who is available to help? I am, even though I don't remember pretty anything of C2.1... Yes please It would be great if 2 or 3 people other than me could try to run unit tests and run samples. Almost 5 years after the 2.1.11, I also don't remember all blocks, it would be great to also have feedbacks from users of some specific blocks. 4. Considering the questions above, when do you think we can start releasing 2.1.12? Depending if we try to gather some feedbacks from devs and users or not, it could be quite fast, say in the next few days. But 5 years after, we can afford one or two more weeks if needed Thanks for info. Regards. [1] https://issues.apache.org/jira/browse/COCOON/fixforversion/12312903#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel [1] https://issues.apache.org/jira/browse/COCOON-2288 [2] https://issues.apache.org/jira/browse/COCOON-2313 [3] https://issues.apache.org/jira/browse/COCOON-2314 Best regards, -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Hi, Le 18/11/2012 18:35, Francesco Chicchiriccò a écrit : Hi all (but Cédric in particular), by looking at JIRA [1] it seems that quite a considerable number of issues have been fixed since 2.1.11 (31) even though some are still standing (11+2). Following our recent discussion in another thread, I have some questions to Cédric (and other C2.1 devs, if there are...): 1. Do you think that the the 13 outstanding issues can be moved to 2.1.13 or there are some that need to be absolutely included in 2.1.12? 3 of them were opened by myself before gaining committership. [1] [2] [3] I could have closed them already, but was waiting for others' approval. I don't know if someone has something to say about them ... The 10 others issues are more than 2 years old There are also 74 issues with no fix for version (29 with a patch included) but affecting a 2.1.x version We should maybe ask 2.1 users if there are particular issues they want to be fixed before cutting a 2.1.12 ? 2. Is the release process clear to you? If not, who (maybe active in the past) can provide some hint? Not really. I think there was once a page written by Carsten describing the release process, but I can't find it anymore. 3. Do you need any help in the release process? If so, who is available to help? I am, even though I don't remember pretty anything of C2.1... Yes please :) It would be great if 2 or 3 people other than me could try to run unit tests and run samples. Almost 5 years after the 2.1.11, I also don't remember all blocks, it would be great to also have feedbacks from users of some specific blocks. 4. Considering the questions above, when do you think we can start releasing 2.1.12? Depending if we try to gather some feedbacks from devs and users or not, it could be quite fast, say in the next few days. But 5 years after, we can afford one or two more weeks if needed :) Thanks for info. Regards. [1] https://issues.apache.org/jira/browse/COCOON/fixforversion/12312903#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel [1] https://issues.apache.org/jira/browse/COCOON-2288 [2] https://issues.apache.org/jira/browse/COCOON-2313 [3] https://issues.apache.org/jira/browse/COCOON-2314 Best regards, -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Releasing 2.1.12
Le 19/11/2012 12:00, Francesco Chicchiriccò a écrit : On 19/11/2012 11:40, Francesco Chicchiriccò wrote: [...] 2. Is the release process clear to you? If not, who (maybe active in the past) can provide some hint? Not really. I think there was once a page written by Carsten describing the release process, but I can't find it anymore. I guess we should directly ask Carlsten, then: let's see if he replies here, otherwise we can try to contact him somehow else. What about http://wiki.apache.org/cocoon/CocoonReleaseHowTo ? It seems to be what I was looking for. I was searching in the site and didn't remember there was a wiki ! -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/ -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: [DISCUSS] Release plan
Hi all, I indeed think that the the "aliveness" of Cocoon should be proved by releasing something. I am still one of the old players around here stuck with Cocoon-2.1 and one thing I could do is to help releasing 2.1.12 Do you think it could help people seeing Cocoon as a still-alive project ? Regards, Cdric Le 12/11/2012 10:25, Francesco Chicchiricc a crit: Hi all, yet another thread asking about Cocoon project vitality [1] was recently started. Besides other things, one of major issues seems to be the lack of a stable C3 release (but also missing updates for C2.2). = About C2.2.1, there is an outstanding request by Thorsten [2] asking for support on releasing the C2.2.X series. This means we could do this with no code effort: we just need someone either acting as RM or supporting Thorsten (I guess) as RM. = About C3, we *really* need to provide a stable release in the near future: the last official release is still alpha and, even though most of us are running latest SNAPSHOTs in production environment, we cannot ask this to end-users. AFAICT, the major outstanding issues that need to be solved before attempting to release 3.0.0-beta-1 (and after this a 3.0.0 release) are related to: * caching: COCOON3-30 / COCOON3-100 - an imperfect solution was implemented for COCOON3-61 (which actually needs some additional fixing I am going to provide in the next two weeks for a customer) that can be applied to COCOON3-100 as well; I'd rather move COCOON3-30 (and other caching improvements) to C3 3.0.1 * problems running 2 C3 webapps in the same container (COCOON3-107): together with Javier and Thorsten, during hackaton at latest ApacheCon EU 2012, we have probably found a way to fix this but performed no implementation yet We have also other stuff [3] but I'd move any other issue to either 3.0.X or 3.1.0. Finally, we have some outstanding proposals for improving the pipeline APIs from Simone [4] and Reinhard [5]: I'd push this anyway to C3 3.1.0. In addition to the code issues above, we need to improve and finish the documentation [6], still plenty of 'TBW' and javadocs (COCOON3-92); I would take these as blockers for 3.0.0, but not for 3.0.0-beta-1. = My questions now are: 1. Would you agree with the above drafted release plan? 2. If so, who is available to help with these tasks? Consider that documentation tasks are an easier way to contribute to the project even without development skills. If you've been using C3 and appreciate this, please don't deny your help: we really need it! Regards. [1] http://markmail.org/message/ycdrjbtx736akli3 [2] http://markmail.org/message/xs2wmijgej76n5u2 [3] https://issues.apache.org/jira/browse/COCOON3#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel [4] http://markmail.org/message/vztzzzjfckgees4v [5] http://markmail.org/message/szfzsrk4p3kkifi7 [6] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/parent/src/docbkx/reference -- www.anyware-services.com Inscrivez-vous notre newsletter Cdric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Htel Tlcom - Augustin Fresnel / 40 rue du Village d'entreprises / 31670 LABEGE Ametys: Smart Web CMS www.ametys.org Ce message et toutes les pices jointes (le "Message") sont confidentiels et tablis l'intention exclusive de ses destinataires. Toute modification, dition, utilisation ou diffusion non autorise est interdite. Anyware Services dcline toute responsabilit au titre de ce Message s'il a t altr, dform, falsifi ou dit, diffus sans autorisation.
Re: an issue with Cocoon source package release vote
Hi, I suppose that if we ever manage to release a 2.1.12 package, this will affect us as well. Is the way Forrest propose to solve the issue officially approved ? IMHO, if so, it won't be that hard to modify the Ant build file to produce separate packages with and without external dependencies. Regards, Cédric Le 10/04/2012 09:51, Simone Tripodi a écrit : Good morning David, if an action is required to fix the release, so +1. Cocoon 2.X people: are you following? :) -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Apr 5, 2012 at 7:40 AM, David Crossley cross...@apache.org wrote: Please see the following thread at Apache Forrest which explains the problem with conducting our release vote on a package that contained not only our project sources but also contained other binary files. That thread links to an important discussion at Apache Incubator, etc. Subject: [Proposal] re-release 0.9 with proper source code package http://s.apache.org/mCW There would be a similar situation for the Cocoon-2.1.11 release vote. -David -- www.anyware-services.com Inscrivez-vous à notre newsletter Cédric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - 254 avenue de l'Occitane - 31676 LABEGE CEDEX - France Ametys: Smart Web CMS www.ametys.org Ce message et toutes les pièces jointes (le "Message") sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Anyware Services décline toute responsabilité au titre de ce Message s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation.
Re: c3 pipelines (was Re: [jira] [Commented] (COCOON3-96) Add support for internal-only pipelines)
IIRC it was juste that configure() was brought by Avalon and setup()
by the SitemapComponent interface
At that time, you could setup a non-Configurable sitemap component.
But you're definitely right, a single setup() method with some
configuration parameters is enough.
Cédric
Le 04/04/2012 09:34, Robby Pelssers a écrit :
Exactly my thought. I never comprehended the difference between the configure() and setup() either. I'm pretty sure I asked the same in a old thread. Even for component developers this leads to confusion. Nice to see some good discussion being started !!
Robby
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of Simone Tripodi
Sent: Wednesday, April 04, 2012 8:42 AM
To: dev@cocoon.apache.org
Subject: Re: c3 pipelines (was Re: [jira] [Commented] (COCOON3-96) Add support for "internal-only" pipelines)
I second that concern since I am hitting lately some frontiers opposed
by that sitemap focused view. IMO *.xmap in the end should be a wrapper
to configure spring registered pipes.
+1000!!! :)
Some old school configure methods had sneaked into some componentes and
I think we should clean up some methods and ways to change attributes in
general.
For example the difference between configure() and setup() is IMO not
justifiable to maintain. Further the complete usage of java based
pipelines need to better be synced with the sitemap. I need to be able
to look up pipelines configured by the sitemap in a java only context.
can you believe that today I still get in trouble with that? If it is
confusing for me, I can imagine what users can think - not that I am
good, but of course more familiar that newcomers
However the principal difference ATM is that in xmap the hierarchy is
pipe-match-components but "match" is in no way part of the java pipe
api. Leading to the current situation where both are treated completely
separated.
However components such as regexpLinkRewriter and i18nTransformer should
be configured in a spring context to be reusable in a hybrid
environment. In one of our projects I had to duplicate the effort to
configure this. It is a "lesser evil" decisions for now but I am keen to
change it in the near future.
So bottom line IMHO c3 pipes being java or xmap should be usable vice
versa otherwise they cause double of work.
+1
...and if we think abstract the look up of a java pipe in xmap env would
be fire the request "matching" a pattern. What comes within a match are
basically a java pipe. The only thing is to integrate the input
module/language interpreter into the java pipe logic to make xmap pipes
usable as java pipe.
in the CLI module I started working on that, even if with a different
format that xmap - even if not complete yet (I feel shame for not
having completed yet) it shows anyway that injecting config parameters
to pipeline without the Map context is possible
Having worked with all versions and supporting projects that are hybrids
of c2.x and c3 I have to admit if we can think of the traditional 2.x
sitemap as config for spring and we can lookup and (re)use the matches
in both environments than we are so much more than the leading xml
framework since 1998. Since finally our Lego(tm) web components
(generators, transformers, ...) are not bound to avalon and reusable
everywhere.
Having said that, we need to sometimes expose much more setters in our
components to break away from the xmap and vice versa to expose setup()
method to configure the component via sitemap. The parameter based
configuration proofed to be quick and flexible to configure components
in both environments.
...maybe we even can implement "map:invoke-method name="setup|..." ..."
for components and "configure" them in a more general way. ... with the
benefit in reusing the logic in different environments.
I will write a summary of java pipes in c3 after we go online with the
main project we based on c3, but that may take at least 2 months.
You have my full support, please let me know if/how we can cooperate!
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
--
www.anyware-services.com
Inscrivez-vous
à notre newsletter
Cédric Damioli
Directeur technique
cedric.dami...@anyware-services.com
Te
Re: [JIRA] add more karma to Cedric and Robby
Hi all,
I just wanted to mark some issues as "Resolved" on the COCOON Jira
project but it seems I don't have any available action to do it.
Is it a karma issue ?
Thanks in advance,
Cédric
Le 11/01/2012 08:31, Reinhard Pötz a écrit :
On
01/10/2012 11:17 AM, Simone Tripodi wrote:
Good morning all,
I'm here to kindly ask if some of us has enough powers to give
more
karma on JIRA to our new PMC members Cedric (cedric) and Robby
(robbypelssers).
I cc-ed Reinhard because he added Francesco and I so at 90% he
can
help us (sorry for the noise Reinhard!)
Many thanks in advance, all the best!
done
--
www.anyware-services.com
Inscrivez-vous
à notre newsletter
Cédric Damioli
Directeur technique
cedric.dami...@anyware-services.com
Tel : +33(0)5 62 19 19 07
Mob : +33(0)6 87 03 61 63
Fax : +33(0)5 61 75 84 12
Adresse : Innopole 13 - 254 avenue de l'Occitane
- 31676 LABEGE CEDEX - France
Ametys: Smart Web CMS
www.ametys.org
Ce message et toutes les pièces jointes (le "Message") sont
confidentiels et établis à l'intention exclusive de ses
destinataires.
Toute modification, édition, utilisation ou diffusion non
autorisée est interdite.
Anyware Services décline
toute responsabilité au titre de ce Message s'il a été altéré,
déformé, falsifié ou édité, diffusé sans autorisation.
Re: [DISCUSS] online APIs doc
Big +1 Le 20/03/2012 09:43, Francesco Chicchiriccò a écrit : On 20/03/2012 08:46, Simone Tripodi wrote: Hi all guys, after many users request - last just received on user@ - I would suggest to deploy APIs doc on SVN to make them available online. If no objections will be shown in the next 72h, I'll proceed on deploying the C3 - guess I'll need help on deploying the C2.X versions. WDYT? A strong +1 from my side; the following links are copied from respective sites, and all lead to 404: http://cocoon.apache.org/2.1/apidocs/index.html http://cocoon.apache.org/3.0/apidocs/index.html About 2.2, the situation is better, since instead of a bare 404, visitors are warned Run the download script in order to get the Java API docs instead of this page. :-O http://cocoon.apache.org/2.2/core-modules/core/2.2/apidocs/index.html http://cocoon.apache.org/2.2/blocks/ajax/1.0/apidocs/index.html http://cocoon.apache.org/2.2/blocks/apples/1.0/apidocs/index.html ... I can help in generating C2.1 javadocs (well, at least I can try...) but in my opinion we should also enable javadoc reporting for C2.2 core and blocks in their POMs. Regards. -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/ -- Cédric Damioli Ametys CMS http://www.ametys.org http://www.anyware-services.com
Re: JIRA unification proposal
Hi, Unfortunately I don't had enough time to do this in the past weeks. I'd also like to have a stable 2.1.12 release soon, but I must admit that I've never used Dojo-related features in Cocoon 2.1.x. BTW, I just take a look at open JIRA issues targeted for 2.1.12 and nothing seems to be related to Dojo Regards, Cdric Le 27/02/2012 22:16, Kaj Kandler a crit: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/3/12 6:18 AM, Cdric Damioli wrote: Hi, I will actually work soon on 2.1 issues (at least those I've opened). I also want to have a look to all existing 2.1 issues, to measure the distance to an eventual 2.1.12 release in a near future. So please don't close all 2.1 entries right now. Hi Cedric, any update on this measurement? I saw some good things flowing into 2.1.12 in 2008, like Dojo being pulled from Google's script CDN. So I'm eager to see a (stable) 2.1.12 come out three years later ;-) Ko Chief Screencaster at http://plan-b-for-libreoffie.org/ - a site powered by Apache Cocoon. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9L8psACgkQRDUvrJRNjTBHxgCghbS8Fyj9IrLB3GkyU3AqLNW4 LIUAn3K8RAcOVRikH9bvF31IrLcXMuIR =jKj4 -END PGP SIGNATURE- -- www.anyware-services.com Inscrivez-vous notre newsletter Cdric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - 254 avenue de l'Occitane - B.P 97672 - 31676 LABEGE CEDEX - France Ametys: Smart Web CMS www.ametys.org Ce message et toutes les pices jointes (le "Message") sont confidentiels et tablis l'intention exclusive de ses destinataires. Toute modification, dition, utilisation ou diffusion non autorise est interdite. Anyware Services dcline toute responsabilit au titre de ce Message s'il a t altr, dform, falsifi ou dit, diffus sans autorisation.
Re: JIRA unification proposal
Hi, I will actually work soon on 2.1 issues (at least those I've opened). I also want to have a look to all existing 2.1 issues, to measure the distance to an eventual 2.1.12 release in a near future. So please don't close all 2.1 entries right now. It is IMHO a good thing to merge the two JIRA projects, but we should take care to the various components spread accross different versions. Cocoon 2.1 blocks are for instance a non sense for Cocoon 3, as well as Cocoon 3 components does not mean anything for Cocoon 2.x We could maybe rename such components with a prefix indicating their version ? Cdric Le 03/01/2012 11:59, Jasha Joachimsthal a crit: Merging those projects is good, but only if we clean up COCOON. There is a long list of issues with patches (there used to be a weekly mail with them) and an even longer list of unresolved issues. If we keep these issues open, it will be harder to see what we're working on and what we're dragging with us for years. IMO we can close the 2.1 and 2.2 issues that were created in 2010 or earlier with resolution "won't fix". They can always be reopened (or re-created) when someone is actually going to work on them. Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam -+31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 -+1 877 414 4776 (toll free) www.onehippo.com 2012/1/3 Francesco Chicchiricc ilgro...@apache.org Hi devs, as you all know, you currently have two separate projects on Apache JIRA, COCOON and COCOON3. Since there is currently a plan for restructuring the SVN tree [1], what if we unify these two projects on JIRA as well? AFAIK, this should involve: 1. create new versions and components on COCOON 2. move all tickets from COCOON3 to COCOON 3. close COCOON3 WDYT? Regards. [1] http://old.nabble.com/Re%3A--C3--Import-subprojects-proposal--WAS%3A-Re%3A--c3--Log4j-injection-in-target-of-blocks--td32880500.html -- Francesco Chicchiricc Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/ -- www.anyware-services.com Inscrivez-vous notre newsletter Cdric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - 254 avenue de l'Occitane - B.P 97672 - 31676 LABEGE CEDEX - France Ametys: Smart Web CMS www.ametys.org Ce message et toutes les pices jointes (le "Message") sont confidentiels et tablis l'intention exclusive de ses destinataires. Toute modification, dition, utilisation ou diffusion non autorise est interdite. Anyware Services dcline toute responsabilit au titre de ce Message s'il a t altr, dform, falsifi ou dit, diffus sans autorisation.
Re: Welcome Cédric Damioli and Robby Pelssers as Cocoon committers
Hi community, I'm very proud to have been nominated for Cocoon commitership. Thanks a lot to all who voted for me. Let's introduce briefly myself: I am a 32 years old french guy, living and working near Toulouse (south west of France). I am married with Florence and have two daughters, Lisa, 3 years and Julia, 7 months and 2 teeth since last week :) My long story with Cocoon began in 2002 as an intern of Sylvain Wallez, with pre-2.0 versions, on a time where sitemap was compiled and XSP were kings ! I was immediately impressed by the elegance of SAX based pipelines. I quickly learned to write custom components and to understand Cocoon internals. During the 7 next years, I have trained 100+ people from French administration and universities to Cocoon and developped dozens of Cocoon 2.0 and 2.1 based applications. Since 2009, I am the co-founder and CTO of Anyware Services, a small company developping Ametys (http://www.ametys.org), an Open Source Web CMS written on top of Cocoon 2.1. Ametys is currently mainly used by French universities, and run almost 50 000 sites around the world. Despite that Cocoon 2.1 may be considered as obsolete by many people, I still consider it as the best existing framework for building publishing applications. It is VERY stable and reliable. I must admit that I never considered a migration to Cocoon 2.2 nor 3.0, because of the amount of work it would represent to migrate all the features I hacked directly deep in the Cocoon internals. That's why I volunteered to help maintaining and releasing Cocoon 2.1 I hope to be able to contribute back to Cocoon community as much as it brought to me and my projects the last 10 years. Best regards, Cédric Damioli Le 18/12/2011 23:53, Sylvain Wallez a écrit : Hi all, I am very happy to announce that the Cocoon PMC has voted Cédric Damioli and Robby Pelssers as new Cocoon committers, provided of course that they accept it. Also, once you have your commit rights, you are welcome to join the Cocoon PMC whose member have binding votes for releases and other project matters. Please read the instructions for committers and PMC members [1], first thing being to send a CLA if not already done, and suggest your preferred account name. Welcome on board guys! Sylvain [1] http://apache.org/dev/#committers
Re: [2.1] Future of Cocoon 2.1.x... again :)
Hi team, I recently came again across annoying 2.1 bugs, which I have proposed patches for, and realized that I received almost no answers to my what's the future of Cocoon 2.1 e-mail, and that my patches have not been reviewed nor committed. I have found and patched a new one this morning : https://issues.apache.org/jira/browse/COCOON-2319 As I previously said, I fully understand that current Cocoon committers are focused on Cocoon 3, and that they probably have no great interest to old maintenance releases. Again, I totally volunteer to help to maintain and release 2.1.x branch, as I have dozens of production applications on top of it, running with a a-lot-patched Cocoon. Please tell me what I can do to help. Regards, Cédric Le 11/08/2011 15:36, Cédric Damioli a écrit : Hi Cocoon team, A little more than one year ago, I sent a mail [1] to this list, to get feedbacks about usage of Cocoon 2.1.x, 3 years after the last release. I must admit that I received many more answers (privately and publicly on the list) than I could have expected first. This proved me the vitality of the 2.1.x community. So I began to open some tickets [2] [3] [4] [5] [6] [7] and provide some patches gathered during the last years on my projects, but unfortunately, I received nearly no feedback from committers around here. Is there still any interest from devs for the 2.1.x branch ? Could someone review the patches ? I obviously volunteer to help, to stop having to run dozen apps with a patched Cocoon. Has someone interest to prepare and schedule a 2.1.12 maintenance release ? Best regards, Cédric [1] http://markmail.org/thread/hizllvbjdeurr2de [2] https://issues.apache.org/jira/browse/COCOON-2288, allow to use SLF4J [3] https://issues.apache.org/jira/browse/COCOON-2307, bug in the ResourceReader [4] https://issues.apache.org/jira/browse/COCOON-2309, possible bug with SitemapSource under certain circumstances [5] https://issues.apache.org/jira/browse/COCOON-2310, XHTMLSerializer from serializers block does not handle HTML5 [6] https://issues.apache.org/jira/browse/COCOON-2313, subclassing of org.apache.cocoon.Cocoon [7] https://issues.apache.org/jira/browse/COCOON-2314, override upload params in CocoonServlet
Re: [2.1] Future of Cocoon 2.1.x... again :)
Cocoon 2.1.x was meant to be used with 1.3 But the release notes file of the current 2.1.12-dev mention 1.4 as minimum requirement ! Le 12/12/2011 11:24, Robby Pelssers a crit: What JDK are you using? It seems like you will need a very old JDK for this branch to work. Robby From: Francesco Chicchiricc [mailto:ilgro...@apache.org] Sent: Monday, December 12, 2011 11:22 AM To: dev@cocoon.apache.org Subject: Re: [2.1] Future of Cocoon 2.1.x... again :) On 12/12/2011 11:00, Cdric Damioli wrote: Hi team, I recently came again across annoying 2.1 bugs, which I have proposed patches for, and realized that I received almost no answers to my "what's the future of Cocoon 2.1" e-mail, and that my patches have not been reviewed nor committed. I have found and patched a new one this morning : https://issues.apache.org/jira/browse/COCOON-2319 As I previously said, I fully understand that current Cocoon committers are focused on Cocoon 3, and that they probably have no great interest to old maintenance releases. Again, I totally volunteer to help to maintain and release 2.1.x branch, as I have dozens of production applications on top of it, running with a a-lot-patched Cocoon. Please tell me what I can do to help. Hi Cedric, as I wrote in [8], here it follows what I did for building C2.1 trunk (in order to start applying your patches, of course): 1. svn co https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X cocoon-2_1_X 2. cp blocks.properties local.blocks.properties 3. set include.all.blocks=true 4. ./build.sh 5. ./build.sh test resulted in 6 test failures (DefaultRunnableManagerTestCase) Am I doing something wrong? [8] http://mail-archives.apache.org/mod_mbox/cocoon-dev/201108.mbox/%3c4e4a7273.2020...@apache.org%3E Le 11/08/2011 15:36, Cdric Damioli a crit : Hi Cocoon team, A little more than one year ago, I sent a mail [1] to this list, to get feedbacks about usage of Cocoon 2.1.x, 3 years after the last release. I must admit that I received many more answers (privately and publicly on the list) than I could have expected first. This proved me the vitality of the 2.1.x community. So I began to open some tickets [2] [3] [4] [5] [6] [7] and provide some patches gathered during the last years on my projects, but unfortunately, I received nearly no feedback from committers around here. Is there still any interest from devs for the 2.1.x branch ? Could someone review the patches ? I obviously volunteer to help, to stop having to run dozen apps with a patched Cocoon. Has someone interest to prepare and schedule a 2.1.12 maintenance release ? Best regards, Cdric [1] http://markmail.org/thread/hizllvbjdeurr2de [2] https://issues.apache.org/jira/browse/COCOON-2288, allow to use SLF4J [3] https://issues.apache.org/jira/browse/COCOON-2307, bug in the ResourceReader [4] https://issues.apache.org/jira/browse/COCOON-2309, possible bug with SitemapSource under certain circumstances [5] https://issues.apache.org/jira/browse/COCOON-2310, XHTMLSerializer from serializers block does not handle HTML5 [6] https://issues.apache.org/jira/browse/COCOON-2313, subclassing of org.apache.cocoon.Cocoon [7] https://issues.apache.org/jira/browse/COCOON-2314, override upload params in CocoonServlet -- Francesco Chicchiricc Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/ -- www.anyware-services.com Inscrivez-vous notre newsletter Cdric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07
Re: [2.1] Future of Cocoon 2.1.x... again :)
Hi Francesco, Indeed, if I run tests with a JDK 6, I also have JUnit failures (could not remember which ones) but IIRC all tests run fine with JDK 1.4 Cdric Le 12/12/2011 11:22, Francesco Chicchiricc a crit: On 12/12/2011 11:00, Cdric Damioli wrote: Hi team, I recently came again across annoying 2.1 bugs, which I have proposed patches for, and realized that I received almost no answers to my "what's the future of Cocoon 2.1" e-mail, and that my patches have not been reviewed nor committed. I have found and patched a new one this morning : https://issues.apache.org/jira/browse/COCOON-2319 As I previously said, I fully understand that current Cocoon committers are focused on Cocoon 3, and that they probably have no great interest to old maintenance releases. Again, I totally volunteer to help to maintain and release 2.1.x branch, as I have dozens of production applications on top of it, running with a a-lot-patched Cocoon. Please tell me what I can do to help. Hi Cedric, as I wrote in [8], here it follows what I did for building C2.1 trunk (in order to start applying your patches, of course): 1. svn co https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X cocoon-2_1_X 2. cp blocks.properties local.blocks.properties 3. set include.all.blocks=true 4. ./build.sh 5. ./build.sh test resulted in 6 test failures (DefaultRunnableManagerTestCase) Am I doing something wrong? [8] http://mail-archives.apache.org/mod_mbox/cocoon-dev/201108.mbox/%3c4e4a7273.2020...@apache.org%3E Le 11/08/2011 15:36, Cdric Damioli a crit : Hi Cocoon team, A little more than one year ago, I sent a mail [1] to this list, to get feedbacks about usage of Cocoon 2.1.x, 3 years after the last release. I must admit that I received many more answers (privately and publicly on the list) than I could have expected first. This proved me the vitality of the 2.1.x community. So I began to open some tickets [2] [3] [4] [5] [6] [7] and provide some patches gathered during the last years on my projects, but unfortunately, I received nearly no feedback from committers around here. Is there still any interest from devs for the 2.1.x branch ? Could someone review the patches ? I obviously volunteer to help, to stop having to run dozen apps with a patched Cocoon. Has someone interest to prepare and schedule a 2.1.12 maintenance release ? Best regards, Cdric [1] http://markmail.org/thread/hizllvbjdeurr2de [2] https://issues.apache.org/jira/browse/COCOON-2288, allow to use SLF4J [3] https://issues.apache.org/jira/browse/COCOON-2307, bug in the ResourceReader [4] https://issues.apache.org/jira/browse/COCOON-2309, possible bug with SitemapSource under certain circumstances [5] https://issues.apache.org/jira/browse/COCOON-2310, XHTMLSerializer from serializers block does not handle HTML5 [6] https://issues.apache.org/jira/browse/COCOON-2313, subclassing of org.apache.cocoon.Cocoon [7] https://issues.apache.org/jira/browse/COCOON-2314, override upload params in CocoonServlet -- Francesco Chicchiricc Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/ -- www.anyware-services.com Inscrivez-vous notre newsletter Cdric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - 254 avenue de l'Occitane - B.P 97672 - 31676 LABEGE CEDEX - France Ametys: Smart Web CMS www.ametys.org Ce message et toutes les pices jointes (le "Message") sont confidentiels et tablis l'intention exclusive de ses destinataires. Toute modification,
[2.1] Future of Cocoon 2.1.x... again :)
Hi Cocoon team, A little more than one year ago, I sent a mail [1] to this list, to get feedbacks about usage of Cocoon 2.1.x, 3 years after the last release. I must admit that I received many more answers (privately and publicly on the list) than I could have expected first. This proved me the vitality of the 2.1.x community. So I began to open some tickets [2] [3] [4] [5] [6] [7] and provide some patches gathered during the last years on my projects, but unfortunately, I received nearly no feedback from committers around here. Is there still any interest from devs for the 2.1.x branch ? Could someone review the patches ? I obviously volunteer to help, to stop having to run dozen apps with a patched Cocoon. Has someone interest to prepare and schedule a 2.1.12 maintenance release ? Best regards, Cédric [1] http://markmail.org/thread/hizllvbjdeurr2de [2] https://issues.apache.org/jira/browse/COCOON-2288, allow to use SLF4J [3] https://issues.apache.org/jira/browse/COCOON-2307, bug in the ResourceReader [4] https://issues.apache.org/jira/browse/COCOON-2309, possible bug with SitemapSource under certain circumstances [5] https://issues.apache.org/jira/browse/COCOON-2310, XHTMLSerializer from serializers block does not handle HTML5 [6] https://issues.apache.org/jira/browse/COCOON-2313, subclassing of org.apache.cocoon.Cocoon [7] https://issues.apache.org/jira/browse/COCOON-2314, override upload params in CocoonServlet -- Cédric Damioli ANYWARE SERVICES http://www.anyware-services.com http://www.ametys.org
Re: [2.1.11] Strange behaviour with a cocoon://, mount and redirect combination
Yes.
The SitemapSource is executed within the root sitemap, so the
redirection leads to an error.
Cédric
Le 04/10/2010 18:58, Laurent Medioni a écrit :
Hi,
" but if I call http://server/test2/A, it redirects internally to
cocoon:/B (ignoring the mount), thus leading to a 404 Not Found."
Do you mean it is trying to match cocoon:/B in the root sitemap ?
Laurent
-Original Message-----
From: Cédric Damioli [mailto:cedric.dami...@anyware-services.com]
Sent: samedi, 2. octobre 2010 17:04
To: dev@cocoon.apache.org
Subject: [2.1.11] Strange behaviour with a cocoon://, mount and redirect combination
Hi team,
Before filling an JIRA issue, I wanted to know if the following use case
is actually a bug or a feature (Cocoon 2.1.11):
I have two sitemaps:
In the root sitemap, I write two pipelines:
map:match pattern="test/**"
map:mount src="" uri-prefix="test" /
/map:match
map:match pattern="test2/**"
map:generate src="" /
map:serialize/
/map:match
In the sub sitemap, I have:
map:match pattern="A"
map:redirect-to uri="B" /
/map:match
map:match pattern="B"
// does real stuff here
/map:match
Now, if I call directly http://server/test/A, it correctly redirects me
to http://server/test/B (the redirect is relative to the request URI and
thus to the mounted sitemap),
but if I call http://server/test2/A, it redirects internally to
cocoon:/B (ignoring the mount), thus leading to a 404 Not Found.
Note that if I rewrite the pipeline A to redirect to cocoon:/B instead
of B, it works as expected.
Technically speaking, in the first case, the redirection is made by the
HttpEnvironment which rely directly on Response.sendRedirect() which,
according to the servlet spec, interprets URI relative to the current
requestURI if it does not begin with a '/'.
In the second case, the redirection is handled by the EnvironmentWrapper
created by the SitemapSource, which does not know anything about an
eventual mount point when actually processing the redirection.
Looking at the code, a relative redirect within a cocoon:// pipeline can
only work in the same sitemap then the calling pipeline, as the
redirectURL is prefixed with "cocoon:/" before processing
(SitemapSource.java, revision 540711, line 366).
So my question is: is it a bug ? Or do I have to consider that this is
the correct behaviour of the redirector ?
If this is considered as a bug, we could simply change the SitemapSource
so that when getting a relative redirect, the URL is rewritten and the
whole process is run again.
What do others think ?
Regards,
--
www.anyware-services.com
Cédric Damioli
Directeur technique
cedric.dami...@anyware-services.com
Tel : +33(0)5 62 19 19 07
Mob : +33(0)6 87 03 61 63
Fax : +33(0)5 61 75 84 12
Adresse : Innopole 13 - L'Occitane - B.P 97672 -
31676 LABEGE CEDEX - France
Ametys: le CMS Web Java Open Source
www.ametys.org
Ce message et toutes les pièces jointes (le "Message") sont
confidentiels et établis à l'intention exclusive de ses
destinataires.
Toute modification, édition, utilisation ou diffusion non
autorisée est interdite.
Anyware Services décline
toute responsabilité au titre de ce Message s'il a été altéré,
déformé, falsifié ou édité, diffusé sans autorisation.
[2.1.11] Strange behaviour with a cocoon://, mount and redirect combination
Hi team,
Before filling an JIRA issue, I wanted to know if the following use case
is actually a bug or a feature (Cocoon 2.1.11):
I have two sitemaps:
In the root sitemap, I write two pipelines:
map:match pattern=test/**
map:mount src=sub/sitemap.xmap uri-prefix=test /
/map:match
map:match pattern=test2/**
map:generate src=cocoon://test/{1} /
map:serialize/
/map:match
In the sub sitemap, I have:
map:match pattern=A
map:redirect-to uri=B /
/map:match
map:match pattern=B
// does real stuff here
/map:match
Now, if I call directly http://server/test/A, it correctly redirects me
to http://server/test/B (the redirect is relative to the request URI and
thus to the mounted sitemap),
but if I call http://server/test2/A, it redirects internally to
cocoon:/B (ignoring the mount), thus leading to a 404 Not Found.
Note that if I rewrite the pipeline A to redirect to cocoon:/B instead
of B, it works as expected.
Technically speaking, in the first case, the redirection is made by the
HttpEnvironment which rely directly on Response.sendRedirect() which,
according to the servlet spec, interprets URI relative to the current
requestURI if it does not begin with a '/'.
In the second case, the redirection is handled by the EnvironmentWrapper
created by the SitemapSource, which does not know anything about an
eventual mount point when actually processing the redirection.
Looking at the code, a relative redirect within a cocoon:// pipeline can
only work in the same sitemap then the calling pipeline, as the
redirectURL is prefixed with cocoon:/ before processing
(SitemapSource.java, revision 540711, line 366).
So my question is: is it a bug ? Or do I have to consider that this is
the correct behaviour of the redirector ?
If this is considered as a bug, we could simply change the SitemapSource
so that when getting a relative redirect, the URL is rewritten and the
whole process is run again.
What do others think ?
Regards,
--
Cédric Damioli
ANYWARE SERVICES
http://www.anyware-services.com
http://www.ametys.org
[2.1] Use SLF4J for traces
Hi all, I've submitted a patch in https://issues.apache.org/jira/browse/COCOON-2288, allowing usage of the SLF4J logging facade in Cocoon 2.1. SLF4J (http://www.slf4j.org) allows to change logging subsystem by simply dropping corresponding jar in the classpath, without modifying Cocoon itself. Implementations are currently available for log4j, JCL and logback. Could someone review and eventually apply it ? Regards, -- Cédric Damioli RD director CMS Ametys ANYWARE SERVICES Tel : +33 (0)5 61 00 73 47 Mob : +33 (0)6 87 03 61 63 Fax : +33 (0)5 61 00 51 46 http://www.anyware-services.com http://www.ametys.org
Re: [2.1] Is Cocoon 2.1.x officially dead ?
Hi Francesco, Sorry for the broken URL. You have access to the SVN here : https://svn.ametys.org and to the viewvc here : http://viewvc.ametys.org For JCR details, its quite off topic here, but feel free to ask if you have any questions Regards, Cdric Le 29/03/2010 09:10, Francesco Chicchiricc a crit: On 29/mar/10, at 00:10, Cdric Damioli wrote: [...] BTW, for the records (and eventually some "who use it" page), here at Anyware, we build an Open Source CMS around Cocoon 2.1, called Ametys (http://www.ametys.org), which is currently in its "3.0 beta" version, also leveraging JCR-Jackrabbit, Lucene and OSWorkflow. We currently have about 50 live systems, handling 2+ web sites. So we'll continue to use and support Cocoon for many years ! Hei, this is very interesting to know :-) I really would like to see how you dealt with implementation of JCR-related components! I tried to access [1] with no success, could you point me to a subversion repository? Thanks. Cheers. [1] http://viewvc.ametys.org/viewvc/ametys/trunk/cms/trunk -- www.anyware-services.com Cdric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - L'Occitane - B.P 97672 - 31676 LABEGE CEDEX - France Ametys: le CMS Web Java Open Source www.ametys.org Ce message et toutes les pices jointes (le "Message") sont confidentiels et tablis l'intention exclusive de ses destinataires. Toute modification, dition, utilisation ou diffusion non autorise est interdite. Anyware Services dcline toute responsabilit au titre de ce Message s'il a t altr, dform, falsifi ou dit, diffus sans autorisation.
Re: [2.1] Is Cocoon 2.1.x officially dead ?
Hi all, Now that I know that the 2.1 community is alive and healthy, I'll begin to send various patches I've collected during the last few years :-) First of all, may someone review and eventually apply https://issues.apache.org/jira/browse/COCOON-2286 ? It's a very small patch allowing users of serializers-block to start Cocoon from a directory which path contains spaces (such as "C:\Program Files") BTW, for the records (and eventually some "who use it" page), here at Anyware, we build an Open Source CMS around Cocoon 2.1, called Ametys (http://www.ametys.org), which is currently in its "3.0 beta" version, also leveraging JCR-Jackrabbit, Lucene and OSWorkflow. We currently have about 50 live systems, handling 2+ web sites. So we'll continue to use and support Cocoon for many years ! Regards, Cdric Le 23/03/2010 10:52, Sylvain Wallez a crit: David Crossley wrote: Bertrand Delacretaz wrote: Cdric Damioli wrote: ...I'm wondering if someone around here was still willing to maintain the Cocoon-2.1 branch ? If not, I volunteer to do the job, as this branch is important for us, and I don't want to have to fork it in our own repository I'm +1 on someone maintaining the 2.1 branch and cutting releases as needed. I don't use Cocoon anymore, but some of the projects that I created with 2.1.x a few years ago are still running very well and maintained, though more at the application level where they probably don't need changes to Cocoon itself. I think 2.1.x is stable enough for people who use it to stay on that version, so maintaining it makes at lot of sense. Are there any current committers willing to help maintain it? Yes, i will play a part. I can certainly help with the release process. I have tried on various occasions to apply some of the outstanding patches, but had difficulty. It would need the help of others. I still have a pretty good memory of Cocoon 2.1.x internals, and can help to review/apply patches. But I can't do any test on a real world application, so will need help from the user community before we can make a release. Sylvain -- www.anyware-services.com Cdric Damioli Directeur technique cedric.dami...@anyware-services.com Tel : +33(0)5 62 19 19 07 Mob : +33(0)6 87 03 61 63 Fax : +33(0)5 61 75 84 12 Adresse : Innopole 13 - L'Occitane - B.P 97672 - 31676 LABEGE CEDEX - France Ametys: le CMS Web Java Open Source www.ametys.org Ce message et toutes les pices jointes (le "Message") sont confidentiels et tablis l'intention exclusive de ses destinataires. Toute modification, dition, utilisation ou diffusion non autorise est interdite. Anyware Services dcline toute responsabilit au titre de ce Message s'il a t altr, dform, falsifi ou dit, diffus sans autorisation.
[2.1] Is Cocoon 2.1.x officially dead ?
Hi Cocoon community, Here at Anyware, we have dozens of Cocoon-2.1 based applications in production. We've hacked Cocoon a lot, so that migrating to most recent releases of Cocoon is not an option for us at the moment Cocoon 2.1 is a *very* stable framework, especially the core, but I recently came across a bug and discovered that, even if I provide a patch, there will be nobody to commit it, let alone release the next 2.1.12 maintenance version. Diving in the ML archives, I discovered than Carsten, the last 2.1 release manager, resigned from the job almost two years ago [1], and that nobody took over. So I'm wondering if someone around here was still willing to maintain the Cocoon-2.1 branch ? If not, I volunteer to do the job, as this branch is important for us, and I don't want to have to fork it in our own repository. Otherwise, do you have other solutions for me ? BTW, is there still many Cocoon-2.1 users around here ? Best regards, Cédric Damioli [1] http://mail-archives.apache.org/mod_mbox/cocoon-dev/200805.mbox/%3c483cf62f.3000...@apache.org%3e -- Cédric Damioli RD director Ametys CMS ANYWARE SERVICES Tel : +33 (0)5 61 00 73 47 Mob : +33 (0)6 87 03 61 63 Fax : +33 (0)5 61 00 51 46 http://www.anyware-services.com http://www.ametys.org
2.1.12 maintenance release ?
Hi all, I'm wondering if there could be a 2.1.12 maintenance release in a near future. Last thread about that was issued by Carsten mor than one year ago! There was only a few bugs fixed since 2.1.11, but one of these is quite important : a deadlock occuring in AbstractCachingProcessingPipeline (COCOON-1985). WDYT ? Regards, -- Cédric Damioli Ametys product manager CMS Solutions ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 73 47 Mob : +33 (0)6 87 03 61 63 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com http://www.ametys.fr / http://www.ametys.org Ce message et toutes les pièces jointes (le Message) sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Anyware Technologies et sa maison mère Wavecom déclinent toute responsabilité au titre de ce Message s'il a été altéré, déformé, falsifié ou édité, diffusé sans autorisation.
Bug when overriding the SourceResolver in a sub-sitemap
Hi all, I just discovered a strange behaviour with Cocoon 2.1.10. I have created a dummy, easily, reproducible sample to demonstrate it : Let suppose you want to add a new SourceFactory implementation in a sub-sitemap, you may write something as : map:components source-factories component-instance class=org.apache.cocoon.components.source.impl.ContextSourceFactory name=context2/ /source-factories /map:components Actually, you also have to declare again the SourceResolver component at this level, so that it will be declared in the correct ComponentManager. map:components source-resolver class=org.apache.excalibur.source.impl.SourceResolverImpl/ source-factories component-instance class=org.apache.cocoon.components.source.impl.ContextSourceFactory name=context2/ /source-factories /map:components and then use it in your pipeline with : map:match pattern=foo map:generate type=file src=context2://welcome.xml/ map:serialize type=xml/ /map:match However, it does not work... And why ? Because in the FileGenerator, as in all others sitemap components, the SourceResolver object given in the setup() or act() method is the wrong one (ie that of top CocoonComponentManager). So the resolver.resolveURI(context2://welcome.xml) will fail. Of course, if I execute manager.lookup(SourceResolver.ROLE).resolveURI(context2://welcome.xml), it is totally correct, because it uses the good SourceResolver (that of the sitemap's CocoonComponentManager). So anybody has an idea ? Why maintaining two parallel SourceResolver objects in all Cocoon internals (that of the TreeProcessor (correct one) and that of the Environment (wrong one)) ? This example is of course very simple, but my real life production app has a similar need. Any help appreciated. Regards, Cédric
Re: [jcr] Scope of JCRNodeSource
Hi Andreas, This block is really in an very early stage of development. In the actually committed version, it does not work as expected. Sylvain first wrote this JCRNodeSource for my own needs (I am one of his coworkers) and I've applied many many patches to it without contributing them back to Cocoon. I obviously apologize for that :-) With this introduction beeing made, I'll try to answer your questions : Andreas Hartmann a écrit : Hi Cocoon devs, I'm currently examining the JCR block (thanks, Sylvain, Michi and all others who were involved!) Some questions: 1) IIUC, every time a source is resolved a new JCR session is created. Does this mean that no transactions can be used? Maybe it would make sense to attach the JCR session to the Cocoon session, so that all resolved JCRNodeSources save their data to a single session which would allow them to take part in a single transaction? There are many points here : some may wants to attach to the JCR Session to the Servlet Session, others will want to attach JCR Session to the Request (as a JDBC Connection, this is my case), others will want to have one single JCR Session for the entire application. This IMHO must be a configurable thing. Other problem is the logout one : when called, the repository.login() is made by the JCR block classes, but the logout must be made by the application. But when ? I choose to implement this via Servlet's RequestListeners or SessionListeners. You may also extend the CocoonServlet to logout at the end of the service() method. 2) How about storing additional custom properties (e.g., meta data) in the node which is represented by the source? good point :-) The JCRNodeSource is actually made for Nodes :-) This idea was to also have a JCRPropertySource. But it has never been implemented. 3) How about locking and versioning? Another good point. At the begining of my JCR-related work, I wanted to have VersionedSource, LockableSource, and then LockableModifiableTraversableVersionableSource :-p And I then realized that such business logic things may overrun the goal of Sources. So I finally simply get the JCR Node from the JCRNodeSource and directly play with JCR API in my own business logic classes. Sylvain and I have actually had different ideas about what a JCRSource must be. I personally thought about an entry point to every JCR Item in the Repository (it appears it is what you want too) Sylvain thought more about a TraversableSource with directories and files (actually nt:directory and nt:file Nodes). I would be interested to known your usecases. Regards, Cédric -- Cédric Damioli ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com
Re: [jcr] Scope of JCRNodeSource
Andreas Hartmann a écrit : Cédric Damioli wrote: Hi Andreas, This block is really in an very early stage of development. In the actually committed version, it does not work as expected. Sylvain first wrote this JCRNodeSource for my own needs (I am one of his coworkers) and I've applied many many patches to it without contributing them back to Cocoon. BTW - are you planning to provide your work to the project? I'm just asking because I want to avoid doing work which has already been done :) -- Andreas Yes, it is in our TODO list... We have to fix some bugs and so on, and we will contribute our changes. But I'm afraid we won't have much time in the next few days to play with the JCR stuff... BTW the JCRNodeSource in itself does not do much : it is only Traversable and Modifiable. IMHO, one of its most interesting method is getNode(), which provide access to JCR Node :-) Regards, Cédric -- Cédric Damioli Chef de projets systèmes d'informations Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com
Re: CocoonTask
Upayavira, Any thoughts about this ? Or do you prefer that I come up with a concrete proposal ? :-) Cédric Cédric Damioli wrote: Upayavira wrote: Cédric Damioli wrote: Hi, I'm using CocoonTask, wich allow CocoonBean to be embedded in a Ant build script. Great. I'm glad to hear you're using it. I'm actually running Cocoon in a servlet, which periodically executes an Ant build script ending with the CocoonTask :-) Seems complex, but is really effective !!! And your work on the CLI is great and very appreciated ;-) I'm wondering if there's any reasons why there's no access (via protected method or fields or whatever) to the CocoonBean. Basically, the CocoonBean is invoked via reflection, using a different classloader. Now, I'm no reflection expert, and calling each getter and setter one at a time using reflection seemed unreasonably complex. So, I chose to create a Delegate class, invoke that with reflection, and have that do the real work. I'm ok with the concept of single entry point, but what I wanted is the possibility to act on the CocoonBean before processing the different uris. Imagine you have a Java method returning a Collection of uris to be processed, you may want to directly fill the CocoonBean with this Collection, instead of dynamically re-creating the CocoonBean configuration. I wanted to use it directly to add BeanListeners, eventually add targets, and so on... What sort of listeners would you like to add? If you want to specify a different listener, I would suggest coming up with a generic way to specify listeners and add that to the BeanConfigurator, so that all users of the CLI and Ant task get to benefit. I wanted to add org.apache.cocoon.bean.BeanListener implementations to my instance of CocoonBean. The problem with adding this at BeanConfigurator level is that we can't interact with the Ant Project (or its Properties), for example, or whatever is not directly tied to the Bean. IMHO, the best way to open the CocoonTask is to allow subclasses to change the delegate class (org.apache.cocoon.bean.helpers.AntDelegate at the moment) and to give this delegate access to the calling Ant project. So you supply a piece of java that configures the bean before running? Hmmm, I would much rather extend the xconf format to be able to add everything you want. The CocoonTask really should not assume any Java knowledge in its users. Of course, but I think that the xconf format is already very complete for users who do not want to write any Java code : all the setters of the Bean have their counterparts in the xconf format (except the addBuildListener). The next step would be to add a syntax to add Java entry points (such as : listener class=.../ or configurator class=.../) but users of such a syntax would have to write Java code anyway. What I proposed is to have the possibility to extend the CocoonTask (or the AntDelegate, or both) to provide access to users (such as me :-) ) who want to have more control over the Bean. Regards, Upayavira Cédric
Re: CocoonTask
Upayavira wrote:
Cédric Damioli wrote:
Upayavira wrote:
Cédric Damioli wrote:
I'm wondering if there's any reasons why there's no access (via
protected method or fields or whatever) to the CocoonBean.
Basically, the CocoonBean is invoked via reflection, using a
different classloader. Now, I'm no reflection expert, and calling
each getter and setter one at a time using reflection seemed
unreasonably complex. So, I chose to create a Delegate class,
invoke that with reflection, and have that do the real work.
I'm ok with the concept of single entry point, but what I wanted
is the possibility to act on the CocoonBean before processing the
different uris.
Imagine you have a Java method returning a Collection of uris to be
processed, you may want to directly fill the CocoonBean with this
Collection, instead of dynamically re-creating the CocoonBean
configuration.
So you're saying that you've got code running in other Ant tasks, and
that Java code wants to make collection data available to the
CocoonTask? How would it get there? Could you include a sample of the
code that your CocoonAntDelegate would use?
The AntDelegate I currently use is basically like :
public process (Document xconf, String uriGroup,
org.apache.tools.ant.Project project)
{
CocoonBean cocoon = new CocoonBean();
// Adding some target URIs, coming from anywhere (database, Ant
properties, environment, ...)
cocoon.addTarget(...);
// Adding some listeners
cocoon.addListener(...);
BeanConfigurator.configure(...);
cocoon.initialize();
cocoon.process();
cocoon.dispose();
}
I see the AntDelegate as a bridge between Ant and Cocoon worlds : it is
why I included the Project as third argument. But I think it's not
enough : the AntDelegate could be extensible, and become a real class
(not only with a single static method), or even an interface with the
current AntDelegate as a default implementation.
BTW, i don't see why you used an OutputStreamListener as last argument
of BeanConfigurator.configure()
IIUC, the OutputStreamListener mixes two roles : a role of
DefaultListener (logging to stdout) and a role of reporter (generating a
report for broken-links), actually used by the BeanConfigurator. May
this Listener be split into two : a DefaultListener and a
BrokenLinksListener ?
I wanted to use it directly to add BeanListeners, eventually add
targets, and so on...
What sort of listeners would you like to add? If you want to
specify a different listener, I would suggest coming up with a
generic way to specify listeners and add that to the
BeanConfigurator, so that all users of the CLI and Ant task get to
benefit.
I wanted to add org.apache.cocoon.bean.BeanListener implementations
to my instance of CocoonBean.
The problem with adding this at BeanConfigurator level is that we
can't interact with the Ant Project (or its Properties), for
example, or whatever is not directly tied to the Bean.
Sorry, I don't understand. What do you mean that you can't interact
with the Ant project? You can use Ant properties in the Cocoon task.
Are you looking for a greater integration?
Let me give an example :
I have a Java class able to retrieve somewhere (in a DB with JDBC, or in
a XML file, ...) a list of uris to be processed by the CocoonBean.
I have to instanciate this class, set some parameters and finally asking
it for the URIs list.
I'm not an Ant expert, but I think it would be hard to do it easily in
pure Ant. With my new AntDelegate, it's very easy.
I think you're getting at something here. What I'd like to see is the
Ant task using Ant's methods and approaches to configure itself,
rather than using Java - putting your code into Java can hide it, as
far as the Ant script is concerned.
IMHO, the best way to open the CocoonTask is to allow subclasses
to change the delegate class
(org.apache.cocoon.bean.helpers.AntDelegate at the moment) and
to give this delegate access to the calling Ant project.
So you supply a piece of java that configures the bean before
running? Hmmm, I would much rather extend the xconf format to be
able to add everything you want. The CocoonTask really should not
assume any Java knowledge in its users.
Of course, but I think that the xconf format is already very
complete for users who do not want to write any Java code : all the
setters of the Bean have their counterparts in the xconf format
(except the addBuildListener). The next step would be to add a
syntax to add Java entry points (such as : listener class=.../
or configurator class=.../) but users of such a syntax would
have to write Java code anyway.
What I proposed is to have the possibility to extend the CocoonTask
(or the AntDelegate, or both) to provide access to users (such as me
:-) ) who want to have more control over the Bean.
I'm okay with that, but I'd like to see if it is possible to keep that
sort of configuration out of Java
CocoonTask
Hi, I'm using CocoonTask, wich allow CocoonBean to be embedded in a Ant build script. I'm wondering if there's any reasons why there's no access (via protected method or fields or whatever) to the CocoonBean. I wanted to use it directly to add BeanListeners, eventually add targets, and so on... IMHO, the best way to open the CocoonTask is to allow subclasses to change the delegate class (org.apache.cocoon.bean.helpers.AntDelegate at the moment) and to give this delegate access to the calling Ant project. What do you mean ? Cédric Damioli
Re: CocoonTask
Upayavira wrote: Cédric Damioli wrote: Hi, I'm using CocoonTask, wich allow CocoonBean to be embedded in a Ant build script. Great. I'm glad to hear you're using it. I'm actually running Cocoon in a servlet, which periodically executes an Ant build script ending with the CocoonTask :-) Seems complex, but is really effective !!! And your work on the CLI is great and very appreciated ;-) I'm wondering if there's any reasons why there's no access (via protected method or fields or whatever) to the CocoonBean. Basically, the CocoonBean is invoked via reflection, using a different classloader. Now, I'm no reflection expert, and calling each getter and setter one at a time using reflection seemed unreasonably complex. So, I chose to create a Delegate class, invoke that with reflection, and have that do the real work. I'm ok with the concept of single entry point, but what I wanted is the possibility to act on the CocoonBean before processing the different uris. Imagine you have a Java method returning a Collection of uris to be processed, you may want to directly fill the CocoonBean with this Collection, instead of dynamically re-creating the CocoonBean configuration. I wanted to use it directly to add BeanListeners, eventually add targets, and so on... What sort of listeners would you like to add? If you want to specify a different listener, I would suggest coming up with a generic way to specify listeners and add that to the BeanConfigurator, so that all users of the CLI and Ant task get to benefit. I wanted to add org.apache.cocoon.bean.BeanListener implementations to my instance of CocoonBean. The problem with adding this at BeanConfigurator level is that we can't interact with the Ant Project (or its Properties), for example, or whatever is not directly tied to the Bean. IMHO, the best way to open the CocoonTask is to allow subclasses to change the delegate class (org.apache.cocoon.bean.helpers.AntDelegate at the moment) and to give this delegate access to the calling Ant project. So you supply a piece of java that configures the bean before running? Hmmm, I would much rather extend the xconf format to be able to add everything you want. The CocoonTask really should not assume any Java knowledge in its users. Of course, but I think that the xconf format is already very complete for users who do not want to write any Java code : all the setters of the Bean have their counterparts in the xconf format (except the addBuildListener). The next step would be to add a syntax to add Java entry points (such as : listener class=.../ or configurator class=.../) but users of such a syntax would have to write Java code anyway. What I proposed is to have the possibility to extend the CocoonTask (or the AntDelegate, or both) to provide access to users (such as me :-) ) who want to have more control over the Bean. Regards, Upayavira Cédric
