Re: [C3] Java version 1.6
On 11/08/2011 00:42, Steven Dolg wrote: Am 04.08.2011 00:03, schrieb Sylvain Wallez: Le 01/08/11 16:26, Nathaniel, Alfred a écrit : Hi all, C3 is still set to 1.5 as source and target version. Java5 is end of life since almost two years now. Is there any good reason not to go 1.6? Here's an additional one to the ones already given : StAX (javax.xml.stream) is included in 1.6, whereas it requires a separate implementation (e.g. Woodstox) in 1.5. I have another one: trunk cannot be compiled with Java 5 any more. Adding @Override to methods that implement an interface is only allowed in 1.6 and not in 1.5. I can see 44 errors due to that in cocoon-sax, cocoon-sitemap, cocoon-stringtemplate and cocoon-wicket. So our build is only working because de facto we are already running on 1.6. I guess that at this point we should urgently choose whether to officially upgrade to 1.6 or to put in place something like animal sniffer [1] - as suggested by Simone, in order to retain effective 1.5 compatibility. If we get stuck in the current situation, instead, we will keep an inconsistent build behavior where either you need a real 1.5 JDK - it's been long time since I had something similar installed in my laptop - or a human 1.5 parser :-) Regards. [1] http://mojo.codehaus.org/animal-sniffer-maven-plugin -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: Fwd: Cocoon-trunk - Build # 49 - Unstable
On 11/08/2011 00:03, Steven Dolg wrote: Oops!... I did it again But this time I'm innocent :P It took me some time to figure this one out since I didn't touch anything near it. My theory is this: With COCOON3-69 ehcache was upgraded from 1.6.1 to 2.4.3. Ehm, yes, I am actually guilty in this respect: I did this version upgrade, mainly to solve some dependency issues related to SLF4J, Commons Logging and Log4j. Between those versions, the serialVersionUID of net.sf.ehcache.Element changed, so serialized versions of that class cannot be loaded any more. The build fails because the ehcache for cocoon-profiling is configured to be diskPersistent and reading the old cache with the new class fails. The build fails only sometimes, because it fails only once on each node in the build cluster, after that the cache is rewritten with the newer version. This is coherent with what I've found while building C3 on different machines: from a fresh checkout no errors, from a source tree already built before updating, first an error, then everything works. Should we wait until the build has spread through all nodes and stopped failing from this or try something else? I'm really for changing the profiling cache to non-persistent - unless that breaks something. Do we need to preserve profiling results between restarts? AFAIK, there should be no issue in making profiling results volatile, but I am really not familiar with profiling internals: who knows better? Regards. Original-Nachricht Betreff:Cocoon-trunk - Build # 49 - Unstable Datum: Wed, 10 Aug 2011 21:22:17 + (UTC) Von:Apache Jenkins Server jenk...@builds.apache.org An: steven.d...@indoqa.com The Apache Jenkins build system has built Cocoon-trunk (build #49) Status: Unstable Check console output athttps://builds.apache.org/job/Cocoon-trunk/49/ to view the results. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: A couple of issues with JIRA
On 10/08/2011 10:46, Reinhard Pötz wrote: On 08/10/2011 10:03 AM, Francesco Chicchiriccò wrote: Hello, I think we should fix a couple of things related to Cocoon JIRA: 1. Versions At the moment [1] alpha-2 and alpha-3 are shown as unreleased and beta-1 is missing: this makes rather impossible to make good ticket assignments to versions and also to plan next releases. Who have enough rights to fix this? I have. I've just created 3.0.0-beta-1 Good :-) 2. Notifications Some months ago, the discussion [2] about how to re-enable this has stopped with an unanswered question: What do we have to do in order to get the notification mails back? Can we just open a ticket to the infrastructure team about this? Yes please. TIA! Done: https://issues.apache.org/jira/browse/INFRA-3844. Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: A couple of issues with JIRA
On 11/08/2011 08:54, Francesco Chicchiriccò wrote: On 10/08/2011 10:46, Reinhard Pötz wrote: On 08/10/2011 10:03 AM, Francesco Chicchiriccò wrote: Hello, I think we should fix a couple of things related to Cocoon JIRA: 1. Versions At the moment [1] alpha-2 and alpha-3 are shown as unreleased and beta-1 is missing: this makes rather impossible to make good ticket assignments to versions and also to plan next releases. Who have enough rights to fix this? I have. I've just created 3.0.0-beta-1 Good :-) 2. Notifications Some months ago, the discussion [2] about how to re-enable this has stopped with an unanswered question: What do we have to do in order to get the notification mails back? Can we just open a ticket to the infrastructure team about this? Yes please. TIA! Done: https://issues.apache.org/jira/browse/INFRA-3844. The ticket has just been closed with message done, enjoy! :-) -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: Fwd: Cocoon-trunk - Build # 49 - Unstable
AFAIK, there should be no issue in making profiling results volatile, but I am really not familiar with profiling internals: who knows better? One could argue that the profiling should match up against the regular release just so that we know the results correspond. As long as everyone know what is going on I don't see a big issue leaving it the way it is, but that means documenting it in an obvious way some how. Any ideas?
[2.1] Future of Cocoon 2.1.x... again :)
Hi Cocoon team, A little more than one year ago, I sent a mail [1] to this list, to get feedbacks about usage of Cocoon 2.1.x, 3 years after the last release. I must admit that I received many more answers (privately and publicly on the list) than I could have expected first. This proved me the vitality of the 2.1.x community. So I began to open some tickets [2] [3] [4] [5] [6] [7] and provide some patches gathered during the last years on my projects, but unfortunately, I received nearly no feedback from committers around here. Is there still any interest from devs for the 2.1.x branch ? Could someone review the patches ? I obviously volunteer to help, to stop having to run dozen apps with a patched Cocoon. Has someone interest to prepare and schedule a 2.1.12 maintenance release ? Best regards, Cédric [1] http://markmail.org/thread/hizllvbjdeurr2de [2] https://issues.apache.org/jira/browse/COCOON-2288, allow to use SLF4J [3] https://issues.apache.org/jira/browse/COCOON-2307, bug in the ResourceReader [4] https://issues.apache.org/jira/browse/COCOON-2309, possible bug with SitemapSource under certain circumstances [5] https://issues.apache.org/jira/browse/COCOON-2310, XHTMLSerializer from serializers block does not handle HTML5 [6] https://issues.apache.org/jira/browse/COCOON-2313, subclassing of org.apache.cocoon.Cocoon [7] https://issues.apache.org/jira/browse/COCOON-2314, override upload params in CocoonServlet -- Cédric Damioli ANYWARE SERVICES http://www.anyware-services.com http://www.ametys.org
Re: [2.1] Future of Cocoon 2.1.x... again :)
First question I have to ask is whether there is anyone with the relevant permission to do anything with these patches. Alec, On 11/08/11 15:36, Cédric Damioli wrote: Hi Cocoon team, A little more than one year ago, I sent a mail [1] to this list, to get feedbacks about usage of Cocoon 2.1.x, 3 years after the last release. I must admit that I received many more answers (privately and publicly on the list) than I could have expected first. This proved me the vitality of the 2.1.x community. So I began to open some tickets [2] [3] [4] [5] [6] [7] and provide some patches gathered during the last years on my projects, but unfortunately, I received nearly no feedback from committers around here. Is there still any interest from devs for the 2.1.x branch ? Could someone review the patches ? I obviously volunteer to help, to stop having to run dozen apps with a patched Cocoon. Has someone interest to prepare and schedule a 2.1.12 maintenance release ? Best regards, Cédric [1] http://markmail.org/thread/hizllvbjdeurr2de [2] https://issues.apache.org/jira/browse/COCOON-2288, allow to use SLF4J [3] https://issues.apache.org/jira/browse/COCOON-2307, bug in the ResourceReader [4] https://issues.apache.org/jira/browse/COCOON-2309, possible bug with SitemapSource under certain circumstances [5] https://issues.apache.org/jira/browse/COCOON-2310, XHTMLSerializer from serializers block does not handle HTML5 [6] https://issues.apache.org/jira/browse/COCOON-2313, subclassing of org.apache.cocoon.Cocoon [7] https://issues.apache.org/jira/browse/COCOON-2314, override upload params in CocoonServlet
Re: [C3] i18n support
On 14/07/2011 09:25, Francesco Chicchiriccò wrote: Hi folks, yesterday Thorsten wrote something about C3 and i18n support, and we also discussed something about this a while ago [1]. Since I need now this kind of support for my Hippo Cocoon Toolkit project [2], I think in the next weeks I'll be working on this topic, so: is there anything I can start from? Do you think that migrating Cocoon 2.2 components (as suggested in [3]) would be the easier / better way to do it? Thanks. [1] http://cocoon.markmail.org/message/wey7tzgeqlyrhsmv?q=+list:org.apache.cocoon.dev+c3+anf+i18n [2] http://forge.onehippo.org/gf/project/hct/ [3] https://issues.apache.org/jira/browse/COCOON3-64 Gents, I've just committed all the modifications involved with issue COCOON3-64: I've ported the i18NTransformer in cocoon-sax (since no additional dependencies are involved), added some unit tests and some sitemap samples in cocoon-sitemap. Some remarks: 1. With respects to comments into COCOON3-64, I've NOT ported all the classes from the trunk, but only the transformer: in particular, I thought - at least from the moment - not to consider XML catalogs but to use instead standard JDK ResourceBundle, much like other frameworks - namely Wicket - are doing. 2. This porting is for C3 only, even though I think it could be quit easily adaptable to C2.2 as well. 3. I've taken as reference for writing unit tests the old but still well written [4]: I think we should enclose something similar in C3 documentation. 4. In C2.1 there used to be a type attribute, already deprecated in some situations like as i18n:param type=date pattern=dd-MMM-yy / C3 I18NTransformer does not consider such situations at all; the sample above becomes - like it also used to be in C2.1 i18n:parami18n:date pattern=dd-MMM-yy //i18n:param 5. I needed to port ParamSAXBuffer extending SAXBuffer (from cocoon-xml): for the moment I put its source in cocoon-sax, but of course the right place would be in cocoon-xml, so how could we handle this? Can I move that class to cocoon-xml's? In which SVN place? And how can we release a SNAPSHOT version of this subproject? Regards. [4] https://cocoon.apache.org/2.1/userdocs/i18nTransformer.html -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (COCOON3-64) i18n support
[ https://issues.apache.org/jira/browse/COCOON3-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083164#comment-13083164 ] Francesco Chicchiriccò commented on COCOON3-64: --- I've just committed all the modifications involved with issue COCOON3-64: I've ported the i18NTransformer in cocoon-sax (since no additional dependencies are involved), added some unit tests and some sitemap samples in cocoon-sitemap. Some remarks: 1. With respects to comments into COCOON3-64, I've NOT ported all the classes from the trunk, but only the transformer: in particular, I thought - at least from the moment - not to consider XML catalogs but to use instead standard JDK ResourceBundle, much like other frameworks - namely Wicket - are doing. 2. This porting is for C3 only, even though I think it could be quit easily adaptable to C2.2 as well. 3. I've taken as reference for writing unit tests the old but still well written [1]: I think we should enclose something similar in C3 documentation. 4. In C2.1 there used to be a type attribute, already deprecated in some situations like as i18n:param type=date pattern=dd-MMM-yy / C3 I18NTransformer does not consider such situations at all; the sample above becomes - like it also used to be in C2.1 i18n:parami18n:date pattern=dd-MMM-yy //i18n:param 5. I needed to port ParamSAXBuffer extending SAXBuffer (from cocoon-xml): for the moment I put its source in cocoon-sax, but of course the right place would be in cocoon-xml, so how could we handle this? Can I move that class to cocoon-xml's? In which SVN place? And how can we release a SNAPSHOT version of this subproject? Regards. [1] https://cocoon.apache.org/2.1/userdocs/i18nTransformer.html i18n support Key: COCOON3-64 URL: https://issues.apache.org/jira/browse/COCOON3-64 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-pipeline, cocoon-sax, cocoon-servlet, cocoon-sitemap Affects Versions: 3.0.0-alpha-3 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Cocoon 3 would take benefit from having a complete i18n support, possibly porting the 2.1 I18NTransformer. We would also need some sitemap, pipeline and servlet integration and, of course, an overlook should also be considered towards the cocoon-wicket integration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [2.1] Future of Cocoon 2.1.x... again :)
On 11/08/2011 15:36, Cédric Damioli wrote: Hi Cocoon team, A little more than one year ago, I sent a mail [1] to this list, to get feedbacks about usage of Cocoon 2.1.x, 3 years after the last release. I must admit that I received many more answers (privately and publicly on the list) than I could have expected first. This proved me the vitality of the 2.1.x community. So I began to open some tickets [2] [3] [4] [5] [6] [7] and provide some patches gathered during the last years on my projects, but unfortunately, I received nearly no feedback from committers around here. Is there still any interest from devs for the 2.1.x branch ? Could someone review the patches ? I obviously volunteer to help, to stop having to run dozen apps with a patched Cocoon. Has someone interest to prepare and schedule a 2.1.12 maintenance release ? Hi Cédric, some of my e-mails are part of your thread [1], and here I come again :-) In the meanwhile we dismissed our Cocoon 2.1 applications and we are moving everything to Cocoon 3: even though not mature, looks more promising, Anyway, I am not that familiar with C2.1 ant-based build process, so I don't think I can help you at all. Devs, is there anyone still familiar with C2.1 build? Regards. [1] http://markmail.org/thread/hizllvbjdeurr2de [2] https://issues.apache.org/jira/browse/COCOON-2288, allow to use SLF4J [3] https://issues.apache.org/jira/browse/COCOON-2307, bug in the ResourceReader [4] https://issues.apache.org/jira/browse/COCOON-2309, possible bug with SitemapSource under certain circumstances [5] https://issues.apache.org/jira/browse/COCOON-2310, XHTMLSerializer from serializers block does not handle HTML5 [6] https://issues.apache.org/jira/browse/COCOON-2313, subclassing of org.apache.cocoon.Cocoon [7] https://issues.apache.org/jira/browse/COCOON-2314, override upload params in CocoonServlet -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (COCOON3-64) i18n support
[ https://issues.apache.org/jira/browse/COCOON3-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083200#comment-13083200 ] Hudson commented on COCOON3-64: --- Integrated in Cocoon-trunk #51 (See [https://builds.apache.org/job/Cocoon-trunk/51/]) COCOON3-64 #resolve ilgrosso : http://svn.apache.org/viewvc/?view=revrev=1156644 Files : * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n/base_it.properties * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n/base_en.properties * /cocoon/cocoon3/trunk/cocoon-sample/src/main/resources/COB-INF/i18n/base_it.properties * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n/formatting.xml * /cocoon/cocoon3/trunk/cocoon-sample/src/main/resources/COB-INF/i18n/base_en.properties * /cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/xml/sax * /cocoon/cocoon3/trunk/cocoon-sample/src/main/resources/COB-INF/overview.html * /cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/util/VariableExpressionTokenizer.java * /cocoon/cocoon3/trunk/cocoon-sitemap/src/main/resources/META-INF/cocoon/spring/cocoon-pipeline-component.xml * /cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/LogAsXMLTransformerTestCase.java * /cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/xml/sax/ParamSAXBuffer.java * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n/translate_en.properties * /cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/xml * /cocoon/cocoon3/trunk/cocoon-sample/rcl-config/WEB-INF/classes/logback.xml * /cocoon/cocoon3/trunk/cocoon-sample/src/main/resources/COB-INF/sitemap.xmap * /cocoon/cocoon3/trunk/cocoon-sample/src/main/resources/COB-INF/i18n * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n/base.xml * /cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/I18nTransformer.java * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n/translate_de.properties * /cocoon/cocoon3/trunk/cocoon-sample/src/main/resources/COB-INF/i18n/base.xml * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n/formatting_en.properties * /cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/I18NTransformerTest.java * /cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/component/LinkRewriterTransformerTest.java * /cocoon/cocoon3/trunk/cocoon-sax/src/test/resources/i18n/translate.xml i18n support Key: COCOON3-64 URL: https://issues.apache.org/jira/browse/COCOON3-64 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-pipeline, cocoon-sax, cocoon-servlet, cocoon-sitemap Affects Versions: 3.0.0-alpha-3 Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Cocoon 3 would take benefit from having a complete i18n support, possibly porting the 2.1 I18NTransformer. We would also need some sitemap, pipeline and servlet integration and, of course, an overlook should also be considered towards the cocoon-wicket integration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
