Re: [jira] Closed: (COCOON3-2) Add an XSchema Validator as PipeLineComponent
Hi Reinhard, Hi Steven (and nice to meet you) is there a way I can help you to close the issue related to the FIXME in /cocoon/cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/component/sax/SchemaProcessorTransformer.java Best regards, Simone 2008/10/9 Reinhard Poetz (JIRA) [EMAIL PROTECTED]: [ https://issues.apache.org/jira/browse/COCOON3-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Reinhard Poetz closed COCOON3-2. Resolution: Fixed The SchemaErrorHandler throws a specific unchecked exception (SchemaValidationException) when the XML is invalid now. Add an XSchema Validator as PipeLineComponent - Key: COCOON3-2 URL: https://issues.apache.org/jira/browse/COCOON3-2 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-pipeline Affects Versions: 3.0.0-alpha-2 Reporter: Simone Tripodi Assignee: Reinhard Poetz Priority: Minor Fix For: 3.0.0-alpha-2 Attachments: XSchemaProcessor.patch XSchema Validation can be performed as an Identity Transformer where the input will be filter by the XSchema validation. An error occurs - and the pipeline will be break - when the input is not valid against the declared XML Schema. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- My LinkedIn profile: http://www.linkedin.com/in/simonetripodi My GoogleCode profile: http://code.google.com/u/simone.tripodi/ My Picasa: http://picasaweb.google.com/simone.tripodi/ My Tube: http://www.youtube.com/user/stripodi My Del.icio.us: http://del.icio.us/simone.tripodi
Re: [jira] Closed: (COCOON3-2) Add an XSchema Validator as PipeLineComponent
Hi Reinhard, Steven,
sorry if I'm a little late but I had some work to do. In attach on the
COCOON3-2 Jira's issue you can find the patch we need.
Just a small note: in way to run the example, Jetty replied on port
instead of 8190 as wrote in the README.
I hope that's all useful.
Best regards!!!
Simone
2008/10/10 Reinhard Pötz [EMAIL PROTECTED]:
Simone Tripodi wrote:
Hi Reinhard, Hi Steven (and nice to meet you)
is there a way I can help you to close the issue related to the FIXME in
/cocoon/cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/component/sax/SchemaProcessorTransformer.java
Yes, very appreciated.
If you want to use the SchemaProcessorTransformer in a sitemap, you have
to provide a default constructor and implement the setConfiguration()
method which gives the component access to all sitemap parameters. (e.g.
see the FileGenerator).
The 'cocoon-sample' module should give you an idea how you can define a
pipeline in a sitemap. If you haven't run the 'cocoon-sample' module
yet, see the README.txt in the root directory of Cocoon 3.
If this doesn't answer all your questions, just let us know.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
[COCOON3] cocoon-optional is missing in Jira
Hi everybody, just to notify you that cocoon-optional is missing in cocoons Jira; I've a patch to submit but before I need to create the issue in the right place. Thanks in advance, best regards, Simone
Re: [COCOON3] cocoon-optional is missing in Jira
My pleasure Reinhard!!!
2008/10/14 Reinhard Pötz [EMAIL PROTECTED]:
Simone Tripodi wrote:
Hi everybody,
just to notify you that cocoon-optional is missing in cocoons Jira;
I've a patch to submit but before I need to create the issue in the
right place.
done and thanks for spotting1
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
[COCOON3] XSLTTransformer optimization and reusability
Hi Reinhard/everybody, I would like to argue with you some simple point about the org.apache.cocoon.pipeline.component.sax.XSLTTransformer, sharing ideas and collecting feedbacks. Note: my attention is focused more just on the basic pipeline API use, the test case (mine!!!) is the case where a developer is programming an application based only on the pipeline - eventually the optional components; by the way, what I'm going to expose doesn't want to be incompatible with the Sitemap, etc. 1) Optimization: *every time* the XSLTTransformer#setXMLConsumer method is called, the XSLT is parsed reading the URL source and used to create the javax.xml.transform.sax.TransformerHandler: to be more clear [...] XSLTTransformer xsltTransformer = new XSLTTransformer(getClass().getResource(myXSLT.xsl)); Pipeline pipeline1 = new NonCachingPipeline(); pipeline1.addComponent(new StringGenerator(xy//x)); pipeline1.addComponent(xsltTransformer); pipeline1.addComponent(new XMLSerializer()); pipeline1.setup(System.out); pipeline1.execute(); Pipeline pipeline2 = new NonCachingPipeline(); pipeline2.addComponent(new StringGenerator(zw//z)); pipeline2.addComponent(xsltTransformer); == the URL pointed by getClass().getResource(myXSLT.xsl) will be parsed again!!! pipeline2.addComponent(new XMLSerializer()); pipeline2.setup(System.out); pipeline2.execute(); I'm sure we can do, even if small, a nice optimization's step, creating just once a javax.xml.transform.Templates (it have to be a Class' field) when the constructors or the XSLTTransformer#setConfiguration methods are called, then when the XSLTTransformer#setXMLConsumer method will be invoked the javax.xml.transform.sax.TransformerHandler can be created just invoking http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/transform/sax/SAXTransformerFactory.html#newTransformerHandler(javax.xml.transform.Templates) In my mind makes more sense reading the XSLT once, an org.apache.cocoon.pipeline.component.sax.XSLTTransformer instance should be reusable and it shouldn't read the same XSLT each time it has to perform a transformation. Please correct me if I'm wrong! 2) Reusability: this point is, in some way, correlated to previous, but the focus is on the missing XSLTTransformer#setParameters(MapString, Object parameters) method. At this time I can't reuse the same transformer whit different parameters because they can be set only by the constructor or by XSLTTransformer#setConfiguration method, but as we already know this method has much more sense to be used in the Sitemap... 3) Xalan's XSLTC compatibility: now the XSLTTransformer is not compatible with XSLTC because we don't have any way to pass attributes to the internal javax.xml.transform.TransformerFactory used to create the javax.xml.transform.sax.TransformerHandler. IMHO using the XSLTC is very useful in cases where the Transformation is really hard to perform! For instance, last week, using the Optimus' XSLT (http://microformatique.com/optimus/) through XSLTC I saved up about 4 seconds (!!!) in performing a single transformation, and that sounds GREAT!!! Ok I finish here, I don't want you get bored :) Please let me know and give me feedbacks, if you agree I'll open the Issues and I'm able to provide the needed patches. Have a nice day, best regards! Yours, Simone -- My LinkedIn profile: http://www.linkedin.com/in/simonetripodi My GoogleCode profile: http://code.google.com/u/simone.tripodi/ My Picasa: http://picasaweb.google.com/simone.tripodi/ My Tube: http://www.youtube.com/user/stripodi My Del.icio.us: http://del.icio.us/simone.tripodi
Re: [COCOON3] XSLTTransformer optimization and reusability
Hi Reinhard!!!
thank you for your reply!!!
I'll proceed working on all these small issues - and I'll provide the
patches ASAP :)
I'm sorry for my rather long response times (e.g. your
XIncludeTransformer stuff) but I'm very busy ATM. The
XIncludeTransformer will take me some time to review because I haven't
used it so far with Cocoon 2.x and I have to get familiar with the
XInclude and XPointer specs (at least to some extend).
Don't worry, I already though you're busy, you don't have anything to
be sorry :)
Take care, best regards,
Simone
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
Re: [COCOON3] XSLTTransformer optimization and reusability
Hi Reinhard, In my mind makes more sense reading the XSLT once, an org.apache.cocoon.pipeline.component.sax.XSLTTransformer instance should be reusable and it shouldn't read the same XSLT each time it has to perform a transformation. Please correct me if I'm wrong! no makes sense! See http://tinyurl.com/5hxbjp - this is the XSLTProcessorImpl that is used by Cocoon 2.x. It uses the Excalibur store to avoid the recreation of TransformerHandler objects. As a quick solution we can of course store the transformer handler objects in a static hashmap, but in the future we should introduce stores in Cocoon 3 too. As Sylvain and you suggested, I took a look on http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XSLTTransformer.java This trasformer, as reported in the Javadoc, is an adaptation of Excalibur's XSLTProcessor. As you wrote, one of the cocoon3-pipeline's main scopes is limit to 0 the dependencies (just the logging library), so I propose you 2 alternatives: 1) include dependencies where necessary; or 2) in the cocoon-pipeline, define a set of interfaces to manage XSLT's stores and reloaders, then include in the cocoon-pipeline simple basic implementations (adapters of HashMap for stores, Threads for reloaders), and include different implementations in cocoon-optional (adapters of Excalibur store for stores, Quartz http://www.opensymphony.com/quartz/ job for reloaders). We could include also a strategy similar to the commons-dicovery (commons.apache.org/discovery) to discover what kind of Store/Reloader have to be used. What do you think about it? Best regards, Simone
Re: [COCOON3] XSLTTransformer optimization and reusability
Hi Reinhard,
I'm sorry I was not very clear, as reloader I mean a sort of XSLT
watchdog that reload it when it's changed - it's a feature already
present in oldest Cocoon's version, Sylvain spoke about it in the Jira
issue
https://issues.apache.org/jira/browse/COCOON3-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641831#action_12641831
Best Regards, alles gute!
Simone
2008/10/24 Reinhard Pötz [EMAIL PROTECTED]:
Simone Tripodi wrote:
Hi Reinhard,
In my mind makes more sense reading the XSLT once, an
org.apache.cocoon.pipeline.component.sax.XSLTTransformer instance
should be reusable and it shouldn't read the same XSLT each time it
has to perform a transformation. Please correct me if I'm wrong!
no makes sense! See http://tinyurl.com/5hxbjp - this is the
XSLTProcessorImpl that is used by Cocoon 2.x. It uses the Excalibur
store to avoid the recreation of TransformerHandler objects.
As a quick solution we can of course store the transformer handler
objects in a static hashmap, but in the future we should introduce
stores in Cocoon 3 too.
As Sylvain and you suggested, I took a look on
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XSLTTransformer.java
This trasformer, as reported in the Javadoc, is an adaptation of
Excalibur's XSLTProcessor. As you wrote, one of the cocoon3-pipeline's
main scopes is limit to 0 the dependencies (just the logging library),
so I propose you 2 alternatives:
1) include dependencies where necessary;
or
2) in the cocoon-pipeline, define a set of interfaces to manage XSLT's
stores and reloaders, then include in the cocoon-pipeline simple basic
implementations (adapters of HashMap for stores, Threads for
reloaders), and include different implementations in cocoon-optional
(adapters of Excalibur store for stores, Quartz
http://www.opensymphony.com/quartz/ job for reloaders).
What do you mean by 'reloaders' in this context?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member [EMAIL PROTECTED]
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
Re: [C3] Imaging Module
Hi Steven,
that's really cool, I like it very much, confratulations!
The most important thing is IMHO the Pipeline APIs are adaptable to
build various kind of Pipeline not just SAX/XML... and that's great!
Thanks to share your work with us!
Best regards,
Simone
2009/1/14 Steven Dolg steven.d...@indoqa.com:
Hi,
I planned to come up with an Imaging Module for quite some time now.
There were several situations in some of the projects I worked on where such
a module would have been handy IMO.
I also thought this might serve as another example of how the Pipeline API
could be used.
I did not invest much time (only a couple of hours this afternoon) and I'm
actually not very versatile in using the Imaging API and/or Java2D.
So please don't blame me when the implementation of the transformations is
not ideal or not really fast.
(Actually if someone know how to implement some or all of those
manipulations better, I'd love to hear about that).
The transformers still miss alot of configuration possiblities (most of it
is simply hardwired) and are not really suited to be used in the Sitemap,
yet.
But I intend to continue working on this...
So far I created the following transformers:
* CropImageTransformer
Crops the image to an area of the configured size. The area is centered on
the image
* MaxSizeImageTransformer
Reduces the size of the image so that it fits inside the given dimensions.
The aspect ratio of the image is maintained. If the image already fits
inside the given bound it will remain unchanged.
*RotateImageTransformer
Rotates the whole image by a given amount. Any value is possible.
*ScaleImageTransformer
Scales the image by a given factor, maininting the aspect ratio.
*WatermarkImageTransformer
Write a configurable text centered on the image. Color and transparancy of
the text is configurable.
Additionally there is an ImageGenerator and an ImageSerializer.
Both ImageGenerator and ImageSerializer use the Imaging API of Java. So by
default the image formats JPG, PNG, GIF and BMP are supported (IIRC).
Additional formats may be supported by registering them with the Imaging
API.
All the components mentioned above a fully compatible to each other - and
not compatible to any other Cocoon 3 components currently available - and
the transformers can be combined in every way.
The basic rules of the PipelineAPI still apply of course (Generator -
Transformer* - Serializer)
I have provided a unit test that uses several pipelines using all
components.
Attached you can find the patch for the code and a sample image (in case you
have none handy).
The generator uses the URL mechanism already implemented in other generators
in Cocoon 3, so images can also be loaded directly from a web site or some
other location.
Regards,
Steven
Index:
cocoon-imaging/src/test/java/org/apache/cocoon/imaging/PipelineTest.java
===
--- cocoon-imaging/src/test/java/org/apache/cocoon/imaging/PipelineTest.java
(revision 0)
+++ cocoon-imaging/src/test/java/org/apache/cocoon/imaging/PipelineTest.java
(revision 0)
@@ -0,0 +1,130 @@
+package org.apache.cocoon.imaging;
+
+import java.io.File;
+import java.io.FileOutputStream;
+
+import org.apache.cocoon.imaging.components.CropImageTransformer;
+import org.apache.cocoon.imaging.components.MaxSizeImageTransformer;
+import org.apache.cocoon.imaging.components.RotateImageTransformer;
+import org.apache.cocoon.imaging.components.ScaleImageTransformer;
+import org.apache.cocoon.imaging.components.WatermarkImageTransformer;
+import org.apache.cocoon.pipeline.NonCachingPipeline;
+import org.apache.cocoon.pipeline.Pipeline;
+import org.junit.Test;
+
+public class PipelineTest {
+
+@Test
+public void writeUnchanged() throws Exception {
+Pipeline pipeline = new NonCachingPipeline();
+
+// just read and write the image without changing it
+// this might be used to change the image format, etc. as soon as
this is supported by the
+// ImageSerializer
+pipeline.addComponent(new ImageGenerator(new
File(src/test/resources/sample.JPG).toURI().toURL()));
+pipeline.addComponent(new ImageSerializer());
+
+FileOutputStream outputStream = new
FileOutputStream(target/unchanged.jpg);
+pipeline.setup(outputStream);
+pipeline.execute();
+outputStream.close();
+}
+
+@Test
+public void addWatermark() throws Exception {
+Pipeline pipeline = new NonCachingPipeline();
+
+pipeline.addComponent(new ImageGenerator(new
File(src/test/resources/sample.JPG).toURI().toURL()));
+// write the given text centered on the image, using the specified
color and alpha values
+pipeline.addComponent(new WatermarkImageTransformer(Cocoon 3
Imaging, 0xFF, 128));
+pipeline.addComponent(new ImageSerializer());
+
+
cocoon-sax test packages
Hi All, I noticed the cocoon-sax module implements tests referring to old cocoon-pipeline module, this should be the right taxonomy: org.apache.cocoon.pipeline.util.TransformationUtilsTest should be org.apache.cocoon.sax.util.TransformationUtilsTest --- org.apache.cocoon.pipeline.component.sax.SchemaProcessorTransformerTest should be org.apache.cocoon.sax.component.SchemaProcessorTransformerTest --- Nothing wrong or broke, but just to make more order. Hope this helps, best regards Simone -- http://www.google.com/profiles/simone.tripodi
Re: cocoon-sax test packages
Thanks Reinhard!
I just moved an issue liked to a wrong component, and then uploaded a
new patch for the XSLT, I hope this will be useful!
Best regards,
Simone
On Thu, Apr 30, 2009 at 11:14 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi All,
I noticed the cocoon-sax module implements tests referring to old
cocoon-pipeline module, this should be the right taxonomy:
org.apache.cocoon.pipeline.util.TransformationUtilsTest
should be
org.apache.cocoon.sax.util.TransformationUtilsTest
---
org.apache.cocoon.pipeline.component.sax.SchemaProcessorTransformerTest
should be
org.apache.cocoon.sax.component.SchemaProcessorTransformerTest
---
Nothing wrong or broke, but just to make more order.
Hope this helps, best regards
Thanks Simone! I've just checked in the refactored packages.
Btw, great to see you back!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Re: cocoon-sax test packages
Also cocoon-optional packages should be renamed, here you can find my
suggestions:
org.apache.cocoon.optional.pipeline.components.sax.betwixt ||
org.apache.cocoon.sax.components.betwixt
org.apache.cocoon.optional.pipeline.components.sax.fop ||
org.apache.cocoon.sax.components.fop
org.apache.cocoon.optional.pipeline.components.sax.neko ||
org.apache.cocoon.sax.components.neko
I don't see any need to specify the 'optional' keyword in the path,
but it's just my opinion ;)
Best regards!!!
Simone
On Thu, Apr 30, 2009 at 1:16 PM, Simone Tripodi
simone.trip...@gmail.com wrote:
Thanks Reinhard!
I just moved an issue liked to a wrong component, and then uploaded a
new patch for the XSLT, I hope this will be useful!
Best regards,
Simone
On Thu, Apr 30, 2009 at 11:14 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi All,
I noticed the cocoon-sax module implements tests referring to old
cocoon-pipeline module, this should be the right taxonomy:
org.apache.cocoon.pipeline.util.TransformationUtilsTest
should be
org.apache.cocoon.sax.util.TransformationUtilsTest
---
org.apache.cocoon.pipeline.component.sax.SchemaProcessorTransformerTest
should be
org.apache.cocoon.sax.component.SchemaProcessorTransformerTest
---
Nothing wrong or broke, but just to make more order.
Hope this helps, best regards
Thanks Simone! I've just checked in the refactored packages.
Btw, great to see you back!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
--
http://www.google.com/profiles/simone.tripodi
XInclude optimization
Hi all guys, I'm very sorry if I don't appear frequently on the ML but since April I've been working very hard for a customer client in Paris that don't let me some spare time to dedicate to OS projects. I'm writing because I'm sure the XInclude transformer I submitted time ago could be optimized, so I'd like to ask you a little help :) The state of the art is that, when including an entire document, it is processed efficiently through SAX APIs; the problem comes when processing a document referenced by xinclude+xpointer, that forces the processor to extract a sub-document of the included. To perform this, I implemented a DOM parsing, then through XPath I extract the sub-document the processor has to be included, then navigating the elements will be converted to SAX events. As you noticed, this takes time, too much IMO, but I didn't find/don't know any better solution :( Since you experienced the stax, maybe you're able to suggest me a fast way to parse a document with xpath and invoke SAX events, so I'm able to provide you a much better - and faster, above all - solution. Any hint? Every suggestion will be very appreciated. Thanks in adavance, best regards!!! Simone -- http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi Sylvain, thanks for your kind reply! I suspected the XPath limitations you explained very well, but deeply in my heart I was hoping to a solution I didn't know yet, for this reason I asked it :P :P I'll take a look at both the solutions, eve if the first sounds to me more compliant to the xpointer recommendation and at the same time closer with what I already did - and to older XInclude cocoon implementations. Thank you very much for your hints, very well appreciated :) A bientot! Simone P.S. Offtopic: maybe I'm wrong, but I'm sure we met once in Tolouse, I was one of the Asemantics juniors involved in Joost :P On Sun, Nov 22, 2009 at 3:27 PM, Sylvain Wallez sylv...@apache.org wrote: Simone Tripodi wrote: Hi all guys, I'm very sorry if I don't appear frequently on the ML but since April I've been working very hard for a customer client in Paris that don't let me some spare time to dedicate to OS projects. Don't be sorry. We all have our own jobs/interest/duties that have driven us away from Cocoon. Glad to see you back! I'm writing because I'm sure the XInclude transformer I submitted time ago could be optimized, so I'd like to ask you a little help :) The state of the art is that, when including an entire document, it is processed efficiently through SAX APIs; the problem comes when processing a document referenced by xinclude+xpointer, that forces the processor to extract a sub-document of the included. To perform this, I implemented a DOM parsing, then through XPath I extract the sub-document the processor has to be included, then navigating the elements will be converted to SAX events. As you noticed, this takes time, too much IMO, but I didn't find/don't know any better solution :( Since you experienced the stax, maybe you're able to suggest me a fast way to parse a document with xpath and invoke SAX events, so I'm able to provide you a much better - and faster, above all - solution. Any hint? Every suggestion will be very appreciated. The problem with XPath and XML streaming (be it SAX or StAX) is that XPath is a language that allows exploring the document tree in all directions and thus inherently expects having the whole document tree available, which is clearly not compatible with streaming. There are different approaches to solving this : - use a deferred loading DOM implementation, which buffers events only when it needs them to traverse the tree. Axiom [1] provides this IIRC, along with an XPath implementation. - restrain the XPointer expression to a subset of XPath that can easily be implemented on top of a stream. This means restricting selection only on the current element, its attribute and its ancestors. There's an implementation of this approach in Tika. The XInclude transformer can be smart enough to use the most efficient implementation for the given XPath expression, i.e. try to parse it with Tika's restricted subset, and fallback to something more costly, either Axiom or plain DOM. Sylvain [1] http://ws.apache.org/commons/axiom/ [2] https://svn.apache.org/repos/asf/lucene/tika/trunk/tika-core/src/main/java/org/apache/tika/sax/xpath/ -- Sylvain Wallez - http://bluxte.net -- http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi Jos, thanks for your reply, the XPath expression is already known before parsing the document since the XInclude processor catches the xpointer reference before including the document. I think your solution works but I've the suspect just for a limited subset of the XPath expressions, the exception comes when an expression contains siblings/parent references... What do you think about it? Best regards and thanks for your hint! Simone On Mon, Nov 23, 2009 at 7:12 AM, Jos Snellings jos.snelli...@pandora.be wrote: Hmmm, I guess the XPath expression is known before the parsing begins? I remember I have done a similar thing, where a chunk had to be isolated from a document that came by via a SAX stream, but here the xpath expression was something like: /element1/elemen...@id=somenumber]. Theorem: any XPath expression can be evaluated with a SAX filter. Proof? Do you know some exceptions? Jos -- http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi Sylvain, indeed, that's yet another exception I didn't think, thanks for your clarification!!! Bonne journée, a bientot ;) Simo On Mon, Nov 23, 2009 at 8:28 AM, Sylvain Wallez sylv...@apache.org wrote: Jos Snellings wrote: Hmmm, I guess the XPath expression is known before the parsing begins? I remember I have done a similar thing, where a chunk had to be isolated from a document that came by via a SAX stream, but here the xpath expression was something like: /element1/elemen...@id=somenumber]. Theorem: any XPath expression can be evaluated with a SAX filter. Proof? Do you know some exceptions? What about this one : //foo[bar[position() = 3]//baz], find all elements foo whose 3rd bar child has a baz descendent element. This requires to buffer the contents of every foo element to inspect their chidren sub-tree. Sylvain -- Sylvain Wallez - http://bluxte.net -- http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi Sylvain and Simone, thank you a lot, the suggestions you provided are all very very interesting, so I wonder now if it is possible to realize a processor able to use at the same time the Tika way when it recognizes some kind of paths, the XSL-on-the-fly for more complex cases. What do you think? Sylvain, I still haven't read the Tika documentation, can you just point me the related doc about this topic? Simo, did you already give a try about the XSLT generation on the fly? The most basic operation I thought is generating the XSL string by a template, then pass it to the XSL parser, but I'm sure it could be implemented in a better way :P Every suggestion will be very appreciated, thanks in advance Best regards, have a nice evening!!! Simone On Mon, Nov 23, 2009 at 7:16 PM, Sylvain Wallez sylv...@apache.org wrote: Simone Gianni wrote: Hi Simone and Sylvain, aren't XSLT transformers already SAX/Xpath optimized? I mean, an XSLT containing an XPath expression and used in a SAX context, isn't already able to resolve the XPath while keeping buffering at the minimum possible? I can clearly remember that there has been a lot of work about this in Xalan and other XSLT engines, and also how a complex XPath expressions could change the performance of a transformation because of increased buffering. Xalan has an optimized implementation of the document tree [1], more efficient than the standard DOM for read-only and selection operations. Xalan has an incremental processing mode, but IIRC it's more about being able to produce some output before the whole document has been read rather than avoiding to build parts of the document tree. So it will allow for faster processing, but won't change memory consumption. In that case, maybe, instead of reinventing it, it should be possible to delegate the transformation (extraction of a fragment from the entire XML stream) to an XSLT processor. The simplest way could be to generate an XSLT on the fly :) .. the correct way would be to use the [Xalan|Saxon|any other] internal APIs to perform the XPath resolution. In both cases, it will be faster than transforming to DOM. Agree. It may be easier to produce a small XSL transformation from the XPointer expression than using Axiom. But still, for simple expressions, the pure streaming approach used by Tika would be way more efficient. Sylvain [1] http://xml.apache.org/xalan-j/dtm.html -- Sylvain Wallez - http://bluxte.net -- http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi Sylvain, there are no words to say thank you, very very appreciated, I'll follow your suggestions :) A bientot Simone On Tue, Nov 24, 2009 at 10:21 AM, Sylvain Wallez sylv...@apache.org wrote: Simone Tripodi wrote: Hi Sylvain and Simone, thank you a lot, the suggestions you provided are all very very interesting, so I wonder now if it is possible to realize a processor able to use at the same time the Tika way when it recognizes some kind of paths, the XSL-on-the-fly for more complex cases. What do you think? As I suggested previously: first try to parse the XPath expression with Tika's parser, and if it fails because the expression doesn't match the subset it accepts, fall back to XSL-on-the-fly. Looking at Tika's parser [1], it looks like you'll have to overload the parse() method to fail hard by throwing an exception rather than returning Matcher.FAIL to be able to detect XPath features outside of the subset it accepts. Sylvain, I still haven't read the Tika documentation, can you just point me the related doc about this topic? There's no specific documentation on this particular feature, as its more an internal utility than a primary feature in Tika. Now the code is pretty straightforward. Simo, did you already give a try about the XSLT generation on the fly? The most basic operation I thought is generating the XSL string by a template, then pass it to the XSL parser, but I'm sure it could be implemented in a better way :P Sounds like the way to go, but you should cache the resulting template object to avoid recreating and reparsing the XSL at every request. The same applies to Tika matcher objects. Sylvain [1] https://svn.apache.org/repos/asf/lucene/tika/trunk/tika-core/src/main/java/org/apache/tika/sax/xpath/XPathParser.java -- Sylvain Wallez - http://bluxte.net -- http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi Sylvain Sorry but I forgot to ask you a short question in the previous email: can the Tika code be imported/modified into Cocoon3? AFAIK it should be allowed, but I don't know the conditions under which it can be done. A bientot!!! Simo On Tue, Nov 24, 2009 at 10:29 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi Sylvain, there are no words to say thank you, very very appreciated, I'll follow your suggestions :) A bientot Simone On Tue, Nov 24, 2009 at 10:21 AM, Sylvain Wallez sylv...@apache.org wrote: Simone Tripodi wrote: Hi Sylvain and Simone, thank you a lot, the suggestions you provided are all very very interesting, so I wonder now if it is possible to realize a processor able to use at the same time the Tika way when it recognizes some kind of paths, the XSL-on-the-fly for more complex cases. What do you think? As I suggested previously: first try to parse the XPath expression with Tika's parser, and if it fails because the expression doesn't match the subset it accepts, fall back to XSL-on-the-fly. Looking at Tika's parser [1], it looks like you'll have to overload the parse() method to fail hard by throwing an exception rather than returning Matcher.FAIL to be able to detect XPath features outside of the subset it accepts. Sylvain, I still haven't read the Tika documentation, can you just point me the related doc about this topic? There's no specific documentation on this particular feature, as its more an internal utility than a primary feature in Tika. Now the code is pretty straightforward. Simo, did you already give a try about the XSLT generation on the fly? The most basic operation I thought is generating the XSL string by a template, then pass it to the XSL parser, but I'm sure it could be implemented in a better way :P Sounds like the way to go, but you should cache the resulting template object to avoid recreating and reparsing the XSL at every request. The same applies to Tika matcher objects. Sylvain [1] https://svn.apache.org/repos/asf/lucene/tika/trunk/tika-core/src/main/java/org/apache/tika/sax/xpath/XPathParser.java -- Sylvain Wallez - http://bluxte.net -- http://www.google.com/profiles/simone.tripodi -- http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi all,
Thank you both guys, my question was about legal issues that you clarified me :)
Reinhard, no problem about the optionals, even if I remember the
policy I appreciate you reminded me it :) BTW, after a quick overview
on Tika, I was thinking about importing just the needed classes and
modifying them according to our needs, so if you agree I'd add the
XInclude in the cocoon-sax module... what do you think about it? Just
let me know!
See you guys and thanks a *lot* for your help :)
Best regards
Simo
On Tue, Nov 24, 2009 at 12:16 PM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi Sylvain
Sorry but I forgot to ask you a short question in the previous email:
can the Tika code be imported/modified into Cocoon3?
Do you really have to modify Tika code? If so it would be best to give
back your contributions to the their project.
Since you have to include a library I strongly recommend that everything
goes into cocoon-optional in order to keep the number of required
libraries low for the pipeline API.
AFAIK it should
be allowed, but I don't know the conditions under which it can be
done.
If your questions is about licensing, then it's very simple: You don't
have to do anything because Tika is an ASF project.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Re: closeLoudly()
Hi Jos,
nice to meet you :) Usually suggestions of this kind have to be
submitted by the issue tracker:
http://issues.apache.org/jira/browse/COCOON3
Make your own patch through the command line:
svn diff -x -u Main.java arg-fix.patch
giving your patch file meaningful name.
Goof job!
Simo
On Sat, Dec 5, 2009 at 8:29 AM, Jos Snellings jos.snelli...@pandora.be wrote:
URLResponse.java:
Modifying the finally-clause to remain silent:
finally {
if (servletConnection != null)
URLConnectionUtils.closeQuietly(servletConnection);
}
Jos
--
http://www.google.com/profiles/simone.tripodi
Re: closeLoudly()
Hi Jos,
please don't think so, were are a community and we should help each other :)
In the past I did errors, but Reinhard and Steven kindly helped me as well ;)
Have a nice day,
Simo
On Sat, Dec 5, 2009 at 9:51 AM, Jos Snellings jos.snelli...@pandora.be wrote:
I attached the patch. Is this the proper way to submit?
Thanks, and please excuse me my ignorance. It is the first time.
(first times can be traumatic, so far I am feeling well).
Jos
On Sat, 2009-12-05 at 09:28 +0100, Jos Snellings wrote:
Thank you, Simone. I will do that.
On Sat, 2009-12-05 at 09:21 +0100, Simone Tripodi wrote:
Hi Jos,
nice to meet you :) Usually suggestions of this kind have to be
submitted by the issue tracker:
http://issues.apache.org/jira/browse/COCOON3
Make your own patch through the command line:
svn diff -x -u Main.java arg-fix.patch
giving your patch file meaningful name.
Goof job!
Simo
On Sat, Dec 5, 2009 at 8:29 AM, Jos Snellings jos.snelli...@pandora.be
wrote:
URLResponse.java:
Modifying the finally-clause to remain silent:
finally {
if (servletConnection != null)
URLConnectionUtils.closeQuietly(servletConnection);
}
Jos
--
http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi Guys,
do you have some spare time to review the last patch submitted on [1]?
I know it requires time...
Thanks in advance, best regards,
Simone
[1] https://issues.apache.org/jira/browse/COCOON3-3
On Tue, Nov 24, 2009 at 12:42 PM, Simone Tripodi
simone.trip...@gmail.com wrote:
Hi all,
Thank you both guys, my question was about legal issues that you clarified me
:)
Reinhard, no problem about the optionals, even if I remember the
policy I appreciate you reminded me it :) BTW, after a quick overview
on Tika, I was thinking about importing just the needed classes and
modifying them according to our needs, so if you agree I'd add the
XInclude in the cocoon-sax module... what do you think about it? Just
let me know!
See you guys and thanks a *lot* for your help :)
Best regards
Simo
On Tue, Nov 24, 2009 at 12:16 PM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi Sylvain
Sorry but I forgot to ask you a short question in the previous email:
can the Tika code be imported/modified into Cocoon3?
Do you really have to modify Tika code? If so it would be best to give
back your contributions to the their project.
Since you have to include a library I strongly recommend that everything
goes into cocoon-optional in order to keep the number of required
libraries low for the pipeline API.
AFAIK it should
be allowed, but I don't know the conditions under which it can be
done.
If your questions is about licensing, then it's very simple: You don't
have to do anything because Tika is an ASF project.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
--
http://www.google.com/profiles/simone.tripodi
Re: XInclude optimization
Hi Reinhard
Very appreciated, thanks!!! :)
alles gute, auf wiedersehen!
Simo
On Fri, Dec 11, 2009 at 8:44 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi Guys,
do you have some spare time to review the last patch submitted on [1]?
I know it requires time...
Thanks in advance, best regards,
Unless somebody else is quicker than me, I will have a look at your
patch before I create the release.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Re: SAXGenerator - URLGenerator
Hi Reinhard,
it makes a lot of sense - at least for me - since their internal
behaviors are exactly the same.
Have a nice sunday,
Simo
On Sun, Dec 13, 2009 at 2:44 PM, Reinhard Pötz reinh...@apache.org wrote:
Long time ago (I think when the StAX module was added) we discussed to
have a SAXGenerator which is mainly useful when the pipeline API is
used. It has constructors for File, InputStream, String and Node. See
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/SAXGenerator.java
I also renamed FileGenerator to URLGenerator because this better
reflects what it really does.
But thinking more about this it would also make sense to merge the
URLGenerator into the SAXGenerator.
WDYT?
BTW, these changes are transparent at sitemap level because the
generator type 'file' is still supported and now points to the
URLGenerator. Additionally I also added a shorthand 'url'.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Re: SAXGenerator - URLGenerator
Hi all, I'd follow the Joerg suggestion since it reminded me the Neko HTML Generator included in the optional module that has the behavior similar to the old FileGenerator that takes an URL in input and transforms HTML in XHTML. At that point I'd suggest to have an AbstractGenerator that manipulate an URL stream, than having different specialization, like: *) SAXGenerator *) NekoGenerator *) Anyhing else? How does it sound? Simo On Sun, Dec 13, 2009 at 3:59 PM, Joerg Heinicke joerg.heini...@gmx.de wrote: On 13.12.2009 14:44, Reinhard Pötz wrote: Long time ago (I think when the StAX module was added) we discussed to have a SAXGenerator which is mainly useful when the pipeline API is used. It has constructors for File, InputStream, String and Node. See http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/SAXGenerator.java I also renamed FileGenerator to URLGenerator because this better reflects what it really does. But thinking more about this it would also make sense to merge the URLGenerator into the SAXGenerator. WDYT? A long time ago I argued for renaming the FileGenerator to XMLGenerator since the generators are usually named after the input they accept (Midi, HTML, Directory, JSP, JXTemplate, etc.). I'm not sure SAXGenerator reflects that exactly but it's good enough I guess. Joerg -- http://www.google.com/profiles/simone.tripodi
Re: SAXGenerator - URLGenerator
Hi Reinhard,
I agree with you for solution a) for the same reason you explained,
there's no need to prefix classes since we can use packages for it.
Best regards,
Simone
On Mon, Dec 14, 2009 at 9:33 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi all,
I'd follow the Joerg suggestion since it reminded me the Neko HTML
Generator included in the optional module that has the behavior
similar to the old FileGenerator that takes an URL in input and
transforms HTML in XHTML.
At that point I'd suggest to have an AbstractGenerator that manipulate
an URL stream, than having different specialization, like:
*) SAXGenerator
*) NekoGenerator
*) Anyhing else?
How does it sound?
Simo
On Sun, Dec 13, 2009 at 3:59 PM, Joerg Heinicke joerg.heini...@gmx.de
wrote:
On 13.12.2009 14:44, Reinhard Pötz wrote:
Long time ago (I think when the StAX module was added) we discussed to
have a SAXGenerator which is mainly useful when the pipeline API is
used. It has constructors for File, InputStream, String and Node. See
http://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/SAXGenerator.java
I also renamed FileGenerator to URLGenerator because this better
reflects what it really does.
But thinking more about this it would also make sense to merge the
URLGenerator into the SAXGenerator.
WDYT?
A long time ago I argued for renaming the FileGenerator to XMLGenerator
since the generators are usually named after the input they accept (Midi,
HTML, Directory, JSP, JXTemplate, etc.). I'm not sure SAXGenerator reflects
that exactly but it's good enough I guess.
I agree that we should have one consistent naming scheme and since we
usually use the input type, we shouldn't change it for this case.
I see two solutions in order to get a consistent naming of our components:
a) We rename SAXGenerator AND StAXGenerator to XMLGenerator
or
b) We add the SAX prefix to all pipeline components.
I'm in favor of a) because SAX or StAX is already part of the package
name and looking at the implemented interfaces makes it clear what
underlying event mechanism is used.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Re: [result][vote] Simone Tripodi as new Cocoon committer
Hi Reinhard, all,
in one word, I really feel touched. All these positives votes let me
without words... I couldn't receive any better present for Christmas,
really!!!
Reinhard, Joerg, David, Leszek, Peter, Felix, Thorsten, Sylvain,
David, Steven, Ralph, Vadim: THANK YOU, it's incredible the trust
you're giving to me, I hope I'll never disappoint you.
About myself: I'm Italian, born and grown up in L'Aquila, a small
medieval city recently destroyed by the earthquake, and moved to Rome
at age of 24 after my B.Sc. graduation in Computer Science. I
experienced GIS, spent a lot of time on Shortest Path Algorithms, REST
services and since February 2007 I've been working as a software
engineer in Asemantics, a small company which focuses on new emerging
technologies/specifications, such OpenID, OAuth, PortableContacts and
the Semantic Web.
I joined the Cocoon ML since September 2008 after read an old
Reinhard's post[1] on his blog which charmed me: first I contacted him
privately, so I was invited to join the ML then been in touch also
with Steven... and every passing day I found the Cocoon3 idea so
brilliant that I couldn't resist to contribute!!!
I also play a lot writing my small reusable components[2] that help me
avoiding repeating myself in my everyday work :P
I'm used and love working in heterogeneous environments: at age of 22
I moved to Portugal for 6 months because of the Erasmus Project, I
participated in the Joost[3] backend development and since April 2009
I've been working on the Goom Radio[4] backend development; last, I
married a South-American woman, so every passing day of my life I have
to find the right compromises between different idioms and cultures :D
I accept very proudly my nomination, I already signed the ICLA because
last month I submitted a donation to the Apache Commons community and
they required it, and Rahul Akolkar confirmed it was registered.
My preferred id is simone.tripodi, and my forwarding email address is
simone[dot]tripodi[at]gmail[dot]com.
Thank you guys, the 2009 has been very difficult for me after the
earthquake, my parents still don't have their own home (you can see
the effects here[5]) so this Christmas will be better thanks to this
amazing news :)
Best regards, take care!!!
Simone Tripodi
Margin Note: in all European countries the name Simone is for girls,
except here in Italy; during the Erasmus I take part of a football
tournament, it was very funny looking amazed people's faces because
they expected looking a girl playing... :D
[1] http://www.indoqa.com/en/people/reinhard.poetz/blog/610
[2] http://code.google.com/u/simone.tripodi
[3] http://www.joost.com/
[4] http://www.goomradio.com/
[5]
http://picasaweb.google.com/simone.tripodi/TheEarthquakeDesrtroyedMyParentsHouse
On Mon, Dec 21, 2009 at 3:33 PM, Reinhard Pötz reinh...@apache.org wrote:
Reinhard Pötz wrote:
I propose Simone Tripodi as a new Cocoon committer and PMC member.
Simone has been participating on our mailing lists since Sept 2008.
Recently he provided an extensive patch that adds XInclude support to
Cocoon 3. Additionally he provided 6 other patches.
That shows that his interest in Cocoon is longer-term which he also
confirmed at some chats that we both had.
This vote ends one week from today, i.e. midnight UTC on Sunday 2009-12-20
So please cast your votes.
Simone's nomination has been accepted. He got 12 positive votes and no
negative one. Congratulations Simone and welcome!
Simone, if you accept your nomination, please get familiar with
http://www.apache.org/dev/new-committers-guide.html and send your signed
CLA to the ASF Secretary.
Please also let me know which user id you prefer and what your
forwarding email address is.
It's also a good tradition here to introduce yourself.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Re: Release Cocoon 3.0.0-alpha-2
Hi Reinhard,
count on me to fix the open issues, let's have a chat if you already
have an idea how to fix them so I can provide you the help needed.
Have a nice evening,
Simo
On Mon, Dec 21, 2009 at 3:27 PM, Reinhard Pötz reinh...@apache.org wrote:
Reinhard Pötz wrote:
Reinhard Pötz wrote:
I plan to do a release of Cocoon 3.0.0-alpha-2 at the first half of
August. If there is anything that you want to see fixed/included, let me
know or provide a patch in time.
Of course this also means that I will go through the list of all
available patches and bug reports in Jira and will try to resolve them.
I was busier in Aug/Sept than expected and didn't have enough time. In
the next two weeks I will concentrate on the C3 docs and then create the
release artifacts in the last week of October.
Is there anything that speaks against this time plan?
I'm going to create the release artifacts as soon as cocoon-xml 2.0.2 is
available from the central Maven repo.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Merry Christmas
Dear Cocoon community, Merry Christmas and best wishes for a happy and prosperous New Year. All the best!!! Simone Tripodi -- http://www.google.com/profiles/simone.tripodi
Re: Exporting graphs to PDF
Hi, we included FOP in cocoon3 pipeline, in the optional module. The 3.0 is still an alpha, but you can take a look on it by downloading it from http://cocoon.apache.org//3.0/download.html If you want something to generate charts out of XML in various format (PNG, SVG, JPEG, GIF) for later inclusion in POF, you may take a look at Fins (http://www.lucamorandini.it/fins/index.html). Sounds *great* I'll integrate it on 3.0 pipeline :) Best regards, happy new year!!! Simone Regards, Luca Morandini www.lucamorandini.it -- http://www.google.com/profiles/simone.tripodi
Re: [vote] Release Cocoon 3.0.0-alpha-2
Hi Reinhard,
going to leave to office now, when I'm at home I'll start having a look at it!!!
Happy new year!!
Simo
On Mon, Jan 4, 2010 at 4:39 PM, Reinhard Pötz reinh...@apache.org wrote:
Reinhard Pötz wrote:
I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-2.
Since it has been more than a year since alpha-1 was released, there are
many improvements and enhancements:
Pipeline API level
~~~
. Add generics to the pipeline interface. With additionally introducing
marker interfaces for the component types (SAX, StAX, etc.) this allows
compile time checks if all components have the correct type when
assembling the pipeline
. Use MurmurHash 2.0, a strong hashing algorithm, to implement the
hashCode() method of cache keys.
. Introduce an exception hierarchy for pipeline components
(ProcessingException and SetupException extend both PipelineException).
. Create a separate SAX module that contains all SAX specific classes
. Provide basic component implementations of StAX pipeline components
(new module: 'cocoon-stax')
. Add a new module 'cocoon-optional' for components that need external
libraries (i.e. everything that goes beyond JDK5, commons-logging and
cocoon-sax)
New components:
. XMLGenerator (constructors for File, InputStream, String, Node,
SAXBuffer) [cocoon-sax]
. XIncludeTransformer [cocoon-sax]
. SchemaProcessorTransformer [cocoon-sax]
. Add factory methods to o.a.c.sax.component.XMLSerializer to create
properly configured serializers for XML, XHTML and HTML4 [cocoon-sax]
. FOPSerializer [cocoon-optional]
. NekoHTMLGenerator [cocoon-optional]
. BetwixtBeanGenerator [cocoon-optional]
Sitemap level
~~~
Only minor changes
Webapplication level
~~~
. REST controller (new module: 'cocoon-rest')
. JAX-RS based controllers (JSR 311)
. Automatic conditional GET support for all caching pipelines.
(ETag and Last-Modified are supported)
. Wicket integration in both ways (new module: 'cocoon-wicket')
. JMX based monitoring: Cache overview, reconfiguration of logging,
Servlet-Service-Framework overview (new module: 'cocoon-monitoring')
. SSF/Sitemap/Pipeline profiling (new module: 'cocoon-profiling'
. Update to Spring 2.5.6
Find all details at http://cocoon.apache.org/3.0/changes-report.html.
You can find the staged files for all modules (sources, binaries,
javadocs, checksums, gpg signatures) at
http://people.apache.org/builds/cocoon/
SVN tags of all these artifacts can be found at
http://svn.apache.org/repos/asf/cocoon/cocoon3/tags/
The general distribution artifacts (tar, zip) are available at
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.asc
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.md5
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.zip.sha1
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.asc
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.md5
http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-2/cocoon-all-3.0.0-alpha-2-dist.tar.gz.sha1
I want to stress again that this is an alpha release. This means that we
are free to change contracts without following any deprecation rules.
See http://cocoon.apache.org/3.0/alpha-warning.html
This majority vote stays open for at least 72 hours. Please cast your votes!
+1
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Re: [vote] Release Cocoon 3.0.0-alpha-2
Hi Reinhard, just a couple of questions before expressing my +1: On SVN repo I found alpha2 tags out of sync the following modules: - cocoon-all (is empty) - cocoon-optional (is empty) - cocoon-parent (is empty) I didn't find tagged the following modules: - cocoon-docs - cocoon-profiling-firebug - cocoon-sample-webapp - cocoon-sample-wicket-webapp - cocoon-sax After downloaded both zip and tar.gz archives, I didn't find the parent pom to build all modules: did I miss something? XInclude: I'm sure my patch doesn't include the sitemap integration, and I'm very sorry for that :( Should I integrate it before releasing alpha2? Documentation: should we move my name from contributors to committers? sorry but I'm still celebrating my graduation :P :D Have a nice evening, and count on me for any help you need!!! Simo On Mon, Jan 4, 2010 at 5:48 PM, Peter Hunsberger peter.hunsber...@gmail.com wrote: On Mon, Jan 4, 2010 at 9:36 AM, Reinhard Pötz reinh...@apache.org wrote: I've prepared the artifacts for the release of Cocoon 3.0.0-alpha-2. Since it has been more than a year since alpha-1 was released, there are many improvements and enhancements: [...] This majority vote stays open for at least 72 hours. Please cast your votes! +1 -- Peter Hunsberger -- http://www.google.com/profiles/simone.tripodi
Re: [vote] Release Cocoon 3.0.0-alpha-2
Hi Reinhard,
all tests worked!!! :)
+1
Have a nice day!
Simo
On Tue, Jan 5, 2010 at 1:16 PM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi Reinhard,
just a couple of questions before expressing my +1:
On SVN repo I found alpha2 tags out of sync the following modules:
- cocoon-all (is empty)
- cocoon-optional (is empty)
- cocoon-parent (is empty)
Thanks for spotting - I created all the release tags and updated the
tagging script. Unfortunately Maven doesn't do this out of the box (see
the 'svn-release-tags.bat' script in the root directory of Cocoon 3).
I didn't find tagged the following modules:
- cocoon-docs
directory and tag added
- cocoon-profiling-firebug
not released this time because I have to check how to properly
release/distribute Firefox/Firebug plugins.
- cocoon-sample-webapp
- cocoon-sample-wicket-webapp
Not there because it doesn't make much sense to release them because
everything is packed in a war file. In order to explore the webapp
samples, use the samples archetype.
- cocoon-sax
directory and tag added.
After downloaded both zip and tar.gz archives, I didn't find the
parent pom to build all modules: did I miss something?
It's not there on purpose because its modules section would point to
non-existing projects.
If you want to rebuild the release from its sources, you either have to
build the modules in the right order or you would have to add a root pom
yourself.
For the next release we could enhance the apache-release profile of the
'cocoon-all' module e.g. by a Groovy script that creates the root POM.
XInclude: I'm sure my patch doesn't include the sitemap integration,
and I'm very sorry for that :(
no problem. Since you'll get commit privileges very soon, you can fix it
yourself :-P
Should I integrate it before releasing
alpha2?
I would only want to rebuild the release artifacts either if there is a
serious bug or a formal issue that makes the release 'invalid' regarding
to ASF rules. Otherwise we should just ship alpha-3 asap.
Documentation: should we move my name from contributors to committers?
sorry but I'm still celebrating my graduation :P :D
:-)
You're welcome, add yourself to the parent pom, otherwise see above.
Have a nice evening, and count on me for any help you need!!!
Thanks for reviewing!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Re: [result][vote] Release Cocoon 3.0.0-alpha-2
Hi reinhard,
don't worry, the most important thing for me is the project success,
so nice to hear that the release passed :)
Have a nice evening,
Simo
On Thu, Jan 7, 2010 at 5:05 PM, Reinhard Pötz reinh...@apache.org wrote:
Reinhard Pötz wrote:
This majority vote stays open for at least 72 hours. Please cast your votes!
The vote passed with 3 binding +1 votes and one non-binding one (Simone,
your vote will be binding starting with tomorrow evening, 3 days after
the acknowledgment of the ASF board of your PMC member status.)
Thanks to all for your reviews and votes.
I will take care of the synchronization of the release artifacts with
the central Maven repo and the Apache distribution area, will update the
docs and send the official announcement asap.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://www.google.com/profiles/simone.tripodi
Site Updates
Hi all guys, I modified the c3 site home page and developers list page, but it seems not be updated; is it the site update a manual or automatic operation? can anyone explain to me please? On my personal apache space[1] I integrated a JS code syntax highlighter in the maven skin site, do you think could be useful having it in the C3 site? I'd more than pleased to improve our doc, please let me know :) Thanks in advance, best regards! Simo [1] http://people.apache.org/~simonetripodi/projects.html -- http://people.apache.org/~simonetripodi/
Re: Site Updates
Hi Reinhard,
thanks a lot for the provided info, and nice to hear you like the
syntax highlighter, tonight I'll start modifying the skin :)
Have a nice evening,
Simo
On Mon, Jan 11, 2010 at 5:30 PM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi all guys,
I modified the c3 site home page and developers list page, but it
seems not be updated; is it the site update a manual or automatic
operation? can anyone explain to me please?
It's a manual process. There is an ASF requirement that all site content
has to be put into SVN. In our case it is located a
https://svn.apache.org/repos/asf/cocoon/site/site/
Checkout this URL.
Then you have to install the Cocoon Maven site skin:
https://svn.apache.org/repos/asf/cocoon/trunk/site/cocoon-thien-maven-site-skin/
to your Maven repository.
And
mvn site-deploy -Ddocs.deploymentBaseUrl=file://[path-to-site]
from the cocoon-docs module base directory creates the site.
Then commit the newly generated content.
On the server-side, login to people.apache.org and go to
/www/cocoon.apache.org/3.0/ and call 'svn up'.
(Unfortunately there is no easier way but you could create a script at
your local machine that does everything for you.)
On my personal apache space[1] I integrated a JS code syntax
highlighter in the maven skin site, do you think could be useful
having it in the C3 site? I'd more than pleased to improve our doc,
please let me know :)
That would be great! Just go to the cocoon-thien-maven-site-skin and
change whatever you need.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://people.apache.org/~simonetripodi/
Re: Site Updates
Hi Reinhard,
I should stop working in the night when I'm tired :P I just forgot to
add the license header - the prettify comes from google[1] and it
licensed under apache license 2
Going to fix it now, sorry for the misses,
Simo
[1] http://code.google.com/p/google-code-prettify/
On Tue, Jan 12, 2010 at 7:38 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi Reinhard,
I just modified the skin and updated the new site version - I took
time because of the maven build but everything worked fine.
I did the svn up on the server side, it updated the pages but the
don't appear updated on the browser. Is there anything I missed or the
pages are just cached?
Thanks in advance, see you!
There is some sync mechanism that copies /www/* of people.apache.org
every hour.
The site has been updated but
http://cocoon.apache.org/3.0/js/prettify.js can't be found. It's not in
/x1/www/cocoon.apache.org/3.0/js where I would expect it.
BTW, where does the prettify.js code come from (AFAICS there is no
license header).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://people.apache.org/~simonetripodi/
Re: Site Updates
Hi Reinhard,
missing license headers added, site regenerated and committed missing
packages, site updated on server server, I hope everything gone fine
this time, feel free to ping me whenever you want, also on skype, if
something needs to be fixed :)
Have a nice day, all the best!!!
Simo
On Tue, Jan 12, 2010 at 8:07 AM, Simone Tripodi
simone.trip...@gmail.com wrote:
Hi Reinhard,
I should stop working in the night when I'm tired :P I just forgot to
add the license header - the prettify comes from google[1] and it
licensed under apache license 2
Going to fix it now, sorry for the misses,
Simo
[1] http://code.google.com/p/google-code-prettify/
On Tue, Jan 12, 2010 at 7:38 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi Reinhard,
I just modified the skin and updated the new site version - I took
time because of the maven build but everything worked fine.
I did the svn up on the server side, it updated the pages but the
don't appear updated on the browser. Is there anything I missed or the
pages are just cached?
Thanks in advance, see you!
There is some sync mechanism that copies /www/* of people.apache.org
every hour.
The site has been updated but
http://cocoon.apache.org/3.0/js/prettify.js can't be found. It's not in
/x1/www/cocoon.apache.org/3.0/js where I would expect it.
BTW, where does the prettify.js code come from (AFAICS there is no
license header).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://people.apache.org/~simonetripodi/
--
http://people.apache.org/~simonetripodi/
Re: Site Updates
Hi Reinhard,
the site has been updated and everything worked fine this time, thanks
for your help!
Simo
On Tue, Jan 12, 2010 at 8:23 AM, Simone Tripodi
simone.trip...@gmail.com wrote:
Hi Reinhard,
missing license headers added, site regenerated and committed missing
packages, site updated on server server, I hope everything gone fine
this time, feel free to ping me whenever you want, also on skype, if
something needs to be fixed :)
Have a nice day, all the best!!!
Simo
On Tue, Jan 12, 2010 at 8:07 AM, Simone Tripodi
simone.trip...@gmail.com wrote:
Hi Reinhard,
I should stop working in the night when I'm tired :P I just forgot to
add the license header - the prettify comes from google[1] and it
licensed under apache license 2
Going to fix it now, sorry for the misses,
Simo
[1] http://code.google.com/p/google-code-prettify/
On Tue, Jan 12, 2010 at 7:38 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi Reinhard,
I just modified the skin and updated the new site version - I took
time because of the maven build but everything worked fine.
I did the svn up on the server side, it updated the pages but the
don't appear updated on the browser. Is there anything I missed or the
pages are just cached?
Thanks in advance, see you!
There is some sync mechanism that copies /www/* of people.apache.org
every hour.
The site has been updated but
http://cocoon.apache.org/3.0/js/prettify.js can't be found. It's not in
/x1/www/cocoon.apache.org/3.0/js where I would expect it.
BTW, where does the prettify.js code come from (AFAICS there is no
license header).
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
http://people.apache.org/~simonetripodi/
--
http://people.apache.org/~simonetripodi/
--
http://people.apache.org/~simonetripodi/
Re: Site Updates
Hi David, very nice to meet you and thank for the links :) even if I already uploaded the modifications, that's very good keeping in mind the guide, very appreciated! Best regards, Simo http://people.apache.org/~simonetripodi/ On Mon, Jan 18, 2010 at 11:20 PM, David Crossley cross...@apache.orgwrote: Reinhard P??tz wrote: Simone Tripodi wrote: Hi Reinhard, I just modified the skin and updated the new site version - I took time because of the maven build but everything worked fine. I did the svn up on the server side, it updated the pages but the don't appear updated on the browser. Is there anything I missed or the pages are just cached? Thanks in advance, see you! There is some sync mechanism that copies /www/* of people.apache.org every hour. See info at: http://apache.org/dev/#web http://apache.org/dev/project-site.html -David
[Cocoon 3] Optimizing resources creation on SAX pipeline components
Hi all guys,
I'd like to improve a little the resources creation into C3 SAX pipelines
components, saving consumed memory and components initialization time,
reusing already created resources.
I mean, instantiating the same kind of XSLTTransformer (or the
SchemaProcessorTransformer) twice, in different parts of the application,
with the same resource:
class Service1 {
XSLTTransformer xsltTransformer =
new XSLTTransformer(this.getClass().getResource(myStyle.xsl));
...
}
class Service2 {
XSLTTransformer xsltTransformer =
new XSLTTransformer(this.getClass().getResource(myStyle.xsl));
...
}
causes the myStyle.xsl resource has to be load twice, consuming memory. As
proposed time ago - also mentioned by Sylvain - I'd like to introduce an
InMemoryLRU cache that stores and maintains already loaded resources.
What do you think about it? It's a simple improvement I can realize quickly
and that's not hard to integrate in the existing code, obviously any kind of
help and suggestion is more than welcome! :)
Best regards,
Simo
http://people.apache.org/~simonetripodi/
Re: [Cocoon 3] Optimizing resources creation on SAX pipeline components
Hi Reinhard,
Thanks for your reply! I wouldn't add a dependency but rather using a simple
yet powerful ad-hoc implementation based on LinkedhashMap that allows
realizing a memory based LRU cache, I already provided an implementation in
Apache Commons Sandbox[1]. If you agree I can start adding it and modifying
the components.
About making the mentioned components as CachingPipelineComponent: do you
have any hint you can suggest to me please? I'd more than pleased to working
on it!
Thanks in advance, best regards!!!
Simo
[1]
https://svn.apache.org/repos/asf/commons/sandbox/at-digester/trunk/src/java/org/apache/commons/digester/annotations/utils/InMemoryLRUCache.java
http://people.apache.org/~simonetripodi/
On Mon, Jan 25, 2010 at 8:20 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi all guys,
I'd like to improve a little the resources creation into C3 SAX
pipelines components, saving consumed memory and components
initialization time, reusing already created resources.
I mean, instantiating the same kind of XSLTTransformer (or the
SchemaProcessorTransformer) twice, in different parts of the
application, with the same resource:
class Service1 {
XSLTTransformer xsltTransformer =
new XSLTTransformer(this.getClass().getResource(myStyle.xsl));
...
}
class Service2 {
XSLTTransformer xsltTransformer =
new XSLTTransformer(this.getClass().getResource(myStyle.xsl));
...
}
causes the myStyle.xsl resource has to be load twice, consuming
memory. As proposed time ago - also mentioned by Sylvain - I'd like to
introduce an InMemoryLRU cache that stores and maintains already loaded
resources.
What do you think about it? It's a simple improvement I can realize
quickly and that's not hard to integrate in the existing code, obviously
any kind of help and suggestion is more than welcome! :)
Yes, improvements in that area are very appreciated. What solution (api)
do you propose?
And when we are at it, it would also be great to support the
CachingPipelineComponent interface in the XSLTTransformer and the
SchemaProcessorTransformer.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
More karma on Jira
Hi all guys, I need more karma on Cocoon 3 Jira to assign to me issues, start working and resolve them. Can anyone please help me? Thanks in adavance and have a nice weekend!!! Simo http://people.apache.org/~simonetripodi/
Re: More karma on Jira
Thanks Reinhard,
very very appreciated, have a nice weekend :)
Simo
http://people.apache.org/~simonetripodi/
On Sat, Jan 30, 2010 at 2:55 PM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi all guys,
I need more karma on Cocoon 3 Jira to assign to me issues, start working
and resolve them. Can anyone please help me?
Thanks in adavance and have a nice weekend!!!
Simo
I added you to the Jira group cocoon-developers.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
[Cocoon 3] cocoon-sax build error
Hi all guys, I've some problem in building the cocoon-sax modules using the m2eclipse plugin for eclipse (I'm not using the built-in maven3, but linked my own 2.2.1), the error message I get is: 2/3/10 10:12:52 AM CET: Build error for /cocoon-sax/pom.xml; org.apache.maven.project.ProjectBuildingException: Some problems were encountered while processing the POMs: [ERROR] 'dependencyManagement.dependencies.dependency.(groupId:artifactId:type:classifier)' must be unique: org.springframework:spring-context:jar - duplicate declaration of version 2.5.6 @ org.apache.cocoon.parent:cocoon-parent:3.0.0-alpha-3-SNAPSHOT, /Users/simone/Documents/workspace-cocoon3/cocoon-root/parent/pom.xml Do have you experienced the same? If not, which settings I've to take care to avoid it? Thanks in advance, have a nice day :) Simo http://people.apache.org/~simonetripodi/
Adding new components to C3 Optionals
Hi all guys, even if a little late, I noticed an old email[1] in the users ML where one of C3 users was asking us how to integrate a JAXB marshaller into C3. After provided the hint, I suggested him to send a patch but at the same time I don't know if it could be applied because of the licensing: on the JAXB documentation I'm reading is reported that. * JAXB is a redistributable component of the JWSDP that's covered by the JWSDP License[3] * Parts of the JAXP software bundled with JAXB are covered by the Apache License and the W3C License I'm not a lawyer and honestly not expert about licenses: do you have any info that confirm we can/can't add JAXB in C3? Also Javolution[4] contains a nice and fast XML marshaller[5], but Javolution is released under the BSD[6] License. Are we allowed to integrate Javolution in C3? Thanks in advance, very appreciated!!! Simo [1] http://markmail.org/message/sql2zaa53vlktx2a [2] http://java.sun.com/webservices/docs/1.5/jaxb/index.html [3] http://java.sun.com/webservices/docs/1.5/LICENSE [4] http://javolution.org/ [5] http://javolution.org/target/site/apidocs/javolution/xml/package-summary.html#package_description [6] http://javolution.org/LICENSE.txt http://people.apache.org/~simonetripodi/
Re: Adding new components to C3 Optionals
Thank a lot Reinhard,
I'll check the projects you mentioned!!!
Have anice day :)
Simo
http://people.apache.org/~simonetripodi/
On Thu, Feb 18, 2010 at 8:53 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi all guys,
even if a little late, I noticed an old email[1] in the users ML where
one of C3 users was asking us how to integrate a JAXB marshaller into
C3.
After provided the hint, I suggested him to send a patch but at the
same time I don't know if it could be applied because of the
licensing: on the JAXB documentation I'm reading is reported that.
* JAXB is a redistributable component of the JWSDP that's covered
by the JWSDP License[3]
* Parts of the JAXP software bundled with JAXB are covered by the
Apache License and the W3C License
I'm not a lawyer and honestly not expert about licenses: do you have
any info that confirm we can/can't add JAXB in C3?
Also Javolution[4] contains a nice and fast XML marshaller[5], but
Javolution is released under the BSD[6] License. Are we allowed to
integrate Javolution in C3?
I've never used JAXB, but I found http://camel.apache.org/jaxb.html
which says that JAXB is part of Java 6.
In order to remain Java 5 compliant, we have to add an optional JAXB
dependency. Maybe Apache WS, CXF or Geronimo offer an AL 2.0 complient
implementation or you could at least find out how they provide JAXB support.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
Hi All, Reinhard,
in the Apache BeanValidation we're using JAXB without any particular
care on Licensing, being JAXB now part of the JVM.
If you agree I'd add a JAXB based component starter to serialize beans
through the SAX Pipeline in the sax module... what do you think about
it?
Have a nice evening,
Simo
http://people.apache.org/~simonetripodi/
On Thu, Feb 18, 2010 at 11:45 AM, Simone Tripodi
simone.trip...@gmail.com wrote:
Thank a lot Reinhard,
I'll check the projects you mentioned!!!
Have anice day :)
Simo
http://people.apache.org/~simonetripodi/
On Thu, Feb 18, 2010 at 8:53 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi all guys,
even if a little late, I noticed an old email[1] in the users ML where
one of C3 users was asking us how to integrate a JAXB marshaller into
C3.
After provided the hint, I suggested him to send a patch but at the
same time I don't know if it could be applied because of the
licensing: on the JAXB documentation I'm reading is reported that.
* JAXB is a redistributable component of the JWSDP that's covered
by the JWSDP License[3]
* Parts of the JAXP software bundled with JAXB are covered by the
Apache License and the W3C License
I'm not a lawyer and honestly not expert about licenses: do you have
any info that confirm we can/can't add JAXB in C3?
Also Javolution[4] contains a nice and fast XML marshaller[5], but
Javolution is released under the BSD[6] License. Are we allowed to
integrate Javolution in C3?
I've never used JAXB, but I found http://camel.apache.org/jaxb.html
which says that JAXB is part of Java 6.
In order to remain Java 5 compliant, we have to add an optional JAXB
dependency. Maybe Apache WS, CXF or Geronimo offer an AL 2.0 complient
implementation or you could at least find out how they provide JAXB support.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
Hi Reinhard,
follow below what Donald Woods, from Apache Geronimo Apache
BeanValidation, wrote me about JAXB Licensing, maybe could help us o
resolve our issue.
Before starting coding I'll wait for your feedbacks.
Have a nice evening, all the best!
Simo
---
We've distributed JAXB in Geronimo releases, as a CDDL binary-only jar
(no source or jar checked into svn.) To do so, you just need to include
the appropriate info in the LICENSE and NOTICE files for your project.
See -
https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/LICENSE.txt
https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/NOTICE.txt
BUT, if your project can use the Java SE 5 or 6 provided levels of JAXB,
then I strongly suggest you not provide your own. We had to include
different levels in Geronimo, as the Java EE spec was always one
generation of JAXB ahead of the Java SE spec
1) LICENSE - third-party licenses after the ASL 2.0 text -
=
== Sun CDDL License ==
== JAXB-API, JAXB, JAXWS, JSTL, SAAJ ==
=
COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0
license text here
2) NOTICE - third-party required notices -
. . .
This product includes/uses software, Java Architecture for XML Binding
(JAXB API),
developed by Sun Microsystems (http://www.sun.com/)
License: COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0
(http://www.sun.com/cddl/cddl.html)
. . .
=
== Sun CDDL Notice==
=
This product includes software developed for the JAXB Reference
Implementation project. (https://jaxb.dev.java.net/)
This product includes software developed for Java API for XML Web Services
project (JAX-WS) (https://jax-ws.dev.java.net/)
This product includes software developed for the Java Server Pages Tag
Library project (https://jstl.dev.java.net/)
This product includes software developed for SOAP with Attachments
API for Java (SAAJ). The software is available from the GlassFish project
(https://saaj.dev.java.net/)
http://people.apache.org/~simonetripodi/
On Wed, Apr 7, 2010 at 10:07 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi All, Reinhard,
in the Apache BeanValidation we're using JAXB without any particular
care on Licensing, being JAXB now part of the JVM.
If you agree I'd add a JAXB based component starter to serialize beans
through the SAX Pipeline in the sax module... what do you think about
it?
Hi Simone,
isn't it a question of what JVM version we want to target? IIUC JAXB is
part of Java 6 but for Java 5 you have to add external libraries. Since
Cocoon 3 should be Java 5 compatible, we don't come around this problem.
Reinhard
On Thu, Feb 18, 2010 at 11:45 AM, Simone Tripodi
simone.trip...@gmail.com wrote:
Thank a lot Reinhard,
I'll check the projects you mentioned!!!
Have anice day :)
Simo
http://people.apache.org/~simonetripodi/
On Thu, Feb 18, 2010 at 8:53 AM, Reinhard Pötz reinh...@apache.org wrote:
Simone Tripodi wrote:
Hi all guys,
even if a little late, I noticed an old email[1] in the users ML where
one of C3 users was asking us how to integrate a JAXB marshaller into
C3.
After provided the hint, I suggested him to send a patch but at the
same time I don't know if it could be applied because of the
licensing: on the JAXB documentation I'm reading is reported that.
* JAXB is a redistributable component of the JWSDP that's covered
by the JWSDP License[3]
* Parts of the JAXP software bundled with JAXB are covered by the
Apache License and the W3C License
I'm not a lawyer and honestly not expert about licenses: do you have
any info that confirm we can/can't add JAXB in C3?
Also Javolution[4] contains a nice and fast XML marshaller[5], but
Javolution is released under the BSD[6] License. Are we allowed to
integrate Javolution in C3?
I've never used JAXB, but I found http://camel.apache.org/jaxb.html
which says that JAXB is part of Java 6.
In order to remain Java 5 compliant, we have to add an optional JAXB
dependency. Maybe Apache WS, CXF or Geronimo offer an AL 2.0 complient
implementation or you could at least find out how they provide JAXB
support.
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinh...@apache.org
--
Reinhard Pötz Founder Managing Director
Re: Changes.xml and contributors in our parent POM
Hi Reinhard!!! Sure, I'll take care ASAP, that means this evening after watched Lost ;) Take care, best regards!!! Simo http://people.apache.org/~simonetripodi/ On Wed, Apr 14, 2010 at 10:39 PM, Reinhard Pötz reinh...@apache.org wrote: simonetrip...@apache.org wrote: Author: simonetripodi Date: Wed Apr 14 20:14:55 2010 New Revision: 934171 URL: http://svn.apache.org/viewvc?rev=934171view=rev Log: COCOON3-54 LinkRewriterTransformer porting from Cocoon 2.X by Francesco Chicchiriccò Hi Simone, many thanks for taking care of committing this patch! Additionally it would be great if you could add Francesco to the parent POM as contributor and update the changes.xml in the cocoon-site module. This is our way to 'officially' say thank you to contributors and to give an overview of what has changed between releases. IIRC you also applied some patch some time ago - please check if this is mentioned as described above.TIA -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Changes.xml and contributors in our parent POM
Couldn't resist, already done :) Best regards!!! Simo http://people.apache.org/~simonetripodi/ On Thu, Apr 15, 2010 at 3:50 PM, Simone Tripodi simone.trip...@gmail.com wrote: Hi Reinhard!!! Sure, I'll take care ASAP, that means this evening after watched Lost ;) Take care, best regards!!! Simo http://people.apache.org/~simonetripodi/ On Wed, Apr 14, 2010 at 10:39 PM, Reinhard Pötz reinh...@apache.org wrote: simonetrip...@apache.org wrote: Author: simonetripodi Date: Wed Apr 14 20:14:55 2010 New Revision: 934171 URL: http://svn.apache.org/viewvc?rev=934171view=rev Log: COCOON3-54 LinkRewriterTransformer porting from Cocoon 2.X by Francesco Chicchiriccò Hi Simone, many thanks for taking care of committing this patch! Additionally it would be great if you could add Francesco to the parent POM as contributor and update the changes.xml in the cocoon-site module. This is our way to 'officially' say thank you to contributors and to give an overview of what has changed between releases. IIRC you also applied some patch some time ago - please check if this is mentioned as described above.TIA -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
Hi all, Reinhard, I just added the JAXB generator to C3 Optionals, I'd like to ask if you have time to review the licensing part. I followed yours and Donald's hints, but 4 eyes are better than 2 :P Thanks in advance, have a nice evening, Simo http://people.apache.org/~simonetripodi/ On Sat, Apr 17, 2010 at 11:25 AM, Reinhard Pötz reinh...@apache.org wrote: I'm not sure what is meant by Java SE 5 level of JAXB support because AFAICS it doesn't come with the JRE. I guess that it means that we have to add a JAXB dependency to the cocoon-optional POM: dependency groupIdcom.sun.xml.bind/groupId artifactIdjaxb-impl/artifactId version2.2/version optionaltrue/optional /dependency and dependency groupIdjavax.xml/groupId artifactIdjaxb-api/artifactId version2.1/version optionaltrue/optional /dependency Both are available at the central Maven repo. Since the impl is licenced under CDDL we have to add the CDDL license to the cocoon-optional LICENSE.txt and the mentioned third-party notice to the NOTICE.txt file. Reinhard Simone Tripodi wrote: Hi Reinhard, follow below what Donald Woods, from Apache Geronimo Apache BeanValidation, wrote me about JAXB Licensing, maybe could help us o resolve our issue. Before starting coding I'll wait for your feedbacks. Have a nice evening, all the best! Simo --- We've distributed JAXB in Geronimo releases, as a CDDL binary-only jar (no source or jar checked into svn.) To do so, you just need to include the appropriate info in the LICENSE and NOTICE files for your project. See - https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/LICENSE.txt https://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-2.1.5/NOTICE.txt BUT, if your project can use the Java SE 5 or 6 provided levels of JAXB, then I strongly suggest you not provide your own. We had to include different levels in Geronimo, as the Java EE spec was always one generation of JAXB ahead of the Java SE spec 1) LICENSE - third-party licenses after the ASL 2.0 text - = == Sun CDDL License == == JAXB-API, JAXB, JAXWS, JSTL, SAAJ == = COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0 license text here 2) NOTICE - third-party required notices - . . . This product includes/uses software, Java Architecture for XML Binding (JAXB API), developed by Sun Microsystems (http://www.sun.com/) License: COMMON DEVELOPMENT AND DISTRIBUTION LICENSE (CDDL) Version 1.0 (http://www.sun.com/cddl/cddl.html) . . . = == Sun CDDL Notice == = This product includes software developed for the JAXB Reference Implementation project. (https://jaxb.dev.java.net/) This product includes software developed for Java API for XML Web Services project (JAX-WS) (https://jax-ws.dev.java.net/) This product includes software developed for the Java Server Pages Tag Library project (https://jstl.dev.java.net/) This product includes software developed for SOAP with Attachments API for Java (SAAJ). The software is available from the GlassFish project (https://saaj.dev.java.net/) http://people.apache.org/~simonetripodi/ On Wed, Apr 7, 2010 at 10:07 AM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi All, Reinhard, in the Apache BeanValidation we're using JAXB without any particular care on Licensing, being JAXB now part of the JVM. If you agree I'd add a JAXB based component starter to serialize beans through the SAX Pipeline in the sax module... what do you think about it? Hi Simone, isn't it a question of what JVM version we want to target? IIUC JAXB is part of Java 6 but for Java 5 you have to add external libraries. Since Cocoon 3 should be Java 5 compatible, we don't come around this problem. Reinhard On Thu, Feb 18, 2010 at 11:45 AM, Simone Tripodi simone.trip...@gmail.com wrote: Thank a lot Reinhard, I'll check the projects you mentioned!!! Have anice day :) Simo http://people.apache.org/~simonetripodi/ On Thu, Feb 18, 2010 at 8:53 AM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi all guys, even if a little late, I noticed an old email[1] in the users ML where one of C3 users was asking us how to integrate a JAXB marshaller into C3. After provided the hint, I suggested him to send a patch but at the same time I don't know if it could be applied because of the licensing: on the JAXB documentation I'm reading is reported that. * JAXB is a redistributable component of the JWSDP that's covered by the JWSDP License[3] * Parts
Re: Adding new components to C3 Optionals
Thanks to you, very appreciated! :) See you, Simo http://people.apache.org/~simonetripodi/ On Tue, Apr 20, 2010 at 10:21 PM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi all, Reinhard, I just added the JAXB generator to C3 Optionals, I'd like to ask if you have time to review the licensing part. I followed yours and Donald's hints, but 4 eyes are better than 2 :P Thanks in advance, have a nice evening, Looks good to me, thanks! -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
Hi Reinhard! OK, I'll take care about it during the lunchtime, don't worry!!! All the best, Simo http://people.apache.org/~simonetripodi/ On Wed, Apr 21, 2010 at 9:49 AM, Reinhard Pötz reinh...@apache.org wrote: I forgot to mention another place where we have to mentation the inclusion of CDDL licensed stuff: The cocoon-all module creates the distribution that contains all Cocoon modules, of course also cocoon-optional. Simone Tripodi wrote: Thanks to you, very appreciated! :) See you, Simo http://people.apache.org/~simonetripodi/ On Tue, Apr 20, 2010 at 10:21 PM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi all, Reinhard, I just added the JAXB generator to C3 Optionals, I'd like to ask if you have time to review the licensing part. I followed yours and Donald's hints, but 4 eyes are better than 2 :P Thanks in advance, have a nice evening, Looks good to me, thanks! -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Adding new components to C3 Optionals
Hi Reinhard! Thanks a lot, very appreciated! :) Simo http://people.apache.org/~simonetripodi/ On Wed, Apr 21, 2010 at 10:34 AM, Reinhard Pötz reinh...@apache.org wrote: While reviewing your commit, I've already done the necessary changes. Simone Tripodi wrote: Hi Reinhard! OK, I'll take care about it during the lunchtime, don't worry!!! All the best, Simo http://people.apache.org/~simonetripodi/ On Wed, Apr 21, 2010 at 9:49 AM, Reinhard Pötz reinh...@apache.org wrote: I forgot to mention another place where we have to mentation the inclusion of CDDL licensed stuff: The cocoon-all module creates the distribution that contains all Cocoon modules, of course also cocoon-optional. Simone Tripodi wrote: Thanks to you, very appreciated! :) See you, Simo http://people.apache.org/~simonetripodi/ On Tue, Apr 20, 2010 at 10:21 PM, Reinhard Pötz reinh...@apache.org wrote: Simone Tripodi wrote: Hi all, Reinhard, I just added the JAXB generator to C3 Optionals, I'd like to ask if you have time to review the licensing part. I followed yours and Donald's hints, but 4 eyes are better than 2 :P Thanks in advance, have a nice evening, Looks good to me, thanks! -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: [C3] Adding the cinclude transformer
Hi Hugh, very nice to meet you :) I don't know the C2 cinclude, but AFAIK the C3 relative component is the org.apache.cocoon.sax.component.IncludeTransformer, already supported since the alpha-1. Moreover since the beta-2, C3 supports also XInclude. Have a nice evening, Simo http://people.apache.org/~simonetripodi/ On Wed, Apr 21, 2010 at 5:13 PM, Hugh Sparks h...@csparks.com wrote: Would the cinclude transformer be an appropriate / possible / planned addition to Cocoon 3? If not, how can a C3 transformer process a document to effect a POST request (with parameters) and return the result to the pipeline? Is there some existing alternative in C3? Thanks!
Re: [C3] Adding the cinclude transformer
Hi Hugh, interesting topic, and sorry if I didn't understand your needs earlier :P I'd appreciate very much if you could - raise a Jira issue about it - attach as much info as you have, like C2 link sources, doc, etc Thank you, have a nice day :) Simo http://people.apache.org/~simonetripodi/ On Thu, Apr 22, 2010 at 5:55 PM, Hugh Sparks h...@csparks.com wrote: It appears that IncludeTransformer might work if I pass the parameters in the url, which would make an ugly mess out of my code. IncludeTransformer is pretty simple. Would it be appropriate to add optional protocol for controlling the request (GET, POST) and passing parameters in an element? Or would it be better to add some new thing like a rewrite of the old CIncludeTransform? It seems excessive to have Include, XInclude, and CInclude... This is what I'm doing now with C2: ci:includexml ci:configuration ci:srchttp://myserver/cgi-bin/someScript.sh/ci:src ci:parameter ci:namemethod/ci:name ci:valuePOST/ci:value /ci:parameter /ci:configuration ci:parameters ci:parameter ci:nameparam1/ci:name ci:valuevalue1/ci:value /ci:parameter ... /ci:parameters /ci:include I think it would be good for C3 to have some kind of door to invoke scripts on the server. And cramming things onto the URL and using GET isn't very attractive. Thanks! -Hugh
Re: Planning for Cocoon 3 alpha-3
Hi Reinhard! Yes I totally agree with you, before releasing it I personally would like to spent some effort on integrating the new latest components (XInclude, LinkRewriter, Log and LogAsXML) into the sitemap, this weekend I'm trying to do my best. Once these integration will be completed, then we should be able to release the alpha 3. Does it work for you? An of course, as you reminded, any contribution will be more than appreciated :) All the best, thanks in advance!!! Simo http://people.apache.org/~simonetripodi/ On Fri, Apr 23, 2010 at 9:05 AM, Reinhard Pötz reinh...@apache.org wrote: The latest Cocoon 3 release is three months ago. In the meantime a couple of improvements and fixes have found their way into SVN. See https://svn.eu.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-docs/src/changes/changes.xml I think it's time for another release. I propose to release it as 'alpha-3' because I expect some more backwards-incompatible changes of the pipline API (a pipeline should be able to produce other output than java.io.OutputStream as a direct result). After this change we could start with beta releases IMO. WDOT? -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Planning for a release of the Cocoon Maven Plugin
Hi Reinhard, very sorry to have missed this thread :( BTW I agree with you, my late (and now useless) +1 All the best, Simo http://people.apache.org/~simonetripodi/ On Fri, May 14, 2010 at 6:18 PM, Reinhard Pötz reinh...@apache.org wrote: Reinhard Pötz wrote: The upgrade of Spring 3 required some minor changes of the Cocoon Maven plugin. See http://cocoon.markmail.org/message/hapiusamiic4uzq2 In order to make this fix (http://cocoon.markmail.org/message/ab4muyauhznirms7) available for all people that don't want to build it themselves, I'd like to release the plugin. The current version is 1.0.0-M3. I think that a 1.0.0 release is appropriate because the plugin has proven to be stable with respect to its interfaces as well as its implementation. Since there are no objections, I will create the release artifacts over the weekend or next week. -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Help needed on finalizing the JAXB optional support
Hi all, a month ago I started developing the JAXB optional support for C3 pipeline, with a lot of limits: * each time a new object has to be mashalled, the JAXBContext were created, now it uses a memory-based LRU cache; * it supported just POJOs graphs, without any support for collections and array. I was able to plug the array support (see cocoon-optional r936231) but after several tries I had to resign to discover collections generic type at runtime; I also checked-out the Jersey source code to see how do they extract this information, but I got lost :( So, my first question is: can anyone help me please? :P Moreover, for Collection/Array object, there is the need that the root element name of the marshalled document is the plural of the list; I found two existing implementations for this purpose: * the Apache Betwixt PluralStemmer [1] * the Jersey Inflector [2] I personally find the Jersey implementation much more complete but it is not licensed under the Apache license. So my question is: can I extract part of that class to include in our software? Is that allowed? Many thanks in advance, have a nice day Simo [1] http://tinyurl.com/376ehs9 [2] http://tinyurl.com/3yqbssj http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: Gump for Cocoon3
Hi all, it seems something wrong happens when pre-compiling XSLTs, as Reinhard supposed. I'll try to add the BCEL dependency to fix that, btw I don't understand why it happens... I'll let you know as soon as possible. Thanks!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 24, 2010 at 10:42 AM, Reinhard Pötz reinh...@apache.org wrote: David Crossley wrote: At Apache Gump, Stefan has recently added a Gump build of Cocoon3. See http://thread.gmane.org/gmane.comp.jakarta.gump/14458/focus=14475 Here is the first output: http://vmgump.apache.org/gump/public/cocoon3/ If not familiar with Gump, then follow: All Projects : cocoon3 then Project-level Work : build_cocoon3_cocoon3 then Output : Complete Output File Could someone here at Cocoon assist with the build errors. Not sure if Gump runs more than once per day, but that last run finished at 19:20 US PDT. When it settles, we could enable Gump to nag us. I guess it is somehow related with the XSLTC precompilation tests. Simone, any idea? -- Reinhard Pötz Founder Managing Director, Indoqa http://www.indoqa.com/people/reinhard-poetz.html Member of the Apache Software Foundation Apache Cocoon Committer, PMC member reinh...@apache.org
Re: Help needed on finalizing the JAXB optional support
Hi all guys, I resolved the Collection Generic type problem[1], but the question about the plural stemmer/inflector is still open, can anyone help me please? Thanks in advance, have a nice weekend :) Simo [1] http://tinyurl.com/23bpwnc r958243 http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 24, 2010 at 10:49 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all, a month ago I started developing the JAXB optional support for C3 pipeline, with a lot of limits: * each time a new object has to be mashalled, the JAXBContext were created, now it uses a memory-based LRU cache; * it supported just POJOs graphs, without any support for collections and array. I was able to plug the array support (see cocoon-optional r936231) but after several tries I had to resign to discover collections generic type at runtime; I also checked-out the Jersey source code to see how do they extract this information, but I got lost :( So, my first question is: can anyone help me please? :P Moreover, for Collection/Array object, there is the need that the root element name of the marshalled document is the plural of the list; I found two existing implementations for this purpose: * the Apache Betwixt PluralStemmer [1] * the Jersey Inflector [2] I personally find the Jersey implementation much more complete but it is not licensed under the Apache license. So my question is: can I extract part of that class to include in our software? Is that allowed? Many thanks in advance, have a nice day Simo [1] http://tinyurl.com/376ehs9 [2] http://tinyurl.com/3yqbssj http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [Gump] cocoon-sax build error
Hi Stefan, thanks a lot for the incredible analysis you've done!!! Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Jun 28, 2010 at 9:21 AM, Stefan Bodewig bode...@apache.org wrote: Hi, I think I see why the build currently fails in Gump. The Xalan jar that can be downloaded from the mvn repository contains java_cup and bcel and regex and a few other things while the one Gump currently builds does not. So if you build Cocoon the normal way you get the additional dependencies for free (and without control over their version, I may add). I'll see whether I can make the Xalan build produce the same jar that can be found in the mvn repo - looks possible - and once Gump produces that I think the cocoon-sax build will be fixed. You should be able to remove the bcel test dependency as well after that. Stefan
Re: Help needed on finalizing the JAXB optional support
Hi all guys, any hint on it? Please! :P Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Jun 26, 2010 at 7:11 PM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all guys, I resolved the Collection Generic type problem[1], but the question about the plural stemmer/inflector is still open, can anyone help me please? Thanks in advance, have a nice weekend :) Simo [1] http://tinyurl.com/23bpwnc r958243 http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 24, 2010 at 10:49 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all, a month ago I started developing the JAXB optional support for C3 pipeline, with a lot of limits: * each time a new object has to be mashalled, the JAXBContext were created, now it uses a memory-based LRU cache; * it supported just POJOs graphs, without any support for collections and array. I was able to plug the array support (see cocoon-optional r936231) but after several tries I had to resign to discover collections generic type at runtime; I also checked-out the Jersey source code to see how do they extract this information, but I got lost :( So, my first question is: can anyone help me please? :P Moreover, for Collection/Array object, there is the need that the root element name of the marshalled document is the plural of the list; I found two existing implementations for this purpose: * the Apache Betwixt PluralStemmer [1] * the Jersey Inflector [2] I personally find the Jersey implementation much more complete but it is not licensed under the Apache license. So my question is: can I extract part of that class to include in our software? Is that allowed? Many thanks in advance, have a nice day Simo [1] http://tinyurl.com/376ehs9 [2] http://tinyurl.com/3yqbssj http://people.apache.org/~simonetripodi/ http://www.99soft.org/
[C3] needed step to alpha-3
Hi all guys, this email just to remind the steps have to be completed to before the alpha-3 release. Jira issues have to be created. After the alpha-2 release, in the last development time of C3, 3 new pipeline components have been developed/improved that have to be integrated in the sitemap: - org.apache.cocoon.sax.component.XIncludeTransformer - org.apache.cocoon.sax.component.LogTransformer - org.apache.cocoon.sax.component.LogAsXMLTransformer A new optional component has to be completed due to the plural stememer/inflator technical/legal issue: - org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGenerator The following components have to be implemented as cacheable: - org.apache.cocoon.sax.component.XIncludeTransformer - org.apache.cocoon.sax.component.XSLTTransformer - org.apache.cocoon.sax.component.SchemaProcessorTransformer once completed all these subtasks, IMHO we're ready to release the alpha-3 :) All the best, yours, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [C3] needed step to alpha-3
Hi all guys, just to be sure to put black on white, I opened the Jira issues to track all these requirements. Have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Aug 12, 2010 at 8:59 PM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all guys, this email just to remind the steps have to be completed to before the alpha-3 release. Jira issues have to be created. After the alpha-2 release, in the last development time of C3, 3 new pipeline components have been developed/improved that have to be integrated in the sitemap: - org.apache.cocoon.sax.component.XIncludeTransformer - org.apache.cocoon.sax.component.LogTransformer - org.apache.cocoon.sax.component.LogAsXMLTransformer A new optional component has to be completed due to the plural stememer/inflator technical/legal issue: - org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGenerator The following components have to be implemented as cacheable: - org.apache.cocoon.sax.component.XIncludeTransformer - org.apache.cocoon.sax.component.XSLTTransformer - org.apache.cocoon.sax.component.SchemaProcessorTransformer once completed all these subtasks, IMHO we're ready to release the alpha-3 :) All the best, yours, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: Cocoon 3 status?
Hi Hugh, unfortunately we've been being very busy due to our main job. But our intention is continuing Cocoon3 development and we are coming back soon :) APIs are in alpha that means that classes/methods can appear and disappear without warnings, but code on /trunk is quite stable. Stay tuned!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Nov 22, 2010 at 8:26 PM, Hugh Sparks h...@csparks.com wrote: Could someone please review the political and technical status of Cocoon 3? I notice that posts and svn activity stopped rather suddenly... Thanks! -Hugh Sparks
[C3] Pipeline DSL
Hi all guys, I just committed a first working spike of a Pipeline DSL[1] to expose more fluent APIs to final users to help them correctly creating and running pipelines, built on top of pipeline APIs. I also modified a test to show how to use the new APIs. WDYT? Every feedback/suggestion would be much more than appreciated!!! Have a nice day, Simo [1] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/builder [2] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/PipelineTest.java#testPipelineWithCompiledXSLT() http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [C3] Pipeline DSL
Hi Robby, I perfectly agree with you!!! even if I'm conservative I recently started having the feeling of a subset of functional APIs that really simplify the objects creation/setup. Pipeline for example, even if has a very simple and intuitive APIs, sometimes are subject to users misinterpretation, with the new builder users are forced to follow the right workflow. Yet another good example of functional Java is LamdaJ (http://code.google.com/p/lambdaj/) that looks very similar to your stuff; that should put an emphasis on java users need of functional APIs. Back to Cocoon: unfortunately I don't know C2.X, since I began directly with C3... but I agree with Jos, you can safely choose for C3 :P Thanks for the feedback and have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Dec 8, 2010 at 4:47 AM, Jos Snellings jos.snelli...@pandora.be wrote: Good point. I would say: everything you need and even more is there! For people who were familiar with 2.2 or who want to port their application: they are going to miss flowscript. For people who lost contact in version 2.1 or so, they will probably be missing xsp as a presentation scripting, and then get used to the rigid separation line imposed by StringTemplate. So my message would be: cocoon3 is 'gewöhnungsbedürftig', but you can safely choose for it. There is a non-vanishing upgrade effort involved. Jos On 12/07/2010 10:54 PM, Robby Pelssers wrote: Hi Simoni, i think it's indeed more fluent and more explicit. So I think it certainly is an improvement. Only a few days back I wrote a mail to my fellow Java team members complaining that Java feels like a big fat bloated beast more and more with lack of expressiveness and higher order functions. Especially after playing with functional languages. And Guava and functionaljava are good examples... Hell, I even am experimenting myself with similar stuff ;-) http://code.google.com/p/functionalprogramming/wiki/Introduction By the way... If I were to jump on the Cocoon 3 wagon... would i be able to do the same stuff already as with 2.2? Or let me rephrase the question... is most stuff already ported to 3.0? Cheers, Robby Pelssers -Oorspronkelijk bericht- Van: Simone Tripodi [mailto:simone.trip...@gmail.com] Verzonden: di 7-12-2010 21:39 Aan: dev@cocoon.apache.org Onderwerp: [C3] Pipeline DSL Hi all guys, I just committed a first working spike of a Pipeline DSL[1] to expose more fluent APIs to final users to help them correctly creating and running pipelines, built on top of pipeline APIs. I also modified a test to show how to use the new APIs. WDYT? Every feedback/suggestion would be much more than appreciated!!! Have a nice day, Simo [1] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/builder [2] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/PipelineTest.java#testPipelineWithCompiledXSLT() http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [C3] Pipeline DSL
Hi Robby, nope we're not using Saxon and we can't since, AFAIK, there are legal issue due to different licenses, but I don't know more details. For the same reason Saxon is not present in any of public Maven central repo. HTH, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Dec 8, 2010 at 10:38 AM, Robby Pelssers robby.pelss...@ciber.com wrote: Just reading through lamdaj. They use proxies... interesting... Anyway, I'm having some strange bugs in a big C2.2 application I built and what worries me is I can't reproduce them locally ;-( Flowscript is nice but it becomes dangerous when you start building reusable flowscript components which you might even share between cocoon blocks. Refactoring has to be done with great care since Eclipse will not blink an eye. PS. One question. Are you using saxon8.7 with cocoon3? Kind regards, Robby -Oorspronkelijk bericht- Van: Simone Tripodi [mailto:simone.trip...@gmail.com] Verzonden: wo 8-12-2010 8:22 Aan: dev@cocoon.apache.org Onderwerp: Re: [C3] Pipeline DSL Hi Robby, I perfectly agree with you!!! even if I'm conservative I recently started having the feeling of a subset of functional APIs that really simplify the objects creation/setup. Pipeline for example, even if has a very simple and intuitive APIs, sometimes are subject to users misinterpretation, with the new builder users are forced to follow the right workflow. Yet another good example of functional Java is LamdaJ (http://code.google.com/p/lambdaj/) that looks very similar to your stuff; that should put an emphasis on java users need of functional APIs. Back to Cocoon: unfortunately I don't know C2.X, since I began directly with C3... but I agree with Jos, you can safely choose for C3 :P Thanks for the feedback and have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Dec 8, 2010 at 4:47 AM, Jos Snellings jos.snelli...@pandora.be wrote: Good point. I would say: everything you need and even more is there! For people who were familiar with 2.2 or who want to port their application: they are going to miss flowscript. For people who lost contact in version 2.1 or so, they will probably be missing xsp as a presentation scripting, and then get used to the rigid separation line imposed by StringTemplate. So my message would be: cocoon3 is 'gewöhnungsbedürftig', but you can safely choose for it. There is a non-vanishing upgrade effort involved. Jos On 12/07/2010 10:54 PM, Robby Pelssers begin_of_the_skype_highlighting end_of_the_skype_highlighting wrote: Hi Simoni, i think it's indeed more fluent and more explicit. So I think it certainly is an improvement. Only a few days back I wrote a mail to my fellow Java team members complaining that Java feels like a big fat bloated beast more and more with lack of expressiveness and higher order functions. Especially after playing with functional languages. And Guava and functionaljava are good examples... Hell, I even am experimenting myself with similar stuff ;-) http://code.google.com/p/functionalprogramming/wiki/Introduction By the way... If I were to jump on the Cocoon 3 wagon... would i be able to do the same stuff already as with 2.2? Or let me rephrase the question... is most stuff already ported to 3.0? Cheers, Robby Pelssers -Oorspronkelijk bericht- Van: Simone Tripodi [mailto:simone.trip...@gmail.com] Verzonden: di 7-12-2010 21:39 Aan: dev@cocoon.apache.org Onderwerp: [C3] Pipeline DSL Hi all guys, I just committed a first working spike of a Pipeline DSL[1] to expose more fluent APIs to final users to help them correctly creating and running pipelines, built on top of pipeline APIs. I also modified a test to show how to use the new APIs. WDYT? Every feedback/suggestion would be much more than appreciated!!! Have a nice day, Simo [1] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-pipeline/src/main/java/org/apache/cocoon/pipeline/builder [2] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/test/java/org/apache/cocoon/sax/PipelineTest.java#testPipelineWithCompiledXSLT() http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [C3] Pipeline DSL
Hi David thanks for the feedback!!! Looking forward to include Saxon in C3, that's great news! Thanks once again! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Dec 14, 2010 at 1:22 AM, David Crossley cross...@apache.org wrote: Simone Tripodi wrote: Hi Robby, nope we're not using Saxon and we can't since, AFAIK, there are legal issue due to different licenses, but I don't know more details. For the same reason Saxon is not present in any of public Maven central repo. HTH, Simo It seems that Saxon-HE would be okay. http://www.saxonica.com/documentation/conditions/intro.xml http://apache.org/legal/resolved.html#category-b -David Robby Pelssers wrote: Just reading through lamdaj. They use proxies... interesting... Anyway, I'm having some strange bugs in a big C2.2 application I built and what worries me is I can't reproduce them locally ;-( Flowscript is nice but it becomes dangerous when you start building reusable flowscript components which you might even share between cocoon blocks. Refactoring has to be done with great care since Eclipse will not blink an eye. PS. One question. Are you using saxon8.7 with cocoon3? Kind regards, Robby
[C3] Pipeline DSL - part two
Hi all guys, after a generic Pipeline DSL, I recently added also a SAX Pipeline DSL[1] to build SAX pipelines in an easier and more fluent way. Feedbacks and contributions are more than welcome, thanks in advance!!! Simo [1] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/builder http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: Preparing releases: cocoon-maven-plugin, cocoon-jnet, cocoon-thien-maven-site-skin
+1 for me, there I don't see any blocking issue. thanks for taking care about it! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jan 4, 2011 at 4:27 PM, Peter Hunsberger peter.hunsber...@gmail.com wrote: On Tue, Jan 4, 2011 at 1:51 AM, Reinhard Pötz reinh...@apache.org wrote: On 01/04/2011 03:38 AM, Peter Hunsberger wrote: On Mon, Jan 3, 2011 at 5:36 PM, Reinhard Pötzreinh...@apache.org wrote: +1 - I'm not completely sure about whether 1.0 is completely correct in some cases, but OTOH I don't think it's worth worrying about... Neither am I but changing any contracts without some deprecation phase in the cocoon-maven-plugin or the site-skin wouldn't be very helpful to the existing users. And, there's always the chance of a 2.x release ;-) Hah. I won't say, not in my life time, but I'm sure not going to hold my breath -- Peter Hunsberger
Re: [vote] Release Cocoon JNet 1.2.0, Cocoon Maven Plugin 1.0.0 Cocoon Maven Site Skin 1.0.0
Sorry to have taken so much time to check, but here comes my +1! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jan 18, 2011 at 6:34 PM, Peter Hunsberger peter.hunsber...@gmail.com wrote: On Tue, Jan 18, 2011 at 11:22 AM, Reinhard Pötz reinh...@apache.org wrote: I created release artifacts for following modules: This majority vote stays open for at least 72 hours. Please cast your votes. Thanks. Won't be able to look at these until I get home tonight, but +1 -- Peter Hunsberger
Re: [c3] Log*Transformer
Hi all,
I'd tend agree with Reinhard if the CloseShield functionality is not
simple (and I mean very simple, almost silly) to replicate into our
module.
I'm sure the CloseShield in the IO takes care of more general
PrintStream use cases rather then just the sysout, so I'm worried that
the proposed patch is not enough...
Just my 0.02 cents,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
2011/2/18 Francesco Chicchiriccò francesco.chicchiri...@tirasa.net:
On 18/feb/2011, at 20.28, Reinhard Pötz wrote:
I had to comment the usage of the Log*Transformers in the sample sitemap
because they break the integration tests (run it.sh or it.bat from C3's root
directory). The problem is that the logfile is written to the file system
which doesn't work in a multi-module build (map:parameter name=logfile
value=target/logasxml.log / - there is no target directory at the base
directory).
IMO the best idea would be changing the transformer configurations to use
System.out but the current implementations close the output stream in their
finish methods. That's of course useful for FileOutputStreams but mustn't
happen for System.out.
IMO the best solution would be wrapping the usage of System.out with Commons
IO's CloseShieldOutputStream
(http://s.apache.org/commons-io-close-shield-outputstream). However, this
would introduce a dependency of cocoon-sax on commons-io which should be
avoided for a minor use case like this.
I see two possible solutions:
a) move the Log*Transformers to cocoon-optional and wrap the usage
of System.out with the CloseShieldOutputStream
b) implement the CloseShield functionality ourselves and leave them
where they are.
I would prefer option a) because it's the simpler solution and leads to less
code.
WDYT?
What if we choose a third option, like changing
this.outputStream.close();
to
if (System.out.equals(this.outputStream)) {
this.outputStream.flush();
} else {
this.outputStream.close();
}
in the finish() body, for both transformers?
I made these simple modifications (in the attached patch) and, at least on my
machine, the integration tests are running successfully.
Let me know if this solution is acceptable, thanks.
Regards.
Welcome Francesco Chicchiriccò as new Cocoon Committer
Hi all, Francesco's nomination has been accepted. He got 7 positive votes and no negative one. Congratulations Francesco and welcome! Francesco, it's a good tradition here to introduce yourself. Thanks in advance, have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [c3] Log*Transformer
on a side note: Francesco, did you receive the account activation? It's been a while now and looks like it's taking time... please let me know! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Feb 22, 2011 at 3:15 PM, Reinhard Pötz reinh...@apache.org wrote: On 02/21/2011 11:32 AM, Francesco Chicchiriccò wrote: On 21/feb/2011, at 10.56, Simone Tripodi wrote: Hi all, I'd tend agree with Reinhard if the CloseShield functionality is not simple (and I mean very simple, almost silly) to replicate into our module. I'm sure the CloseShield in the IO takes care of more general PrintStream use cases rather then just the sysout, so I'm worried that the proposed patch is not enough... For the sake of clarity: I've proposed that naive patch mainly because I think that Log*Transformers are there to be used only for dev purpose, where System.out or FileOutpuStream are the only viable candidates. Anyway, I've taken a quick look to http://s.apache.org/commons-io-close-shield-outputstream and its parent class http://bit.ly/h7AolY: it seems to me that it would be quite easy to embed these two classes in order to have a CloseShield functionality in cocoon3-sax. If you think that it could be useful to have such functionality there (also for usage by other classes than just Log*Transformers), please let me know. I think the patch with the simple approach is good enough in this case because the class encapsulates the usage of the output stream completely. (It would be different if an output stream was passed to the transformer ...) Since you get commit access to the repository soon, you can apply the patch yourself ;-) Congratulations BTW! -- 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] Log*Transformer
Hi again, Francesco, did you receive your account activation? If not...: Reinhard, do you know who I have to ping? Many thanks in advance! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/2/25 Francesco Chicchiriccò francesco.chicchiri...@tirasa.net: On 25/02/2011 09:57, Simone Tripodi wrote: on a side note: Francesco, did you receive the account activation? It's been a while now and looks like it's taking time... please let me know! Hi Simone, unfortunately nothing has arrived so far :-( On Tue, Feb 22, 2011 at 3:15 PM, Reinhard Pötzreinh...@apache.org wrote: On 02/21/2011 11:32 AM, Francesco Chicchiriccò wrote: On 21/feb/2011, at 10.56, Simone Tripodi wrote: Hi all, I'd tend agree with Reinhard if the CloseShield functionality is not simple (and I mean very simple, almost silly) to replicate into our module. I'm sure the CloseShield in the IO takes care of more general PrintStream use cases rather then just the sysout, so I'm worried that the proposed patch is not enough... For the sake of clarity: I've proposed that naive patch mainly because I think that Log*Transformers are there to be used only for dev purpose, where System.out or FileOutpuStream are the only viable candidates. Anyway, I've taken a quick look to http://s.apache.org/commons-io-close-shield-outputstream and its parent class http://bit.ly/h7AolY: it seems to me that it would be quite easy to embed these two classes in order to have a CloseShield functionality in cocoon3-sax. If you think that it could be useful to have such functionality there (also for usage by other classes than just Log*Transformers), please let me know. I think the patch with the simple approach is good enough in this case because the class encapsulates the usage of the output stream completely. (It would be different if an output stream was passed to the transformer ...) Since you get commit access to the repository soon, you can apply the patch yourself ;-) Congratulations BTW! -- 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 -- # Dott. Francesco Chicchiriccò Amministratore unico Tel +393290573276 Tirasa S.r.l. Via Pescara Tel / FAX +3908500 http://www.tirasa.net To Iterate is Human, to Recurse, Divine (James O. Coplien, Bell Labs) #
Re: [c3] Log*Transformer
OK thanks, let's wait and be patient :) have a nice evening, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Feb 28, 2011 at 9:34 PM, Reinhard Pötz reinh...@apache.org wrote: On 02/28/2011 09:28 AM, Simone Tripodi wrote: Hi again, Francesco, did you receive your account activation? If not...: Reinhard, do you know who I have to ping? It's not unusual if it takes a week or two to get an account created ... -- 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] *LinkRewriterTransformer
Hi Francesco, I had a look at your final proposal and IMHO looks very fine. I suggest you can commit it without any side-issue then continue working on it if needed. Well done, I'd say ;) Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/3/10 Francesco Chicchiriccò ilgro...@apache.org: Hi gents, since a while we have in C3 cocoon-sax sources an AbstractLinkRewriterTransformer that, inspired by C2.1 and C2.2 LinkRewriterTransformers, provides all means to intercept all links in the source document and delegates any effective operation to an abstract rewrite() method. The issue [1] is about making such transformer sitemap-compliant: of course, an abstract class cannot be meant under such consideration. For this reason, based on some Simone's ideas, I wrote a RegexpLinkRewriterTransformer extending the abstract class above and providing a mean to define link rewriting based on standard java regular expressions. Moreover, the sitemap-compliancy is shown by an extension of current cocoon-sample. Ah, and finally running './it.sh' seems to be working ;-) All that is, for the moment, included in a patch attached to [1]: do you see any problem in committing such code? Do you think that such implementation could be meaningful / useful? Do you see any possible update / extension? Thanks. [1] https://issues.apache.org/jira/browse/COCOON3-56 -- Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Plural Stemmer/Inflactor - part 2
Hi all guys, I (maybe) fixed the issue, can you please check legal issues we could have on the attached patch as reported on COCOON3-58, please? Many thanks in advance, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: Plural Stemmer/Inflactor - part 2
Hi Reinhard! did you have the chance to have a quick look at the patch? If it is ok for you, I'll perform my initial commit. Thanks in advance! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Apr 7, 2011 at 10:30 AM, Reinhard Pötz reinh...@apache.org wrote: On 04/02/2011 12:26 PM, Francesco Chicchiriccò wrote: On 02/04/2011 12:03, Simone Tripodi wrote: Hi all guys, I (maybe) fixed the issue, can you please check legal issues we could have on the attached patch as reported on COCOON3-58, please? I am not at all a legal expert but if the possible TM issue is limited to regexp patterns, I don't think there could be anything to claim about. I think so too. -- 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] replacing the logging framework
Hi all guys, Reinhard, Francesco and I had a quick chat on tweeter about replacing the logging framework in C3 and we all agreed on migrating to SLF4J + Logback. IMHO it is an operation simple enough that can be completed before proceeding to next release, what does someone else think about it? If there isn't any objection, I can take easily take care of it, just let me know! Have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [C3] replacing the logging framework
Hi all guys, thanks for your feedbacks, I didn't change any single line of code indeed before hearing about possible side-effects. I agree with Jasha, let's release the alpha-3 first, then adding improvements in future releases! I can take care of making the release - any advice before I start? :) Thanks in advance, have a nice day!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Apr 26, 2011 at 1:26 PM, Jasha Joachimsthal j.joachimst...@onehippo.com wrote: On 26 April 2011 13:24, Reinhard Pötz reinh...@apache.org wrote: On 04/23/2011 04:56 PM, Simone Tripodi wrote: Hi all guys, Reinhard, Francesco and I had a quick chat on tweeter about replacing the logging framework in C3 and we all agreed on migrating to SLF4J + Logback. IMHO it is an operation simple enough that can be completed before proceeding to next release, what does someone else think about it? If there isn't any objection, I can take easily take care of it, just let me know! I guess you're right with the pipeline and sitemap modules, but I expect it to be more difficult for the servlet module. The question _for now_ is whether we have to replace the logging framework there at all and keep the Spring configurator's log4j integration instead. Changing the servlet module to use the slf4j/log4j binding could be done later. But I'm not sure if this plan works as expected ... I think we've been waiting for the alpha-3 release long enough. Why not ship it as is and then do the logging framework changes in an alpha-4 release? Jasha Joachimsthal j.joachimst...@onehippo.com - ja...@apache.org Hippo Europe • Amsterdam • Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • Boston • 1 Broadway • Cambridge, MA 02142 • +1 877 414 4776 (toll free) www.onehippo.com • www.onehippo.org • i...@onehippo.com
Re: svn commit: r1096155 - in /cocoon/cocoon3/trunk/cocoon-optional/src: main/java/org/apache/cocoon/optional/pipeline/components/sax/jaxb/ test/java/org/apache/cocoon/optional/pipeline/components/sax
Apologizes ;( I accidentally modified the matching pattern before committing, then I broke the build; anyway I already fixed it on trunk, it works now (Francesco already confirmed in chat :P) Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Apr 27, 2011 at 6:50 PM, Reinhard Pötz reinh...@apache.org wrote: On 04/23/2011 04:49 PM, simonetrip...@apache.org wrote: Author: simonetripodi Date: Sat Apr 23 14:49:10 2011 New Revision: 1096155 URL: http://svn.apache.org/viewvc?rev=1096155view=rev Log: fix for COCOON3-58: The org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGenerator is incomplete test cases included Unfortunately this commit breaks the build: --- Test set: org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGeneratorTestCase --- Tests run: 6, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.802 sec FAILURE! testPipelineWithUncountableNamedBean(org.apache.cocoon.optional.pipeline.components.sax.jaxb.JAXBGeneratorTestCase) Time elapsed: 0.004 sec ERROR! java.lang.IndexOutOfBoundsException: No group 1 at java.util.regex.Matcher.group(Matcher.java:470) at java.util.regex.Matcher.appendReplacement(Matcher.java:737) at java.util.regex.Matcher.replaceFirst(Matcher.java:861) at org.apache.cocoon.optional.pipeline.components.sax.jaxb.PluralStemmer.toPlural(PluralStemmer.java:187) snip/ -- 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
[OGNL] PPMC members, please subscribe to private ML!
Hi all guys, thanks to Gavin, we've now a fully working ognl-private@, please subscribe!!! Thanks in advance, have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
[C3] StAX pipeline improvement
Hi all guys, I just received a feedback from Tatu Saloranta (the Woodstox author) via Twitter[1] about the XMLOutputFactory.newInstance(); usage. Does it make sense improve it before the release (which in I'm terribly late but first attempts failed :P) Have a nice day, all the best! Simo [1] http://twitter.com/#!/cowtowncoder/status/74898782231330816 http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [OGNL] PPMC members, please subscribe to private ML!
Sorry guys, wrong ML!!! I had to send to commons@ :D Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, May 28, 2011 at 1:31 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, thanks to Gavin, we've now a fully working ognl-private@, please subscribe!!! Thanks in advance, have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [C3] StAX pipeline improvement
totally agreed, +1 Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/5/30 Francesco Chicchiriccò ilgro...@apache.org: On 30/05/2011 08:31, Simone Tripodi wrote: Hi all guys, I just received a feedback from Tatu Saloranta (the Woodstox author) via Twitter[1] about the XMLOutputFactory.newInstance(); usage. Does it make sense improve it before the release (which in I'm terribly late but first attempts failed :P) Simone, I would personally prefer to create an issue for this - very nice - suggestion, to be maybe addressed to the first beta release: as soon as I can understand, it is about performance improvement, isn't it? -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: [C3] Fwd: [Hippo-cms7-user] Cocoon 3 based frontend
Great achievement Francesco, congrats!!! the good news is that starting from tomorrow morning I'll be on forced vacations for a long time and I have a lot of spare time to dedicate to OSS, so potentially starting from tomorrow morning we can have an Alpha3 release candidate!!! So, if it would help, I'll start the release process paying much more care than the first attempt. HTH, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/6/8 Francesco Chicchiriccò ilgro...@apache.org Hi there, fist of all, sorry for the cross-posting. You can find below an e-mail that I've just sent to the Hippo CMS mailing list. There is some concrete possibility to use Cocoon 3 in a (rather small, as said) production environment. I would basically like to build a JCR SAX transformer (similar in functions to the Cocoon 2.1 WebDAV transformer) but I would also need, for example, some caching and i18n features. Do you see any particular issues besides the obvious risk of using an Alpha-2 (not yet Alpha-3) software for production? ;-) Messaggio originale Oggetto: [Hippo-cms7-user] Cocoon 3 based frontend Data: Wed, 08 Jun 2011 12:02:32 +0200 Mittente: Francesco Chicchiriccò francesco.chicchiri...@tirasa.netfrancesco.chicchiri...@tirasa.net Rispondi-a: Hippo CMS 7 development public mailinglist hippo-cms7-u...@lists.onehippo.com hippo-cms7-u...@lists.onehippo.com Organizzazione: Tirasa A: Hippo CMS 7 development public mailinglist hippo-cms7-u...@lists.onehippo.com hippo-cms7-u...@lists.onehippo.com Hi all, we've recently got a (rather small, indeed) customer with a very particular need: to be able, in the near future, to migrate either all the documents from its current legacy CMS and also all of its Cocoon 2.1 sites. They basically want to preserve - as much as possible - past investments done in terms of XSLTs and components. We are now defining the basic structure of our project and we do want to put Hippo CMS 7.6 in place. Of course this would mean to replace all the HST2 stuff that is normally involved when building sites with some Cocoon-based components. Looking at the documentation, I've found this reference to the Hippo's JCR interface [1]. Do you think it would be fine to build something that will interact with Hippo repository at that level or instead there are some higher-level classes from HST2 that should instead taken into account? Do you have any particular advice when doing such operation? Is there any more documentation we should take a look at? Thanks. [1] http://www.onehippo.org/cms7/documentation/development/content+repository/jcr/index.html -- Dott. Francesco Chicchiriccò Tel +393290573276 Amministratore unico @ Tirasa S.r.l. Viale D'Annunzio 267 - 65127 Pescara Tel +39 0859116307 / FAX +39 085973http://www.tirasa.net Apache Cocoon Committer and PMC Memberhttp://people.apache.org/~ilgrosso/ To Iterate is Human, to Recurse, Divine (James O. Coplien, Bell Labs) ___ Hippo-cms7-user mailing list and forumshttp://www.onehippo.org/cms7/support/forums.html
[C3] Release process clarification needed
Hi Reinhard/all, can someone explain me please what the third point in the RELEASE_HOWTO.txt means: * set all versions in the generated pom.xml files of all archetypes I didn't see where poms have been generated... thanks in advance!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [C3] Release process clarification needed
thanks a lot for your kind help Reinhard!!! sorry for my lack of knowledge of Groovy, but... do I need an interpreter to install to execute it? Many thanks in advance!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Jun 8, 2011 at 11:19 PM, Reinhard Pötz reinh...@apache.org wrote: On 06/08/2011 09:16 PM, Simone Tripodi wrote: Hi Reinhard/all, can someone explain me please what the third point in the RELEASE_HOWTO.txt means: * set all versions in the generated pom.xml files of all archetypes I didn't see where poms have been generated... thanks in advance!!! I've just updated the RELEASE_HOWTO.txt. HTH I also fixed the sample and the block archetype. To make things clearer for cocoon-archetype-sample: the sample-archetype uses a Groovy script to generate the assembly descriptor on the fly based on the content of cocoon-sample and copies all relevant resources to src/main/resources/archetype-resources Maybe there are better ways to achieve this goal with 'standard' Maven plugins in the meantime ... -- 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] Release process clarification needed
thanks a lot Reinhard, I'm an idiot and started downloading Groovy, installing... :) I'll let you know my progresses, thanks for your help! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 7:43 AM, Reinhard Pötz reinh...@apache.org wrote: On 06/08/2011 11:26 PM, Simone Tripodi wrote: thanks a lot for your kind help Reinhard!!! sorry for my lack of knowledge of Groovy, but... do I need an interpreter to install to execute it? Many thanks in advance!!! No, that's done by the GMaven plugin automatically for you. See the pom.xml of the cocoon-archetype-sample module. -- 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
[VOTE] Release Apache Cocoon 3.0.0-alpha-3
Hi all guys, I'm here to propose the release of Apache Cocoon 3.0.0-alpha-3. Tags can be found on https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-all/cocoon-all-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-archetype-block/cocoon-archetype-block-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-archetype-parent/cocoon-archetype-parent-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-archetype-sample/cocoon-archetype-sample-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-archetype-webapp/cocoon-archetype-webapp-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-controller/cocoon-controller-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-docs/cocoon-docs-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-monitoring/cocoon-monitoring-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-optional/cocoon-optional-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-parent/cocoon-parent-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-pipeline/cocoon-pipeline-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-rest/cocoon-rest-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-sample/cocoon-sample-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-sax/cocoon-sax-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-stax/cocoon-stax-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-profiling/cocoon-profiling-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-profiling-firebug/cocoon-profiling-firebug-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-optional/cocoon-optional-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-servlet/cocoon-servlet-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-sitemap/cocoon-sitemap-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-stringtemplate/cocoon-stringtemplate-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-wicket/cocoon-wicket-3.0.0-alpha-3/ Maven artifacts can be found on people.apache.org: /www/people.apache.org/builds/cocoon/org/apache/cocoon/archetype-webapp/cocoon-archetype-webapp/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/servlet/cocoon-servlet/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/wicket/cocoon-wicket/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/root/cocoon-root/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/stax/cocoon-stax/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/sax/cocoon-sax/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/optional/cocoon-optional/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/profiling/cocoon-profiling/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/stringtemplate/cocoon-stringtemplate/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/archetype-block/cocoon-archetype-block/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/parent/cocoon-parent/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/sitemap/cocoon-sitemap/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/pipeline/cocoon-pipeline/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/sample/cocoon-sample/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/monitoring/cocoon-monitoring/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/archetype-parent/cocoon-archetype-parent/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/rest/cocoon-rest/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/archetype-sample/cocoon-archetype-sample/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/controller/cocoon-controller/3.0.0-alpha-3 Vote will be open for next 72 hours and will be closed on June 12th at 5:00pm CET. So please cast your votes [ ] +1, let's release Apache Cocoon 3.0.0-alpha-3 [ ] +/- 0 [ ] -1, because (explain the reason why) Many thanks in advance, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [VOTE] Release Apache Cocoon 3.0.0-alpha-3
tests and IT worked on my env: simonetripodi$ mvn --version Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_24 Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x version: 10.6.7 arch: x86_64 Family: mac my GPG key: Simone Tripodi (simonetripodi) simonetrip...@apache.org 1024-bit DSA key, ID 19FEA27D, created 2010-03-24 is distributed on keyservers so that's my +1 http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 7:06 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I'm here to propose the release of Apache Cocoon 3.0.0-alpha-3. Tags can be found on https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-all/cocoon-all-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-archetype-block/cocoon-archetype-block-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-archetype-parent/cocoon-archetype-parent-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-archetype-sample/cocoon-archetype-sample-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-archetype-webapp/cocoon-archetype-webapp-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-controller/cocoon-controller-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-docs/cocoon-docs-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-monitoring/cocoon-monitoring-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-optional/cocoon-optional-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-parent/cocoon-parent-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-pipeline/cocoon-pipeline-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-rest/cocoon-rest-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-sample/cocoon-sample-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-sax/cocoon-sax-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-stax/cocoon-stax-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-profiling/cocoon-profiling-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-profiling-firebug/cocoon-profiling-firebug-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-optional/cocoon-optional-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-servlet/cocoon-servlet-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-sitemap/cocoon-sitemap-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-stringtemplate/cocoon-stringtemplate-3.0.0-alpha-3/ https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/cocoon-wicket/cocoon-wicket-3.0.0-alpha-3/ Maven artifacts can be found on people.apache.org: /www/people.apache.org/builds/cocoon/org/apache/cocoon/archetype-webapp/cocoon-archetype-webapp/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/servlet/cocoon-servlet/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/wicket/cocoon-wicket/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/root/cocoon-root/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/stax/cocoon-stax/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/sax/cocoon-sax/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/optional/cocoon-optional/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/profiling/cocoon-profiling/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/stringtemplate/cocoon-stringtemplate/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/archetype-block/cocoon-archetype-block/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/parent/cocoon-parent/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/sitemap/cocoon-sitemap/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/pipeline/cocoon-pipeline/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/sample/cocoon-sample/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/monitoring/cocoon-monitoring/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/archetype-parent/cocoon-archetype-parent/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/rest/cocoon-rest/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/archetype-sample/cocoon-archetype-sample/3.0.0-alpha-3 /www/people.apache.org/builds/cocoon/org/apache/cocoon/controller/cocoon-controller/3.0.0-alpha-3 Vote
Re: [VOTE] Release Apache Cocoon 3.0.0-alpha-3
Hi Reinhard! just a couple of minor questions for now: a) where I can find the KEYS file on svn? I'm pretty sure I updated it once, but can't remember if it was the cocoon or commons one that I'm referring... thanks in advance! :P b) artifacts in http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-3/ are the ones automatically updated by maven, that's why there is some missing... anyway, since they already have been signed by gpg-plugin, can we reuse them with signatures/md5/sha attached? Have a nice day, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Jun 9, 2011 at 11:37 PM, Reinhard Pötz reinh...@apache.org wrote: On 06/09/2011 11:22 PM, Reinhard Pötz wrote: On 06/09/2011 07:06 PM, Simone Tripodi wrote: [ ] +1, let's release Apache Cocoon 3.0.0-alpha-3 [x] +/- 0 [ ] -1, because (explain the reason why) Thanks for your great efforts! There are two things that need to be done before I can vote with +1 a) Please add you PGP key to http://www.apache.org/dist/cocoon/KEYS b) We also need a non-Maven (yes, there are still people that don't use the central Maven repo) distribution. You don't have to redo the release for that reason. Checkout the release tag, go to cocoon-all/pom.xml and apply the changes that I've just comitted to your working copy. Then run mvn clean package -P apache-release which will create the release artifacts. At this point the PGP signature files are missing because the creation of the release artifacts doesn't happen as part of the Maven release procedure. Hence sign the created .zip and .tar.gz files manually (gpg -sba [filename] should to the trick, at least with Linux GPG) and upload them to your people.apache.org public html folder so that others can check them before they cast their votes. Otherwise the Maven release artifacts are fine AFAICS. I've updated my Cocoon 3 projects and they all work well with alpha-3. One thing I forgot to mention: There are distribution release artifacts in http://people.apache.org/builds/cocoon/org/apache/cocoon/all/cocoon-all/3.0.0-alpha-3/ but they are lacking the docs and some submodules. Sorry, I haven't thought sooner of it :-( One final note: The distribution release artifacts don't need to be copied to the central Maven repository sync folder when the vote is completed. I've just updated the release notes. -- 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: [VOTE] Release Apache Cocoon 3.0.0-alpha-3
Thanks both Reinhard and David, I uploaded my key, after lunch I'll fill the missing distribution package! Have a nice weekend, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 11:53 AM, David Crossley cross...@apache.org wrote: Reinhard Pötz wrote: Simone Tripodi wrote: a) where I can find the KEYS file on svn? I'm pretty sure I updated it once, but can't remember if it was the cocoon or commons one that I'm referring... thanks in advance! :P I think you have to update it directly in our release directory on people.apache.org. David, is this correct? Yes. I just now did ssh people.apache.org and looked in /www/www.apache.org/dist/cocoon The 'svn info' shows that most peripheral files are managed in SVN at https://svn.apache.org/repos/asf/cocoon/site/mirrors/ but KEYS is not. FWIW, at Forrest we do. I also checked and the httpd project does too. -David
Re: [VOTE] Release Apache Cocoon 3.0.0-alpha-3
Hi Reinhard, I'm experiencing difficulties on finalizing the distribution packages (maybe I'm trying to manage too much things at the same time :/) Can we arrange a chat on skype/gtalk/whatever when you have some spire time? I need your help to finalize it. Many thanks in advance, have a nice day!!! All the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Jun 11, 2011 at 12:03 PM, Simone Tripodi simonetrip...@apache.org wrote: Thanks both Reinhard and David, I uploaded my key, after lunch I'll fill the missing distribution package! Have a nice weekend, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 10, 2011 at 11:53 AM, David Crossley cross...@apache.org wrote: Reinhard Pötz wrote: Simone Tripodi wrote: a) where I can find the KEYS file on svn? I'm pretty sure I updated it once, but can't remember if it was the cocoon or commons one that I'm referring... thanks in advance! :P I think you have to update it directly in our release directory on people.apache.org. David, is this correct? Yes. I just now did ssh people.apache.org and looked in /www/www.apache.org/dist/cocoon The 'svn info' shows that most peripheral files are managed in SVN at https://svn.apache.org/repos/asf/cocoon/site/mirrors/ but KEYS is not. FWIW, at Forrest we do. I also checked and the httpd project does too. -David
Re: Patch list reminders
Hi guys, can you give more hints how to do it? It was indeed a nice service, if I have enough karma I can take care of it. Just let me know, many thanks in advance! have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Jun 17, 2011 at 8:38 AM, David Crossley cross...@apache.org wrote: Andy Stevens wrote: Is it just me, or have there been no Subscription: COCOON-open-with-patch emails from JIRA since the middle of February? Has something gone wrong with the link? That is correct. The technique used to send that report was closed down due to other security concerns. There is email to Cocoon private@ around that time. Some Cocoon PMC person needs to reconfigure our JIRA. Thanks for your interest. -David
