Re: [VOTE] Retire 2.1/3.0 and keep 2.x
On 13/12/23 15:00, Cédric Damioli wrote: 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. +1 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/
Re: [DISCUSS] Retiring 3.0 ? (Was: Re: Future of the Cocoon project)
On 2023/12/01 17:45:42 Francesco Chicchiriccò wrote: > On 01/12/23 18:24, Cédric Damioli wrote: > > 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. > > Cocoon 3.0 has been my first "serious" approach to The ASF and also where I > earned committership and PMC membership. > > I am not pleased to admin that, but I think it is time to let it go: while > its ground ideas were incredibly neat at the time, they never turned into > mainstream, regrettably. > > It has been even used by Syncope until 3.0.0-M0 [1] around Q4 2022. Also found [2] from my archives, at a cross site with the old Hippo CMS... > Regards. > > [1] > https://github.com/apache/syncope/blob/syncope-3.0.0-M0/pom.xml#L1167-L1176 [2] https://hct.tirasa.net/ > -- > 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/ > >
Re: [DISCUSS] Retiring 3.0 ? (Was: Re: Future of the Cocoon project)
On 01/12/23 18:24, Cédric Damioli wrote: 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. Cocoon 3.0 has been my first "serious" approach to The ASF and also where I earned committership and PMC membership. I am not pleased to admin that, but I think it is time to let it go: while its ground ideas were incredibly neat at the time, they never turned into mainstream, regrettably. It has been even used by Syncope until 3.0.0-M0 [1] around Q4 2022. Regards. [1] https://github.com/apache/syncope/blob/syncope-3.0.0-M0/pom.xml#L1167-L1176 -- 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/
Re: [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
Here is my +1. Download and build checked on Linux, JDK 17. Sorry it took so long. Regards. On 2023/10/29 11:55:14 Christofer Dutz wrote: > 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: 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) > > > [1] https://repository.apache.org/content/repositories/orgapachecocoon-1007 > [2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/ > [3] https://www.apache.org/dev/release.html#approving-a-release > [4] > https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release > >
Re: [VOTE] Release Cocoon 2.1.13
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/
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
On 25/06/20 19:52, Cédric Damioli wrote: > 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 ? I can confirm it works like a charm - and Jenkins agrees: https://builds.apache.org/view/A-D/view/Cocoon/job/Cocoon%202.1.X/143/ Good job! 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/
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
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: >>> >>> >>>>> 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. 100% agree of course :-) >> 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. 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/
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
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. 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? 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/
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
On 23/06/20 09:23, Francesco Chicchiriccò wrote: > On 22/06/20 16:58, Cédric Damioli wrote: >> 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. >> 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 :-) Jenkins confirms: build #142 is succeeding again. https://builds.apache.org/view/A-D/view/Cocoon/job/Cocoon%202.1.X/142/ -- 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/
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
On 22/06/20 16:58, Cédric Damioli wrote: > 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. > > 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. -- 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/
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
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. -- 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/
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
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. > 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/
Re: Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
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/
Fwd: Cocoon 2.1.X - Build # 141 - Still Failing
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.
Re: Upcoming 2.1.13 release
+1 go ahead Cédric! ;-) On 17/06/20 01:29, Cédric Damioli wrote: > 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 -- 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/
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.
--
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/
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.
--
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/
Re: [DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1
On 10/10/2016 19:28, Antonio Gallardo wrote: Hi folks, +1 for 1.5. If in the future we have the need to move to a more recent version (ie: because a patch), then we should discuss it. Hi, we *are* discussing exactly that. At the moment we have a couple of patches on hold, for COCOON-2354 and COCOON-2352. Since it seems to me that there is enough consensus to move on, I will open a new issue for setting the compatibility to JDK 1.5 (at least for the moment) so that we can move on and accept the two patches above. Regards. On 07/10/16 03:46, Francesco Chicchiriccò wrote: Hi all, as recently noticed during the (unfortunately rejected) patch for COCOON-2354 [1], it might make sense to upgrade the current minimum JDK requirement for Cocoon 2.1 from 1.4 to 1.5, mainly to ease some upgrades and help Cocoon 2.1 living in the modern world. Besides 3rd part library updates, some work could be needed to upgrade our Java code, so help would be appreciated. WDYT? Regards. [1] https://lists.apache.org/thread.html/c03a2390ddd45b801a25e9946a49276693652870f4f4fbe732d8@%3Cdev.cocoon.apache.org%3E -- 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/
Re: [DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1
FYI, another applied patch that we should reject instead, because it requires 1.5: https://builds.apache.org/job/Cocoon%202.1.X/111/console On 08/10/2016 13:14, Francesco Chicchiriccò wrote: Wow, did not expect this... To be clear, are you proposing to move to 1.8 the binary AND source compatibility? Even wilder: how would you see moving the 2_1_X branch to GIT with github integration, thus allowing us accepting pull requests? We'll definitely need some help here... Regards. Il 8 ottobre 2016 06:43:06 CEST, David Crossley <cross...@apache.org> ha scritto: I agree. It should also enable better participation at both Cocoon and at Apache Forrest. There were also many supporting products that could then be updated. Lets go to 8. -David Insight 49 wrote: +1, and I strongly agree with Alfred. Cocoon 2.1 is a good stable platform, but doesn't encourage new participation, partly I suspect, because many people and businesses run Java 8 or 7 (as you know, you get all kinds of build errors when trying to build cocoon using those Java versions). If we can upgrade the code, classes and supporting jars, I'd recommend Java version 7 or 8. As an example, the very successful Apache Solr search uses Java 8! "You will need the Java Runtime Environment (JRE) version 1.8 or higher." https://cwiki.apache.org/confluence/display/solr/Installing+Solr Dan On 10/7/16, Nathaniel, Alfred <alfred.nathan...@six-group.com> wrote: +1 but I would go straight to 6, 7, or even 8. Past experience is that it is a real nuisance trying to support an ancient JDK no developer is actually using anymore. Cheers, Alfred. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 7. Oktober 2016 11:46 To: dev@cocoon.apache.org Subject: [DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1 Hi all, as recently noticed during the (unfortunately rejected) patch for COCOON-2354 [1], it might make sense to upgrade the current minimum JDK requirement for Cocoon 2.1 from 1.4 to 1.5, mainly to ease some upgrades and help Cocoon 2.1 living in the modern world. Besides 3rd part library updates, some work could be needed to upgrade our Java code, so help would be appreciated. -- 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/
Re: [DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1
Wow, did not expect this... To be clear, are you proposing to move to 1.8 the binary AND source compatibility? Even wilder: how would you see moving the 2_1_X branch to GIT with github integration, thus allowing us accepting pull requests? We'll definitely need some help here... Regards. Il 8 ottobre 2016 06:43:06 CEST, David Crossley <cross...@apache.org> ha scritto: >I agree. It should also enable better participation at both Cocoon >and at Apache Forrest. There were also many supporting products >that could then be updated. Lets go to 8. > >-David > >Insight 49 wrote: >> +1, and I strongly agree with Alfred. >> >> Cocoon 2.1 is a good stable platform, but doesn't encourage new >> participation, partly I suspect, because many people and businesses >> run Java 8 or 7 (as you know, you get all kinds of build errors when >> trying to build cocoon using those Java versions). >> >> If we can upgrade the code, classes and supporting jars, I'd >recommend >> Java version 7 or 8. >> >> As an example, the very successful Apache Solr search uses Java 8! >> >> "You will need the Java Runtime Environment (JRE) version 1.8 or >higher." >> https://cwiki.apache.org/confluence/display/solr/Installing+Solr >> >> Dan >> >> >> On 10/7/16, Nathaniel, Alfred <alfred.nathan...@six-group.com> wrote: >> > +1 but I would go straight to 6, 7, or even 8. >> > Past experience is that it is a real nuisance trying to support an >ancient >> > JDK no developer is actually using anymore. >> > >> > Cheers, Alfred. >> > >> > -Original Message- >> > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] >> > Sent: Freitag, 7. Oktober 2016 11:46 >> > To: dev@cocoon.apache.org >> > Subject: [DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1 >> > >> > Hi all, >> > as recently noticed during the (unfortunately rejected) patch for >> > COCOON-2354 [1], it might make sense to upgrade the current minimum >JDK >> > requirement for Cocoon 2.1 from 1.4 to 1.5, mainly to ease some >upgrades >> > and help Cocoon 2.1 living in the modern world. >> > >> > Besides 3rd part library updates, some work could be needed to >upgrade >> > our Java code, so help would be appreciated. >> -- 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/
[DISCUSS] Set minimum JDK version to 1.5 for Cocoon 2.1
Hi all, as recently noticed during the (unfortunately rejected) patch for COCOON-2354 [1], it might make sense to upgrade the current minimum JDK requirement for Cocoon 2.1 from 1.4 to 1.5, mainly to ease some upgrades and help Cocoon 2.1 living in the modern world. Besides 3rd part library updates, some work could be needed to upgrade our Java code, so help would be appreciated. WDYT? Regards. [1] https://lists.apache.org/thread.html/c03a2390ddd45b801a25e9946a49276693652870f4f4fbe732d8@%3Cdev.cocoon.apache.org%3E -- 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/
Re: [jira] [Commented] (COCOON-2354) Update POI 3.0.2 to 3.10-FINAL and fix support Merge tag support.
On 03/10/2016 23:40, Jörg Heinicke wrote: Hi Francesco, Maybe we should no longer stick to this requirement. It's outdated since many years. And it might prevent even the little community support Cocoon (2.1) still has. Hi Jörg, it might make sense. Please consider that setting the minimum requirement to JDK 1.5 will also require some help for upgrading the Java classes (say, at least for Generics) throughout the whole codebase: would you be available for landing a hand? Why don't you start a separate [DISCUSS] thread about this here on dev@? Regards. On 30/09/16 10:26, Francesco Chicchiriccò (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15535403#comment-15535403 ] Francesco Chicchiriccò commented on COCOON-2354: Sorry, I had to revert my commit with your patch as I have finally found that POI > 3.2 requires JDK 1.5 and thus is not acceptable for Cocoon 2.1. http://svn.apache.org/viewvc?rev=1762866=rev Update POI 3.0.2 to 3.10-FINAL and fix support Merge tag support. - Key: COCOON-2354 URL: https://issues.apache.org/jira/browse/COCOON-2354 Project: Cocoon Issue Type: Bug Components: Blocks: POI Affects Versions: 2.1.12 Reporter: Carlos Navarro Assignee: Francesco Chicchiriccò Fix For: 2.1.13 Attachments: poi_update.patch Update POI 3.0.2 to 3.10-FINAL and fix support Merge tag support. We need update the POI version lib to implement support to xwpf. * Change the jar lib lib/optional/poi-3.0.2-FINAL-20080204.jar for a newer version lib/optional/poi-3.10-FINAL.jar . source: https://mvnrepository.com/artifact/org.apache.poi/poi/3.10-FINAL * Change for the EPMerge class: - Replace Range class(deprecated) with CellRangeAddress. - Add Overcharge method addMergedRegion to the Sheet class. - Remove Cell Encoding UTF_16 in class Sheet, Cell and Workbook constructor. - Adding tets merge cell range in src/blocks/poi/samples/content/simple-date-test.xml -- This message was sent by Atlassian JIRA (v6.3.4#6332) -- 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/
Re: error in jetty with 3.0.0-beta-1-SNAPSHOT
On 2016-02-13 11:54 Hans-Heinrich Braun wrote:
> when i do what you told i get by jetty:run the following error:
>
> [ERROR] [ERROR] Some problems were encountered while processing the POMs:
> [ERROR] 'dependencies.dependency.version' for org.aspectj:aspectjrt:jar is
> missing. @ line 93, column 20
This is exactly what I've fixed yesterday: I also re-published all
SNAPSHOT artifacts, but for some reason you're still getting the old
ones.
Either ensure to re-generate your project from fresh SNAPSHOT artifacts
or simply remove
org.aspectj
aspectjrt
from your pom.xml
HTH
Regards.
> -----
> VON: Francesco Chicchiriccò <ilgro...@apache.org>
> AN: dev@cocoon.apache.org
> GESENDET: 16:39 Freitag, 12.Februar 2016
> BETREFF: Re: error in jetty with 3.0.0-beta-1-SNAPSHOT
>
> On 12/02/2016 16:02, Hans-Heinrich Braun wrote:
>
>> i have a cocoon application which i used already some time.
>> When i tried to reinstall it and tried to start it with jetty:run i get the
>> following error.:
>
> Hi,
> I have just fixed some problems with published SNAPSHOT artifacts.
>
> I have just re-generated an empty Cocoon 3 block with
>
> mvn archetype:generate \
> -DarchetypeGroupId=org.apache.cocoon.archetype-block \
> -DarchetypeArtifactId=cocoon-archetype-block \
> -DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
> -DgroupId=com.mycompany \
> -DartifactId=mysite \
> -DarchetypeRepository=https://repository.apache.org/content/repositories/snapshots/
>
> then
>
> cd mysite
> mvn jetty:run
>
> and it worked flawlessly.
>
> I have noticed troubles in building Cocoon 3 source with JDK 8, so I had to
> switch to JDK 7.
>
> HTH
> Regards.
>
>> [ERROR] Failed startup of context
>> org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@3c3562c0{/,/home/braun/appfuse/braunimmobilien/cocoon/target/rcl/webapp}
>>
>> java.lang.RuntimeException: Cannot invoke listener
>> org.springframework.web.context.ContextLoaderListener@6468904c
>>
>> and later
>>
>> Caused by: org.springframework.beans.factory.BeanDefinitionStoreException:
>> Unable to read spring configurations from classpath*:META-INF/cocoon/spring;
>> nested exception is
>> org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
>> Configuration problem: Unexpected failure during bean definition parsing
>> Offending resource: URL
>> [jar:file:/home/braun/.m2/repository/org/apache/cocoon/cocoon-jnet/1.2.2/cocoon-jnet-1.2.2.jar!/META-INF/cocoon/spring/cocoon-jnet-collector.xml]
>>
>> Bean 'org.apache.cocoon.jnet.URLHandlerFactoryCollector'; nested exception
>> is java.lang.NoSuchMethodError:
>> org.springframework.util.ClassUtils.forName(Ljava/lang/String;)Ljava/lang/Class;
>>
>>
>> I could not find out what i made wrong
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF Committer
http://home.apache.org/~ilgrosso/
Re: error in jetty with 3.0.0-beta-1-SNAPSHOT
On 12/02/2016 16:02, Hans-Heinrich Braun wrote:
i have a cocoon application which i used already some time.
When i tried to reinstall it and tried to start it with jetty:run i
get the following error.:
Hi,
I have just fixed some problems with published SNAPSHOT artifacts.
I have just re-generated an empty Cocoon 3 block with
mvn archetype:generate \
-DarchetypeGroupId=org.apache.cocoon.archetype-block \
-DarchetypeArtifactId=cocoon-archetype-block \
-DarchetypeVersion=3.0.0-beta-1-SNAPSHOT \
-DgroupId=com.mycompany \
-DartifactId=mysite \
-DarchetypeRepository=https://repository.apache.org/content/repositories/snapshots/
then
cd mysite
mvn jetty:run
and it worked flawlessly.
I have noticed troubles in building Cocoon 3 source with JDK 8, so I had
to switch to JDK 7.
HTH
Regards.
[ERROR] Failed startup of context
org.mortbay.jetty.plugin.Jetty6PluginWebAppContext@3c3562c0{/,/home/braun/appfuse/braunimmobilien/cocoon/target/rcl/webapp}
java.lang.RuntimeException: Cannot invoke listener
org.springframework.web.context.ContextLoaderListener@6468904c
and later
Caused by:
org.springframework.beans.factory.BeanDefinitionStoreException: Unable
to read spring configurations from classpath*:META-INF/cocoon/spring;
nested exception is
org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
Configuration problem: Unexpected failure during bean definition parsing
Offending resource: URL
[jar:file:/home/braun/.m2/repository/org/apache/cocoon/cocoon-jnet/1.2.2/cocoon-jnet-1.2.2.jar!/META-INF/cocoon/spring/cocoon-jnet-collector.xml]
Bean 'org.apache.cocoon.jnet.URLHandlerFactoryCollector'; nested
exception is java.lang.NoSuchMethodError:
org.springframework.util.ClassUtils.forName(Ljava/lang/String;)Ljava/lang/Class;
I could not find out what i made wrong.
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
http://home.apache.org/~ilgrosso/
Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
Hi all,
I have applied almost all provided patches to
* https://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_2_COCOON-2347
*
https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/branches/COCOON-2347
*
https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/branches/COCOON-2347
With respect to the patches attached to COCOON-2347, I had no need to
mess with MultiMap and MultiValueMap
FYI I am building with latest JDK 1.6 from Oracle (as said, we will
handle the Java 8 compatibility later).
As you can see by yourself, when building from BRANCH_2_2_COCOON-2347,
we have the following failures - as expected:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test)
on project cocoon-core: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/ilgrosso/work/cocoon/2_2_COCOON-2347/core/cocoon-core/target/surefire-reports
for the individual test results.
[ERROR] -> [Help 1]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.19:test (default-test)
on project cocoon-servlet-service-components: There are test failures.
[ERROR]
[ERROR] Please refer to
/home/ilgrosso/work/cocoon/2_2_COCOON-2347/core/cocoon-servlet-service/cocoon-servlet-service-components/target/surefire-reports
for the individual test results.
[ERROR] -> [Help 1]
[ERROR] Failed to execute goal
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M3:rcl (default) on project
cocoon-it: Execution default of goal
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M3:rcl failed: Can't deploy
'/home/ilgrosso/work/cocoon/2_2_COCOON-2347/core/cocoon-core/target/classes'.
/home/ilgrosso/work/cocoon/2_2_COCOON-2347/core/cocoon-core/target/classes
(Is a directory) -> [Help 2]
[ERROR] Failed to execute goal
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M3:rcl (rcl) on project
cocoon-welcome: Execution rcl of goal
org.apache.cocoon:cocoon-maven-plugin:1.0.0-M3:rcl failed: Can't deploy
'/home/ilgrosso/work/cocoon/2_2_COCOON-2347/core/cocoon-core/target/classes'.
/home/ilgrosso/work/cocoon/2_2_COCOON-2347/core/cocoon-core/target/classes
(Is a directory) -> [Help 2]
This is where I am looking forward for Javier's intervention :-)
Regards.
On 28/10/2015 09:39, Francesco Chicchiriccò wrote:
Hi Gabriel,
thanks again for your patches: see
https://issues.apache.org/jira/browse/COCOON-2347?focusedCommentId=14977966=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14977966
for an update.
May I ask you if you have already sent an ICLA to cover your contribution?
http://www.apache.org/licenses/#clas
Thanks.
Regards.
On 27/10/2015 17:59, Gabriel Gruber wrote:
One thing I forgot: it would be really nice to centralize the spring
version in a property within in the parent pom like this:
...
org.springframework
spring-_aop_
${spring-version}
_avalon_-framework
_avalon_-framework
_logkit_
_logkit_
...
4.2.2.RELEASE
...
Then being able to easily switch between versions.
Mit freundlichen Grüssen / Best regards,
Mag. Gabriel Gruber
Geschäftsführung
*/Workflow EDV Gesm.b.H./*
A-1030 Wien, Dannebergplatz 6/23
phone: +43 - 1 - 7188842 22
fax: +43 - 1 - 7188842 30
mobile: +43 - 676 - 3939435
mailto:gabriel.gru...@workflow.at
https://personalwolke.at <https://personalwolke.at/>
http://www.workflow.at <http://www.workflow.at/>
https://www.facebook.com/workflow.edv
From: Gabriel Gruber <gabriel.gru...@workflow.at>
To: dev@cocoon.apache.org
Date: 27.10.2015 17:53
Subject: Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
yes, I just use this:
mvn clean install -fn
Using following infrastructure on windows:
- maven 3.3.3
- JDK 1.8.0_51
The -fn (fail never) switch gives me a nice summary at the end, which
projects were successful and where there have been failures.
greets,
Gabriel
From: Francesco Chicchiriccò <ilgro...@apache.org>
To: dev@cocoon.apache.org
Date: 27.10.2015 17:42
Subject: Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
On 27/10/2015 16:30, Gabriel Gruber wrote:
Hi Folks,
I was able to compile cocoon 2.2 with spring framework 4.2 and fix
all the obvious problems like
- Using RootBeanDefinition.setScope() instead of
RootBeanDefinition.setSingleton()
- finding the correct method calls after deprecated methods or
constants have been removed.
- forking the commons-collections MultiMap and MultiValueMap classes
into a util package of cooon-expression-language-api in order to make
the interface compatible with Java 8 maps (conflict in remove() method!)
- implement missing methods in PipelineComponentScope,
PipelineComponentInfoInitializerDecorator, CallScope, ServletScope,
MockRequestAttributes due to changes of Spring Superclasses
- implement missing
Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
On 27/10/2015 17:52, Javier Puerto wrote:
2015-10-27 13:59 GMT+01:00 Francesco Chicchiriccò <ilgro...@apache.org
<mailto:ilgro...@apache.org>>:
On 27/10/2015 13:37, Javier Puerto wrote:
Hi all,
@Gabriel, sounds very interesting and the update can bring some
new energy to the project. :)
> Hum, is there anyone around with enough know-how about 2.2.?
Sorry Francesco, I was quite busy last three months but I will
have some spare time in December so I could take a look into the
changes.
Thanks Javier!
I have already set my very first question for you - see my comment
in COCOON-2347.
No problem. To reply the question I will need to check it with the
code as I don't remember ATM. I could take a look into the issue at
Friday afternoon or weekend.
Great: see my last comment
https://issues.apache.org/jira/browse/COCOON-2347?focusedCommentId=14977966=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14977966
for an update on this.
Regards.
2015-10-27 13:25 GMT+01:00 Gabriel Gruber <gabriel.gru...@workflow.at
<mailto:gabriel.gru...@workflow.at>>:
Hello Folks,
nice to see the project still being alive :-) I decided to make
a jira issue about our attempt to make cocoon 2.2 work with
spring framework 4.2.x.
https://issues.apache.org/jira/browse/COCOON-2347
I will append comments about progress etc. there and give you an
update on the mailing list as soon as something substantial could
be found out.
greets,
gabriel
> Francesco Chicchiriccò <ilgro...@apache.org
<mailto:ilgro...@apache.org>> wrote on 26.10.2015 15:37:00:
>> Hi Gabriel,
>> I do run actually few Cocoon instances in production, but
that's 3.
>> 0.0(-beta-1-SNAPSHOT...). I used to run Cocoon 2.1.X as well.
>>
>> Unfortunately, I am not very confident with 2.2, but if you would
>> like to provide some patches against Spring Configurator [1]
or any
>> other component to bring them to latest Spring version, I
would be
>> happy to review and handle your contribution(s).
>>
>> Please be sure to review our contribution docs[2].
>
> I am successfully running spring 4.0.6 with cocoon 2.2 in
production.
>
> I had to patch:
> - cocoon-pipeline-impl
> - cocoon-servlet-service-impl
> - cocoon-sitemap-impl
>
> anything higher in spring version fails. I do not recall the
actual
> problems but they were deep in cocoon internals and I was
unable to
> debug it properly.
>
> I have not been commiting those to cocoon repo as I have too
little
> knowledge how these changes might affect cocoon overall. I could
> create a branch and commit my changes for someone more
experienced than me.
>
> WDYT?
>
> Hum, is there anyone around with enough know-how about 2.2.?
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
Hi Gabriel,
thanks again for your patches: see
https://issues.apache.org/jira/browse/COCOON-2347?focusedCommentId=14977966=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14977966
for an update.
May I ask you if you have already sent an ICLA to cover your contribution?
http://www.apache.org/licenses/#clas
Thanks.
Regards.
On 27/10/2015 17:59, Gabriel Gruber wrote:
One thing I forgot: it would be really nice to centralize the spring
version in a property within in the parent pom like this:
...
org.springframework
spring-_aop_
${spring-version}
_avalon_-framework
_avalon_-framework
_logkit_
_logkit_
...
4.2.2.RELEASE
...
Then being able to easily switch between versions.
Mit freundlichen Grüssen / Best regards,
Mag. Gabriel Gruber
Geschäftsführung
*/Workflow EDV Gesm.b.H./*
A-1030 Wien, Dannebergplatz 6/23
phone: +43 - 1 - 7188842 22
fax: +43 - 1 - 7188842 30
mobile: +43 - 676 - 3939435
mailto:gabriel.gru...@workflow.at
https://personalwolke.at <https://personalwolke.at/>
http://www.workflow.at <http://www.workflow.at/>
https://www.facebook.com/workflow.edv
From: Gabriel Gruber <gabriel.gru...@workflow.at>
To: dev@cocoon.apache.org
Date: 27.10.2015 17:53
Subject: Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
yes, I just use this:
mvn clean install -fn
Using following infrastructure on windows:
- maven 3.3.3
- JDK 1.8.0_51
The -fn (fail never) switch gives me a nice summary at the end, which
projects were successful and where there have been failures.
greets,
Gabriel
From: Francesco Chicchiriccò <ilgro...@apache.org>
To: dev@cocoon.apache.org
Date: 27.10.2015 17:42
Subject: Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
On 27/10/2015 16:30, Gabriel Gruber wrote:
Hi Folks,
I was able to compile cocoon 2.2 with spring framework 4.2 and fix all
the obvious problems like
- Using RootBeanDefinition.setScope() instead of
RootBeanDefinition.setSingleton()
- finding the correct method calls after deprecated methods or
constants have been removed.
- forking the commons-collections MultiMap and MultiValueMap classes
into a util package of cooon-expression-language-api in order to make
the interface compatible with Java 8 maps (conflict in remove() method!)
- implement missing methods in PipelineComponentScope,
PipelineComponentInfoInitializerDecorator, CallScope, ServletScope,
MockRequestAttributes due to changes of Spring Superclasses
- implement missing method SourceResource.contentLength() due to
change of Spring Superclass
Cool.
Which commandline are you using for building Cocoon 2.2? Bare "mvn
clean install"?
However still a number of tests are failing like:
org.apache.cocoon.transformation.CIncludeTransformerTestCase.testCInclude1()
org.apache.cocoon.transformation.CIncludeTransformerTestCase.testCInclude2()
org.apache.cocoon.transformation.I18NTransformerTestCase.testI18n1()
org.apache.cocoon.transformation.I18NTransformerTestCase.testI18n2()
org.apache.cocoon.servletservice.AbsoluteServletConnectionTestCase.testURI()
org.apache.cocoon.template.jxtg.JXTemplateGeneratorTestCase.testFormatDate()
org.apache.cocoon.template.jxtg.JXTemplateGeneratorTestCase.testAttribute()
org.apache.cocoon.template.jxtg.JXTemplateGeneratorTestCase.testElementSuccess()
Ok, these needs of course to be reviewed and possibly adjusted.
Now I am able to start jetty with cocoon.
Even cooler.
When starting with Java 8 I get this error while accessing the start
page (while the page is rendered correctly)_
org.apache.cocoon.ProcessingException_: Reader already set. Cannot set
reader 'resource'|?at -
_file:///C:/j2ee/open-sources/cocoon/cocoon-2.2-trunk-2015/blocks/cocoon-samples-style/cocoon-samples-style-default/target/classes/COB-INF/sitemap.xmap:63:44|?at_
-
_file:///C:/j2ee/open-sources/cocoon/cocoon-2.2-trunk-2015/blocks/cocoon-samples-style/cocoon-samples-style-default/target/classes/COB-INF/sitemap.xmap:62:35_
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setReader(_AbstractProcessingPipeline.java:298_)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setReader(_AbstractCachingProcessingPipeline.java:180_)
at sun.reflect.NativeMethodAccessorImpl.invoke0(_Native Method_)
at
sun.reflect.NativeMethodAccessorImpl.invoke(_NativeMethodAccessorImpl.java:62_)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(_DelegatingMethodAccessorImpl.java:43_)
at java.lang.reflect.Method.invoke(_Method.java:497_)
at
org.apache.cocoon.core.container.spring.avalon.PoolableProxyHandler.invoke(_PoolableProxyHandler.java:79_)
The above exception only appears, if starting jetty with Java 8. When
using a JRE7 it will not appear.
Ok, I would say to separa
Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
On 27/10/2015 13:37, Javier Puerto wrote:
Hi all,
@Gabriel, sounds very interesting and the update can bring some new
energy to the project. :)
> Hum, is there anyone around with enough know-how about 2.2.?
Sorry Francesco, I was quite busy last three months but I will have
some spare time in December so I could take a look into the changes.
Thanks Javier!
I have already set my very first question for you - see my comment in
COCOON-2347.
Regards.
2015-10-27 13:25 GMT+01:00 Gabriel Gruber <gabriel.gru...@workflow.at
<mailto:gabriel.gru...@workflow.at>>:
Hello Folks,
nice to see the project still being alive :-) I decided to make a
jira issue about our attempt to make cocoon 2.2 work with spring
framework 4.2.x.
https://issues.apache.org/jira/browse/COCOON-2347
I will append comments about progress etc. there and give you an
update on the mailing list as soon as something substantial could
be found out.
greets,
gabriel
> Francesco Chicchiriccò <ilgro...@apache.org
<mailto:ilgro...@apache.org>> wrote on 26.10.2015 15:37:00:
>> Hi Gabriel,
>> I do run actually few Cocoon instances in production, but that's 3.
>> 0.0(-beta-1-SNAPSHOT...). I used to run Cocoon 2.1.X as well.
>>
>> Unfortunately, I am not very confident with 2.2, but if you would
>> like to provide some patches against Spring Configurator [1] or
any
>> other component to bring them to latest Spring version, I would be
>> happy to review and handle your contribution(s).
>>
>> Please be sure to review our contribution docs[2].
>
> I am successfully running spring 4.0.6 with cocoon 2.2 in
production.
>
> I had to patch:
> - cocoon-pipeline-impl
> - cocoon-servlet-service-impl
> - cocoon-sitemap-impl
>
> anything higher in spring version fails. I do not recall the actual
> problems but they were deep in cocoon internals and I was unable to
> debug it properly.
>
> I have not been commiting those to cocoon repo as I have too little
> knowledge how these changes might affect cocoon overall. I could
> create a branch and commit my changes for someone more
experienced than me.
>
> WDYT?
>
> Hum, is there anyone around with enough know-how about 2.2.?
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/
Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
.java:302_) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(_ReflectiveMethodInvocation.java:190_) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(_ReflectiveMethodInvocation.java:157_) at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(_MethodInvocationProceedingJoinPoint.java:85_) at org.apache.cocoon.jnet.URLHandlerFactoryCollector.installURLHandlers(_URLHandlerFactoryCollector.java:37_) at sun.reflect.NativeMethodAccessorImpl.invoke0(_Native Method_) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(_AbstractAspectJAdvice.java:621_) at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(_AbstractAspectJAdvice.java:610_) at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(_AspectJAroundAdvice.java:68_) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(_ReflectiveMethodInvocation.java:179_) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(_ExposeInvocationInterceptor.java:92_) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(_ReflectiveMethodInvocation.java:179_) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(_JdkDynamicAopProxy.java:207_) at com.sun.proxy.$Proxy8.service(Unknown Source) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(_ServletServiceContext.java:485_) at org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(_ServletServiceContext.java:459_) at org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(_ServletFactoryBean.java:245_) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(_ReflectiveMethodInvocation.java:179_) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(_JdkDynamicAopProxy.java:207_) at com.sun.proxy.$Proxy11.service(Unknown Source) at org.apache.cocoon.servletservice.DispatcherServlet.service(_DispatcherServlet.java:106_) at javax.servlet.http.HttpServlet.service(_HttpServlet.java:848_) at org.eclipse.jetty.servlet.ServletHolder.handle(_ServletHolder.java:684_) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(_ServletHandler.java:1496_) at org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(_MultipartFilter.java:131_) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(_ServletHandler.java:1476_) at org.eclipse.jetty.servlet.ServletHandler.doHandle(_ServletHandler.java:499_) at org.eclipse.jetty.server.handler.ScopedHandler.handle(_ScopedHandler.java:137_) at org.eclipse.jetty.security.SecurityHandler.handle(_SecurityHandler.java:557_) at org.eclipse.jetty.server.session.SessionHandler.doHandle(_SessionHandler.java:231_) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(_ContextHandler.java:1086_) at org.eclipse.jetty.servlet.ServletHandler.doScope(_ServletHandler.java:428_) at org.eclipse.jetty.server.session.SessionHandler.doScope(_SessionHandler.java:193_) at org.eclipse.jetty.server.handler.ContextHandler.doScope(_ContextHandler.java:1020_) at org.eclipse.jetty.server.handler.ScopedHandler.handle(_ScopedHandler.java:135_) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(_HandlerWrapper.java:116_) at org.eclipse.jetty.server.Server.handle(_Server.java:370_) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(_AbstractHttpConnection.java:494_) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(_AbstractHttpConnection.java:971_) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(_AbstractHttpConnection.java:1033_) at org.eclipse.jetty.http.HttpParser.parseNext(_HttpParser.java:644_) at org.eclipse.jetty.http.HttpParser.parseAvailable(_HttpParser.java:235_) at org.eclipse.jetty.server.AsyncHttpConnection.handle(_AsyncHttpConnection.java:82_) at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(_SelectChannelEndPoint.java:667_) at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(_SelectChannelEndPoint.java:52_) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(_QueuedThreadPool.java:608_) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(_QueuedThreadPool.java:543_) at java.lang.Thread.run(Unknown Source) Where to go from here now? Should I commit to some branch? Or should I comment every needed patch for every class in the ticket? (will be up to 20 patches in summary I guess) Please attach a single patch by running svn diff from file:///C:/j2ee/open-sources/cocoon/cocoon-2.2-trunk-2015/ Let's try to first make this working, thanks. Regards. From: Francesco Chicchiriccò <ilgro...@apache.org> To: dev@cocoon.apache.org
Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
On 23/10/2015 18:05, Gabriel Gruber wrote: Hello Cocooners! Are there still some people using cocoon in a production application? We still use it in our standard product and now have the challenge to migrate to java 1.8 and spring framework 4.2. While this gives us a few issues to solve in terms of migrating code relying on spring 3, we now face the challenge that we have to touch cocoon again. As cocoon 2.2 heavily relies on spring, I wondered if anyone of you guys has also ready tried to upgrade cocoon 2.2 to spring 4.2 (and implicitly also to java 1.8 - also with JDK 1.8 bytecode compatibility turned on). While the trunk of cocoon (2.2) still uses officially spring 2.5.5 it actually runs without problems also with latest 3.2.x of spring. But never tried with spring 4.x so far and according to our first tries with our product I assume there could be some more (heavy) issues, because minimum requirements to list of supported libraries has changed quite a bit. https://github.com/spring-projects/spring-framework/wiki/Migrating-from-earlier-versions-of-the-spring-framework As an example the Cocoon Spring Configurator needed some small changes, as it was not compiling against Spring 4.2. Other projects I have not tried so far. Is there an interest in the community to make this changes in the trunk? Hi Gabriel, I do run actually few Cocoon instances in production, but that's 3.0.0(-beta-1-SNAPSHOT...). I used to run Cocoon 2.1.X as well. Unfortunately, I am not very confident with 2.2, but if you would like to provide some patches against Spring Configurator [1] or any other component to bring them to latest Spring version, I would be happy to review and handle your contribution(s). Please be sure to review our contribution docs[2]. Regards. [1] https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-spring-configurator/trunk/ [2] http://cocoon.apache.org/1273_1_1.html -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: Cocoon 2.2 with Java 8 and Spring Framework 4.2?
On 26/10/2015 15:29, Leszek Gawron wrote: Hi Gabriel, I do run actually few Cocoon instances in production, but that's 3.0.0(-beta-1-SNAPSHOT...). I used to run Cocoon 2.1.X as well. Unfortunately, I am not very confident with 2.2, but if you would like to provide some patches against Spring Configurator [1] or any other component to bring them to latest Spring version, I would be happy to review and handle your contribution(s). Please be sure to review our contribution docs[2]. I am successfully running spring 4.0.6 with cocoon 2.2 in production. I had to patch: - cocoon-pipeline-impl - cocoon-servlet-service-impl - cocoon-sitemap-impl anything higher in spring version fails. I do not recall the actual problems but they were deep in cocoon internals and I was unable to debug it properly. I have not been commiting those to cocoon repo as I have too little knowledge how these changes might affect cocoon overall. I could create a branch and commit my changes for someone more experienced than me. WDYT? Hum, is there anyone around with enough know-how about 2.2.? -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: [jira] Updated: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
On 22/10/2015 17:42, josepascual wrote: Hello, we are trying to deploy a cocoon web application in a Sun One 6.1 Server. We have some problems, one of them is that when the application is starting to run, fail with this error: ERROR [main] (DiskStore.java:668) - cocoon-ehcache-1Cache: Failed to write element to disk 'EVENTREGWRAPPER'. Initial cause was org.apache.commons.collections.map.MultiValueMap java.io.NotSerializableException: org.apache.commons.collections.map.MultiValueMap Following these post, I have seen that the solution is upgrade to 2.1.11 version of cocoon, we had 2.1.10 version, but the problems are still happening. We have copied in our war deploying file and install the war in our Sun One. Do you have any idea what is happening? Hi, this mail subject refers to [1] which was fixed in 2007 (!), with partial split to [2] which is still unresolved. I guess there are no many people around that can help you, neither do I, unfortunately. Having been working with such technology for a long while, I need to ask: really there is some SunOne WebServer 6.1 still around?!? Regards. [1] https://issues.apache.org/jira/browse/COCOON-2146 [2] https://issues.apache.org/jira/browse/COCOON-2152 -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: [jira] Updated: (COCOON-2146) Using EventAware cache implementation breaks persistent cache restore on restart
On 23/10/2015 09:07, josepascual wrote: Hi francesco, thanks for your answer ... in our case, the problem is that we try to deploy the web application in our local environment under our pc windows 7 system. We can deploy the app under client environment without any problem, the customer can use it correctly. We received the maintenance of this application several years ago, and when we have to modify something we work in our computers and prove over client systems, in Integration environment. As you will guess this is very difficult manner to work, because all developers share the same environment to prove. So we decided to try install in our local environment the Sun One over our windows and install the app to work. I'm trying to do this for two weeks and unfortunately it doesn't work. Why not trying a VM with Linux or (Open)Solaris, then? -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: cocoon 2.1.x and java 8
Hi,
I've just committed an updated fix which relies on
org.eclipse.jdt.core-3.9.1.v20130905-0837 which seems to be the latest
version retaining compatibility with Java 1.4.
I had to change the patch a bit, but the result is succeeding with both
the URLs below and Java 8.
Regards.
On 02/02/2015 04:27, Carlos Chávez wrote:
Let me see what can I do.
Francesco Chicchiriccò Escribio :-)
On 31/01/2015 06:24, Francesco Chicchiriccò wrote:
On 30/01/2015 15:09, Carlos Chávez wrote:
Hi Francesco.
I uploaded the patch.
Hi Carlos,
patch applied (and issue closed), thanks.
It seems there is a problem; see
https://builds.apache.org/job/Cocoon%202.1.X/98/console
bad class file: /home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/lib/core/org.eclipse.jdt.core_3.10.0.v20140902-0626.jar(org/eclipse/jdt/core/compiler/IProblem.class)
class file has wrong version 50.0, should be 48.0
This means that the JAR above does not work with JDK 1.4, which is
currently a pre-requisite for Cocoon 2.1.X - can you find a compatible
version of that JAR?
Alternatively I will need to revert the patch...
Regards.
On 16/01/15 01:24, Francesco Chicchiriccò wrote:
On 15/01/2015 18:59, Carlos Chávez wrote:
Hi Francesco.
I downloaded that file and it works with java 8.
I found another test that is failing,
http://localhost:/samples/blocks/xsp/java/java5, this seems to be
related to :
// Set the sourceCodeVersion
// Set the target platform
Check the patch:
Hi,
thanks for reporting: could you please unify my patch with your
changes
and attach the resulting patch to
https://issues.apache.org/jira/browse/COCOON-2344
? Thanks.
Regards.
Index:
src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
===
---
workspace/cocoon-BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
(revision 1652165)
+++
workspace/cocoon-BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
(working copy)
@@ -215,8 +215,11 @@
}
return result;
}
-}
+public boolean ignoreOptionalProblems() {
+return false;
+}
+}
final INameEnvironment env = new INameEnvironment() {
@@ -336,6 +339,18 @@
}
// Set the sourceCodeVersion
switch (this.compilerComplianceLevel) {
+case 180:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_8);
+ settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_8);
+break;
+case 170:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_7);
+ settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_7);
+break;
+case 160:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_6);
+ settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_6);
+break;
case 150:
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_5);
settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_5);
@@ -348,6 +363,15 @@
}
// Set the target platform
switch (SystemUtils.JAVA_VERSION_INT) {
+case 180:
+ settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_8);
+break;
+case 170:
+ settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_7);
+break;
+case 160:
+ settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_6);
+break;
case 150:
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_5);
break;
On 15/01/15 02:19, Francesco Chicchiriccò wrote:
On 08/01/2015 00:12, Carlos Chávez wrote:
Hi all.
I'm trying to run cocoon in java 8, I found an issue with the JDT
core
that did not recognize java 8, the version in cocoon is
lib/core/jdtcore-3.1.0.jar
I did tried updating that version, what I did was copy the file
org.eclipse.jdt.core_3.10.0.v20140902-0626.jar from my Eclipse Luna
Installation and it works.
I did not find a public repository to download the jtdcore jar, I
searched in maven repos and did not find any updated jar.
When I compile and run cocoon with java 8, i found the issue
testing
the
sample http://localhost:/samples/blocks/xsp/java/cacheable
which it
throw a NullPointerException when it tried to compile the XPS.
With that version the exception is gone and the page is generated.
thoughts, please ?
Hi Carlos,
I tried as you explain above and got exactly the same results: only
found this updated JAR
Re: cocoon 2.1.x and java 8
On 31/01/2015 06:24, Francesco Chicchiriccò wrote:
On 30/01/2015 15:09, Carlos Chávez wrote:
Hi Francesco.
I uploaded the patch.
Hi Carlos,
patch applied (and issue closed), thanks.
It seems there is a problem; see
https://builds.apache.org/job/Cocoon%202.1.X/98/console
bad class file: /home/jenkins/jenkins-slave/workspace/Cocoon
2.1.X/BRANCH_2_1_X/lib/core/org.eclipse.jdt.core_3.10.0.v20140902-0626.jar(org/eclipse/jdt/core/compiler/IProblem.class)
class file has wrong version 50.0, should be 48.0
This means that the JAR above does not work with JDK 1.4, which is
currently a pre-requisite for Cocoon 2.1.X - can you find a compatible
version of that JAR?
Alternatively I will need to revert the patch...
Regards.
On 16/01/15 01:24, Francesco Chicchiriccò wrote:
On 15/01/2015 18:59, Carlos Chávez wrote:
Hi Francesco.
I downloaded that file and it works with java 8.
I found another test that is failing,
http://localhost:/samples/blocks/xsp/java/java5, this seems to be
related to :
// Set the sourceCodeVersion
// Set the target platform
Check the patch:
Hi,
thanks for reporting: could you please unify my patch with your changes
and attach the resulting patch to
https://issues.apache.org/jira/browse/COCOON-2344
? Thanks.
Regards.
Index:
src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
===
---
workspace/cocoon-BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
(revision 1652165)
+++
workspace/cocoon-BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
(working copy)
@@ -215,8 +215,11 @@
}
return result;
}
-}
+public boolean ignoreOptionalProblems() {
+return false;
+}
+}
final INameEnvironment env = new INameEnvironment() {
@@ -336,6 +339,18 @@
}
// Set the sourceCodeVersion
switch (this.compilerComplianceLevel) {
+case 180:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_8);
+ settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_8);
+break;
+case 170:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_7);
+ settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_7);
+break;
+case 160:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_6);
+ settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_6);
+break;
case 150:
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_5);
settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_5);
@@ -348,6 +363,15 @@
}
// Set the target platform
switch (SystemUtils.JAVA_VERSION_INT) {
+case 180:
+ settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_8);
+break;
+case 170:
+ settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_7);
+break;
+case 160:
+ settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_6);
+break;
case 150:
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_5);
break;
On 15/01/15 02:19, Francesco Chicchiriccò wrote:
On 08/01/2015 00:12, Carlos Chávez wrote:
Hi all.
I'm trying to run cocoon in java 8, I found an issue with the JDT
core
that did not recognize java 8, the version in cocoon is
lib/core/jdtcore-3.1.0.jar
I did tried updating that version, what I did was copy the file
org.eclipse.jdt.core_3.10.0.v20140902-0626.jar from my Eclipse Luna
Installation and it works.
I did not find a public repository to download the jtdcore jar, I
searched in maven repos and did not find any updated jar.
When I compile and run cocoon with java 8, i found the issue testing
the
sample http://localhost:/samples/blocks/xsp/java/cacheable
which it
throw a NullPointerException when it tried to compile the XPS.
With that version the exception is gone and the page is generated.
thoughts, please ?
Hi Carlos,
I tried as you explain above and got exactly the same results: only
found this updated JAR [1], but the error is the same.
However, I have found these places [2] [3] from which the version
reported above can be downloaded.
I have opened COCOON-2344 [4] and provided a patch with which the XSP
sample above is working (checked with OpenJDK 6 / 7 / 8).
I have not committed the fix because I have no mean to check if
everything is working with Java 4 / 5 and also if other XSP
Re: cocoon 2.1.x and java 8
On 08/01/2015 00:12, Carlos Chávez wrote: Hi all. I'm trying to run cocoon in java 8, I found an issue with the JDT core that did not recognize java 8, the version in cocoon is lib/core/jdtcore-3.1.0.jar I did tried updating that version, what I did was copy the file org.eclipse.jdt.core_3.10.0.v20140902-0626.jar from my Eclipse Luna Installation and it works. I did not find a public repository to download the jtdcore jar, I searched in maven repos and did not find any updated jar. When I compile and run cocoon with java 8, i found the issue testing the sample http://localhost:/samples/blocks/xsp/java/cacheable which it throw a NullPointerException when it tried to compile the XPS. With that version the exception is gone and the page is generated. thoughts, please ? Hi Carlos, I tried as you explain above and got exactly the same results: only found this updated JAR [1], but the error is the same. However, I have found these places [2] [3] from which the version reported above can be downloaded. I have opened COCOON-2344 [4] and provided a patch with which the XSP sample above is working (checked with OpenJDK 6 / 7 / 8). I have not committed the fix because I have no mean to check if everything is working with Java 4 / 5 and also if other XSP features are affected. Can anyone please double check and confirm if the proposed patch can be committed? Regards. [1] http://central.maven.org/maven2/eclipse/jdtcore/3.2.0.v_658/jdtcore-3.2.0.v_658.jar [2] http://repository.grepcode.com/java/eclipse.org/4.4.1/plugins/org.eclipse.jdt.core_3.10.0.v20140902-0626.jar [3] http://www.aadl.info/aadl/osate/testing/update-site/plugins/org.eclipse.jdt.core_3.10.0.v20140902-0626.jar [4] https://issues.apache.org/jira/browse/COCOON-2344 -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: cocoon 2.1.x and java 8
On 15/01/2015 18:59, Carlos Chávez wrote:
Hi Francesco.
I downloaded that file and it works with java 8.
I found another test that is failing,
http://localhost:/samples/blocks/xsp/java/java5, this seems to be
related to :
// Set the sourceCodeVersion
// Set the target platform
Check the patch:
Hi,
thanks for reporting: could you please unify my patch with your changes
and attach the resulting patch to
https://issues.apache.org/jira/browse/COCOON-2344
? Thanks.
Regards.
Index:
src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
===
---
workspace/cocoon-BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
(revision 1652165)
+++
workspace/cocoon-BRANCH_2_1_X/src/blocks/xsp/java/org/apache/cocoon/components/language/programming/java/EclipseJavaCompiler.java
(working copy)
@@ -215,8 +215,11 @@
}
return result;
}
-}
+public boolean ignoreOptionalProblems() {
+return false;
+}
+}
final INameEnvironment env = new INameEnvironment() {
@@ -336,6 +339,18 @@
}
// Set the sourceCodeVersion
switch (this.compilerComplianceLevel) {
+case 180:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_8);
+settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_8);
+break;
+case 170:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_7);
+settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_7);
+break;
+case 160:
+settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_6);
+settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_6);
+break;
case 150:
settings.put(CompilerOptions.OPTION_Source,
CompilerOptions.VERSION_1_5);
settings.put(CompilerOptions.OPTION_Compliance,
CompilerOptions.VERSION_1_5);
@@ -348,6 +363,15 @@
}
// Set the target platform
switch (SystemUtils.JAVA_VERSION_INT) {
+case 180:
+settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_8);
+break;
+case 170:
+settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_7);
+break;
+case 160:
+settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_6);
+break;
case 150:
settings.put(CompilerOptions.OPTION_TargetPlatform,
CompilerOptions.VERSION_1_5);
break;
On 15/01/15 02:19, Francesco Chicchiriccò wrote:
On 08/01/2015 00:12, Carlos Chávez wrote:
Hi all.
I'm trying to run cocoon in java 8, I found an issue with the JDT core
that did not recognize java 8, the version in cocoon is
lib/core/jdtcore-3.1.0.jar
I did tried updating that version, what I did was copy the file
org.eclipse.jdt.core_3.10.0.v20140902-0626.jar from my Eclipse Luna
Installation and it works.
I did not find a public repository to download the jtdcore jar, I
searched in maven repos and did not find any updated jar.
When I compile and run cocoon with java 8, i found the issue testing the
sample http://localhost:/samples/blocks/xsp/java/cacheable which it
throw a NullPointerException when it tried to compile the XPS.
With that version the exception is gone and the page is generated.
thoughts, please ?
Hi Carlos,
I tried as you explain above and got exactly the same results: only
found this updated JAR [1], but the error is the same.
However, I have found these places [2] [3] from which the version
reported above can be downloaded.
I have opened COCOON-2344 [4] and provided a patch with which the XSP
sample above is working (checked with OpenJDK 6 / 7 / 8).
I have not committed the fix because I have no mean to check if
everything is working with Java 4 / 5 and also if other XSP features are
affected.
Can anyone please double check and confirm if the proposed patch can be
committed?
Regards.
[1]
http://central.maven.org/maven2/eclipse/jdtcore/3.2.0.v_658/jdtcore-3.2.0.v_658.jar
[2]
http://repository.grepcode.com/java/eclipse.org/4.4.1/plugins/org.eclipse.jdt.core_3.10.0.v20140902-0626.jar
[3]
http://www.aadl.info/aadl/osate/testing/update-site/plugins/org.eclipse.jdt.core_3.10.0.v20140902-0626.jar
[4] https://issues.apache.org/jira/browse/COCOON-2344
--
Francesco Chicchiriccò
Tirasa - Open Source Excellence
http://www.tirasa.net/
Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http
Re: sitemap trouble when deploy cocoon-2.1 war in tomcat
On 02/09/2014 09:53, David Crossley wrote: I am having difficulty deploying a cocoon.war to a local Tomcat (using recent v7.0.55). To start with, see the Cocoon jail demo: http://cocoon.zones.apache.org/cocoon21/samples/ and notice how the trailing slash just works okay as it should according to the sitemap.xmap Now when i build Cocoon 2.1.13-dev (head of svn branch) locally, and then do: ]$ ./cocoon.sh http://localhost:/samples/ all is okay using the built-in Jetty. Now do: ]$ ./build.sh war then copy to the Tomcat webapps directory. http://localhost:8080/cocoon/samples/ and get error: org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: samples/index.html Looking at the docs for the cocoon.zones.apache.org at http://wiki.apache.org/cocoon/JailManagement https://svn.apache.org/repos/private/pmc/cocoon/cocoon.zones.apache.org/ i do not see any special configuration for Tomcat. So can anyone explain the difference. Also does anyone know how that redirect to index.html is happening. I do vaguely recall these problems in the past. Hi David, can [1] be of any help? [1] http://blog.tirasa.net/apache-fun-cocoon-2-1.html -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: sitemap trouble when deploy cocoon-2.1 war in tomcat
On 02/09/2014 10:02, David Crossley wrote: On Tue, Sep 02, 2014 at 09:56:07AM +0200, Francesco Chicchiriccò wrote: On 02/09/2014 09:53, David Crossley wrote: I am having difficulty deploying a cocoon.war to a local Tomcat (using recent v7.0.55). To start with, see the Cocoon jail demo: http://cocoon.zones.apache.org/cocoon21/samples/ and notice how the trailing slash just works okay as it should according to the sitemap.xmap Now when i build Cocoon 2.1.13-dev (head of svn branch) locally, and then do: ]$ ./cocoon.sh http://localhost:/samples/ all is okay using the built-in Jetty. Now do: ]$ ./build.sh war then copy to the Tomcat webapps directory. http://localhost:8080/cocoon/samples/ and get error: org.apache.cocoon.ResourceNotFoundException: No pipeline matched request: samples/index.html Looking at the docs for the cocoon.zones.apache.org at http://wiki.apache.org/cocoon/JailManagement https://svn.apache.org/repos/private/pmc/cocoon/cocoon.zones.apache.org/ i do not see any special configuration for Tomcat. So can anyone explain the difference. Also does anyone know how that redirect to index.html is happening. I do vaguely recall these problems in the past. Hi David, can [1] be of any help? [1] http://blog.tirasa.net/apache-fun-cocoon-2-1.html You are a champ. Yes it does. Remove the welcome-file-list from $CATALINA_HOME/conf/web.xml What a team. I have been struggling all afternoon, then an answer in minutes. Thanks. You're welcome :-) Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PMC http://people.apache.org/~ilgrosso/
Re: Update Cocoon 2.1.13-dev dojo up to 1.9.3
On 03/03/2014 15:40, Reynaldo Porras García wrote: Thanks Francesco for merging changes, I'll be performing the investigation for sure. Before the merge I found issue and I have the fix for it, it looks like it was unfinished work. I guess I should open an issue on Jira to upload the patches when I them ready, shouldn't I? It sounds nice: if you haven't before, please download, fill and submit an ICLA [5] (read also [6] for more information), so that your contributions are covered even from a legal point of view, thanks. Regards. Thanks for your suggestion David. I think Jeremy was the main developer in that branch I hope he still read the cocoon mailing list :). - - Reynaldo Porras On 03/01/2014 10:41 PM, David Crossley wrote: Francesco Chicchiriccò wrote: Reynaldo Porras García wrote: Dear cocooners, I am working on upgrading a app for a client. We have found issues with recent browsers and dojo 0.4.3 which comes in cocoon. I am working on updating dojo to it latest version 1.9.3 which the latest available. I know there was some work going to update cocoon 2.1 to use dojo 1.1.1 [1] long time ago. I am looking at the branch [2] and the work looks promising. I am planning to use that branch to move dojo up to 1.9.3. But I see the branch is behind current development branch[3]. Is it possible to add merge changes from current development branch to the dojo branch? Last change in branch [2] is dated 2008-11-05 16:06:50 +0100, e.g. 5 years and a half ago: I have just merged without particular problems [4] - everything seems to be working, but I am sure it worths more investigation that I assume you are going to perform, right? ;-) Regards. Any suggestions or ideas? Perhaps contact the people who were involved in that branch. Maybe they have some unfinished work or dump of ideas. Thanks to Reynaldo for attending to Cocoon-2.1 ... it has life yet. Thanks too to Francesco. -David [1] - http://markmail.org/message/iatwhjzsa53skbdz?q=apache+cocoon+%2B+dojo+1.1+%2B+jeremy [2] - http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1/ [3] - http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X [4] http://svn.apache.org/r1573205 [5] http://www.apache.org/licenses/#clas [6] http://cocoon.apache.org/1273_1_1.html -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
Re: Update Cocoon 2.1.13-dev dojo up to 1.9.3
On 01/03/2014 00:28, Reynaldo Porras García wrote: Dear cocooners, I am working on upgrading a app for a client. We have found issues with recent browsers and dojo 0.4.3 which comes in cocoon. I am working on updating dojo to it latest version 1.9.3 which the latest available. I know there was some work going to update cocoon 2.1 to use dojo 1.1.1 [1] long time ago. I am looking at the branch [2] and the work looks promising. I am planning to use that branch to move dojo up to 1.9.3. But I see the branch is behind current development branch[3]. Is it possible to add merge changes from current development branch to the dojo branch? Last change in branch [2] is dated 2008-11-05 16:06:50 +0100, e.g. 5 years and a half ago: I have just merged without particular problems [4] - everything seems to be working, but I am sure it worths more investigation that I assume you are going to perform, right? ;-) Regards. Any suggestions or ideas? Thanks, Best Regards, [1] - http://markmail.org/message/iatwhjzsa53skbdz?q=apache+cocoon+%2B+dojo+1.1+%2B+jeremy [2] - http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X-dojo1_1/ [3] - http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X [4] http://svn.apache.org/r1573205 -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ Involved at The Apache Software Foundation: member, Syncope PMC chair, Cocoon PMC, Olingo PPMC http://people.apache.org/~ilgrosso/
Re: Your Gump Build(s)
On 02/07/2013 09:34, David Crossley wrote: Reminder to the Cocoon project: We have a number of Gump builds: See http://svn.apache.org/repos/asf/gump/metadata/project/ for the cocoon entries. For example, the output from the vmgump machine is here: http://vmgump.apache.org/gump/public/cocoon3/ and http://vmgump.apache.org/gump/public/cocoon/ for c2.2 (IIRC then cocoon-2.1 is packaged rather than built.) The metadata for each Cocoon project probably needs some care and attention from us. Hi David, I am not familiar with Gump at all, but at least for Cocoon 3 [1] and Cocoon 2.1 [2] we have Jenkins jobs defined. I don't think we still need Gump, at least for C3 and C2.1 (and we might define a job on Jenkins for C2.2 as well), right? WDYT? Should we safely remove cocoon entries from Gump? How could this be done? Regards. [1] https://builds.apache.org/job/Cocoon%203.0/ [2] https://builds.apache.org/job/Cocoon%202.1.X/ Stefan Bodewig wrote: Dear Community Apache Gump builds some of your projects and it is quite possible you don't know or have by now forgotten about it. More than half a year ago a technical problem has forced us to turn off emails on build failures as we would have been sending out lots of false alarms. Before we re-enable emails we'd like to know whether you are still interested in the service Gump provides, so please tell us. :-) Metadata for many projects have been neglected for a long time and it is quite possible they'd need some love for results to be meaningful. All Apache committers have write access to Gump's metadata. In case you don't know what this Gump stuff is about: Apache Gump builds the full stack of the latest commits of software in order to ensure integrity over releases. Build failures surface API discontinuities between projects before they impact releases, and Gump's e-mail notifications hope to promote the conversations between teams to resolve those discontinuities. When responding to this mail please shorten the CC list as appropriate. Cheers Stefan on behalf of the Gump PMC -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Forced Xalan dependency using latest cocoon-maven-plugin
On 27/06/2013 13:34, Javier Puerto wrote: Hi all, We started a Cocoon 3 project with some blocks and we need to use Saxon for XSLT 2.0 features. The problem is with the RCL, we used latest cocoon-maven-plugin (1.0.2) but I've noticed that Xalan dependency is always used so my XSLT are not working. I've change the version to 1.0.0 then it's working OK. Why is using Xalan if I didn't declare the dependency? Is there a way to configure this behaviour? Hi Javier, I guess this bug was introduced by COCOON-2322, included in 1.0.2 [1]: it seems that the new dynamic injection is injecting too much. You can take a look at [2] (the getDependencies() method in particular IIRC) for debugging when Xalan is pulled in. PD: I've tested 1.0.3-SNAPSHOT and it's the same problem, not tested 1.0.1. The release history moves from 1.0.0.M3 to 1.0.2, so there is no 1.0.1 PD2: I've realized that it's not necessary to add the TransformerFactory services file because it's included in Saxon library. Interesting... Regards. [1] http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/changes-report.html#a1.0.2 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: Forced Xalan dependency using latest cocoon-maven-plugin
On 27/06/2013 14:27, Francesco Chicchiriccò wrote: On 27/06/2013 13:34, Javier Puerto wrote: Hi all, We started a Cocoon 3 project with some blocks and we need to use Saxon for XSLT 2.0 features. The problem is with the RCL, we used latest cocoon-maven-plugin (1.0.2) but I've noticed that Xalan dependency is always used so my XSLT are not working. I've change the version to 1.0.0 then it's working OK. Why is using Xalan if I didn't declare the dependency? Is there a way to configure this behaviour? Hi Javier, I guess this bug was introduced by COCOON-2322, included in 1.0.2 [1]: it seems that the new dynamic injection is injecting too much. You can take a look at [2] (the getDependencies() method in particular IIRC) for debugging when Xalan is pulled in. PD: I've tested 1.0.3-SNAPSHOT and it's the same problem, not tested 1.0.1. The release history moves from 1.0.0.M3 to 1.0.2, so there is no 1.0.1 PD2: I've realized that it's not necessary to add the TransformerFactory services file because it's included in Saxon library. Interesting... Regards. [1] http://cocoon.apache.org/2.2/maven-plugins/maven-plugin/1.0/changes-report.html#a1.0.2 [2] https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-maven-plugin/trunk/src/main/java/org/apache/cocoon/maven/rcl/PrepareWebappMojo.java -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Fwd: [SECURITY] Frame injection vulnerability in published Javadoc
Hi all, I am forwarding the attached e-mail here for notification: please take a look at it before continuing here. As you might see, we had only 6 problematic files that I have already fixed and committed via [1]. Regards. [1] https://github.com/olamy/JavadocUpdaterTool Original Message Subject:[SECURITY] Frame injection vulnerability in published Javadoc Date: Thu, 20 Jun 2013 09:29:23 +0100 From: Mark Thomas ma...@apache.org Reply-To: infrastruct...@apache.org infrastruct...@apache.org To: committ...@apache.org CC: r...@apache.org Hi All, Oracle has announced [1], [2] a frame injection vulnerability in Javadoc generated by Java 5, Java 6 and Java 7 before update 22. The infrastructure team has completed a scan of our current project websites and identified over 6000 instances of vulnerable Javadoc distributed across most TLPs. The chances are the project(s) you contribute to is(are) affected. A list of projects and the number of affected Javadoc instances per project is provided at the end of this e-mail. Please take the necessary steps to fix any currently published Javadoc and to ensure that any future Javadoc published by your project does not contain the vulnerability. The announcement by Oracle includes a link to a tool that can be used to fix Javadoc without regeneration. The infrastructure team is investigating options for preventing the publication of vulnerable Javadoc. The issue is public and may be discussed freely on your project's dev list. Thanks, Mark (ASF Infra) [1] http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html [2]http://www.kb.cert.org/vuls/id/225657 Project Instances abdera.apache.org 1 accumulo.apache.org 2 activemq.apache.org 105 any23.apache.org13 archiva.apache.org 4 archive.apache.org 13 aries.apache.org7 avro.apache.org 23 axis.apache.org 5 beehive.apache.org 16 bval.apache.org 12 camel.apache.org786 cayenne.apache.org 4 chemistry.apache.org6 click.apache.org3 cocoon.apache.org 6 commons.apache.org 34 continuum.apache.org9 creadur.apache.org 19 crunch.apache.org 4 ctakes.apache.org 2 curator.apache.org 4 cxf.apache.org 6 db.apache.org 39 directory.apache.org4 empire-db.apache.org1 felix.apache.org5 flume.apache.org5 geronimo.apache.org 241 giraph.apache.org 6 gora.apache.org 3 hadoop.apache.org 21 hbase.apache.org2 hive.apache.org 4 hivemind.apache.org 10 incubator.apache.org355 jackrabbit.apache.org 9 jakarta.apache.org 39 james.apache.org53 jena.apache.org 5 juddi.apache.org3 lenya.apache.org46 logging.apache.org 111 lucene.apache.org 713 manifoldcf.apache.org 112 marmotta.apache.org 1 maven.apache.org1623 maventest.apache.org1178 mina.apache.org 2 mrunit.apache.org 3 myfaces.apache.org 348 nutch.apache.org8 oltu.apache.org 11 oodt.apache.org 1 ooo-site.apache.org 1 oozie.apache.org10 openjpa.apache.org 20 opennlp.apache.org 9 pdfbox.apache.org 1 pig.apache.org 7 pivot.apache.org1 poi.apache.org 1 portals.apache.org 35 river.apache.org2 santuario.apache.org1 shale.apache.org55 shiro.apache.org3 sling.apache.org2 sqoop.apache.org4 struts.apache.org 190 subversion.apache.org 3 synapse.apache.org 1 syncope.apache.org 2 tapestry.apache.org 6 tika.apache.org 9 tiles.apache.org12 turbine.apache.org 100 tuscany.apache.org 4 uima.apache.org 12 velocity.apache.org 41 whirr.apache.org2 wicket.apache.org 3 wink.apache.org 13 ws.apache.org 22 xalan.apache.org1 xerces.apache.org 5 xml.apache.org 1 xmlbeans.apache.org 3 zookeeper.apache.org18
Re: Updating main Cocoon site
On 02/04/2013 20:56, Cédric Damioli wrote: 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 ? Here you go: http://cocoon.apache.org/1256_1_1.html Best regards. 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: How to update 2.1 website ?
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 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/
Re: How to update 2.1 website ?
Il 20/03/2013 15:52, Cédric Damioli ha scritto: 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 Done: time to celebrate :-) BTW : thank you all for your support in the release process ! You're welcome! Now it's time for C3 to hurry with the first beta release. Regards. 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/
Re: [VOTE] Release Cocoon 2.1.12
On 14/03/2013 15:53, Cédric Damioli wrote: 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. +1 Did same steps as Thorsten [1] + build from source tag [2] and test. Everything looks fine. Regards. [1] http://cocoon.markmail.org/thread/5ipoglnkq252rim4 [2] https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.1/RELEASE_2_1_12/ -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
On 14/03/2013 15:56, Cédric Damioli wrote: 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 Added to [3]. Regards. 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
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 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
On 11/03/2013 11:18, Cédric Damioli wrote: 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 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. 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [2.1.x] Code freeze and start of the release process (was Re: [DISCUSS] Releasing 2.1.12)
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 so this on Monday. 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: please add me to the wiki ContributorsGroup
On 06/03/2013 07:06, David Crossley wrote: Would someone please add me to the ContributorsGroup of the Cocoon wiki http://wiki.apache.org/cocoon/ContributorsGroup as DavidCrossley Done. Please let me know if it has worked. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [jira] [Commented] (COCOON-2295) Integrate FOP 1.0
On 04/03/2013 12:29, Cédric Damioli wrote: 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 ? I have just downloaded the binary distribution, assuming (because of [1]) that it was working correctly under JDK 1.4. However, if you take a look at [2]: property name=javac.source value=1.5/ property name=javac.target value=1.5/ make the final word to this. I will re-open COCOON-2295 for reverting to FOP 1.0 (where 1.4 is the javac.source / javac.target [3]) and also open an issue to the FOP team for fixing [1]. Regards. [1] http://xmlgraphics.apache.org/fop/1.1/running.html [2] http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_1/build.xml [3] http://svn.apache.org/repos/asf/xmlgraphics/fop/tags/fop-1_0/build.xml 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 (seehttps://issues.apache.org/jira/browse/COCOON-2289): 1. checkouthttp://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X 2. download (and build) FOP-1.0 fromhttp://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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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 ;-) 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
On 05/03/2013 08:28, David Crossley wrote: Cédric Damioli wrote: Francesco Chicchiriccò a écrit : 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 :) ;-) I only have time for some quick look and testing. Done that now, and my local Forrest seems happy. There are some svg-to-png errors from Batik, but other svg-to-png is okay, so assuming that that is a Forrest issue. Ok, does this mean we can start rolling this long-waited 2.1.12??!? Cédric, are you ready? 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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]. 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'd create the release 2.1.13 on JIRA, move COCOON-2333 there and start the release process for 2.1.12. 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
On 28/02/2013 11:22, Cédric Damioli wrote: 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 ? 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. 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: 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http
Re: [DISCUSS] Releasing 2.1.12
On 28/02/2013 11:44, Cédric Damioli wrote: Le 28/02/2013 11:26, Francesco Chicchiriccò a écrit : On 28/02/2013 11:22, Cédric Damioli wrote: 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 ? 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 ;) Well, the ASF is a do-ocracy [7] so don't be afraid :-) 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. Guess you are referring to [8]. I think this will also be the chance to update it in some parts, so that releasing 2.1.13 would be easier. Regards. 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: 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
Re: REST view and weird error
On 27/02/2013 01:18, Thorsten Scherler wrote: [...] I had some problems to find the important change though between the checkstyle/formating changes. It would be great if you could separate those in the future. ...I knew you would have said that :-) I did my best about that with 1450163, 1450152, 1450140, 1449724 but in 1450217 I guess I was under the just another minor adjustment and I'll stop effect... I hope to have some spare cycles soon: we are only 9 issues away from 3.0.0-beta-1 [1]! Regards. [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20COCOON3%20AND%20fixVersion%20%3D%20%223.0.0-beta-1%22%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: REST view and weird error
On 26/02/2013 13:43, Thorsten Scherler wrote:
On 02/25/2013 02:10 PM, Thorsten Scherler wrote:
...
Passing pipeline parameter as attribute: key=cocoon, value=[FAILED
toString()]
in MessageFormatter.arrayFormat.
still investigating
salu2
Actually you can see it if you start the cocoon-sample block and request
http://localhost:/controller/abc/foo?reqparam=1
SLF4J: Failed toString() invocation on an object of type [java.util.HashMap]
java.lang.StackOverflowError
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:631)
at java.lang.StringBuilder.append(StringBuilder.java:224)
at
org.apache.cocoon.configuration.MutableSettings.toString(MutableSettings.java:312)
at java.lang.String.valueOf(String.java:2902)
It actually happens in STRenderer
[...]
Hi Thorsten,
as you have already found, the problem is the cocoon entry in the
sitemap's ObjectModel, always passed among parameters.
I have been able to actually print the content of the cocoon entry via
common-collection's MapUtils:
if (entry.getValue() instanceof Map) {
MapUtils.verbosePrint(System.out, null, parameters);
} else {
System.out.println(entry.getValue());
}
I am about to commit a fix for the issue in STRenderer you've reported
above based on the usage of MapUtils#verbosePrint()
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: REST view and weird error
On 26/02/2013 15:25, Thorsten Scherler wrote:
On 02/26/2013 03:21 PM, Francesco Chicchiriccò wrote:
On 26/02/2013 13:43, Thorsten Scherler wrote:
On 02/25/2013 02:10 PM, Thorsten Scherler wrote:
...
Passing pipeline parameter as attribute: key=cocoon, value=[FAILED
toString()]
in MessageFormatter.arrayFormat.
still investigating
salu2
Actually you can see it if you start the cocoon-sample block and request
http://localhost:/controller/abc/foo?reqparam=1
SLF4J: Failed toString() invocation on an object of type
[java.util.HashMap]
java.lang.StackOverflowError
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:631)
at java.lang.StringBuilder.append(StringBuilder.java:224)
at
org.apache.cocoon.configuration.MutableSettings.toString(MutableSettings.java:312)
at java.lang.String.valueOf(String.java:2902)
It actually happens in STRenderer
[...]
Hi Thorsten,
as you have already found, the problem is the cocoon entry in the
sitemap's ObjectModel, always passed among parameters.
I have been able to actually print the content of the cocoon entry
via common-collection's MapUtils:
if (entry.getValue() instanceof Map) {
MapUtils.verbosePrint(System.out, null, parameters);
} else {
System.out.println(entry.getValue());
}
I am about to commit a fix for the issue in STRenderer you've reported
above based on the usage of MapUtils#verbosePrint()
Nice you are a monstruo.
Hem, guess you mean mostro (a.k.a. monster) - I'll take as a
compliment ;-)
Anyway as per r1450217 the StackOverflowError is removed from STRenderer.
Let us see whether that gets rid of the redundant data as well.
I've been exploring a bit the various call and I think that this
duplication might be generated when intra-pipeline calls (e.g.
servlet:/) are issued.
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Fix for COCOON3-105
On 05/02/2013 16:32, Thorsten Scherler wrote:
On 02/05/2013 04:10 PM, Thorsten Scherler wrote:
On 01/19/2013 02:23 PM, Francesco Chicchiriccò wrote:
Il 17/01/2013 10:23, Francesco Chicchiriccò ha scritto:
...
Hi Thorsten,
I was finally able to make all needed checks and the good news is
that everything is working as expected.
From the error message you report above I guess that you are not
using the very latest C3 SNAPSHOT artifacts.
Anyway, I've updated the sample application [1] with some
description about how to run and what you get [2].
HTH
Thank you very much, the problem was indeed in the older snapshot.
BTW
diff --git a/mysite2/pom.xml b/mysite2/pom.xml
index c5cb95b..e4c3527 100644
--- a/mysite2/pom.xml
+++ b/mysite2/pom.xml
@@ -17,7 +17,7 @@
dependencies
dependency
groupIdcom.mycompany/groupId
- artifactIdmysite2/artifactId
+ artifactIdmysite/artifactId
version${project.version}/version
/dependency
Fixed, thanks:
https://github.com/ilgrosso/cocoon3EmptyProject/commit/820763548e1cc9270a1f76c27a0602544c5dbc31
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [BLOCKER] SQLTransformer bug 1594 - cause found
On 19/01/2013 17:38, kompromiss wrote:
UPD: I added this:
/public String getAllText() {
return this.buffer.toString();
}/
into the TextRecorder.java, and this:
/public String endTextRecording()
throws SAXException {
sendEndPrefixMapping();
TextRecorder recorder = (TextRecorder) removeRecorder();
String text = recorder.getAllText();
if (getLogger().isDebugEnabled()) {
getLogger().debug(End text recording. Text= + text);
}
return text;
}/
into the SQLTransformer.class. After that I recompiled
cocoon-databases-impl-1.0.0.jar and cocoon-pipeline-impl-1.0.0.jar, and now
it works - spaces are not trimmed in substitute and ancestor variables.
Don't know, was it exactly right thing to do, but it works for now...
Hi,
nice catch! This could be even more interesting since 2.2 SQLTransformer
was also ported to C3 and might be affected by the same problem.
Please file an issue on JIRA, possibly referencing the original issue in
C2.1 (COCOON-1594), and the two mail threads you are referring to [1]
[2]. Then attach a patch with your fix: please remember to generate your
patch [3] against current SVN trunk [4].
Thanks!
[1]
http://cocoon.10839.n7.nabble.com/BLOCKER-SQLTransformer-bug-1594-cause-found-td28461.html#a57549
[2]
http://cocoon.10839.n7.nabble.com/sql-transformer-in-cocoon-2-2-td20170.html
[3] https://commons.apache.org/patches.html
[4] https://svn.apache.org/repos/asf/cocoon/trunk
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
On 19/01/2013 17:19, 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. 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 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? 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: 2.12 Release: Additions to COCOON-2333 (list of current jars)
On 20/01/2013 18:39, insigh...@gmail.com wrote: Was looking through the list of 2.1.12 jars, and notice that many of the jars are quite old. https://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/misc/notes/review-jars.txt?view=markup I also notice that my additions (sent 11 Dec) are not included. What are the plans to upgrade the jars before the 2.1.12 release? Hi, the plans are the ones contained in the SVN link you've reported above: consider that 2.1.12 will run on JDK 1.4, hence even JAR files must comply with this. I cannot find your additions sent 11 Dec: would you mind to add these as comment to COCOON-2333 in the format of the SVN link above, or - better - as SVN patch? Thanks. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [BLOCKER] SQLTransformer bug 1594 - cause found
On 18/01/2013 07:16, kompromiss wrote: Hi All I have this problem right now with cocoon 2.2 - swallowing spaces with substitution and ancestor variables. I've read about trimming text in class TextRecorder (org.apache.cocoon.transformation.helpers) Was the class TextRecorder in cocoon 2.2 fixed too? Wow, that's an old thread from 2005! I don't think that fix for mentioned issue [1] was applied to 2.2 basically because I don't think that 2.2 existed at that time. However, I'd think that SQLTransformer in 2.2 did originate from latest in 2.1, so I wouldn't expect that this issue is still there. FYI, here's the latest 2.2.X SQLTransformer source code: [2] HTH Regards. [1] https://issues.apache.org/jira/browse/COCOON-1594 [2] https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-databases/cocoon-databases-impl/src/main/java/org/apache/cocoon/transformation/SQLTransformer.java -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Fix for COCOON3-105
Il 17/01/2013 10:23, Francesco Chicchiriccò ha scritto: On 14/01/2013 16:20, Thorsten Scherler wrote: [...] Can you please tell me how can I address block_A's sitemap from from block_B's sitemap? I have used *blockcontext:/* for this before. This should work In the same way as in *servlet-service.xml, e.g. by replacing blockcontext:/otherblock/BLA with jar:classpath:lib/otherblock.jar!/COB-INF/BLA Hi, I just tried the above in another project but using it in the sitemap I get java.net.MalformedURLException: invalid url: classpath:lib/api-0.1-SNAPSHOT.jar!/COB-INF/resources/xsl/intern-to-solr.xsl (java.net.MalformedURLException: unknown protocol: classpath) I am trying to use a central module to store common xsl that I need both in cocoon and in my java code. Hi Thorsten, sorry for the delay, I am quite busy in this period on other projects. Anyway, I'll try to check and get back asap to you. Hi Thorsten, I was finally able to make all needed checks and the good news is that everything is working as expected. From the error message you report above I guess that you are not using the very latest C3 SNAPSHOT artifacts. Anyway, I've updated the sample application [1] with some description about how to run and what you get [2]. HTH Regards. [1] https://github.com/ilgrosso/cocoon3EmptyProject/tree/COCOON3-105 [2] https://github.com/ilgrosso/cocoon3EmptyProject/blob/COCOON3-105/README.md -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Release plan
Hi all, I've just been playing a bit with JIRA to draft a possible C3 release plan, for 3.0.0-beta-1 [1], 3.0.0 [2] and 3.1.0 [3] according to what we've been discussing so far. Please let me know if you see any problem with this. Regards. [1] https://issues.apache.org/jira/browse/COCOON3/fixforversion/12317578#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel [2] https://issues.apache.org/jira/browse/COCOON3/fixforversion/12323965#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel [3] https://issues.apache.org/jira/browse/COCOON3/fixforversion/12323966#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Fix for COCOON3-105
On 14/01/2013 16:20, Thorsten Scherler wrote: [...] Can you please tell me how can I address block_A's sitemap from from block_B's sitemap? I have used *blockcontext:/* for this before. This should work In the same way as in *servlet-service.xml, e.g. by replacing blockcontext:/otherblock/BLA with jar:classpath:lib/otherblock.jar!/COB-INF/BLA Hi, I just tried the above in another project but using it in the sitemap I get java.net.MalformedURLException: invalid url: classpath:lib/api-0.1-SNAPSHOT.jar!/COB-INF/resources/xsl/intern-to-solr.xsl (java.net.MalformedURLException: unknown protocol: classpath) I am trying to use a central module to store common xsl that I need both in cocoon and in my java code. Hi Thorsten, sorry for the delay, I am quite busy in this period on other projects. Anyway, I'll try to check and get back asap to you. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Fix for COCOON3-105
On 20/12/2012 13:45, Leonardo Miceli wrote: Hello On 12/07/2012 01:33 PM, Francesco Chicchiriccò wrote: On 07/12/2012 13:09, Jos Snellings wrote: In shorthand: What are the implications then? (...) Bottomline: - a block context is addressable within the sitemap load resource from another block context is possible via 'classpath'. The root of every block is available on the classpath? Everything should be working in the same way. Can you please tell me how can I address block_A's sitemap from from block_B's sitemap? I have used *blockcontext:/* for this before. This should work In the same way as in *servlet-service.xml, e.g. by replacing blockcontext:/otherblock/BLA with jar:classpath:lib/otherblock.jar!/COB-INF/BLA Could you provide some more concrete example, in case this is not just working? Thanks. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[ANN] Apache Cocoon Integration Test Framework 1.0.1 and Servlet Service Implementation 1.3.2
The Apache Cocoon team is pleased to announce the release of subprojects Cocoon Integration Test Framework 1.0.1 and Servlet Service Implementation 1.3.2. Apache Cocoon is an XML processing framework built around the concepts of separation of concerns and component-based development. Apache Cocoon 3 is a major rewrite of Cocoon 2.2. Like Cocoon 2 it is based around the concept of pipelines and sitemaps and it is very similar to Cocoon 2.2 in many respects but is slimmed down and designed to be easily used with Java code (= no frameworks required!). On top of this, Cocoon 3 has the goal of becoming the best available platform for RESTful web services and web applications. Subprojects are libraries, shared by different Apache Cocoon versions, that can be used independently from the rest of Cocoon (1.x, 2.x 3.x), or any of its parts (such as sitemap, pipelines, blocks, etc.). Take a look at subprojects site http://cocoon.apache.org/subprojects/ and Maven plugins site http://cocoon.apache.org/2.2/maven-plugins/ for more details. We welcome your help and feedback. For more information on how to report problems, and to get involved, visit the project website at http://cocoon.apache.org/ The Apache Cocoon Team
Re: [VOTE] Apache Cocoon Servlet Service Implementation 1.3.2
On 13/12/2012 10:54, Francesco Chicchiriccò wrote: I've created a Cocoon Servlet Service Implementation 1.3.2 release, with the following artifacts up for a vote: SVN source tag (r1421170): https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/tags/cocoon-servlet-service-impl-1.3.2/ List of changes: https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/tags/cocoon-servlet-service-impl-1.3.2/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-008/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-008/org/apache/cocoon/cocoon-servlet-service-impl/1.3.2/cocoon-servlet-service-impl-1.3.2-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) +1 Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Cocoon Integration Test Framework 1.0.1
On 13/12/2012 10:16, Francesco Chicchiriccò wrote: I've created a Cocoon Integration Test Framework 1.0.1 release, with the following artifacts up for a vote: SVN source tag (r1421155): https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.1/ List of changes: https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.1/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-007/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-007/org/apache/cocoon/cocoon-it-fw/1.0.1/cocoon-it-fw-1.0.1-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) +1 Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[VOTE] Apache Cocoon Integration Test Framework 1.0.1
I've created a Cocoon Integration Test Framework 1.0.1 release, with the following artifacts up for a vote: SVN source tag (r1421155): https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.1/ List of changes: https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.1/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-007/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-007/org/apache/cocoon/cocoon-it-fw/1.0.1/cocoon-it-fw-1.0.1-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[VOTE] Apache Cocoon Servlet Service Implementation 1.3.2
I've created a Cocoon Servlet Service Implementation 1.3.2 release, with the following artifacts up for a vote: SVN source tag (r1421170): https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/tags/cocoon-servlet-service-impl-1.3.2/ List of changes: https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/tags/cocoon-servlet-service-impl-1.3.2/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-008/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-008/org/apache/cocoon/cocoon-servlet-service-impl/1.3.2/cocoon-servlet-service-impl-1.3.2-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] C3 tagging
Hi all, I'd like to understand whether there is any particular reason behind the way tags are created for C3 releases [1] by a dedicated script [2], instead of letting the maven-release-plugin manage tags by following the standard layout. If there are no objections, I'd propose to empower the maven-release-plugin for managing the whole C3 release process; I would also like to update and move [3] to a dedicate page on the website. All this to be proven and refined for upcoming 3.0.0-beta-1 release. WDYT? Regards. [1] https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/ [2] https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/BEFORE_COCOON3-105/svn-release-tags.sh [3] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/RELEASE_HOWTO.txt -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: 2.12 Release: Additions to COCOON-2333 (list of current jars)
On 12/12/2012 05:12, 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. 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. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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]? 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 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: possible design flaw in linking of pipelines (C3)
(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Caused by: java.lang.ClassCastException: net.sf.saxon.Controller cannot be cast
to org.apache.xalan.xsltc.trax.TransformerImpl
at
org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTransformerHandler(TransformerFactoryImpl.java:928)
at
org.apache.cocoon.sax.component.XSLTTransformer.setSAXConsumer(XSLTTransformer.java:245)
... 30 more
This is probably due to
@Override
protected void setSAXConsumer(final SAXConsumer consumer) {
TransformerHandler transformerHandler;
try {
transformerHandler =
TRAX_FACTORY.newTransformerHandler(this.templates);
} catch (Exception e) {
throw new SetupException(Could not initialize transformer
handler., e);
}
...
}
I think we shouldn’t just ALWAYS create a new transformerhandler using the
default TRAX_FACTORY but it should the same SAXTransformerFactory we created in
loadXSLT.
But setSAXConsumer is called from within AbstractPipeline.setConsumer which
again translates to AbstractSAXProducer.setConsumer which sets the SaxConsumer.
Anyone who is expert in this matter?
Robby
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Fix for COCOON3-105
Hi all, any reaction on this? Shall I just apply such huge patch without anyone else's confirmation??!? Regards. On 03/12/2012 16:38, Francesco Chicchiriccò wrote: Hi all, I have finally elaborated a fix for COCOON3-105 and now I am able to run more C3-based webapps in the same servlet container. I have also added a comment explaining the way I have fixed the issue: as you can see, it is a considerable change, so I'd like to get your feedback before applying. Please take a look and let me know. Regards. On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote: [ https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508800#comment-13508800 ] Francesco Chicchiriccò commented on COCOON3-105: Please evaluate the attached patch (COCOON3-105.patch). The patch is quite pervasive and I've seen that it might also cause some troubles when applying: if you find any .rej or .orig files (after application), please remove. This patch basically removes any reference to the blockcontext:/ protocol - as you can see there is no more dependency on cocon-block-deployment. The blockcontext:/ protocol has been replaced by a classpath:/ protocol implementation, working together with the JVM's jar:/ protocol. I have also prepared a demo project for this [1]: after having mvn clean install on the patched C3 source tree, just clone, switch to branch COCOON3-105 and compile by running mvn clean package then launch via mvn cargo:run You will get an Apache Tomcat instance listening on containing two distinct C3 webapps; access URLs are http://localhost:/mywebapp/ http://localhost:/mywebapp2/mysite/ http://localhost:/mywebapp2/mysite2/ e.g. 3 distinct blocks across 2 distinct webapps. Please note that this fix should also work for C2.2, as far as the ClasspathURLStreamHandlerFactory class is provided - I've put this class in cocoon-servlet but we can think to move it to cocoon-servlet-service-impl, for example. [1] https://github.com/ilgrosso/cocoon3EmptyProject webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp running - Key: COCOON3-105 URL: https://issues.apache.org/jira/browse/COCOON3-105 Project: Cocoon 3 Issue Type: Bug Components: cocoon-webapp Affects Versions: 3.0.0-beta-1 Reporter: Thorsten Scherler Assignee: Francesco Chicchiriccò Priority: Blocker Fix For: 3.0.0-beta-1 Attachments: COCOON3-105.npe.diff, COCOON3-105.patch, COCOON3-105.patch, cocoon-block-deployment.patch, cocoon-servlet-service-impl.patch I noticed that you cannot run 2 c3 based war in a tomcat. To reproduce: - seed parent via archetype - seed block in parent via archetype - seed block2 in parent via archetype - seed webapp in parent via archetype - seed webapp2 in parent via archetype where webapp depends on block one and webapp2 depends on block2. My sample was: [INFO] Reactor Summary: [INFO] [INFO] myparent .. SUCCESS [1.163s] [INFO] myblock ... SUCCESS [3.611s] [INFO] mywebapp .. SUCCESS [1.924s] [INFO] myblock2 .. SUCCESS [1.498s] [INFO] mywebapp2 . SUCCESS [1.230s] [INFO] Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it before you start to webapp or if you have it enable deploy it on a running instance. You should see the welcome page under something like http://localhost:8080/mywebapp-1.0-SNAPSHOT/ side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a StringIndexOutOfBoundsException but that is another ticket I guess. Now if you deploy the second webapp on a running instance it will deploy without problem but requesting http://localhost:8080/mywebapp2-1.0-SNAPSHOT/ will return a blank page and in /.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log you find: 2012-09-13 22:12:46,056 ERROR http-8080-1 org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the RequestProcessor correctly. org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build sitemap from blockcontext:/myblock2/sitemap.xmap at org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70) ~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT] at org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203) ~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT] ... Caused by: java.lang.RuntimeException
Re: [DISCUSS] Fix for COCOON3-105
On 07/12/2012 13:09, Jos Snellings wrote:
In shorthand: What are the implications then?
For users? Just the servlet:context declaration, from
servlet:context mount-path=
context-path=blockcontext:/cocoon-sample/ /
to
servlet:context mount-path=
context-path=jar:classpath:lib/${project.build.finalName}.jar!/COB-INF//
However, in order to be consistent with RCL, you should also add - in
the 'dev' profile -
servlet:context mount-path= context-path=classpath:/COB-INF//
The provided patch contains the needed changes for archetypes so that
new blocks are already created with the new way.
In practice, this patch removes the need of the 'blockcontext:/'
protocol that has proven to make unfeasible to deploy two distinct C3
block-enabled webapps in the same container.
As a side note, you can still use the blockcontext:/ protocol, but
you'll need to manually add the cocoon-block-deployment dependency.
Let's say that this patch puts the blockcontext:/ protocol in a sort of
'deprecated' state.
Bottomline:
- a block context is addressable within the sitemap
load resource from another block context is possible via 'classpath'.
The root of every block is available on the classpath?
Everything should be working in the same way.
- different web applications relying on cocoon3 can deploy blocks with
the same name
they won't interfere with each other?
Correct.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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? Thanks. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] Fix for COCOON3-105
Hi all,
I have finally elaborated a fix for COCOON3-105 and now I am able to run
more C3-based webapps in the same servlet container.
I have also added a comment explaining the way I have fixed the issue:
as you can see, it is a considerable change, so I'd like to get your
feedback before applying.
Please take a look and let me know.
Regards.
On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508800#comment-13508800
]
Francesco Chicchiriccò commented on COCOON3-105:
Please evaluate the attached patch (COCOON3-105.patch).
The patch is quite pervasive and I've seen that it might also cause some
troubles when applying: if you find any .rej or .orig files (after
application), please remove.
This patch basically removes any reference to the blockcontext:/ protocol - as
you can see there is no more dependency on cocon-block-deployment.
The blockcontext:/ protocol has been replaced by a classpath:/ protocol
implementation, working together with the JVM's jar:/ protocol.
I have also prepared a demo project for this [1]: after having mvn clean
install on the patched C3 source tree, just clone, switch to branch COCOON3-105 and
compile by running
mvn clean package
then launch via
mvn cargo:run
You will get an Apache Tomcat instance listening on containing two
distinct C3 webapps; access URLs are
http://localhost:/mywebapp/
http://localhost:/mywebapp2/mysite/
http://localhost:/mywebapp2/mysite2/
e.g. 3 distinct blocks across 2 distinct webapps.
Please note that this fix should also work for C2.2, as far as the
ClasspathURLStreamHandlerFactory class is provided - I've put this class in
cocoon-servlet but we can think to move it to cocoon-servlet-service-impl, for
example.
[1] https://github.com/ilgrosso/cocoon3EmptyProject
webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp
running
-
Key: COCOON3-105
URL: https://issues.apache.org/jira/browse/COCOON3-105
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-webapp
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler
Assignee: Francesco Chicchiriccò
Priority: Blocker
Fix For: 3.0.0-beta-1
Attachments: COCOON3-105.npe.diff, COCOON3-105.patch,
COCOON3-105.patch, cocoon-block-deployment.patch,
cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
To reproduce:
- seed parent via archetype
- seed block in parent via archetype
- seed block2 in parent via archetype
- seed webapp in parent via archetype
- seed webapp2 in parent via archetype
where webapp depends on block one and webapp2 depends on block2.
My sample was:
[INFO] Reactor Summary:
[INFO]
[INFO] myparent .. SUCCESS [1.163s]
[INFO] myblock ... SUCCESS [3.611s]
[INFO] mywebapp .. SUCCESS [1.924s]
[INFO] myblock2 .. SUCCESS [1.498s]
[INFO] mywebapp2 . SUCCESS [1.230s]
[INFO]
Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it
before you start to webapp or if you have it enable deploy it on a running
instance. You should see the welcome page under something like
http://localhost:8080/mywebapp-1.0-SNAPSHOT/
side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a
StringIndexOutOfBoundsException but that is another ticket I guess.
Now if you deploy the second webapp on a running instance it will deploy
without problem but requesting
http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
will return a blank page and in
/.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
you find:
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build
sitemap from blockcontext:/myblock2/sitemap.xmap
at
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70)
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
at
org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
...
Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed.
The available blocks are
{myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/blocks
[DISCUSS] Fix for COCOON3-105
Hi all,
I have finally elaborated a fix for COCOON3-105 and now I am able to run
more C3-based webapps in the same servlet container.
I have also added a comment explaining the way I have fixed the issue:
as you can see, it is a considerable change, so I'd like to get your
feedback before applying.
Please take a look and let me know.
Regards.
On 03/12/2012 16:31, Francesco Chicchiriccò (JIRA) wrote:
[
https://issues.apache.org/jira/browse/COCOON3-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13508800#comment-13508800
]
Francesco Chicchiriccò commented on COCOON3-105:
Please evaluate the attached patch (COCOON3-105.patch).
The patch is quite pervasive and I've seen that it might also cause some
troubles when applying: if you find any .rej or .orig files (after
application), please remove.
This patch basically removes any reference to the blockcontext:/ protocol - as
you can see there is no more dependency on cocon-block-deployment.
The blockcontext:/ protocol has been replaced by a classpath:/ protocol
implementation, working together with the JVM's jar:/ protocol.
I have also prepared a demo project for this [1]: after having mvn clean
install on the patched C3 source tree, just clone, switch to branch COCOON3-105 and
compile by running
mvn clean package
then launch via
mvn cargo:run
You will get an Apache Tomcat instance listening on containing two
distinct C3 webapps; access URLs are
http://localhost:/mywebapp/
http://localhost:/mywebapp2/mysite/
http://localhost:/mywebapp2/mysite2/
e.g. 3 distinct blocks across 2 distinct webapps.
Please note that this fix should also work for C2.2, as far as the
ClasspathURLStreamHandlerFactory class is provided - I've put this class in
cocoon-servlet but we can think to move it to cocoon-servlet-service-impl, for
example.
[1] https://github.com/ilgrosso/cocoon3EmptyProject
webapp fails if on the same servlet container is a c2.2.1 or other c3 webapp
running
-
Key: COCOON3-105
URL: https://issues.apache.org/jira/browse/COCOON3-105
Project: Cocoon 3
Issue Type: Bug
Components: cocoon-webapp
Affects Versions: 3.0.0-beta-1
Reporter: Thorsten Scherler
Assignee: Francesco Chicchiriccò
Priority: Blocker
Fix For: 3.0.0-beta-1
Attachments: COCOON3-105.npe.diff, COCOON3-105.patch,
COCOON3-105.patch, cocoon-block-deployment.patch,
cocoon-servlet-service-impl.patch
I noticed that you cannot run 2 c3 based war in a tomcat.
To reproduce:
- seed parent via archetype
- seed block in parent via archetype
- seed block2 in parent via archetype
- seed webapp in parent via archetype
- seed webapp2 in parent via archetype
where webapp depends on block one and webapp2 depends on block2.
My sample was:
[INFO] Reactor Summary:
[INFO]
[INFO] myparent .. SUCCESS [1.163s]
[INFO] myblock ... SUCCESS [3.611s]
[INFO] mywebapp .. SUCCESS [1.924s]
[INFO] myblock2 .. SUCCESS [1.498s]
[INFO] mywebapp2 . SUCCESS [1.230s]
[INFO]
Now take a tomcat (I used 6) and first deploy the mywebapp. You can copy it
before you start to webapp or if you have it enable deploy it on a running
instance. You should see the welcome page under something like
http://localhost:8080/mywebapp-1.0-SNAPSHOT/
side note: http://localhost:8080/mywebapp-1.0-SNAPSHOT will throw a
StringIndexOutOfBoundsException but that is another ticket I guess.
Now if you deploy the second webapp on a running instance it will deploy
without problem but requesting
http://localhost:8080/mywebapp2-1.0-SNAPSHOT/
will return a blank page and in
/.../tomcat/work/Catalina/localhost/mywebapp-1.0-SNAPSHOT/cocoon.log
you find:
2012-09-13 22:12:46,056 ERROR http-8080-1
org.apache.cocoon.servlet.XMLSitemapServlet - Can't initialize the
RequestProcessor correctly.
org.apache.cocoon.sitemap.SitemapBuilder$SitemapBuilderException: Can't build
sitemap from blockcontext:/myblock2/sitemap.xmap
at
org.apache.cocoon.sitemap.SitemapBuilder.build(SitemapBuilder.java:70)
~[cocoon-sitemap-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
at
org.apache.cocoon.servlet.RequestProcessor.initializeSitemap(RequestProcessor.java:203)
~[cocoon-servlet-3.0.0-beta-1-SNAPSHOT.jar:3.0.0-beta-1-SNAPSHOT]
...
Caused by: java.lang.RuntimeException: There is no block 'myblock2' deployed.
The available blocks are
{myblock=file:/home/thorsten/src/apache/apache-tomcat-6.0.20/work/Catalina/localhost/mywebapp-1.0
Re: keep running into issue while commiting [the specified baseline is not the latest baseline]
On 28/11/2012 13:56, Robby Pelssers wrote: http://www.apache.org/dev/version-control.html#latest-baseline I tried several times to commit the patch for [COCOON3-114] but with no success so far. Anyone experiencing similar issues? I do: I've solved temporarily the situation by switching to svn.us.apache.org from svn.apache.org (which presumably resolves to svn.eu.apache.org for both of us). Hope this helps. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: keep running into issue while commiting [the specified baseline is not the latest baseline]
On 28/11/2012 13:58, Francesco Chicchiriccò wrote: On 28/11/2012 13:56, Robby Pelssers wrote: http://www.apache.org/dev/version-control.html#latest-baseline I tried several times to commit the patch for [COCOON3-114] but with no success so far. Anyone experiencing similar issues? I do: I've solved temporarily the situation by switching to svn.us.apache.org from svn.apache.org (which presumably resolves to svn.eu.apache.org for both of us). It seems there are quite some issues: http://monitoring.apache.org/status/ Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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? Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
On 19/11/2012 10:45, Cédric Damioli wrote: 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 ... I think you can safely apply the lazy consensus [1] here, especially since it seems there is no one else - but you - taking care of C2.1 issues :-( 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 ? I think you should send an e-mail to users@ ML asking to review the 74 issues reported above (a direct link to the JIRA search would be helpful) and to explicitly set the fix-for-version to 2.1.12 if they absolutely require so. Once 72 hours have passed by, you can look at the results and see what to do; for any other non-answered issue, I think you can apply again [4]. 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. 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. Just show what steps are needed to make such verifications; about the completeness of such verifications, I think that only dalily usage can do better, hence don't worry too much. 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 My opinion here is to try to be as safe as possible, but also to try to release ASAP - at most before the end of the year: we cannot afford additional delay: let's apply [4] as much as possible and leave any missing piece from 2.1.13: I hope it won't take 4 more years :-) 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 [4] http://www.apache.org/foundation/glossary.html#LazyConsensus -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Releasing 2.1.12
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 ? -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] Releasing 2.1.12
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? 2. Is the release process clear to you? If not, who (maybe active in the past) can provide some hint? 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... 4. Considering the questions above, when do you think we can start releasing 2.1.12? Thanks for info. Regards. [1] https://issues.apache.org/jira/browse/COCOON/fixforversion/12312903#selectedTab=com.atlassian.jira.plugin.system.project%3Aversion-issues-panel -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] Releasing 2.2.1
Hi all (but Thorsten and Javier in particular), by looking at JIRA [1] it seems that quite a considerable number of issues have been fixed since 2.2 (23) even though some are still standing (6+1). Following our recent discussion in another thread, I have some questions: 1. Do you think that the the 7 outstanding issues can be moved to 2.2.2 or there are some that need to be absolutely included in 2.2.1? 2. Is the release process clear to you? If not, who (maybe active in the past) can provide some hint? 3. Do you need any help in the release process? If so, who is available to help? I am, even though I have never worked with C2.2 4. Considering the questions above, when do you think we can start releasing 2.2.1? Thanks for info. Regards. [1] https://issues.apache.org/jira/browse/COCOON/fixforversion/12313093 -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] Release plan
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 -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Release plan
On 12/11/2012 10:46, Cédric Damioli wrote: 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? Definitely! Please let's consider C2.1.12 added to the release plan below: * which issues are still missing that you would like to include? * who is available to help Cédric? Thanks. Regards. 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 -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [DISCUSS] Release plan
On 12/11/2012 11:17, Robby Pelssers wrote: Hi Francesco, Sounds like a good plan to me. We should make sure that all open tasks are JIRA tickets and we should have on our front page listed which tickets are in scope for 3.0.0 release. (perhaps also with status). And if possible a target release date ;-) Ok, but this sounds like an answer only for question (1) below; what about the other question? ;-) This will give everyone a clear overview and a focus what to work on. And maybe we can discuss internally in what order the tickets should be resolved in order to work efficiently. Fair enough. Regards. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Monday, November 12, 2012 10:25 AM To: dev@cocoon.apache.org Subject: [DISCUSS] Release plan 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 -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: avalon version
On 22/10/2012 07:50, Jos Snellings wrote:
Dear cocooners,
Since today, it is not possible to package cocoon 3 apps via maven
anymore.
Build is requesting:
org.apache.avalon.framework:avalon-framework-api:jar:4.2.0
as well as its implementation.
Who still needs avalon?
- jnet
- fop
- ... are there others?
Latest version of Avalon I can get is 4.3.1
Maven is having trouble getting version 4.2.0.
Which version of C3 are you running?
Latest snapshots (3.0.0-beta-1-SNAPSHOT) don't suffer from this at all:
find ~/.m2/ -name '*avalon*' -exec rm -rf {} \;
. it.sh
...
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache Cocoon 3: Parent ... SUCCESS [5.524s]
[INFO] Apache Cocoon 3: Utilities SUCCESS [2.710s]
[INFO] Apache Cocoon 3: Pipeline . SUCCESS [1.445s]
[INFO] Apache Cocoon 3: SAX .. SUCCESS [6.711s]
[INFO] Apache Cocoon 3: CLI .. SUCCESS [2.794s]
[INFO] Apache Cocoon 3: Sitemap .. SUCCESS [1.863s]
[INFO] Apache Cocoon 3: Controller ... SUCCESS [0.757s]
[INFO] Apache Cocoon 3: Servlet .. SUCCESS [1.137s]
[INFO] Apache Cocoon 3: Optional . SUCCESS [7.556s]
[INFO] Apache cocoon 3: Databases integration components . SUCCESS [1.023s]
[INFO] Apache Cocoon 3: Monitoring ... SUCCESS [3.784s]
[INFO] Apache Cocoon 3: REST support . SUCCESS [2.261s]
[INFO] Apache Cocoon 3: Profiling SUCCESS [1.546s]
[INFO] Apache cocoon 3: Optional REST components . SUCCESS [2.826s]
[INFO] Apache Cocoon 3: String Templates . SUCCESS [1.713s]
[INFO] Apache Cocoon 3: Shiro integration SUCCESS [1.062s]
[INFO] Apache Cocoon 3: StAX . SUCCESS [2.237s]
[INFO] Apache Cocoon 3: Wicket Integration ... SUCCESS [1.076s]
[INFO] Apache Cocoon 3: All dependencies . SUCCESS [1.017s]
[INFO] Apache Cocoon 3: Databases sample integration . SUCCESS [1.428s]
[INFO] Apache Cocoon 3: Sample ... SUCCESS [21.878s]
[INFO] Apache Cocoon 3: Shiro sample integration . SUCCESS [1.480s]
[INFO] Apache Cocoon 3: Webapplication sample SUCCESS [34.077s]
[INFO] Apache Cocoon 3: Wicket Integration Webapp Sample . SUCCESS [2.606s]
[INFO] Apache Cocoon 3: Block Archetype .. SUCCESS [2.493s]
[INFO] Apache Cocoon 3: Parent Archetype . SUCCESS [0.508s]
[INFO] Apache Cocoon 3: Sample Archetype . SUCCESS [3.447s]
[INFO] Apache Cocoon 3: Web Application Archetype SUCCESS [0.691s]
[INFO] Apache Cocoon 3: Root . SUCCESS [0.092s]
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1:59.295s
[INFO] Finished at: Mon Oct 22 09:03:05 CEST 2012
[INFO] Final Memory: 83M/500M
[INFO]
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
