Parent POM subprojects
Hi all, we have recently moved some subprojects to new location [1]: as part of this process, I've also made a new version (9-SNAPSHOT) of cocoon-parent [2] in order to update some items, including reference to latest Apache parent POM. Original 2.2 modules from trunk are linked to cocoon-parent 6-SNAPSHOT. Now I would like to start applying patches provided over time for subprojects and eventually also make a release of these, but I need first to release cocoon-parent 9. If you take a look at [2], you'll see that there is an assembly.xml; the original version [3] (i.e. the one from cocoon-parent 8) isn't valid any more for assembly plugin: once fixed this, assembly execution is still failing [INFO] --- maven-assembly-plugin:2.3:assembly (default-cli) @ cocoon --- [WARNING] The following patterns were never triggered in this artifact exclusion filter: o 'org.apache.cocoon:cocoon-webapp' o 'org.apache.cocoon:cocoon-deployer-minimal-webapp' o 'org.apache.cocoon:cocoon-dists-modules' [WARNING] The following patterns were never triggered in this artifact inclusion filter: o 'org.apache.cocoon:cocoon-webapp' [WARNING] The following patterns were never triggered in this artifact exclusion filter: o 'org.apache.cocoon:cocoon-webapp' o 'org.apache.cocoon:cocoon-deployer-minimal-webapp' o 'org.apache.cocoon:cocoon-dists-modules' [WARNING] NOTE: Currently, inclusion of module dependencies may produce unpredictable results if a version conflict occurs. [WARNING] The following patterns were never triggered in this artifact inclusion filter: o 'org.apache.cocoon:cocoon-webapp' [WARNING] NOTE: Currently, inclusion of module dependencies may produce unpredictable results if a version conflict occurs. [INFO] [INFO] BUILD FAILURE For the moment I've just disabled the assembly plugin, but I'd like to know if anyone remembers the original purpose of such assembly.xml or whether we can just get rid of it. Thanks. Regards. [1] https://svn.apache.org/repos/asf/cocoon/subprojects/ [2] https://svn.apache.org/repos/asf/cocoon/trunk/parent [3] https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon/cocoon-8/assembly.xml -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Javier Puerto as cocoon committer
+1 On 28 May 2012 10:26, Thorsten Scherler thors...@apache.org wrote: Hello all, I propose Javier Puerto as a new Cocoon committer and PMC member. I am working with Javier since over 5 years now in different teams for different clients. Our projects include all version of cocoon and he contributed many qualified patches over the years. He is an ASF committer in Apache Droids and I think he would make a great addition to our team. He contributes now on a regular base and lately as well started to dig into many issues that are critical for the c3 release. That shows that his interest in Cocoon is longer-term. This vote ends one week from today, i.e. midnight UTC on Sunday 2012-06-04 Please cast your votes. -- Thorsten Scherlerthorsten.at.apache.**org http://thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
RE: [VOTE] Javier Puerto as cocoon committer
+1 Cheers, Alfred. -Original Message- From: Thorsten Scherler [mailto:thors...@apache.org] Sent: Montag, 28. Mai 2012 10:26 To: dev@cocoon.apache.org Subject: [VOTE] Javier Puerto as cocoon committer I propose Javier Puerto as a new Cocoon committer and PMC member. Connect to our new co-location service and benefit from the low latency and high capacity of X-stream INET by Nasdaq OMX, the worlds most advanced trading technology. www.six-swiss-exchange.com/trading The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this email immediately. Thank you.
[jira] [Closed] (COCOON3-69) Replace the logging framework with SLF4J + Logback
[ https://issues.apache.org/jira/browse/COCOON3-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò closed COCOON3-69. - Resolution: Fixed Fix Version/s: 3.0.0-beta-1 Replace the logging framework with SLF4J + Logback -- Key: COCOON3-69 URL: https://issues.apache.org/jira/browse/COCOON3-69 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-controller, cocoon-monitoring, cocoon-optional, cocoon-pipeline, cocoon-profiling, cocoon-rest, cocoon-sample, cocoon-sample-webapp, cocoon-sax, cocoon-servlet, cocoon-sitemap, cocoon-stax, cocoon-stringtemplate Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 3.0.0-beta-1 See the mail thread on dev ML at http://comments.gmane.org/gmane.text.xml.cocoon.devel/81149. Be also sure to check http://pmd.sourceforge.net/rules/logging-java.html, otherwise Sonar will blame Cocoon code's quality even more ;-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-69) Replace the logging framework with SLF4J + Logback
[ https://issues.apache.org/jira/browse/COCOON3-69?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13284784#comment-13284784 ] Hudson commented on COCOON3-69: --- Integrated in Cocoon-trunk #183 (See [https://builds.apache.org/job/Cocoon-trunk/183/]) [COCOON3-69] Removing LogbackConfigurator (moved to cocoon-spring-configurator) (Revision 1343691) Result = SUCCESS ilgrosso : http://svn.apache.org/viewvc/?view=revrev=1343691 Files : * /cocoon/cocoon3/trunk/cocoon-servlet/src/main/java/org/apache/cocoon/spring Replace the logging framework with SLF4J + Logback -- Key: COCOON3-69 URL: https://issues.apache.org/jira/browse/COCOON3-69 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-controller, cocoon-monitoring, cocoon-optional, cocoon-pipeline, cocoon-profiling, cocoon-rest, cocoon-sample, cocoon-sample-webapp, cocoon-sax, cocoon-servlet, cocoon-sitemap, cocoon-stax, cocoon-stringtemplate Reporter: Francesco Chicchiriccò Assignee: Francesco Chicchiriccò Fix For: 3.0.0-beta-1 See the mail thread on dev ML at http://comments.gmane.org/gmane.text.xml.cocoon.devel/81149. Be also sure to check http://pmd.sourceforge.net/rules/logging-java.html, otherwise Sonar will blame Cocoon code's quality even more ;-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (COCOON-2320) CachingServletServiceSerializer
[ https://issues.apache.org/jira/browse/COCOON-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Chicchiriccò reassigned COCOON-2320: -- Assignee: (was: Francesco Chicchiriccò) Sorry, I thought issue (and provided patch) were about cocoon-servlet-service-impl, used by either C2.2 and C3 but only now I see that instead they are related to cocoon-servlet-service-components (C2.2 only). CachingServletServiceSerializer --- Key: COCOON-2320 URL: https://issues.apache.org/jira/browse/COCOON-2320 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core, - Servlet service framework Affects Versions: 2.2-dev (Current SVN) Reporter: Javier Puerto Priority: Minor Attachments: CachingServletServiceSerializer.patch Hello Cocoon developers, We are using Apache Cocoon 2.2 for a project and I've found a bottleneck in our template system. We use servlet service components to render our pages in the same way you can see for Style Block. The current Cocoon Welcome block is an example. This way of rendering is very useful but as currently the servlet services components doesn't implement CacheableServiceComponent interface, all the request will be processed completely at the end. For our usecase, here is an example: map:match pattern=x map:generate ... map:transform ... map:include ... map:serialize type=servletService map:parameter name=service value=servlet:style:/service/common/simple-page2html/ /map:serialize /map:match The most expensive part is the serialization process because we use i18n, Link rewriter and some transformations. We can configure everything to be cacheable but at the end, the serialization process must be performed entirely. I've simply extended the current ServletServiceSerializer in CachingServletServiceSerializer adding the cache key as requested service URL and NOPValidity as validity object. This approach has a problem, due to the nature of the servlet service components we need to move all the dynamically generated content from our GUI block since if we detect that the content hasn't changed, the CachingServletServiceSerializer will not perform any process and will return the cached content. Also, as there's a little hack for serializer output mime type, if you want to use the new component you must set the serialization content type explicitly. See http://article.gmane.org/gmane.text.xml.cocoon.devel/73261 map:match pattern=x map:generate ... map:transform ... map:include ... map:serialize type=caching-servletService mime-type=text/html map:parameter name=service value=servlet:style:/service/common/simple-page2html/ /map:serialize /map:match For our usecase seems to fit well and will allow us to enable the powerful cocoon caching system for a lot of pages. IMO, it's a problem when you want to use the ServletServiceSerializer to have a clean and common output for the template system and you can't use the caching even with static files. Attached is the patch for cocoon-servlet-service-components block. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: cocoon-spring-configurator issue
On 29/02/2012 08:29, Reinhard Pötz wrote:
On 02/28/2012 09:59 PM, Leszek Gawron wrote:
[...]
What I actually did was the easiest solution of all:
/**
* @see
org.springframework.beans.factory.config.PropertyPlaceholderConfigurer#processProperties(org.springframework.beans.factory.config.ConfigurableListableBeanFactory,
* java.util.Properties)
*/
protected void processProperties( ConfigurableListableBeanFactory
beanFactoryToProcess, Properties props ) throws BeansException {
super.processProperties( beanFactoryToProcess,
new SettingsProperties( this.settings ) );
}
and @Value works as expected. Still I am not aware if the original
solution was a mistake or was thought out for some other use case.
If noone objects I'd like to commit my change.
Go ahead! I will test with our projects in order to give feedback
about unwanted side effects.
After testing that C3 build wasn't affected by this change, I've just
committed the change provided [1].
Regards.
[1]
http://svn.apache.org/viewvc/cocoon/subprojects/cocoon-spring-configurator/trunk/src/main/java/org/apache/cocoon/spring/configurator/impl/AbstractSettingsBeanFactoryPostProcessor.java?rev=1343741r1=1343740r2=1343741view=diff
--
Francesco Chicchiriccò
ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/
