Re: Improved C3 infrastructure
On 06/30/2011 05:31 PM, Francesco Chicchiriccò wrote: On 30/06/2011 17:25, Simone Tripodi wrote: Hi all guys, we now have new terrific toys available for C3 :) * Sonar - https://analysis.apache.org/dashboard/index/org.apache.cocoon.root:cocoon-root * Nexus - https://repository.apache.org/content/repositories/snapshots/org/apache/cocoon/ * Jenkins - https://builds.apache.org/job/Cocoon-trunk/ See http://www.apache.org/dev/publishing-maven-artifacts.html for more infos how to configure your settings.xml to deploy on Nexus (the Jenkins job should do it for us). I already uploaded the beta-1-snapshot just to test it. Parent POM already updated, have fun!!! Great job, Simone, well done! +1! -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
RE: Does ValidatingTransformer support DTD validation
Hi David, yes it is and i tested it yesterday without any luck by the way. I am going to test some of my existing use cases with #cocoon3 in the next few days. I think it will be much easier for me to walk through the code as it is much leaner and meaner. Robby -Oorspronkelijk bericht- Van: David Crossley [mailto:cross...@apache.org] Verzonden: vr 1-7-2011 2:53 Aan: dev@cocoon.apache.org Onderwerp: Re: Does ValidatingTransformer support DTD validation Robby Pelssers wrote: Hi David, One thing I still need to investigate was Jeroen's reply: Hi Robby, have you checked this page [1]? I'm not sure if this is the same component, but is might lead you further. [1] http://wiki.apache.org/cocoon/ValidationTransformer Jeroen I checked that (probably somewhat deprecated) documentation but i noticed something that could be usefull: map:transform type='validate' src='validation/xhtml1-transitional.dtd' map:parameter name='active' value='true'/ !-- this part -- /map:transform If i find some time this week I will check if setting that 'active' parameter to true does any good unless you beat me to it ;-) This is a different component to the Transformer that is in Cocoon SVN. -David winmail.dat
[C3] Passing parameters from sitemap to generator
Hi all, recently I have been in the situation for which I need to parametrize an XML file of my application; I thought there was a simpler way but I ended up by using an additional XSLT transformation step (since the XSLTTransformer can accep parameters from the pipeline). With C2.1 I used to put in place the JXGenerator [1] (or JXTransformer [2] depending on the case): this saved me, in many cases, from an additional transformation step in the pipeline. Even though it is true that everything you could do with JXGenerator can always be done with XMLGenerator + XSLTTransformer, do you think that such component can be a nice to have in C3? Cheers. [1] http://cocoon.apache.org/2.1/userdocs/jx-generator.html [2] http://cocoon.apache.org/2.1/userdocs/jx-template-transformer.html -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: [C3] Passing parameters from sitemap to generator
Hi, JXGenerator is really useful, its a must have for me. Thomas Am 01.07.2011 10:25, schrieb Francesco Chicchiriccò: Hi all, recently I have been in the situation for which I need to parametrize an XML file of my application; I thought there was a simpler way but I ended up by using an additional XSLT transformation step (since the XSLTTransformer can accep parameters from the pipeline). With C2.1 I used to put in place the JXGenerator [1] (or JXTransformer [2] depending on the case): this saved me, in many cases, from an additional transformation step in the pipeline. Even though it is true that everything you could do with JXGenerator can always be done with XMLGenerator + XSLTTransformer, do you think that such component can be a nice to have in C3? Cheers. [1] http://cocoon.apache.org/2.1/userdocs/jx-generator.html [2] http://cocoon.apache.org/2.1/userdocs/jx-template-transformer.html
Re: [C3] Passing parameters from sitemap to generator
On 07/01/2011 10:25 AM, Francesco Chicchiriccò wrote: Hi all, recently I have been in the situation for which I need to parametrize an XML file of my application; I thought there was a simpler way but I ended up by using an additional XSLT transformation step (since the XSLTTransformer can accep parameters from the pipeline). With C2.1 I used to put in place the JXGenerator [1] (or JXTransformer [2] depending on the case): this saved me, in many cases, from an additional transformation step in the pipeline. Even though it is true that everything you could do with JXGenerator can always be done with XMLGenerator + XSLTTransformer, do you think that such component can be a nice to have in C3? So far there is only the StringTemplateGenerator component, that dynamically generates XML based on a template. There are also no 'build-in' objects like request, session, etc. which were supported by the JXGenerator or the VelocityGenerator in Cocoon 2.x I have no strong opinion on what should be migrated to C3 as long as it goes into a new module or the cocoon-optional module ;-) I suggest that you choose that technology that fits your requirements and your time constraints (VelocityGenerator should be rather straight forward, migrating JX* is definitly more-timeconsuming) best. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [C3] Passing parameters from sitemap to generator
Hi,
Maybe the Generator is sufficient?
To pass parameters from the sitemap is not it is not a big deal.
What sort of parameters do you want? Parts of the path?
controlStuff{tat}/{tit}/{tot}
request parameters?
Kind regards,
Jos
On 07/01/2011 10:33 AM, Thomas Markus wrote:
Hi,
JXGenerator is really useful, its a must have for me.
Thomas
Am 01.07.2011 10:25, schrieb Francesco Chicchiriccò:
Hi all,
recently I have been in the situation for which I need to parametrize
an XML file of my application; I thought there was a simpler way but
I ended up by using an additional XSLT transformation step (since the
XSLTTransformer can accep parameters from the pipeline).
With C2.1 I used to put in place the JXGenerator [1] (or
JXTransformer [2] depending on the case): this saved me, in many
cases, from an additional transformation step in the pipeline.
Even though it is true that everything you could do with JXGenerator
can always be done with XMLGenerator + XSLTTransformer, do you think
that such component can be a nice to have in C3?
Cheers.
[1] http://cocoon.apache.org/2.1/userdocs/jx-generator.html
[2] http://cocoon.apache.org/2.1/userdocs/jx-template-transformer.html
[ANNOUNCE] Apache Cocoon 3.0.0-alpha-3 released!
The Apache Cocoon 3 team is pleased to announce the Apache Cocoon 3.0.0-alpha-3 release! 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 slimed 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 webservices and web applications. Changes in this version include: New features: o [cocoon-sax] Added the SAX Pipeline DSL o [cocoon-pipeline] Added the Pipeline DSL o [cocoon-rest] Add the interface o.a.c.rest.controller.method.ConditionalGet. It requires the implementation of the method #constructCacheKey() which returns a o.a.c.pipeline.caching.CacheKey. This cache key is used to support conditional GET requests based on the ETag header. o [cocoon-servlet] Add the method 'emulatedMethod()' to the request object. It supports the RubyOnRails way of sending an alternative HTTP method to the server in cases where only GET and POST work reliably. The method returns either the value of the request parameter '_method' or if not available, the actually used HTTP method. In future versions of Cocoon this behavior might become the default behavior of Cocoon. Fixed Bugs: o [cocoon-sax] The org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGenerator is incomplete. Issue: COCOON3-58. o [cocoon-sax] Add the LogAsXMLTransformer, prints out the complete XML document; useful for debugging. Issue: COCOON3-57. o [cocoon-sax][cocoon-sitemap] The LinkRewriter Transformer needs to be integrated in the sitemap. Issue: COCOON3-56. o [cocoon-sax][cocoon-sitemap] The XInclude Transformer needs to be integrated in the sitemap. Issue: COCOON3-55. o [cocoon-sax] Added the LinkRewriterTransformer component. Issue: COCOON3-54. o [cocoon-pipeline] XMLSerializer caches all. Issue: COCOON3-53. o [cocoon-sax] XMLSerializer setup method resets output method to xml. Issue: COCOON3-52. o [cocoon-sax] XIncludeTransformer was sending extra startDocument and endDocument events. Issue: COCOON3-51. o [cocoon-sax] SAXException related to endPrefixMapping in XIncludeTransformer. Issue: COCOON3-50. o [cocoon-stringtemplate] Upgrade to latest version of StringTemplate. Issue: COCOON3-44. o [cocoon-pipeline] Add the timestamp value to the TimestampCacheKey hashcode. Changes: o [cocoon-sax] XSLTTransformer and SchemaProcessorTransformer created resources have been cached. o [cocoon-controller] The o.a.c.controller.SpringControllerComponent became a CachingPipelineComponent. For that purpose the controller invocation was separated into a setup and an execution phase. If the controller provides a cache key after the setup, this is returned by the SpringControllerComponent and the pipeline that embeds the controllers becomes cacheable. o [all] Upgrade to cocoon-jnet-1.2.0 o [all] Upgrade all modules that have a dependency on Spring version 3.0.5.RELEASE Have fun! -Simo, on behalf of Apache Cocoon 3 team http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [C3] Passing parameters from sitemap to generator
On 01/07/2011 11:34, Jos Snellings wrote:
Hi,
Maybe the Generator is sufficient?
To pass parameters from the sitemap is not it is not a big deal.
What sort of parameters do you want? Parts of the path?
controlStuff{tat}/{tit}/{tot}
This was exactly my scenario: I am writing a (kind of) JCR generator
that reads from a Jackrabbit repository depending on (sub) request path.
request parameters?
This could also be the case.
Kind regards,
Jos
On 07/01/2011 10:33 AM, Thomas Markus wrote:
Hi,
JXGenerator is really useful, its a must have for me.
Thomas
Am 01.07.2011 10:25, schrieb Francesco Chicchiriccò:
Hi all,
recently I have been in the situation for which I need to
parametrize an XML file of my application; I thought there was a
simpler way but I ended up by using an additional XSLT
transformation step (since the XSLTTransformer can accep parameters
from the pipeline).
With C2.1 I used to put in place the JXGenerator [1] (or
JXTransformer [2] depending on the case): this saved me, in many
cases, from an additional transformation step in the pipeline.
Even though it is true that everything you could do with JXGenerator
can always be done with XMLGenerator + XSLTTransformer, do you think
that such component can be a nice to have in C3?
Cheers.
[1] http://cocoon.apache.org/2.1/userdocs/jx-generator.html
[2] http://cocoon.apache.org/2.1/userdocs/jx-template-transformer.html
--
Francesco Chicchiriccò
Apache Cocoon Committer and PMC Member
http://people.apache.org/~ilgrosso/
Re: [C3] Passing parameters from sitemap to generator
On 01/07/2011 11:29, Reinhard Pötz wrote: On 07/01/2011 10:25 AM, Francesco Chicchiriccò wrote: Hi all, recently I have been in the situation for which I need to parametrize an XML file of my application; I thought there was a simpler way but I ended up by using an additional XSLT transformation step (since the XSLTTransformer can accep parameters from the pipeline). With C2.1 I used to put in place the JXGenerator [1] (or JXTransformer [2] depending on the case): this saved me, in many cases, from an additional transformation step in the pipeline. Even though it is true that everything you could do with JXGenerator can always be done with XMLGenerator + XSLTTransformer, do you think that such component can be a nice to have in C3? So far there is only the StringTemplateGenerator component, that dynamically generates XML based on a template. How long should it be to add sitemap parameter handling there? There are also no 'build-in' objects like request, session, etc. which were supported by the JXGenerator or the VelocityGenerator in Cocoon 2.x I have no strong opinion on what should be migrated to C3 as long as it goes into a new module or the cocoon-optional module ;-) Eh eh, I knew that :-) I suggest that you choose that technology that fits your requirements and your time constraints (VelocityGenerator should be rather straight forward, migrating JX* is definitly more-timeconsuming) best. As far as the sitemap parameter handling part is viable, the VelocityGenerator could be fine. Cheers. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Publishing the C3 javadocs
On 07/01/2011 11:26 AM, simonetrip...@apache.org wrote: Author: simonetripodi Date: Fri Jul 1 09:26:08 2011 New Revision: 1141888 URL: http://svn.apache.org/viewvc?rev=1141888view=rev Log: described how to release apidocs Modified: cocoon/cocoon3/trunk/RELEASE_HOWTO.txt Modified: cocoon/cocoon3/trunk/RELEASE_HOWTO.txt URL: http://svn.apache.org/viewvc/cocoon/cocoon3/trunk/RELEASE_HOWTO.txt?rev=1141888r1=1141887r2=1141888view=diff == --- cocoon/cocoon3/trunk/RELEASE_HOWTO.txt (original) +++ cocoon/cocoon3/trunk/RELEASE_HOWTO.txt Fri Jul 1 09:26:08 2011 @@ -1,8 +1,6 @@ HOWTO RELEASE COCOON 3: Preparations -Note: The Cocoon release process still uploads the artifacts to people.apache.org:/x1/www/people.apache.org/builds/cocoon/ This should be changed to use the Apache Nexus installation - * check your workstation's settings as described at http://cocoon.apache.org/1199_1_1.html (step 1) * update src/main/changes/changes.xml and src/main/site/apt/download.apt in the 'cocoon-docs' module @@ -62,11 +60,19 @@ HOWTO RELEASE COCOON 3: After a successf and call 'svn up'. - -* update the website * upload the Javadocs + That's a manual operation, once created the release package, compress the + + cocoon-all/target/apidocs + + Then upload the compressed file on p.a.o: + +scp apidocs.zip asfusername@p.a.o:/x1/www/cocoon.apache.org/3.0 + + Then login on remote machine and decompress + FYI: The javadocs are also added to the distribution artifacts and automatically contain the correct version number. -- Reinhard Pötz Founder Managing Director, Indoqa and Deepsearch http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org Furthermore, I think Oracle has to honor the JSPA agreement. http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
[C3] Build warnings from duplicate javacc-maven-plugin definition
[Cocoon trunk, SVN 1131615] There are two identical plugin definitions in parent/pom.xml: ... plugin groupIdorg.codehaus.mojo/groupId artifactIdjavacc-maven-plugin/artifactId version2.6/version /plugin ... plugin groupIdorg.codehaus.mojo/groupId artifactIdjavacc-maven-plugin/artifactId version2.6/version /plugin ... Maven complains during the build: [WARNING] Some problems were encountered while building the effective model for org.apache.cocoon.parent:cocoon-parent:pom:3.0.0-beta-1-SNAPSHOT [WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.codehaus.mojo:javacc-maven-plugin @ line 713, column 17 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. -Hugh Sparks
Re: [C3] Build warnings from duplicate javacc-maven-plugin definition
On 01/07/2011 14:50, Hugh Sparks wrote: [Cocoon trunk, SVN 1131615] There are two identical plugin definitions in parent/pom.xml: ... plugin groupIdorg.codehaus.mojo/groupId artifactIdjavacc-maven-plugin/artifactId version2.6/version /plugin ... plugin groupIdorg.codehaus.mojo/groupId artifactIdjavacc-maven-plugin/artifactId version2.6/version /plugin ... Maven complains during the build: [WARNING] Some problems were encountered while building the effective model for org.apache.cocoon.parent:cocoon-parent:pom:3.0.0-beta-1-SNAPSHOT [WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be unique but found duplicate declaration of plugin org.codehaus.mojo:javacc-maven-plugin @ line 713, column 17 [WARNING] [WARNING] It is highly recommended to fix these problems because they threaten the stability of your build. [WARNING] [WARNING] For this reason, future Maven versions might no longer support building such malformed projects. I should have corrected most of these warnings right now (revision 1141927). -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Cocoon 3 and XML DB API
Just wanted to share that i'll be diving into Cocoon3 as well in the next few months. And i'll share my experience starting today: http://robbypelssers.blogspot.com/2011/07/cocoon-30-and-xml-db-api.html Kind regards, Robby
Re: Cocoon 3 and XML DB API
You should start contributing Robby!!! :) Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jul 1, 2011 at 4:23 PM, Robby Pelssers robby.pelss...@ciber.com wrote: Just wanted to share that i'll be diving into Cocoon3 as well in the next few months. And i'll share my experience starting today: http://robbypelssers.blogspot.com/2011/07/cocoon-30-and-xml-db-api.html Kind regards, Robby
