Re: COCOON3-126, xslt cache
Hi Jos, the most important thing is IMHO having the XSLT transformer dependencies-less as much as we can - I suggest to define a cache interface (with a basic implementation) provided to XSLT transformer (via constructor), then users are free to use whatever implementation they need/prefer. Having a default implementation would be a strict constraint, while users should be able to plug their integration module depending to their use case. Does it sound reasonable? I have ~0 spare cycles to OSS ATM, but I promise to have a look at your patch during the WE, so I can at least provide you more feedbacks. Have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi On Tue, Jul 2, 2013 at 11:19 AM, Jos Snellings jos.snelli...@upperware.biz wrote: Hi Francesco et al, I proposed a patch for COCOON3-126, on the configurability of using an LRU cache for xslt transformations. I am not too happy with it though. I would like to have a member function to set isCacheEnabled, or to set this at setup. However, the resource is loaded in the constructor. Would it be better to add a boolean isCacheEnabled' to a constructor, leaving the default to yes? What do you think? Kind regards, Jos -- We should be careful to get out of an experience only the wisdom that is in it - and stay there, lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again - and that is well; but also she will never sit down on a cold one any more. -- Mark Twain
Re: COCOON3-126, xslt cache
We can work out a proposal during the weekend, (though it will be very nice weather in Belgium). we are having sunny days in Rome as well (finally!) so I'll do some work in the night on the terrace :) have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://twitter.com/simonetripodi
Re: [VOTE] Apache Cocoon Servlet Service Implementation 1.3.2
+1 charming release, congrats Francesco! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Dec 13, 2012 at 10:54 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: I've created a Cocoon Servlet Service Implementation 1.3.2 release, with the following artifacts up for a vote: SVN source tag (r1421170): https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/tags/cocoon-servlet-service-impl-1.3.2/ List of changes: https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-servlet-service-impl/tags/cocoon-servlet-service-impl-1.3.2/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-008/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-008/org/apache/cocoon/cocoon-servlet-service-impl/1.3.2/cocoon-servlet-service-impl-1.3.2-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Cocoon Integration Test Framework 1.0.1
+1 and thanks for the hard work! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Dec 13, 2012 at 2:37 PM, Peter Hunsberger peter.hunsber...@gmail.com wrote: On Thu, Dec 13, 2012 at 3:16 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: I've created a Cocoon Integration Test Framework 1.0.1 release, with the following artifacts up for a vote: Vote will be open for 72 hours. Can't really test at the moment but +1
Re: [DISCUSS] C3 tagging
Definitively +1 I think part is inherited by the history - at the C3 early days, it was the time when maven-release-plugin didn't really work well and everybody wrote his own rant-blog-post about it. It looks like that today things have changed and maven-release-plugin is no longer in his beta-so-far-from-stable status, so no reason why to not update. Many thanks in advance for taking care of it! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Dec 13, 2012 at 11:25 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: Hi all, I'd like to understand whether there is any particular reason behind the way tags are created for C3 releases [1] by a dedicated script [2], instead of letting the maven-release-plugin manage tags by following the standard layout. If there are no objections, I'd propose to empower the maven-release-plugin for managing the whole C3 release process; I would also like to update and move [3] to a dedicate page on the website. All this to be proven and refined for upcoming 3.0.0-beta-1 release. WDYT? Regards. [1] https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/ [2] https://svn.apache.org/repos/asf/cocoon/cocoon3/tags/BEFORE_COCOON3-105/svn-release-tags.sh [3] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/RELEASE_HOWTO.txt -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
[Discuss] Sitemap NG
Hi all guys,
I've had this mail draft for a long while and I think it's time to
shout it out to get your feedbacks.
Due to my involvement in Apache Commons and being strongly influenced
by the Google-Guice design, I think we could get benefit from a vision
that mixes the power of:
* modularity;
* Embedded DSL.
The current situation is that the sitemap takes tons of Kb of Spring
dependencies (please assume I'm not a big fan of Spring so my POV is
influenced :P) and the sitemap is described via XML. Since we can
still take the XML configuration, I'm sure - but I haven't had the
time to write even a kickoff spike, so I still don't have the proof on
hands - we could simplify the foundation of sitemap design, getting
benefits from the javac using directly the Java language to describe
the sitemap.
What I'd suggest is introducing Sitemap(s) to describe how the
sitemap is organized, i.e.
+-+
interface Sitemap
{
void configure( SitemapBinder binder );
}
+-+
where the {{SitemapBinder}} contains a set of APIs to allow describing
the path-matching; a possible case could be:
+-+
public class MySitemap
implements Sitemap
{
public void configure( SitemapBinder binder )
{
binder.when( linkmap.xml )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
...
binder.when( linkmap2.xml )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed2.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax2.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
...
}
}
+-+
that would reflect what in XML would be expressed as:
+-+
map:match pattern=linkmap.xml
map:generate src=classpath:feed /
map:transform src={lm:transform.linkmap.document}/
map:serialize type=xml /
/map:match
...
map:match pattern=linkmap2.xml
map:generate src=classpath:feed2 /
map:transform src={lm:transform.linkmap.document}/
map:serialize type=xml /
/map:match
...
+-+
of course, XML looks compact, but please take in consideration that
XML is not type checking, we can get errors at runtime only; that
means that a transformer can be erroneously set as generator, while
using Java APIs it would be notified at compile time.
An AbstractSitemap would help to reduce the `binder` variable verbose
and redundant call:
+-+
public class MySitemap
extends AbstractSitemap
{
@Override
public void configure()
{
when( linkmap.xml )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
...
when( linkmap2.xml )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed2.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax2.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
...
}
}
+-+
we could also work by Sitemap composition:
+-+
public class MySitemap
implements Sitemap
{
public void configure( SitemapBinder binder )
{
binder.when( linkmap.xml )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
...
binder.include( new MySitemap2() );
...
}
}
+-+
then a special loader is used to create the application:
+-+
SitemapLoader.load( Sitemap...sitemaps );
+-+
WDYT?
TIA, all the best,
-Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
Re: [Discuss] Sitemap NG
Hi Peter!
My proposal is writing an intermediate layer to create sitemaps, it
doesn't aim to replace the existing infrastructure but IMHO it could
be used as the foundation to create sitemaps; while all textual
configurations work fine, having a more expressive and type checking
APIs could help - and users could still wrap them in their bigger
picture, making the tree objects construction easier.
You could have a look at the Apache Commons Digester binder[1] APIs,
which are wrapped by the XML configuration[2] and annotated
elements[3]. One expressive layer to create the sitemap, multiple way
to bind them.
I agree that building tree objects would still work, but Fluent
Interfaces would help on respecting the configuration status, i.e. the
first element of a Pipeline can only be a Starter, when using the old
way users are still able to setup a pipeline with no starter and find
the error only when executing it.
I am sure there are cases I am not taking in consideration that would
break my PoC as well :P
what do you think? You would be still able to load a graph from Neo4j
and setup the pipeline using directly native Java APIs - no parsing,
no transforming, a little faster :P
Many thanks in advance, all the best!
-Simo
[1] http://commons.apache.org/digester/guide/binder.html
[2] http://commons.apache.org/digester/guide/xmlrules.html
[3] http://commons.apache.org/digester/guide/annotations.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Aug 6, 2012 at 4:21 PM, Peter Hunsberger
peter.hunsber...@gmail.com wrote:
Hi Simone,
long time ago we had discussions on alternate languages for the C2 Sitemap,
I used to want to do them in XSLT (as opposed to XML) with Java extensions
to implement the actual interface from the XSLT to the resulting Cocoon
object tree for the sitemap. These days I sometimes wonder if I could build
sitemaps in Neo4J and have Cocoon read them in via it's Neo4Js REST
interface (or more directly)...
In some ways it seems Cocoon 3 is already aimed at most of what you outline
or is this in addition to the way you can do Java pipelines there?
Peter Hunsberger
On Mon, Aug 6, 2012 at 2:50 AM, Simone Tripodi simonetrip...@apache.org
wrote:
Hi all guys,
I've had this mail draft for a long while and I think it's time to
shout it out to get your feedbacks.
Due to my involvement in Apache Commons and being strongly influenced
by the Google-Guice design, I think we could get benefit from a vision
that mixes the power of:
* modularity;
* Embedded DSL.
The current situation is that the sitemap takes tons of Kb of Spring
dependencies (please assume I'm not a big fan of Spring so my POV is
influenced :P) and the sitemap is described via XML. Since we can
still take the XML configuration, I'm sure - but I haven't had the
time to write even a kickoff spike, so I still don't have the proof on
hands - we could simplify the foundation of sitemap design, getting
benefits from the javac using directly the Java language to describe
the sitemap.
What I'd suggest is introducing Sitemap(s) to describe how the
sitemap is organized, i.e.
+-+
interface Sitemap
{
void configure( SitemapBinder binder );
}
+-+
where the {{SitemapBinder}} contains a set of APIs to allow describing
the path-matching; a possible case could be:
+-+
public class MySitemap
implements Sitemap
{
public void configure( SitemapBinder binder )
{
binder.when( linkmap.xml )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
...
binder.when( linkmap2.xml )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed2.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax2.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
...
}
}
+-+
that would reflect what in XML would be expressed as:
+-+
map:match pattern=linkmap.xml
map:generate src=classpath:feed /
map:transform src={lm:transform.linkmap.document}/
map:serialize type=xml /
/map:match
...
map:match pattern=linkmap2.xml
map:generate src=classpath:feed2 /
map:transform src={lm:transform.linkmap.document}/
map:serialize type=xml /
/map:match
...
+-+
of course, XML looks compact, but please take in consideration that
XML is not type checking, we can get errors at runtime only; that
means that a transformer can be erroneously set as generator, while
using Java APIs
Re: [Discuss] Sitemap NG
Hi Peter!
apologize for not having been more precise on explaining my idea:
while they look similar, I would consider the Sitemap a superset of
pure Pipeline fluent APIs.
Indeed, while a Sitemap woud _describe_ an action would be performed
if the current pattern matches against the input, the Pipeline APIs
would _invoke_ a Pipeline. i.e.
+-+
public class MySitemap
implements Sitemap
{
public void configure( SitemapBinder binder )
{
binder.when( linkmap.xml )
.newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
binder.when( atom.xml )
.newCachingPipeline()
.setStarter( new SQLTransformer( ... )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/atom.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer );
}
}
+-+
would be different than direct pipeline executions
+-+
newCachingPipeline()
.setStarter( new XMLGenerator(new URL( feed.xml ) )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/trax.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer )
.setup( System.out )
.execute();
newCachingPipeline()
.setStarter( new SQLTransformer( ... )
.addComponent( new
XSLTTransformer(this.getClass().getResource(/atom.xslt) )
.setFinisher( XMLSerializer.createXMLSerializer )
.setup( System.out )
.execute();
+-+
The setup-execute phases, in the pipeline, would be executed by the
Sitemap framework.
best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Aug 6, 2012 at 5:40 PM, Peter Hunsberger
peter.hunsber...@gmail.com wrote:
Hi Simone,
I guess the part I'm missing is how would this differ from what is already
in Cocoon 3 as an API? I do get that part (most, all?) of you objective is
to get rid of the Spring layer, so maybe the end result is essentially the
same as the C3 API in the end?
Peter Hunsberger
On Mon, Aug 6, 2012 at 10:33 AM, Simone Tripodi simonetrip...@apache.org
wrote:
Hi Peter!
My proposal is writing an intermediate layer to create sitemaps, it
doesn't aim to replace the existing infrastructure but IMHO it could
be used as the foundation to create sitemaps; while all textual
configurations work fine, having a more expressive and type checking
APIs could help - and users could still wrap them in their bigger
picture, making the tree objects construction easier.
You could have a look at the Apache Commons Digester binder[1] APIs,
which are wrapped by the XML configuration[2] and annotated
elements[3]. One expressive layer to create the sitemap, multiple way
to bind them.
I agree that building tree objects would still work, but Fluent
Interfaces would help on respecting the configuration status, i.e. the
first element of a Pipeline can only be a Starter, when using the old
way users are still able to setup a pipeline with no starter and find
the error only when executing it.
I am sure there are cases I am not taking in consideration that would
break my PoC as well :P
what do you think? You would be still able to load a graph from Neo4j
and setup the pipeline using directly native Java APIs - no parsing,
no transforming, a little faster :P
Many thanks in advance, all the best!
-Simo
[1] http://commons.apache.org/digester/guide/binder.html
[2] http://commons.apache.org/digester/guide/xmlrules.html
[3] http://commons.apache.org/digester/guide/annotations.html
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Mon, Aug 6, 2012 at 4:21 PM, Peter Hunsberger
Orphaned Cocoon repository on Nexus
Hi all guys, last week I noticed we have an orphaned repo *org.apache.cocoon-042* on Nexus - Francesco, is it still in pipe or it can be dropped? TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: [VOTE] Apache Cocoon XML Utilities 2.0.4
+1 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jun 15, 2012 at 10:36 PM, Peter Hunsberger peter.hunsber...@gmail.com wrote: +1 Peter Hunsberger On Fri, Jun 15, 2012 at 2:40 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: I've created a Cocoon XML Utilities 2.0.4 release, with the following artifacts up for a vote:
Re: [VOTE] Apache Cocoon Maven Plugin 1.0.2
+1 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jun 15, 2012 at 10:36 PM, Peter Hunsberger peter.hunsber...@gmail.com wrote: +1 Peter Hunsberger On Fri, Jun 15, 2012 at 2:47 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: I've created a Cocoon Maven Plugin 1.0.2 release, with the following artifacts up for a vote:
Re: [VOTE] Apache Cocoon Spring Configurator 2.2.1
+1 http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jun 15, 2012 at 10:38 PM, Peter Hunsberger peter.hunsber...@gmail.com wrote: +1 Peter Hunsberger On Fri, Jun 15, 2012 at 2:56 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: I've created a Cocoon Spring Configurator 2.2.1 release, with the following artifacts up for a vote:
Re: [VOTE] Apache Cocoon Serializers Charsets 1.0.2
[X] +1 approve http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: [VOTE] Apache Cocoon Block Deployment 1.2.1
[X] +1 approve http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: [VOTE] Apache Cocoon Integration Test Framework 1.0.0
[X] +1 approve http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Jun 8, 2012 at 11:16 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: I've created a Cocoon Integration Test Framework 1.0.0 release, with the following artifacts up for a vote: SVN source tag (r1347959): https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.0/ List of changes: https://svn.apache.org/repos/asf/cocoon/subprojects/cocoon-it-fw/tags/cocoon-it-fw-1.0.0/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-210/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-210/org/apache/cocoon/cocoon-it-fw/1.0.0/cocoon-it-fw-1.0.0-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Apache Cocoon Configuration API 1.0.4
[X] +1 approve http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: [VOTE] Apache Cocoon Reloading ClassLoader - Spring reloader 1.0.2
[X] +1 approve http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: [VOTE] Apache Cocoon Reloading ClassLoader - Webapp Wrapper 1.0.2
[X] +1 approve http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
[jira] [Commented] (COCOON3-62) The org.apache.cocoon.sax.component.XSLTTransformer is not cacheable
[ https://issues.apache.org/jira/browse/COCOON3-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291732#comment-13291732 ] Simone Tripodi commented on COCOON3-62: --- I am not sure that the current implemented cache policy would definitively fix the issue - IIUC in that way, even if XSL is invoked with different parameters, it returns the same content... Is there something I miss? TIA, -Simo The org.apache.cocoon.sax.component.XSLTTransformer is not cacheable Key: COCOON3-62 URL: https://issues.apache.org/jira/browse/COCOON3-62 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-3 Reporter: Simone Tripodi Assignee: Francesco Chicchiriccò Fix For: 3.0.0-beta-1 The org.apache.cocoon.sax.component.XSLTTransformer component is not a cacheable component, but it is needed to implement it as cacheable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COCOON3-62) The org.apache.cocoon.sax.component.XSLTTransformer is not cacheable
[ https://issues.apache.org/jira/browse/COCOON3-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13291740#comment-13291740 ] Simone Tripodi commented on COCOON3-62: --- sounds reasonable - could you add more test cases to make sure it doesn't cache the same content? best, -Simo The org.apache.cocoon.sax.component.XSLTTransformer is not cacheable Key: COCOON3-62 URL: https://issues.apache.org/jira/browse/COCOON3-62 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-3 Reporter: Simone Tripodi Assignee: Francesco Chicchiriccò Fix For: 3.0.0-beta-1 The org.apache.cocoon.sax.component.XSLTTransformer component is not a cacheable component, but it is needed to implement it as cacheable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (COCOON3-62) The org.apache.cocoon.sax.component.XSLTTransformer is not cacheable
[ https://issues.apache.org/jira/browse/COCOON3-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi reopened COCOON3-62: --- invocations with different parameters always get back the same content from cache The org.apache.cocoon.sax.component.XSLTTransformer is not cacheable Key: COCOON3-62 URL: https://issues.apache.org/jira/browse/COCOON3-62 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-sax Affects Versions: 3.0.0-alpha-3 Reporter: Simone Tripodi Assignee: Francesco Chicchiriccò Fix For: 3.0.0-beta-1 The org.apache.cocoon.sax.component.XSLTTransformer component is not a cacheable component, but it is needed to implement it as cacheable -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] Apache Cocoon parent 9
not sure sources package is need here, since the pom itself cannot be distributed in binary form, anyway everything looks good [X] +1 approve thanks *a lot* for the hard work! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Jun 5, 2012 at 11:36 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: On 05/06/2012 10:59, Francesco Chicchiriccò wrote: I've created a Cocoon parent 9 release, with the following artifacts up for a vote: SVN source tag (r1346276): https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon/cocoon-9/ List of changes: https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon/cocoon-9/src/changes/changes.xml Maven staging repo: https://repository.apache.org/content/repositories/orgapachecocoon-186/ Source release (checksums and signatures are available at the same location): https://repository.apache.org/content/repositories/orgapachecocoon-186/org/apache/cocoon/cocoon/9/cocoon-9-source-release.zip PGP release keys (signed using 273DF287): http://www.apache.org/dist/cocoon/KEYS Vote will be open for 72 hours. [ ] +0 no opinion [ ] -1 disapprove (and reason why) +1 -- Francesco Chicchiriccò ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [VOTE] Javier Puerto as cocoon committer
+1 apologize for arriving late! best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, May 31, 2012 at 12:43 AM, David Legg david.l...@searchevent.co.uk wrote: On 28/05/12 09:26, Thorsten Scherler wrote: I propose Javier Puerto as a new Cocoon committer and PMC member. +1 Regards, David Legg
Re: Cocoon at Codeplex?
I'm going to follow-up the discussion - unless if you want to do it - on trademarks@ for any clarification. Thanks a lot for reporting, please let me know! best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, May 6, 2012 at 7:42 AM, Francesco Chicchiriccò ilgro...@apache.org wrote: Matter for legal? http://cocoon.codeplex.com/ -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
potential SAX builder helper class
Hi all guys, One thing I've always found a little annoying - boring is maybe the more appropriate therm - of SAX APIs is that, when crating even simple XML snippets via ContentHandler APIs, the following boilerplate code has to be written: ++ ContentHandler handler = ... ; contentHandler.startDocument(); contentHandler.startElement( , project, project, new AttributesImpl() ); contentHandler.startElement( , modelVersion, modelVersion, new AttributesImpl() ); String modelVersion = 4.0.0; contentHandler.characters( modelVersion.toCharArray(), 0, modelVersion.length() ); contentHandler.endElement( , modelVersion, modelVersion ); contentHandler.endElement( , project, project, new AttributesImpl() ); contentHandler.endDocument(); ++ I think you would agree with me that to obtain the following snippet ++ ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion /project ++ that code is maybe an overkill :P So, at company I developed a small SAX wrapper that would help on transforming the previous code in the following: ++ ContentHandler handler = ... ; SAXEventsBuilder.newDocument( transformerHandler ) .start( project ) .start( modelVersion ).body( 4.0.0 ).end() .end() .endDocument(); ++ isn't more sexy? It still supports elements that require namespaces/attributes but reduces the lines of code for hardcoded XML documents - especially when closing elements. It also allows users to add manually-generated elements in an existing ContentHandler: ++ ContentHandler handler = ... ; SAXEventsBuilder.wrap( transformerHandler ) .start( modelVersion ).body( 4.0.0 ).end() .start( groupId ).body( org.apache.cocoon.sax ).end() .start( artifactId ).body( cocoon-sax ).end() .start( version ).body( 3.0.0-beta-1 ).end() ++ without starting/closing the document. If you like it, I would be pleased to commit it in the Cocoon repo - as a side question: which component that would fill? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: potential SAX builder helper class
thanks a lot for the quick reply Robby! do you already have an idea where that class should be placed? TIA! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Apr 23, 2012 at 4:40 PM, Robby Pelssers robby.pelss...@nxp.com wrote: Looks definitely like an improvement in usability. +1 Robby -Original Message- From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of Simone Tripodi Sent: Monday, April 23, 2012 4:36 PM To: dev@cocoon.apache.org Subject: potential SAX builder helper class Hi all guys, One thing I've always found a little annoying - boring is maybe the more appropriate therm - of SAX APIs is that, when crating even simple XML snippets via ContentHandler APIs, the following boilerplate code has to be written: ++ ContentHandler handler = ... ; contentHandler.startDocument(); contentHandler.startElement( , project, project, new AttributesImpl() ); contentHandler.startElement( , modelVersion, modelVersion, new AttributesImpl() ); String modelVersion = 4.0.0; contentHandler.characters( modelVersion.toCharArray(), 0, modelVersion.length() ); contentHandler.endElement( , modelVersion, modelVersion ); contentHandler.endElement( , project, project, new AttributesImpl() ); contentHandler.endDocument(); ++ I think you would agree with me that to obtain the following snippet ++ ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion /project ++ that code is maybe an overkill :P So, at company I developed a small SAX wrapper that would help on transforming the previous code in the following: ++ ContentHandler handler = ... ; SAXEventsBuilder.newDocument( transformerHandler ) .start( project ) .start( modelVersion ).body( 4.0.0 ).end() .end() .endDocument(); ++ isn't more sexy? It still supports elements that require namespaces/attributes but reduces the lines of code for hardcoded XML documents - especially when closing elements. It also allows users to add manually-generated elements in an existing ContentHandler: ++ ContentHandler handler = ... ; SAXEventsBuilder.wrap( transformerHandler ) .start( modelVersion ).body( 4.0.0 ).end() .start( groupId ).body( org.apache.cocoon.sax ).end() .start( artifactId ).body( cocoon-sax ).end() .start( version ).body( 3.0.0-beta-1 ).end() ++ without starting/closing the document. If you like it, I would be pleased to commit it in the Cocoon repo - as a side question: which component that would fill? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: potential SAX builder helper class
OK, thanks a lot! will do it in a short while, just the time to ASF-ize the codebase :P best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/4/23 Francesco Chicchiriccò ilgro...@apache.org: On 23/04/2012 16:35, Simone Tripodi wrote: Hi all guys, One thing I've always found a little annoying - boring is maybe the more appropriate therm - of SAX APIs is that, when crating even simple XML snippets via ContentHandler APIs, the following boilerplate code has to be written: ++ ContentHandler handler = ... ; contentHandler.startDocument(); contentHandler.startElement( , project, project, new AttributesImpl() ); contentHandler.startElement( , modelVersion, modelVersion, new AttributesImpl() ); String modelVersion = 4.0.0; contentHandler.characters( modelVersion.toCharArray(), 0, modelVersion.length() ); contentHandler.endElement( , modelVersion, modelVersion ); contentHandler.endElement( , project, project, new AttributesImpl() ); contentHandler.endDocument(); ++ I think you would agree with me that to obtain the following snippet ++ ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion /project ++ that code is maybe an overkill :P So, at company I developed a small SAX wrapper that would help on transforming the previous code in the following: ++ ContentHandler handler = ... ; SAXEventsBuilder.newDocument( transformerHandler ) .start( project ) .start( modelVersion ).body( 4.0.0 ).end() .end() .endDocument(); ++ isn't more sexy? It still supports elements that require namespaces/attributes but reduces the lines of code for hardcoded XML documents - especially when closing elements. It also allows users to add manually-generated elements in an existing ContentHandler: ++ ContentHandler handler = ... ; SAXEventsBuilder.wrap( transformerHandler ) .start( modelVersion ).body( 4.0.0 ).end() .start( groupId ).body( org.apache.cocoon.sax ).end() .start( artifactId ).body( cocoon-sax ).end() .start( version ).body( 3.0.0-beta-1 ).end() ++ without starting/closing the document. If you like it, I would be pleased to commit it in the Cocoon repo - as a side question: which component that would fill? Hi Simone, looks fine and helpful to me, +1 I'd put it in cocoon-sax, under org.apache.cocoon.sax.util package. Cheers. -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: potential SAX builder helper class
done, see r1329308 - happy hacking! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Apr 23, 2012 at 4:57 PM, Simone Tripodi simonetrip...@apache.org wrote: OK, thanks a lot! will do it in a short while, just the time to ASF-ize the codebase :P best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/4/23 Francesco Chicchiriccò ilgro...@apache.org: On 23/04/2012 16:35, Simone Tripodi wrote: Hi all guys, One thing I've always found a little annoying - boring is maybe the more appropriate therm - of SAX APIs is that, when crating even simple XML snippets via ContentHandler APIs, the following boilerplate code has to be written: ++ ContentHandler handler = ... ; contentHandler.startDocument(); contentHandler.startElement( , project, project, new AttributesImpl() ); contentHandler.startElement( , modelVersion, modelVersion, new AttributesImpl() ); String modelVersion = 4.0.0; contentHandler.characters( modelVersion.toCharArray(), 0, modelVersion.length() ); contentHandler.endElement( , modelVersion, modelVersion ); contentHandler.endElement( , project, project, new AttributesImpl() ); contentHandler.endDocument(); ++ I think you would agree with me that to obtain the following snippet ++ ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion /project ++ that code is maybe an overkill :P So, at company I developed a small SAX wrapper that would help on transforming the previous code in the following: ++ ContentHandler handler = ... ; SAXEventsBuilder.newDocument( transformerHandler ) .start( project ) .start( modelVersion ).body( 4.0.0 ).end() .end() .endDocument(); ++ isn't more sexy? It still supports elements that require namespaces/attributes but reduces the lines of code for hardcoded XML documents - especially when closing elements. It also allows users to add manually-generated elements in an existing ContentHandler: ++ ContentHandler handler = ... ; SAXEventsBuilder.wrap( transformerHandler ) .start( modelVersion ).body( 4.0.0 ).end() .start( groupId ).body( org.apache.cocoon.sax ).end() .start( artifactId ).body( cocoon-sax ).end() .start( version ).body( 3.0.0-beta-1 ).end() ++ without starting/closing the document. If you like it, I would be pleased to commit it in the Cocoon repo - as a side question: which component that would fill? Hi Simone, looks fine and helpful to me, +1 I'd put it in cocoon-sax, under org.apache.cocoon.sax.util package. Cheers. -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: an issue with Cocoon source package release vote
Good morning David, if an action is required to fix the release, so +1. Cocoon 2.X people: are you following? :) -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Apr 5, 2012 at 7:40 AM, David Crossley cross...@apache.org wrote: Please see the following thread at Apache Forrest which explains the problem with conducting our release vote on a package that contained not only our project sources but also contained other binary files. That thread links to an important discussion at Apache Incubator, etc. Subject: [Proposal] re-release 0.9 with proper source code package http://s.apache.org/mCW There would be a similar situation for the Cocoon-2.1.11 release vote. -David
Re: [DISCUSS] Moving subprojects tools under /
@Francesco: no objections from my side, +1 @Peter: why do we have the proceed a vote? Isn't lazy consensus enough for that situation? TIA!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Apr 9, 2012 at 4:43 PM, Peter Hunsberger peter.hunsber...@gmail.com wrote: Makes sense from what I understand of the issue. I think you should just take a vote... Peter Hunsberger 2012/4/9 Francesco Chicchiriccò ilgro...@apache.org HI all, a while ago [1] we discussed (and almost agreed) a new structure for our SVN, even though we haven't yet been able to agree on a schedule for performing all related activities. A part of [1] was about moving some modules, used by both C2.2 and C3, to an independent place. Recently I also proposed to apply some pending changes to some of such modules (cocoon-xml, cocoon-servlet-service, ...). Hence, I would like to move modules under [2], [3] and [4] under a new directory [5], create separate trunk, branches and tags subdirs, and modify POMs in order to make each module independent. Do you see any issue with this? TIA. Regards. [1] http://markmail.org/search/?q=subprojects#query:subprojects%20list%3Aorg.apache.cocoon.dev+page:1+mid:d3sinv7vo66pko4m+state:results [2] https://svn.apache.org/repos/asf/cocoon/trunk/subprojects/ [3] https://svn.apache.org/repos/asf/cocoon/trunk/tools/ [4] https://svn.apache.org/repos/asf/cocoon/trunk/blocks/cocoon-serializers/cocoon-serializers-charsets/ [5] https://svn.apache.org/repos/asf/cocoon/subprojects/ -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: c3 pipelines (was Re: [jira] [Commented] (COCOON3-96) Add support for internal-only pipelines)
I second that concern since I am hitting lately some frontiers opposed by that sitemap focused view. IMO *.xmap in the end should be a wrapper to configure spring registered pipes. +1000!!! :) Some old school configure methods had sneaked into some componentes and I think we should clean up some methods and ways to change attributes in general. For example the difference between configure() and setup() is IMO not justifiable to maintain. Further the complete usage of java based pipelines need to better be synced with the sitemap. I need to be able to look up pipelines configured by the sitemap in a java only context. can you believe that today I still get in trouble with that? If it is confusing for me, I can imagine what users can think - not that I am good, but of course more familiar that newcomers However the principal difference ATM is that in xmap the hierarchy is pipe-match-components but match is in no way part of the java pipe api. Leading to the current situation where both are treated completely separated. However components such as regexpLinkRewriter and i18nTransformer should be configured in a spring context to be reusable in a hybrid environment. In one of our projects I had to duplicate the effort to configure this. It is a lesser evil decisions for now but I am keen to change it in the near future. So bottom line IMHO c3 pipes being java or xmap should be usable vice versa otherwise they cause double of work. +1 ...and if we think abstract the look up of a java pipe in xmap env would be fire the request matching a pattern. What comes within a match are basically a java pipe. The only thing is to integrate the input module/language interpreter into the java pipe logic to make xmap pipes usable as java pipe. in the CLI module I started working on that, even if with a different format that xmap - even if not complete yet (I feel shame for not having completed yet) it shows anyway that injecting config parameters to pipeline without the Map context is possible Having worked with all versions and supporting projects that are hybrids of c2.x and c3 I have to admit if we can think of the traditional 2.x sitemap as config for spring and we can lookup and (re)use the matches in both environments than we are so much more than the leading xml framework since 1998. Since finally our Lego(tm) web components (generators, transformers, ...) are not bound to avalon and reusable everywhere. Having said that, we need to sometimes expose much more setters in our components to break away from the xmap and vice versa to expose setup() method to configure the component via sitemap. The parameter based configuration proofed to be quick and flexible to configure components in both environments. ...maybe we even can implement map:invoke-method name=setup|... ... for components and configure them in a more general way. ... with the benefit in reusing the logic in different environments. I will write a summary of java pipes in c3 after we go online with the main project we based on c3, but that may take at least 2 months. You have my full support, please let me know if/how we can cooperate! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
[jira] [Commented] (COCOON3-96) Add support for internal-only pipelines
[
https://issues.apache.org/jira/browse/COCOON3-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13245561#comment-13245561
]
Simone Tripodi commented on COCOON3-96:
---
Hi Grosso!
well done and thanks for taking care! just a request: can we move the
{{isInternalOnly}} detail outside the Pipeline APIs? I mean, that is a method
needed in the sitemap, while Pipeline APis have to be work as a library also
outside Cocoon, it doesn't make a lot of sense to users - like me (blush) -
that are focused on the lower level library only.
How those kind of users should interpret it, outside the Cocoon product?
TIA
-Simo
Add support for internal-only pipelines
-
Key: COCOON3-96
URL: https://issues.apache.org/jira/browse/COCOON3-96
Project: Cocoon 3
Issue Type: Improvement
Components: cocoon-sitemap
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
Fix For: 3.0.0-beta-1
Cocoon 2.1 [1] and 2.2 [2] used to have support for internal-only pipelines,
i.e. pipelines evaulated for internal (i.e. cocoon:/) requests only.
Such feature would be very useful in C3 as well, of course replacing
cocoon:/ with servlet:/
[1] http://cocoon.apache.org/2.1/faq/faq-sitemap.html
[2] http://cocoon.apache.org/2.2/core-modules/core/2.2/835_1_1.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [cocoon3] why setup()?
Hi mate, IIRC, but I could be wrong, the reason is more historical than real need, to make APIs elastic enough for both Sitemap/programmatic executions. Anyway, there are still some things I contine getting confused about the APIs, but I'll discuss them in a separated thread. Thanks a lot for the feedbacks, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Mar 30, 2012 at 12:57 AM, Christian Grobmeier grobme...@gmail.com wrote: Hello folks, I was looking at cocoon3 Pipeline interface. I saw: setup(OutputStream outputStream) setup(OutputStream outputStream, MapString,Object parameters) It seem one always needs to call setup() (which makes sense). But why is there a method like this? Couldn't it be the execute method which takes the OutputStream? execute(OutputStream outputStream) execute(OutputStream outputStream, MapString,Object parameters) One would get rid of setup - this feels more natural to me at first glance. Cheers Christian -- http://www.grobmeier.de https://www.timeandbill.de
Re: [DISCUSS] online APIs doc
You can update the whole site - dind't have the chance unfortunately to link produced javadocs, so feel free to push them if you have time! best and thanks, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/3/23 Francesco Chicchiriccò ilgro...@apache.org: On 20/03/2012 08:46, Simone Tripodi wrote: Hi all guys, after many users request - last just received on user@ - I would suggest to deploy APIs doc on SVN to make them available online. If no objections will be shown in the next 72h, I'll proceed on deploying the C3 - guess I'll need help on deploying the C2.X versions. WDYT? No objects were found and more than 72 hours passed, hence I am about to publish C2.1 and C2.2 javadocs. Simone, how is the situation for C3's? Cheers. -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [C3] Merge parent and cocoon-docs [WAS Re: [DISCUSS] online APIs doc]
thanks a lot for the hard work Francesco, you're the Cocoon Champion of the month!!! +1 for your proposal, it makes a lot of sense. no reason to wait IMHO, you could safety go ahead :) all the best and thanks once again, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/3/23 Francesco Chicchiriccò ilgro...@apache.org: On 23/03/2012 10:39, Simone Tripodi wrote: You can update the whole site - dind't have the chance unfortunately to link produced javadocs, so feel free to push them if you have time! Javadocs for C2.1 and C2.2 are online. About C3, I have a little issue. Currently, site generation is handled by cocoon-docs: this is causing me troubles when I try to add javadoc reporting, since aggregation [1] seems to work for submodules. Hence my proposal: why don't we simply merge cocoon-docs into parent so site generation (including javadoc reporting) takes place there? WDYT? Regards. [1] http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html 2012/3/23 Francesco Chicchiriccò ilgro...@apache.org: On 20/03/2012 08:46, Simone Tripodi wrote: Hi all guys, after many users request - last just received on user@ - I would suggest to deploy APIs doc on SVN to make them available online. If no objections will be shown in the next 72h, I'll proceed on deploying the C3 - guess I'll need help on deploying the C2.X versions. WDYT? No objects were found and more than 72 hours passed, hence I am about to publish C2.1 and C2.2 javadocs. Simone, how is the situation for C3's? Cheers. -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: [C3] Merge parent and cocoon-docs [WAS Re: [DISCUSS] online APIs doc]
Hi Francesco, thanks a lot once again for the HARD work! I agree that this is not the nicer solution, we can do a little step better: IMHO the root parent pom has to become the parent. It allows listing all the modules just once and we can simplify the structure, see Apache Any23 or Apache Amber or Apache DirectMemory. thoughts? many thanks in advance and have a nice weekend! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/3/23 Francesco Chicchiriccò ilgro...@apache.org: Hi all, I have just finished merging cocoon-docs into parent; I've also updated RELEASE_HOWTO.txt and cocoon-all assembly. Generating site docs is now available via mvn -P reports site-deploy -Ddocs.deploymentBaseUrl=file://[path-to-site] from the 'parent' module. Updated website and javadocs have been published. Unfortunately, I had to list modules inside reports profile (otherwise javadoc reports would have not been generated), leading to a situation in which modules are listed either in root POM and in parent POM. I am not satisfied of this, but I wasn't able to find a better solution: any idea? Maybe it's time to give a little refactor to our POM structure... Regards. On 23/03/2012 14:57, Robby Pelssers wrote: Amen !! -Original Message- From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of Simone Tripodi Sent: Friday, March 23, 2012 2:56 PM To: dev@cocoon.apache.org Subject: Re: [C3] Merge parent and cocoon-docs [WAS Re: [DISCUSS] online APIs doc] thanks a lot for the hard work Francesco, you're the Cocoon Champion of the month!!! +1 for your proposal, it makes a lot of sense. no reason to wait IMHO, you could safety go ahead :) all the best and thanks once again, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/3/23 Francesco Chicchiriccò ilgro...@apache.org: On 23/03/2012 10:39, Simone Tripodi wrote: You can update the whole site - dind't have the chance unfortunately to link produced javadocs, so feel free to push them if you have time! Javadocs for C2.1 and C2.2 are online. About C3, I have a little issue. Currently, site generation is handled by cocoon-docs: this is causing me troubles when I try to add javadoc reporting, since aggregation [1] seems to work for submodules. Hence my proposal: why don't we simply merge cocoon-docs into parent so site generation (including javadoc reporting) takes place there? WDYT? Regards. [1] http://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html 2012/3/23 Francesco Chicchiriccò ilgro...@apache.org: On 20/03/2012 08:46, Simone Tripodi wrote: Hi all guys, after many users request - last just received on user@ - I would suggest to deploy APIs doc on SVN to make them available online. If no objections will be shown in the next 72h, I'll proceed on deploying the C3 - guess I'll need help on deploying the C2.X versions. WDYT? No objects were found and more than 72 hours passed, hence I am about to publish C2.1 and C2.2 javadocs. Simone, how is the situation for C3's? Cheers. -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
[RESULT][VOTE] release Apache Cocoon Thien Maven Skin 1.0.1
Hi all, more than 72h have passed and I consider the vote concluded and passes with the following resolution: three +1 binding votes from PMCs: * Francesco Chicchiriccò * Robby Pelssers * Thorsten Scherler no other votes were casted. I'm going to proceed on moving artifacts on Nexus. Thanks everybody took part in the review process. All the best, have a nice day, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Mar 19, 2012 at 5:57 PM, Thorsten Scherler scher...@gmail.com wrote: On 03/17/2012 01:47 PM, Simone Tripodi wrote: Hi all, last year I did some work on the Thien Skin in order to match the brand requirements from ASF, you can see the Cocoon 3 site where logo has the ™ character and the footer reports the needed disclaimer. I also took advantage to optimize js/css, now included in compressed version, the code google-code-prettify has been updated and optimized at site generation time. So, time to make a new release and update docs :) Notice that I didn't change the release procedure because the skin is still included in the old C2.X branch; moreover, a component like the skin shoudln't require nothing more than maven artifacts, no tarballs/zip archives. Tag is located on https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-thien-maven-site-skin/cocoon-thien-maven-site-skin-1.0.1/ Artifacts are deployed on people.apache.org people.apache.org:/www/people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-thien-maven-site-skin/1.0.1/ They can be browsable from HTTP: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-thien-maven-site-skin/1.0.1/ Vote is open for the next 72h and will close on March 20th at ~12:45am. Once (and if) vote will succeed, I will provide to deploy artifacts on Central Repo. Many thanks in advance for reviewing, all the best and have a nice weekend! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ +1 -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: Jail management
Great work! You're the Cocoon champion of the month! thanks a lot for the hard work, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/3/21 Francesco Chicchiriccò ilgro...@apache.org: Hi all, FYI, I have reported some notes about our jail management at [1]. Cheers. [1] http://wiki.apache.org/cocoon/JailManagement -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
[DISCUSS] online APIs doc
Hi all guys, after many users request - last just received on user@ - I would suggest to deploy APIs doc on SVN to make them available online. If no objections will be shown in the next 72h, I'll proceed on deploying the C3 - guess I'll need help on deploying the C2.X versions. WDYT? best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
[VOTE] release Apache Cocoon Thien Maven Skin 1.0.1
Hi all, last year I did some work on the Thien Skin in order to match the brand requirements from ASF, you can see the Cocoon 3 site where logo has the ™ character and the footer reports the needed disclaimer. I also took advantage to optimize js/css, now included in compressed version, the code google-code-prettify has been updated and optimized at site generation time. So, time to make a new release and update docs :) Notice that I didn't change the release procedure because the skin is still included in the old C2.X branch; moreover, a component like the skin shoudln't require nothing more than maven artifacts, no tarballs/zip archives. Tag is located on https://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/cocoon-thien-maven-site-skin/cocoon-thien-maven-site-skin-1.0.1/ Artifacts are deployed on people.apache.org people.apache.org:/www/people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-thien-maven-site-skin/1.0.1/ They can be browsable from HTTP: http://people.apache.org/builds/cocoon/org/apache/cocoon/cocoon-thien-maven-site-skin/1.0.1/ Vote is open for the next 72h and will close on March 20th at ~12:45am. Once (and if) vote will succeed, I will provide to deploy artifacts on Central Repo. Many thanks in advance for reviewing, all the best and have a nice weekend! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: Website management [WAS Re: resurrect the Cocoon documentation]
+1 for option #2, I like keeping the doc under control and in a format can be deployed wherever :) For that purpose, I just launched the VOTE thread for the Thien Skin 1.0.1. Thanks for leading this, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/3/16 Francesco Chicchiriccò ilgro...@apache.org: Hi all, yesterday, while looking at cocoon.zones.apache.org, I've spent some time at our website, and the e-mail below came into my mind. I believe we should act in this respect as soon as possible, since our outdated website is all but attractive and informative: think only that every page reports Errors and Improvements? If you see any errors or potential improvements in this document please help us: View, Edit or comment on the latest development version (registration required). pointing to a non-existing Daisy instance. Taking the attached e-mail into account, I think we should choose whether: 1. try to resurrect a Daisy instance in our jail - with Betrand's help / manage somehow 2.1 docs with forrest; 2. use Cocoon to parse existing HTML files (for C2.2 and C2.1) and generate a bunch of xdoc/apt files that will serve as a basis for managing a whole maven / svnsubpub based website (like as we're currently doing for C3); 3. use Apache CMS and try to import all existing documentation (including C3's, in this case) - as suggested by David in the e-mail below; I am for (2) and can spend some time for this, with some other volunteer, of course ;-) WDYT? Regards. On 16/01/2012 14:21, David Crossley wrote: TL;DNR Use the Apache CMS for at least our top-level docs and the stalled 2.1 and 2.2 docs. However, i cannot actually do this work, just explain and guide. I have done some background research to try to gather the various past threads and docs. Perhaps this will help us to bring the Cocoon documentation back to life. In the past we had the sources for the docs in xml format and then processed by Apache Forrest to generate the html pages. A few years ago we moved to using the Daisy CMS to store/edit all content for 2.1 and 2.2 versions, as well as the top-level project non-version-specific stuff. For Cocoon-2.2, and the top-level stuff, the Maven site plugin extracted the content from Daisy and generated the html pages. [4] For Cocoon-2.1, the Forrest plugin Daisy input plugin extracted the content from Daisy and generated the html pages. [5] For Cocoon-3, the source content is stored in xml files and the Maven site plugin generates the html pages. All generated html was (and still is) committed to the Cocoon site SVN [1]. Then 'svn up' on the people.apache.org machine does the publishing step. (Later that step could move to using svnpubsub.) The Daisy server operated on our Zones machine cocoon.zones.apache.org (which also housed the demonstrations for Cocoon 2.1 and 2.2). The Zones server is managed by the Cocoon project. See [2]. However, the machine that provided the zones for a set of projects needed to be upgraded. The Cocoon project did not move our services in time. IIRC we do now have a freebsd jail which is basically configured, but not yet re-installed Daisy or Cocoon demo examples, nor the web server. IIRC we did get a backup of the Daisy data [3] if that helps. The Forrest forrestbot neededi to be turned off, as it could not access the source content for the 2.1 documentation. For the 2.2 documentation, i presume that Maven also has troubles. So unless someone can re-instate the new cocoon.zones.apache.org and the Daisy server, then we need some other solution. Suggestion to use the Apache CMS: One other solution would be to use the new Apache CMS. [7] It can have source content in either Markdown format or in HTML format and perhaps others. To resurrect the content, we might be able to use the last published generated set of html documents, strip off the outer headers and menu stuff, replace with basic header, and use that set of content to seed the CMS. (Some of these resources are only available to Cocoon PMC members.) [1] http://svn.apache.org/repos/asf/cocoon/site/site/ [2] https://svn.apache.org/repos/private/pmc/cocoon/cocoon.zones.apache.org/ [3] Search the PMC archive for various email from Bertrand [4] http://cocoon.apache.org/1418_1_1.html How to publish docs to cocoon.apache.org (i.e. for Cocoon-2.2 and the top-level of c.a.o) [5] http://wiki.apache.org/cocoon/CocoonWebsiteUpdate How to publish Cocoon-2.1 docs [7] Apache CMS http://wiki.apache.org/general/ApacheCms2010 http://wiki.apache.org/general/ApacheCMSFAQ http://www.apache.org/dev/cmsref.html -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: Cocoon jail
w00t I can just say CONGRATULATIONS at the moment!!! great work, thanks a lot! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/3/15 Francesco Chicchiriccò ilgro...@apache.org: Hi all, after recent warning from INFRA guys about the status of our jail, I spent some time with it. As you can see, we now have a rough index page at [1] and samples at [2]. I have added the source code for index page and samples webapp in [3]. Jail content can of course be improved and extended in may directions: 1. samples for Cocoon 2.2 (is there anything comparable to C3 samples? I tried [4] but it looks almost empty) 2. samples for Cocoon 2.1 3. old content? 4. better index page - current one is cutpaste from website 5. ??? Help, fixes, reports and suggestions are very welcome. Regards. [1] http://cocoon.zones.apache.org/ [2] http://cocoon.zones.apache.org/cocoon3/ [3] https://svn.apache.org/repos/asf/cocoon/trunk/jail/ [4] http://cocoon.apache.org/2.2/1159_1_1.html -- Francesco Chicchiriccò Apache Cocoon PMC and Apache Syncope PPMC Member http://people.apache.org/~ilgrosso/
Re: Please don't update public site on SVN
Hi all, SvnPubSub is already available, so everybody is now able - and feel free - to publish updated documentation as wish. It is really important to keep the doc updated, especially after last feedbacks on users@, so please don't hesitate on adding missing stuff you notice. I'll add latest Francesco's archetypes update ASAP unless someone else is faster than me me (I'll be in a EU project meeting until Wed so I am not in the position to do it ATAM, maybe in the night...) I just updated the doc in the RELEASE-HOWTO.txt on /trunk HTH, all the best, -Simo +---+ * update the 3.0 branch of our site in SVN It's a manual process. There is an ASF requirement that all site content has to be managed by SvnPubSub Apache Cocoon reuses the old site (simplified) deploy procedure. Checkout this URL. svn co https://svn.apache.org/repos/asf/cocoon/site/site/ [site] And run 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. SvnPubSub will take care on pushing the new content online in a short while. ++ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Mar 9, 2012 at 2:08 PM, Simone Tripodi simonetrip...@apache.org wrote: Sometimes happens I send messages in the wrong lists... :) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ -- Forwarded message -- From: Simone Tripodi simonetrip...@apache.org Date: Fri, Mar 9, 2012 at 11:08 AM Subject: Please don't update public site on SVN To: Commons Users List u...@commons.apache.org Hi all, I asked INFRA to enable SvnPubSub (see INFRA-4513) they asked to wait on updating the site until they will have few infra issues solved. TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Fwd: Please don't update public site on SVN
Sometimes happens I send messages in the wrong lists... :) best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ -- Forwarded message -- From: Simone Tripodi simonetrip...@apache.org Date: Fri, Mar 9, 2012 at 11:08 AM Subject: Please don't update public site on SVN To: Commons Users List u...@commons.apache.org Hi all, I asked INFRA to enable SvnPubSub (see INFRA-4513) they asked to wait on updating the site until they will have few infra issues solved. TIA, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
SVN party on IRC - from proposals to actions :)
Hi all guys, time to act! Please schedule your availability on http://www.doodle.com/fzcsynvyphxv7agh Times are just a nerd-ish proposal - feel free to add the times are more comfortable for you and we'll try to find an agreement (I didn't understand how to modify the current doodle :S) #cocoon on irc.freenode.net is still active, but only 2 bots and I are there actually - please join! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Feathercast episode 7 on Apache Cocoon :)
Hi all guys, as announced some time ago, I had the big opportunity to speak about Cocoon on FeatherCast.org, our ASF podcast :) Here is the link: http://feathercast.apache.org/?p=157 Fortunately, the audio has been edited - my voice doesn't hide I was really *really* excited and suffered a little the stress - I usually speak much better :D - I think that should be normal for someone be interviewed for an important audience such as the ASF for the first time!! :) Please apologize some inaccuracies and if I spelled wrong someone's name - I hope I achieved at least thje goal of transmitting the enthusiasm in the Cocoon community :) Enjoy and thanks everybody for the support! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: Community day for cleanup (was Re: [C3] Import subprojects proposal)
Hi Thorsten that is fine for me, do you think a doodle can help? I could set-up ip if you think it could be useful. I am sorry for not being useful for setting up the IRC infra, but looks really useful and I am +1 on this :) Thanks for the feedback! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Feb 9, 2012 at 5:22 PM, Thorsten Scherler scher...@gmail.com wrote: Sorry for not coming back to this issue sooner. I think we should plan at least with 1-2 week buffer. Further we need to make sure that we meet the basic infrastructure of such meetings. e.g. IRC bot that committs the protocol of the chat every x minutes, so that people can follow the day via the log if they want. Then we should have a proper agenda for that day so we all know what we are planning and how we can do distribute the work. I guess: - restructuring of svn - unification of issue tracker ... salu2 On 02/03/2012 02:03 PM, Simone Tripodi wrote: +1, do we want to (virtually) meet during the WE? skype/gtalk/irc just tell me where! thanks Francesco for leading this! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/2/3 Francesco Chicchiriccòilgro...@apache.org: One month of silence about this topic... is there still any willing to restructure our SVN repository layout? On 04/01/2012 09:04, Francesco Chicchiriccò wrote: On 03/01/2012 12:47, Simone Tripodi wrote: Hi!!! +1 on that idea, thanks Thorsten for driving this up! What about launching a doodle[1] to schedule the meeting? Personally, this week is perfect for me because I'm still on vacations (even if our new 2 months old pet ) - but I can adapt my time according to general needs. Nice idea to put Doodle in place :-) Anyway, this week is perfect for me as well. Thorsten? Others? That makes me feel really good, glad to see we can start the new year with renewed energies! All the best, -Simo [1] http://www.doodle.com/main2.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/1/3 Francesco Chicchiriccòilgro...@apache.org: On 03/01/2012 12:00, Thorsten Scherler wrote: On Tue, 2012-01-03 at 09:47 +0100, Francesco Chicchiriccò wrote: ... Hi all, since there seems to be no objections against this reviewed proposal so far, I'll start drafting out the actual reorganization following the guidelines defined above. I would still be glad if anyone is willing to join me in a live session for fixing all details involved (pom changes, JIRA, Sonar, Jenkins, Sonatype, ...). Anyway, because of the effects of such reorganizations, I'll ask here for confirmation before committing. Yeah, I think we should be at least 3-5 committer with enough rights in the different parts to update and a couple of devs to do the hot testing. Formally we had a community day where we meet on IRC (with bot which committed the chat to a svn file, to make the work transparent for the whole community). Wow, I did not know this. It sounds very nice. So who is up for a community day for spring cleaning of the project? Of course I am :-) Which day best fits? I'd prefer this week or possibly early next week. Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/ -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: Community day for cleanup (was Re: [C3] Import subprojects proposal)
+1, do we want to (virtually) meet during the WE? skype/gtalk/irc just tell me where! thanks Francesco for leading this! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/2/3 Francesco Chicchiriccò ilgro...@apache.org: One month of silence about this topic... is there still any willing to restructure our SVN repository layout? On 04/01/2012 09:04, Francesco Chicchiriccò wrote: On 03/01/2012 12:47, Simone Tripodi wrote: Hi!!! +1 on that idea, thanks Thorsten for driving this up! What about launching a doodle[1] to schedule the meeting? Personally, this week is perfect for me because I'm still on vacations (even if our new 2 months old pet ) - but I can adapt my time according to general needs. Nice idea to put Doodle in place :-) Anyway, this week is perfect for me as well. Thorsten? Others? That makes me feel really good, glad to see we can start the new year with renewed energies! All the best, -Simo [1] http://www.doodle.com/main2.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/1/3 Francesco Chicchiriccòilgro...@apache.org: On 03/01/2012 12:00, Thorsten Scherler wrote: On Tue, 2012-01-03 at 09:47 +0100, Francesco Chicchiriccò wrote: ... Hi all, since there seems to be no objections against this reviewed proposal so far, I'll start drafting out the actual reorganization following the guidelines defined above. I would still be glad if anyone is willing to join me in a live session for fixing all details involved (pom changes, JIRA, Sonar, Jenkins, Sonatype, ...). Anyway, because of the effects of such reorganizations, I'll ask here for confirmation before committing. Yeah, I think we should be at least 3-5 committer with enough rights in the different parts to update and a couple of devs to do the hot testing. Formally we had a community day where we meet on IRC (with bot which committed the chat to a svn file, to make the work transparent for the whole community). Wow, I did not know this. It sounds very nice. So who is up for a community day for spring cleaning of the project? Of course I am :-) Which day best fits? I'd prefer this week or possibly early next week. Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: svn commit: r1239305 [1/2] - in /cocoon/site/site/3.0: ./ css/ images/ reference/ reference/html-single/ student-project-ideas/
urg :S :S :S checking right now - I should stop doing work during the night thanks for reporting! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Feb 1, 2012 at 11:28 PM, Thorsten Scherler scher...@gmail.com wrote: On 02/01/2012 09:23 PM, simonetrip...@apache.org wrote: Author: simonetripodi Date: Wed Feb 1 20:23:02 2012 New Revision: 1239305 URL: http://svn.apache.org/viewvc?rev=1239305view=rev Log: addressed the trademark issues on C3 site ... Seems that this commit made the css not found anymore. http://cocoon.apache.org//3.0/ does not have css. salu2 -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: svn commit: r1239305 [1/2] - in /cocoon/site/site/3.0: ./ css/ images/ reference/ reference/html-single/ student-project-ideas/
Hi Thorsten, it should have been fixed on r1239494, let's wait for the rsync to see if it succeeded!!! Thanks again, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Feb 2, 2012 at 9:59 AM, Simone Tripodi simonetrip...@apache.org wrote: urg :S :S :S checking right now - I should stop doing work during the night thanks for reporting! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Feb 1, 2012 at 11:28 PM, Thorsten Scherler scher...@gmail.com wrote: On 02/01/2012 09:23 PM, simonetrip...@apache.org wrote: Author: simonetripodi Date: Wed Feb 1 20:23:02 2012 New Revision: 1239305 URL: http://svn.apache.org/viewvc?rev=1239305view=rev Log: addressed the trademark issues on C3 site ... Seems that this commit made the css not found anymore. http://cocoon.apache.org//3.0/ does not have css. salu2 -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: [c3] Pipeline API refactoring
Hello Reinhard!!! that is *great* news!!! I'm going to checkout the branch to see new APIs, you have the full support from my side! Thanks a lot for taking care of it! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 19, 2012 at 9:09 AM, Reinhard Pötz reinh...@apache.org wrote: As I mentioned several times I think we should polish the pipeline API before we do our first beta release of Cocoon 3. Especially the enforced resutl type OutputStream and the exception handling need some improvements. For that purpose I created a branch c3-pipeline-api-refactoring in our whiteboard (https://svn.apache.org/repos/asf/cocoon/whiteboard/c3-pipeline-api-refactoring/) so that our discussions don't become too theoretical ;-) That branch only contains a minimum set of classes so that we see the effects of a proposed change on real code but don't have to change the whole codebase just for some examples that might be thrown away. Steven and I plan to continue our work some time next week. We will commit our changes then and explain them on the mailing list for further discussions. -- 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] XincludeTransformer.java weirdness
Hola Thorsten! yes as Jos already pointed out, the XPointer frameowrk classes are generated by a JavaCC grammar :) All the best, hasta pronto! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 19, 2012 at 11:25 AM, Thorsten Scherler scher...@gmail.com wrote: On 01/19/2012 11:14 AM, Jos Snellings wrote: Hi Thorsten, They are under generated-sources/javacc/org/apache/cocoon/sax/xpointer/ParseException.java Apparently the java is only generated at build time. Don't know details (pom.xml has javacc-maven-plugin). Thanks, yeah that makes much sense. I thought it must have something like that. Thanks again for pointing out!. salu2 Jos On 01/19/2012 10:56 AM, Thorsten Scherler wrote: Hi all, in https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/component/XIncludeTransformer.java we do import org.apache.cocoon.sax.xpointer.ParseException; ... import org.apache.cocoon.sax.xpointer.XPointerFrameworkParser; but in https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-sax/src/main/java/org/apache/cocoon/sax/xpointer/ There is no such classes. I do not understand since we can build with cli without problems. In eclipse I can fix the project setup by adding the cocoon-sax beta jar to the classpath. However that is the same jar as the project, which does not make sense at all. Somebody has an idea? salu2 -- Thorsten Scherlerscherler.at.gmail.com codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: [JIRA] add more karma to Cedric and Robby
Thanks a lot Reinhard, all the best! Alles gute! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Jan 11, 2012 at 8:31 AM, Reinhard Pötz reinh...@apache.org wrote: On 01/10/2012 11:17 AM, Simone Tripodi wrote: Good morning all, I'm here to kindly ask if some of us has enough powers to give more karma on JIRA to our new PMC members Cedric (cedric) and Robby (robbypelssers). I cc-ed Reinhard because he added Francesco and I so at 90% he can help us (sorry for the noise Reinhard!) Many thanks in advance, all the best! done -- 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: Releasing new skin version
Hi all, apologize for resurrecting zombie-threads but this is something really needed - in the last board@ report I reported that we didn't apply the TM requirements, I would avoid to report the same in the next report... Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Dec 12, 2011 at 10:26 AM, Simone Tripodi simonetrip...@apache.org wrote: hi again guys, any hint, please? I would like to start the skin release process in a short while. Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Dec 10, 2011 at 3:43 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I've just terminated to modify the old cocoon-thien-maven-site-skin according to Apache branding requirements; I took also advantage to update the code prettifier, moreover plugging the YUI compressor we now have merged/minified css/js. I would like to push a RC to call for a [VOTE], so once released the new skin, I'll proceed updating both sites 2.x and 3.0. My question is: can anyone remind me the procedure to release a Cocoon2.X component? :) Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
[JIRA] add more karma to Cedric and Robby
Good morning all, I'm here to kindly ask if some of us has enough powers to give more karma on JIRA to our new PMC members Cedric (cedric) and Robby (robbypelssers). I cc-ed Reinhard because he added Francesco and I so at 90% he can help us (sorry for the noise Reinhard!) Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: where is org.apache.cocoon.components?
Hi Jos!
Looks like the class
org/apache/cocoon/components/serializers/util/XMLSerializer is
contained in C2 cocoon-serializers-charsets, you have to add the
following dependency in your pom:
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-serializers-charsets/artifactId
version1.0.0/version
/dependency
I found it in
jar:file:~/.m2/repository/org/apache/cocoon/cocoon-serializers-charsets/1.0.0/cocoon-serializers-charsets-1.0.0.jar!/org/apache/cocoon/components/serializers/util/XMLSerializer.class
HTH, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Jan 6, 2012 at 8:16 AM, Jos Snellings
jos.snelli...@upperware.biz wrote:
Dear cocooners,
When trying to load cocoon-optional, spring complains loudly about not being
able to find class:
org/apache/cocoon/components/
serializers/util/XMLSerializer
In effect, this class is not within the cocoon distribution.
To my best knowledge, there is no sub project
cocoon-components
The problematic declaration is:
public class EncodingXMLSerializer extends
org.apache.cocoon.components.serializers.util.XMLSerializer implements
SAXPipelineComponent, Finisher, SAXConsumer, CachingPipelineComponent {
Can anybody shed some light upon this one?
Thank you !
Jos
Re: where is org.apache.cocoon.components?
Hi Jos,
indeed, it was not immediate also for me, I had to play a little with
the grep command :P
Thanks for your feedbacks, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Jan 6, 2012 at 11:30 AM, Jos Snellings
jos.snelli...@upperware.biz wrote:
Thanks, Simo!
We should document these dependencies, I think.
The cocoon side projects are not always easy to find.
Cheers,
Jos
On Fri, Jan 6, 2012 at 11:05 AM, Simone Tripodi simonetrip...@apache.org
wrote:
Hi Jos!
Looks like the class
org/apache/cocoon/components/serializers/util/XMLSerializer is
contained in C2 cocoon-serializers-charsets, you have to add the
following dependency in your pom:
dependency
groupIdorg.apache.cocoon/groupId
artifactIdcocoon-serializers-charsets/artifactId
version1.0.0/version
/dependency
I found it in
jar:file:~/.m2/repository/org/apache/cocoon/cocoon-serializers-charsets/1.0.0/cocoon-serializers-charsets-1.0.0.jar!/org/apache/cocoon/components/serializers/util/XMLSerializer.class
HTH, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Jan 6, 2012 at 8:16 AM, Jos Snellings
jos.snelli...@upperware.biz wrote:
Dear cocooners,
When trying to load cocoon-optional, spring complains loudly about not
being
able to find class:
org/apache/cocoon/components/
serializers/util/XMLSerializer
In effect, this class is not within the cocoon distribution.
To my best knowledge, there is no sub project
cocoon-components
The problematic declaration is:
public class EncodingXMLSerializer extends
org.apache.cocoon.components.serializers.util.XMLSerializer implements
SAXPipelineComponent, Finisher, SAXConsumer, CachingPipelineComponent {
Can anybody shed some light upon this one?
Thank you !
Jos
Re: JIRA unification proposal
Hi all, and Happy New Year!! ...but yeah IMO we need to have a apply-patches phase prior to the merge, to get the outstanding patches for 2.x closed and we have a cleaner list. I am +1 on this, sounds like a more than reasonable plan! Thanks all, best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: Community day for cleanup (was Re: [C3] Import subprojects proposal)
Hi!!! +1 on that idea, thanks Thorsten for driving this up! What about launching a doodle[1] to schedule the meeting? Personally, this week is perfect for me because I'm still on vacations (even if our new 2 months old pet ) - but I can adapt my time according to general needs. That makes me feel really good, glad to see we can start the new year with renewed energies! All the best, -Simo [1] http://www.doodle.com/main2.html http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2012/1/3 Francesco Chicchiriccò ilgro...@apache.org: On 03/01/2012 12:00, Thorsten Scherler wrote: On Tue, 2012-01-03 at 09:47 +0100, Francesco Chicchiriccò wrote: ... Hi all, since there seems to be no objections against this reviewed proposal so far, I'll start drafting out the actual reorganization following the guidelines defined above. I would still be glad if anyone is willing to join me in a live session for fixing all details involved (pom changes, JIRA, Sonar, Jenkins, Sonatype, ...). Anyway, because of the effects of such reorganizations, I'll ask here for confirmation before committing. Yeah, I think we should be at least 3-5 committer with enough rights in the different parts to update and a couple of devs to do the hot testing. Formally we had a community day where we meet on IRC (with bot which committed the chat to a svn file, to make the work transparent for the whole community). Wow, I did not know this. It sounds very nice. So who is up for a community day for spring cleaning of the project? Of course I am :-) Which day best fits? I'd prefer this week or possibly early next week. Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
[sitemap] specification
Hi all guys, do we have a sitemap specification? since I'm on vacations I have some time to dedicate to C3 and I would like to put the CLI in a decent state according to what we already discussed :) Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: Welcome Cédric Damioli and Robby Pelssers as Cocoon committers
thanks all for the great work guys, and welcome aboard!!! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Dec 19, 2011 at 3:43 AM, David Crossley cross...@apache.org wrote: Many thanks to both Cédric and Robby. You can reply to private AT cocoon if preferred. Robby already has an Individual Contributor License Agreement. See the list of already taken committer IDs: http://people.apache.org/committer-index.html as a guide to specifying yours (plus an alternative). As well as the reference [1] below, we will be following these notes: http://apache.org/dev/pmc.html#newcommitter -David Sylvain Wallez wrote: Hi all, I am very happy to announce that the Cocoon PMC has voted Cédric Damioli and Robby Pelssers as new Cocoon committers, provided of course that they accept it. Also, once you have your commit rights, you are welcome to join the Cocoon PMC whose member have binding votes for releases and other project matters. Please read the instructions for committers and PMC members [1], first thing being to send a CLA if not already done, and suggest your preferred account name. Welcome on board guys! Sylvain [1] http://apache.org/dev/#committers -- Sylvain Wallez - http://bluxte.net
Re: [C3] new pipeline component: variabelExpander
Hola Thorsten!
Another approach would be to use the transformer configure and use a
language interpreter to generate a Properties object. That works since
we can now inject object and not only strings. Like:
map:transform xmlns:map=http://apache.org/cocoon/sitemap;
type=variableExpanderTransformer
map:parameter name=textproperties value={properties:something}/
/map:transform
This would allow to use other props beside the env.
wdyt?
I really like this approach!!! We could even support loading
properties files, URLs, ... great!
Thanks for your feedback!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: [C3] new pipeline component: variabelExpander
Hi Nathaniel!
*terrific* feedback, you already put me in the condition I'm going to
modify the transformer adoption your suggestion!
Clear, simple, linear - priceless!
I'll let you know when terminated!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Dec 16, 2011 at 1:38 PM, Nathaniel, Alfred
alfred.nathan...@six-group.com wrote:
Hi Simone,
Why this special API call to add it to the pipeline?
I think is should be a regular transformer you can add any number of time
wherever you need it:
VariableExpander expander = new VariableExpander();
expander.addProperty( build.base, /Users/cocoon );
expander.addProperty( build.home, ${build.base}/workspace );
expander.addProperty( dist.home, ${build.base}/downloads );
expander.addProperty( text.property, Cocoon3 rocks! );
then creating and run their pipeline adding the VariableExpander:
newNonCachingPipeline().setURLGenerator(
getClass().getResource( /variables-expander.xml ) )
.addTransformer( expander )
.addSerializer()
.withEmptyConfiguration()
.setup( System.out )
.execute();
That makes it also easier to add configuration to the expander, for example:
* use other marker than ${}, in case you may want generate generate a file
using that syntax for its own purposes
* what to do if there if the property name is undefined: replace it by
nothing / leave as is / throw exception
Also by not just using a stupid property map, it is much easier to avoid
infinite recursions such as
setProperty(build.home,${build.home}/workspace).
Cheers, Alfred.
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
Simone Tripodi
Sent: Donnerstag, 15. Dezember 2011 18:02
To: dev@cocoon.apache.org
Subject: Re: [C3] new pipeline component: variabelExpander
Hi Robby :)
On Thu, Dec 15, 2011 at 5:56 PM, Robby Pelssers robby.pelss...@nxp.com
wrote:
Would it be justified to say that it acts as some kind of transformer
(although non-xslt based) in this case which replaces all variable
references with the value from the Map or Properties provided?
exactly, it just replaces plain text inside attributes/body elements :P
And I suppose it works on any text, not just XML?!
Not ATM, it works as XmlTransformer :(
Bring it on ;-)
I'll do, thanks! :)
best;
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended recipient, please notify the sender and delete
this e-mail immediately.
Thank you.
Re: [C3] new pipeline component: variabelExpander
Hi again guys,
just to continue speaking about core transformer APIs, I just
modified the transformer as you suggested, the showcase is:
VariableExpanderTransformer expander = new
VariableExpanderTransformer();
expander.setProperty( build.base, /Users/cocoon );
expander.setProperty( build.home, ${build.base}/workspace );
expander.setProperty( dist.home, ${build.base}/downloads );
expander.setProperty( text.property, Cocoon3 rocks! );
newNonCachingPipeline().setURLGenerator(
getClass().getResource( /variables-expander.xml ) )
.addComponent( expander )
.addSerializer()
.withEmptyConfiguration()
.setup( System.out )
.execute();
Moreover following VariableExpanderTransformer methods are available:
loadAll(MapString, String)
loadAll(Properties)
loadEnvironmentVariables() // they are prefixed with 'env.' in the context
loadSystemProperties() // Java system properties
loadProperties(URL)
loadXmlProperties(URL)
Do you think could be useful inside a sitemap processing?
Many thanks in advance, all the best!!!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Dec 16, 2011 at 4:06 PM, Simone Tripodi
simonetrip...@apache.org wrote:
Hi Nathaniel!
*terrific* feedback, you already put me in the condition I'm going to
modify the transformer adoption your suggestion!
Clear, simple, linear - priceless!
I'll let you know when terminated!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Fri, Dec 16, 2011 at 1:38 PM, Nathaniel, Alfred
alfred.nathan...@six-group.com wrote:
Hi Simone,
Why this special API call to add it to the pipeline?
I think is should be a regular transformer you can add any number of time
wherever you need it:
VariableExpander expander = new VariableExpander();
expander.addProperty( build.base, /Users/cocoon );
expander.addProperty( build.home, ${build.base}/workspace );
expander.addProperty( dist.home, ${build.base}/downloads );
expander.addProperty( text.property, Cocoon3 rocks! );
then creating and run their pipeline adding the VariableExpander:
newNonCachingPipeline().setURLGenerator(
getClass().getResource( /variables-expander.xml ) )
.addTransformer( expander )
.addSerializer()
.withEmptyConfiguration()
.setup( System.out )
.execute();
That makes it also easier to add configuration to the expander, for example:
* use other marker than ${}, in case you may want generate generate a file
using that syntax for its own purposes
* what to do if there if the property name is undefined: replace it by
nothing / leave as is / throw exception
Also by not just using a stupid property map, it is much easier to avoid
infinite recursions such as
setProperty(build.home,${build.home}/workspace).
Cheers, Alfred.
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf
Of Simone Tripodi
Sent: Donnerstag, 15. Dezember 2011 18:02
To: dev@cocoon.apache.org
Subject: Re: [C3] new pipeline component: variabelExpander
Hi Robby :)
On Thu, Dec 15, 2011 at 5:56 PM, Robby Pelssers robby.pelss...@nxp.com
wrote:
Would it be justified to say that it acts as some kind of transformer
(although non-xslt based) in this case which replaces all variable
references with the value from the Map or Properties provided?
exactly, it just replaces plain text inside attributes/body elements :P
And I suppose it works on any text, not just XML?!
Not ATM, it works as XmlTransformer :(
Bring it on ;-)
I'll do, thanks! :)
best;
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
The content of this e-mail is intended only for the confidential use of the
person addressed.
If you are not the intended recipient, please notify the sender and delete
this e-mail immediately.
Thank you.
[C3] new pipeline component: variabelExpander
Hi all guys,
I just committed r1214835 a new component I need for work, so I
thought it would have been a good idea contributing back to OSS since
C3 is the foundation of the XML processor I am writing.
Basically, I needed to put variables inside our XML document that can
be replaced depending by the context the pipeline works, so the idea
came from Ant/Maven and some code I already did in Commons-Digester,
using the ${} marker for variables have to be expanded.
Using that new component is very simple: given the XML
project
target
delete dir=${build.home} /
delete dir=${dist.home} /
echoA property '${text.property}' inside the text/echo
/target
/project
users can define their variables (in form of Properties/MapString,String):
Properties variables = new Properties();
variables.setProperty( build.base, /Users/cocoon );
variables.setProperty( build.home, ${build.base}/workspace );
variables.setProperty( dist.home, ${build.base}/downloads );
variables.setProperty( text.property, Cocoon3 rocks! );
then creating and run their pipeline adding the VariableExpander:
newNonCachingPipeline().setURLGenerator(
getClass().getResource( /variables-expander.xml ) )
.addVariableExpander( variables )
.addSerializer()
.withEmptyConfiguration()
.setup( System.out )
.execute();
the XML document will be processed by the next component in the
pipeline will look like:
project
target
delete dir=Users/cocoon/workspace /
delete dir=Users/cocoon/download /
echoA property 'Cocoon3 rocks!' inside the text/echo
/target
/project
WDYT? I hope it will be useful for you as well it is for me :P
Have a nice day, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: [C3] new pipeline component: variabelExpander
Hi Robby!
The Stringtemplate generator is much more sophisticated (you have
iterators, access to objects methods, ...) compared to this simple
component, that simply provides variable expansion.
The other difference is: Stringtemplate is a generator, the
VariableExpander is a component you can put in the middle of the
pipeline whenever you need - in my case, I needed to plug it at the
3rd stage of the pipeline.
For what it worths, Stringtemplate generator brings a 3rd party
dependency, VariableExpander comes dependencies-free inside the
cocoon-sax package.
Hope this clarifies, don't hesitate to ask if you need to know more!
All the best,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Dec 15, 2011 at 5:32 PM, Robby Pelssers robby.pelss...@nxp.com wrote:
Hi Simone,
This sounds useful. But it's not really clear to me as to how this differs
from the Stringtemplate generator which is also part of C3.
Robby
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
Simone Tripodi
Sent: Thursday, December 15, 2011 5:25 PM
To: dev@cocoon.apache.org
Subject: [C3] new pipeline component: variabelExpander
Hi all guys,
I just committed r1214835 a new component I need for work, so I
thought it would have been a good idea contributing back to OSS since
C3 is the foundation of the XML processor I am writing.
Basically, I needed to put variables inside our XML document that can
be replaced depending by the context the pipeline works, so the idea
came from Ant/Maven and some code I already did in Commons-Digester,
using the ${} marker for variables have to be expanded.
Using that new component is very simple: given the XML
project
target
delete dir=${build.home} /
delete dir=${dist.home} /
echoA property '${text.property}' inside the text/echo
/target
/project
users can define their variables (in form of Properties/MapString,String):
Properties variables = new Properties();
variables.setProperty( build.base, /Users/cocoon );
variables.setProperty( build.home, ${build.base}/workspace );
variables.setProperty( dist.home, ${build.base}/downloads );
variables.setProperty( text.property, Cocoon3 rocks! );
then creating and run their pipeline adding the VariableExpander:
newNonCachingPipeline().setURLGenerator(
getClass().getResource( /variables-expander.xml ) )
.addVariableExpander( variables )
.addSerializer()
.withEmptyConfiguration()
.setup( System.out )
.execute();
the XML document will be processed by the next component in the
pipeline will look like:
project
target
delete dir=Users/cocoon/workspace /
delete dir=Users/cocoon/download /
echoA property 'Cocoon3 rocks!' inside the text/echo
/target
/project
WDYT? I hope it will be useful for you as well it is for me :P
Have a nice day, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Re: [C3] new pipeline component: variabelExpander
Hi Robby :) On Thu, Dec 15, 2011 at 5:56 PM, Robby Pelssers robby.pelss...@nxp.com wrote: Would it be justified to say that it acts as some kind of transformer (although non-xslt based) in this case which replaces all variable references with the value from the Map or Properties provided? exactly, it just replaces plain text inside attributes/body elements :P And I suppose it works on any text, not just XML?! Not ATM, it works as XmlTransformer :( Bring it on ;-) I'll do, thanks! :) best; -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: [C3] new pipeline component: variabelExpander
Hi Grosso!!! Anyway, could you think of a way for using this new component inside sitemap? Thanks. ehm... yes, so... I was think about... ehm... yes I know how, yes... ehm... don't know yet :P jokes a part, what's your usecase using Stringtemplate inside the sitemap? We could start replicating the same behavior, just for start... Thanks for the feedbacks and TIA for the new ones! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
[jira] [Commented] (COCOON3-82) Allow Saxon to be used as a XSLT transformer
[
https://issues.apache.org/jira/browse/COCOON3-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13168804#comment-13168804
]
Simone Tripodi commented on COCOON3-82:
---
Having Saxon working in C3 would indeed awesome - I am not sure, due to Saxon
license, any Saxon-based code can be included in Cocoon.
Can you provide a patch to show the integration works? I made tests with XSLT-C
just using the SPI pattern, by adding in the classpath
{{META-INF/services/javax.xml.transform.TransformerFactory}} file containing
the XSLT-C {{org.apache.xalan.xsltc.trax.TransformerFactoryImpl}} factory - it
should work with Saxon as well, but it would be wonderful having the proof :)
Allow Saxon to be used as a XSLT transformer
Key: COCOON3-82
URL: https://issues.apache.org/jira/browse/COCOON3-82
Project: Cocoon 3
Issue Type: Improvement
Components: cocoon-sax
Affects Versions: 3.0.0-beta-1
Reporter: Huib Verweij
In order to use XSLT 2.0 features (and beyond) in a XSLT transform I need to
be able to use Saxon as a transformer. In C2.2 this could be done.
There is a way of defining the transformer to be used in the system settings:
-Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl.
This might work, I am not sure, but then the choice of XSLT processor is gone
- but that is perhaps not important?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Releasing new skin version
hi again guys, any hint, please? I would like to start the skin release process in a short while. Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Dec 10, 2011 at 3:43 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I've just terminated to modify the old cocoon-thien-maven-site-skin according to Apache branding requirements; I took also advantage to update the code prettifier, moreover plugging the YUI compressor we now have merged/minified css/js. I would like to push a RC to call for a [VOTE], so once released the new skin, I'll proceed updating both sites 2.x and 3.0. My question is: can anyone remind me the procedure to release a Cocoon2.X component? :) Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Releasing new skin version
Hi all guys, I've just terminated to modify the old cocoon-thien-maven-site-skin according to Apache branding requirements; I took also advantage to update the code prettifier, moreover plugging the YUI compressor we now have merged/minified css/js. I would like to push a RC to call for a [VOTE], so once released the new skin, I'll proceed updating both sites 2.x and 3.0. My question is: can anyone remind me the procedure to release a Cocoon2.X component? :) Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/
Re: [C3] Import subprojects proposal [WAS: Re: [c3] Log4j injection in target of blocks]
Hi all guys! Apologies for the lack of participations but looks like contributing in more ASF communities requires a lot of time! :) My position are: * +1 on migrating old components - that's true that we could maintain them in their proper branch, but at the same time they would need an update to be more compliant with C3 - moreover, since we agreed on migrating to Java6, it would worth started getting advantage from the new platform - that would imply subprojects actualization. * +1 on restructuring the svn, I would like to restructure anyway the C3 first: IMHO having all the modules in a flat structures starts being a little confusing, even to me that I'm involved, I would suggest to move to a different hierarchical structure, grouping modules by technology/extension type/application type. Moreover IMHO the 'optional' module should be split, it contains now a lot of good reusable - more that at the begin - stuff that we could consider as a collection of modules. Of course, we have to pay attention to not overengineering. I would suggest as well to open a Sandbox open to all ASF committers to experiment new modules. My proposal is considering the two topics separately, I would like Francesco lead the topic #1, I can prepare during the weekend a proposal on how to restructure the SVN. WDYT? Many thanks in advance and sorry for the delay! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Nov 29, 2011 at 5:07 PM, Andreas Hartmann andr...@apache.org wrote: Am 27.11.11 00:58, schrieb Thorsten Scherler: On Sat, 2011-11-26 at 15:44 +0100, Francesco Chicchiriccò wrote: On 25/11/2011 10:34, Thorsten Scherler wrote: [...] Unfortunately, there are quite some dependencies that I guess were initially thought for C2.2, then used for C3 and now getting old like as: * cocoon-spring-configurator: think that I had to put replacement of Log4JConfigurator, LogbackConfigurator, in cocoon-servlet [2] * cocoon-rcl-webapp-wrapper * cocoon-xml: think that I had to put ParamSAXBuffer extending SAXBuffer in cocoon-sax [3] I think we should decide how to cope with this. IMO we should either create a new version of them only compatible with c3 or update c2.2. IMO All above mentioned should have new versions and work with c3. What if we just make some nice svn copy of above mentioned cocoon subprojects (and more: servlet-service, for example), as cocoon3 modules? Then we can start updating their POMs and possibly adding / extending source code, and making C3 parent POM pointing to these. I do not see a problem with that, but they do not need to become modules IMO. We can update/maintain them where they are under a new release version. IMO the current SVN structure is not really transparent. Trunk (2.2) and cocoon3/trunk are conflicting versions. Maybe the following would make sense? branches/ cocoon-2.2/ cocoon-3/ … subprojects/ cocoon-jnet … Of course this would imply that the subprojects have a well-defined API and functionality which is independent from any particular functionality in any of the Cocoon branches. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: Cocoon-trunk - Build # 101 - Unstable
well done, thanks for taking care! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Nov 17, 2011 at 9:54 PM, Thorsten Scherler scher...@gmail.com wrote: On Thu, 2011-11-17 at 20:38 +0100, Thorsten Scherler wrote: On Thu, 2011-11-17 at 18:08 +, Apache Jenkins Server wrote: The Apache Jenkins build system has built Cocoon-trunk (build #101) Status: Unstable Check console output at https://builds.apache.org/job/Cocoon-trunk/101/ to view the results. That is due to http://svn.apache.org/viewvc?rev=1203303view=rev When I did the commit I actually suspected that. The problem in short is in the directory generator test we count the nodes of the files/dir in /cocoon-optional/src/test/resources/org/apache/cocoon/optional/pipeline/components/sax/directory However that number is different in jerkins since he is doing svn export meaning it will not have the .svn dir meaning it will be one count less. I will try a small fix. http://svn.apache.org/viewvc?rev=1203347view=rev Yeah, that worked. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: Meet Cocoon CLI
Sorry but I had no chances to work on it, I'll try again tonight!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Nov 2, 2011 at 1:39 PM, Simone Tripodi simonetrip...@apache.org wrote:
Hi Robby,
that would be indeed more interesting, so users can test their
pipeline have to be put on production.
More cycles tonight, I'll let you know ASAP! :)
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Nov 2, 2011 at 11:27 AM, Robby Pelssers robby.pelss...@nxp.com
wrote:
Hi Simone,
I was wondering if it would be possible to instead read a (reusable) sitemap
from the command line instead and just provide some match pattern to execute
a specific pipeline. Not sure if I'm just naïve here but it would make
sense to me on first sight.
{code}
Usage: c3pipe [options]
Options:
-f, --file point to an existing sitemap
-p --pattern the pattern to be handled by the sitemap
Robby
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf
Of Simone Tripodi
Sent: Tuesday, November 01, 2011 9:21 PM
To: dev@cocoon.apache.org
Subject: Meet Cocoon CLI
Hi all guys,
I took advantage from today that's been a vacation day here to play
and experiment a little a new cocoon application I proposed time ago,
called cocoon-cli.
I had a private conversation with Cedri Beust, the author of
JCommander, that gave me a little suggestion how to NOT make a CLI
application :P
So, what I did today is replicating the Apache Ant/Maven behavior, I
mean, cocoon-cli is a console application that takes in input an XML
pipeline descriptor - called c3p.xml by default - that looks like very
similar to ant build.xml file:
{code}
pipelines name=Cocoon Pipelines test default=id0
pipeline id=id0
generator src=${user.dir}/src/test/resources/missing-elements.xml /
serializer /
/pipeline
pipeline id=id1
generator src=${user.dir}/src/test/resources/missing-elements.xml /
serializer /
/pipeline
/pipelines
{code}
as you can see, it reminds the Ant build XML format, pipeline
elements can be associated, as concept, to targets, each pipeline
has an id (and an optional description) and the user can specify a
default one has to be executed if no specific one (or more) are
specified in the CLI.
Note that it supports the ${} variables, both Environment and System
Properties.
Available commands are:
{code}
Usage: c3pipe [options] pipeline IDs*.
Options:
-X, --debug Produce execution debug output.
Default: false
-f, --file Force the use of an alternate c3p file.
Default:
/Users/simonetripodi/Documents/workspace/cocoon-root/cocoon-cli/target/cocoon-cli-3.0.0-beta-1-SNAPSHOT/c3p.xml
-h, --help Display help information.
Default: false
-p, --pipeshelp Print pipelines help information.
Default: false
-v, --version Display version information.
Default: false
{code}
typing `-p`, like Ant, enlists the available pipelines in the actual
descriptor:
{code}
$ c3pipe -p
[INFO]
[INFO]
[INFO] Apache Cocoon 3
[INFO]
[INFO]
[INFO] Apache Cocoon 3 - Pipeline 'Cocoon Pipelines test' (default: id0)
[INFO] id0 (non-caching) - Description not available
[INFO] id1 (non-caching) - Description not available
[INFO]
[INFO]
[INFO] Apache Cocoon 3 SUCCESS
[INFO] Total time: 0s
[INFO] Finished at: Tue Nov 01 20:58:48 CET 2011
[INFO] Final Memory: 10M/493M
[INFO]
{code}
when executing one (or more) pipeline(s), it prints the output in the sysout
{code}
[INFO]
[INFO]
[INFO] Apache Cocoon 3
[INFO]
[INFO]
[INFO] Executing default Pipeline 'id0'
?xml version=1.0 encoding=UTF-8?!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software
Re: Meet Cocoon CLI
Hi Torsten!! Believe me or not, I have a mail in my draft box where describing an alternative approach to XML sitemap, but never had the time (and the brave :P) to complete and send :D Just to give you more background on my madness: I thought about a CLI tool because I used to test XSLTs using `xsltproc` from CLI, so IMHO having a tool that would allow users testing an XML Pipeline would alleviate users the suffering of not seeing the intermediate results, unless the application is not properly deployed. *My* issue - that induced me on the XML format - is that via CLI, expressing a pipeline would be not so easy :/ Moreover, using my beloved commons-digester allowed me having a working PoC in less than one day. Anyway, I agree that something different from XML should be provided to our users, my other issue is that I don't have good background on JavaCC/AnTLR to write a DSL... and haven't taken a look yet on XText... would you recommend it? About packaging: I use the Application Assembler Maven Plugin[1] to create the application - it generates even the scripts for both linux/windows, so not so hard to manage. I would be really pleased if you could share more thoughts and suggestions on how to deliver our users a fresh new Cocoon CLI application! All the best, have anice day! Simo [1] http://mojo.codehaus.org/appassembler/appassembler-maven-plugin/ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Tue, Nov 1, 2011 at 9:41 PM, Torsten Curdt tcu...@vafer.org wrote: So, what I did today is replicating the Apache Ant/Maven behavior, I mean, cocoon-cli is a console application that takes in input an XML pipeline descriptor - called c3p.xml by default - that looks like very similar to ant build.xml file: ...which is not necessarily is a good thing :) I just had to think of an old thread about an even older discussion http://markmail.org/message/mxivpqxli5rcbffu I think many people have come to terms with XML in the sense that it is just not great for humans to write. C3 could be perfect to come up with just a DSL To package it, it is enough launching `mvn package` under /cocoon-cli[1], its execution will produce .tar.gaz and .zip packages under /cocoon-cli/target, that contain a multi-platform application which directories tree looks like the Maven one: . ├── README ├── bin │ ├── c3pipe │ └── c3pipe.bat ├── lib ├── cocoon-cli-3.0.0-beta-1-SNAPSHOT.jar ├── cocoon-pipeline-3.0.0-beta-1-SNAPSHOT.jar ├── cocoon-sax-3.0.0-beta-1-SNAPSHOT.jar ├── cocoon-util-3.0.0-beta-1-SNAPSHOT.jar ├── cocoon-xml-2.0.2.jar ├── commons-beanutils-1.8.3.jar ├── commons-digester3-3.1.jar ├── jcl-over-slf4j-1.6.1.jar ├── jcommander-1.17.jar ├── logback-classic-0.9.29.jar ├── logback-core-0.9.29.jar └── slf4j-api-1.6.1.jar I would just use the maven shade plugin and make it a runnable jar. Makes it much easier to handle. WDYT? Feedbacks are needed and of course participation is open, everybody interested is welcome! :) Go go go Simone! :) cheers, Torsten
Re: status c3
Hi Jos! As you noticed, the 'alpha' status - which is related to APIs only, not software stability - is finally terminated, we are on the beta way, but the first beta release has not been released yet! If I recall correctly, core APIs you are interested on, have not changed, so your application should continue working with the new artifacts - problem would be they are still SNAPSHOTs... :S There is not an official plan, with roadmaps and deadlines, unfortunately, since no one of Cocoon developers has the chance to work fulltime on it, so it is currently maintained in our spare time - that's why there are times where activity increases, but sometimes is very low :P Just let us know if you need details about C3, we would be more than pleased to help you! All the best, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Wed, Nov 2, 2011 at 5:45 AM, Jos Snellings jos.snelli...@pandora.be wrote: Hi everybody, What is the current status of cocoon-3? - I notice that the archetypes in the trunk are still on alpha-3, whereas, - most of the artifacts have shifted to beta-1? Here is the news: - I have been using what I could call c3 core for quite some time now ( 1y) no complaints (core = servlet, pipeline, sax, sitemap, controller) - I have a possible case for a nice c3 application, but I am afraid that cocoons official status (alpha according to the documentation) will scare the customer What's the plan on short notice? Could live with beta, I guess. Kind regards, Jos
Re: Meet Cocoon CLI
Hi Thorsten
apologize for my ignorance but I didn't know C2 had a CLI tool :( Even
if I heard a lot about C2, I joined Cocoon community directly to the
new generation :P
Code is already available on our Cocoon SCM[1], as you can see it is
something really easy - more PoC that a working app - based on Apache
Commons-Digester.
I didn't think about how many/which feature the CLI tool should
support - ATM it just takes in input IDs and prints pielines result -
so every suggestion/participation is more than welcome... there is
still a lot of work to do :P
All the best, have a nice day!
Simo
[1] https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/cocoon-cli
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Nov 2, 2011 at 10:16 AM, Thorsten Scherler scher...@gmail.com wrote:
On Tue, 2011-11-01 at 21:21 +0100, Simone Tripodi wrote:
Hi all guys,
I took advantage from today that's been a vacation day here to play
and experiment a little a new cocoon application I proposed time ago,
called cocoon-cli.
I had a private conversation with Cedri Beust, the author of
JCommander, that gave me a little suggestion how to NOT make a CLI
application :P
So, what I did today is replicating the Apache Ant/Maven behavior, I
mean, cocoon-cli is a console application that takes in input an XML
pipeline descriptor - called c3p.xml by default - that looks like very
similar to ant build.xml file:
{code}
pipelines name=Cocoon Pipelines test default=id0
pipeline id=id0
generator src=${user.dir}/src/test/resources/missing-elements.xml /
serializer /
/pipeline
pipeline id=id1
generator src=${user.dir}/src/test/resources/missing-elements.xml /
serializer /
/pipeline
/pipelines
{code}
Do you create a java pipeline with that? Can you point me to the code?
Have you plans to add matchers, actions and alike components support?
I should finally use droids to bring back the cocoon cli crawler (c3
droids) to crawl a c3 page.
Not sure whether people still remember the old cli of cocoon, but
basically apache forrest is using it as key feature to generate offline
documentation in different formats crawling the documentation page.
In Droids we have an approach that Bertli brought up on the ml where we
use c3 pipelines to invoke business operation on a task (link). His
usecase was to parse a html page and index it to solr.
Florent another user was suggesting something like the above to
configure c3 in droids, so your approach sound interesting to adopt.
Need to find some time somewhere.
salu2
--
Thorsten Scherler thorsten.at.apache.org
codeBusters S.L. - web based systems
consulting, training and solutions
http://www.codebusters.es/
Re: Meet Cocoon CLI
Hi Robby,
that would be indeed more interesting, so users can test their
pipeline have to be put on production.
More cycles tonight, I'll let you know ASAP! :)
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Nov 2, 2011 at 11:27 AM, Robby Pelssers robby.pelss...@nxp.com wrote:
Hi Simone,
I was wondering if it would be possible to instead read a (reusable) sitemap
from the command line instead and just provide some match pattern to execute
a specific pipeline. Not sure if I'm just naïve here but it would make sense
to me on first sight.
{code}
Usage: c3pipe [options]
Options:
-f, --file point to an existing sitemap
-p --pattern the pattern to be handled by the sitemap
Robby
-Original Message-
From: simone.trip...@gmail.com [mailto:simone.trip...@gmail.com] On Behalf Of
Simone Tripodi
Sent: Tuesday, November 01, 2011 9:21 PM
To: dev@cocoon.apache.org
Subject: Meet Cocoon CLI
Hi all guys,
I took advantage from today that's been a vacation day here to play
and experiment a little a new cocoon application I proposed time ago,
called cocoon-cli.
I had a private conversation with Cedri Beust, the author of
JCommander, that gave me a little suggestion how to NOT make a CLI
application :P
So, what I did today is replicating the Apache Ant/Maven behavior, I
mean, cocoon-cli is a console application that takes in input an XML
pipeline descriptor - called c3p.xml by default - that looks like very
similar to ant build.xml file:
{code}
pipelines name=Cocoon Pipelines test default=id0
pipeline id=id0
generator src=${user.dir}/src/test/resources/missing-elements.xml /
serializer /
/pipeline
pipeline id=id1
generator src=${user.dir}/src/test/resources/missing-elements.xml /
serializer /
/pipeline
/pipelines
{code}
as you can see, it reminds the Ant build XML format, pipeline
elements can be associated, as concept, to targets, each pipeline
has an id (and an optional description) and the user can specify a
default one has to be executed if no specific one (or more) are
specified in the CLI.
Note that it supports the ${} variables, both Environment and System
Properties.
Available commands are:
{code}
Usage: c3pipe [options] pipeline IDs*.
Options:
-X, --debug Produce execution debug output.
Default: false
-f, --file Force the use of an alternate c3p file.
Default:
/Users/simonetripodi/Documents/workspace/cocoon-root/cocoon-cli/target/cocoon-cli-3.0.0-beta-1-SNAPSHOT/c3p.xml
-h, --help Display help information.
Default: false
-p, --pipeshelp Print pipelines help information.
Default: false
-v, --version Display version information.
Default: false
{code}
typing `-p`, like Ant, enlists the available pipelines in the actual
descriptor:
{code}
$ c3pipe -p
[INFO]
[INFO]
[INFO] Apache Cocoon 3
[INFO]
[INFO]
[INFO] Apache Cocoon 3 - Pipeline 'Cocoon Pipelines test' (default: id0)
[INFO] id0 (non-caching) - Description not available
[INFO] id1 (non-caching) - Description not available
[INFO]
[INFO]
[INFO] Apache Cocoon 3 SUCCESS
[INFO] Total time: 0s
[INFO] Finished at: Tue Nov 01 20:58:48 CET 2011
[INFO] Final Memory: 10M/493M
[INFO]
{code}
when executing one (or more) pipeline(s), it prints the output in the sysout
{code}
[INFO]
[INFO]
[INFO] Apache Cocoon 3
[INFO]
[INFO]
[INFO] Executing default Pipeline 'id0'
?xml version=1.0 encoding=UTF-8?!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--!-- $Id: missing-elements.xml 1195964 2011-11-01 12
RegexpLinkRewriterTransformer
Hi all guys,
shouldn't RegexpLinkRewriterTransformer implement
{{setConfiguration()}} rather than {{setup()}}?
Many thanks in advance!
Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
Meet Cocoon CLI
Hi all guys,
I took advantage from today that's been a vacation day here to play
and experiment a little a new cocoon application I proposed time ago,
called cocoon-cli.
I had a private conversation with Cedri Beust, the author of
JCommander, that gave me a little suggestion how to NOT make a CLI
application :P
So, what I did today is replicating the Apache Ant/Maven behavior, I
mean, cocoon-cli is a console application that takes in input an XML
pipeline descriptor - called c3p.xml by default - that looks like very
similar to ant build.xml file:
{code}
pipelines name=Cocoon Pipelines test default=id0
pipeline id=id0
generator src=${user.dir}/src/test/resources/missing-elements.xml /
serializer /
/pipeline
pipeline id=id1
generator src=${user.dir}/src/test/resources/missing-elements.xml /
serializer /
/pipeline
/pipelines
{code}
as you can see, it reminds the Ant build XML format, pipeline
elements can be associated, as concept, to targets, each pipeline
has an id (and an optional description) and the user can specify a
default one has to be executed if no specific one (or more) are
specified in the CLI.
Note that it supports the ${} variables, both Environment and System Properties.
Available commands are:
{code}
Usage: c3pipe [options] pipeline IDs*.
Options:
-X, --debug Produce execution debug output.
Default: false
-f, --fileForce the use of an alternate c3p file.
Default:
/Users/simonetripodi/Documents/workspace/cocoon-root/cocoon-cli/target/cocoon-cli-3.0.0-beta-1-SNAPSHOT/c3p.xml
-h, --helpDisplay help information.
Default: false
-p, --pipeshelp Print pipelines help information.
Default: false
-v, --version Display version information.
Default: false
{code}
typing `-p`, like Ant, enlists the available pipelines in the actual descriptor:
{code}
$ c3pipe -p
[INFO]
[INFO]
[INFO] Apache Cocoon 3
[INFO]
[INFO]
[INFO] Apache Cocoon 3 - Pipeline 'Cocoon Pipelines test' (default: id0)
[INFO] id0 (non-caching) - Description not available
[INFO] id1 (non-caching) - Description not available
[INFO]
[INFO]
[INFO] Apache Cocoon 3 SUCCESS
[INFO] Total time: 0s
[INFO] Finished at: Tue Nov 01 20:58:48 CET 2011
[INFO] Final Memory: 10M/493M
[INFO]
{code}
when executing one (or more) pipeline(s), it prints the output in the sysout
{code}
[INFO]
[INFO]
[INFO] Apache Cocoon 3
[INFO]
[INFO]
[INFO] Executing default Pipeline 'id0'
?xml version=1.0 encoding=UTF-8?!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
License); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--!-- $Id: missing-elements.xml 1195964 2011-11-01 12:40:02Z
simonetripodi $ --pipelines
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; name=Valid
Pipeline default=id0
pipeline id=id0/
/pipelines[INFO] Default pipeline 'id0' executed
[INFO]
[INFO]
[INFO] Apache Cocoon 3 SUCCESS
[INFO] Total time: 0s
[INFO] Finished at: Tue Nov 01 21:08:35 CET 2011
[INFO] Final Memory: 13M/493M
[INFO]
{code}
To package it, it is enough launching `mvn package` under
/cocoon-cli[1], its execution will produce .tar.gaz and .zip packages
under /cocoon-cli/target, that contain a multi-platform application
which directories tree looks like the Maven one:
.
├── README
├── bin
│ ├── c3pipe
│ └── c3pipe.bat
├── lib
├── cocoon-cli-3.0.0-beta-1-SNAPSHOT.jar
├── cocoon-pipeline-3.0.0-beta-1-SNAPSHOT.jar
├── cocoon-sax-3.0.0-beta-1-SNAPSHOT.jar
├── cocoon-util-3.0.0-beta-1-SNAPSHOT.jar
├── cocoon-xml-2.0.2.jar
├── commons-beanutils-1.8.3.jar
├── commons-digester3-3.1.jar
├── jcl-over-slf4j-1.6.1.jar
├──
Re: svn commit: r1195161 - in /cocoon/cocoon3/trunk: cocoon-all/pom.xml cocoon-cli/pom.xml cocoon-rest-optional/pom.xml parent/pom.xml pom.xml
Nope, unfortunately ;( I'll give a try as soon as I get a new spare time slot! All the best, Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Mon, Oct 31, 2011 at 11:16 AM, Thorsten Scherler scher...@gmail.com wrote: On Sun, 2011-10-30 at 14:08 +, thors...@apache.org wrote: Author: thorsten Date: Sun Oct 30 14:07:59 2011 New Revision: 1195161 URL: http://svn.apache.org/viewvc?rev=1195161view=rev Log: Fixing cocoon-all adding recently developed modules. The firebugs profiling was not in the root and the build is failing when activated, but it should be managed by the root. ... Modified: cocoon/cocoon3/trunk/pom.xml URL: http://svn.apache.org/viewvc/cocoon/cocoon3/trunk/pom.xml?rev=1195161r1=1195160r2=1195161view=diff == --- cocoon/cocoon3/trunk/pom.xml (original) +++ cocoon/cocoon3/trunk/pom.xml Sun Oct 30 14:07:59 2011 @@ -50,20 +50,21 @@ modulecocoon-optional/module modulecocoon-pipeline/module modulecocoon-profiling/module + !-- modulecocoon-profiling-firebug/module -- I am not sure why that is failing. Somebody has some insides about that module? salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: [VOTE] Fix for COCOON3-79
Hi Grosso, we've marked Cocoon3 as alpha development in therms of APIs stability, so I don't see any potential issue on changing API signatures passing to a beta. Moreover, for what I can see, there are considerable improvements in the patch - I just wonder (but I'm not sure about) if we can add more power using generics, avoid castings and interfering types... but I'm not deep inside the sitemap, so I can be wrong at 99%. Anyway, +1 from my side. All the best, have a nice day! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ 2011/10/31 Francesco Chicchiriccò ilgro...@apache.org: Hi all, I've developed a fix for COCOON3-79, attached [1] as a patch. Some background information is available at [2]. Since the aforementioned patch will involve changing some interface, I'm calling the vote on Code Modification [3]: +1 = Yes, apply patch attached to [1] -1 = No, don't apply patch attached to [1] (with justification for the veto) Please cast your votes before Fri 4 Nov 06:00 UTC. Here is mine: +1 Regards. [1] https://issues.apache.org/jira/browse/COCOON3-79 [2] http://www.mail-archive.com/dev@cocoon.apache.org/msg59948.html [3] http://www.apache.org/foundation/voting.html -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: Piwi to join the ASF?
Hi guys, OTOH I personally would have be pleased on supporting this kind of initiative, I like the idea of giving PHP users a Cocoon experience! Disclaimer: I have PHP basics, but no deep knowledge about FWs, so apologize in advance if it wouldn't fit in that area. Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sat, Oct 29, 2011 at 11:20 PM, Thorsten Scherler scher...@gmail.com wrote: On Sat, 2011-10-29 at 13:55 +0200, Christian Grobmeier wrote: Hello all, we, the maintainers of the Piwi Framework are currently discussing if we move to the ASF.http://code.google.com/a/apache-extras.org/p/piwi/?redir=1 Piwi is an xml/xslt transformation framework in PHP. The reason I write to this list is because Piwi has stolen many things from Cocoon :-) We are speaking of Generators, Pipelines, Transformers, Serializers etc. As you can imagine, Piwi is some kind of PHP implementation of Cocoon. Due to the different nature of PHP we differ on various places from Cocoon. But after all you can say, if you manage to work with Cocoon, you have a good chance to understand Piwi very quickly. Therefore it might make sense to run Piwi as some kind of Cocoon subproject. Piwis goal is to create web applications quickly (as so many frameworks). One of the problems we currently are facing is community. Piwi has only a small community, users know each one face to face. There are many strong frameworks out there, like the Zend MVC. This might be a problem Zeta Components is facing too (another ASF project). Now I am an ASF committer and member, working on various projects (including the incubator). For me it makes perfect sense to move the project to the incubator and start building up a community. Other projects like Zeta Components and log4php might benefit from it. Anyway, to make this happen we need help. We are only two guys and therefore we are looking for other Apache Committers who are interested in stepping up as initial committers, mentors, champion. Please shout, if you are interested or let me know what you think abou it Cheers,Christian Hi Christian, I can remember http://markmail.org/thread/g3gddotmzdwdc6v5 and especially Davids answer http://markmail.org/message/ujr7jrvmgddwcmmc ATM IMO substitute forrest with cocoon and you would have an answer. Do not get me wrong but I am not sure whether similarity in concepts justify being subproject of cocoon. Regarding the community I do not think that being subproject of cocoon would help with that neither. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: [c3] cocoon-all
Hi Thorsten! thanks for leading this! +1, new modules - even if incomplete - should be added in the pom. Many thanks in advance for taking care of it! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Sun, Oct 30, 2011 at 12:33 AM, Thorsten Scherler scher...@gmail.com wrote: Hi all, I noticed that all recent new modules have not been added to cocoon-all. Should I sync the the pom? salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
Re: [c3] New module cocoon-shiro
Hi Thorsten, I think that it would be a great add-on. +1 to add that module, have a nice job! Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Fri, Oct 28, 2011 at 11:20 AM, Thorsten Scherler scher...@gmail.com wrote: Hi all, is there an interest of the community to have a cocoon-shiro module? I could extract the integration code to an official c3 module that I have done so far since it is pretty generic, but only if there is some interest from the community. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
[jira] [Commented] (COCOON3-78) Migrate the SQLTransformer from c2.2 to c3
[ https://issues.apache.org/jira/browse/COCOON3-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13105965#comment-13105965 ] Simone Tripodi commented on COCOON3-78: --- Great add-on Thorsten! just two minor questions: 1) Can we mark COCOON3-74 as 'resolved'? 2) looks like to me that a wrong dir has been added: * /cocoon/cocoon3/trunk/cocoon-databases/src/main/java/org/cocooon It does not contains 'apache' and contains a typo :P Can I drop it or you prefer to take care by yourself? Just let me know! :) Migrate the SQLTransformer from c2.2 to c3 -- Key: COCOON3-78 URL: https://issues.apache.org/jira/browse/COCOON3-78 Project: Cocoon 3 Issue Type: New Feature Components: cocoon-optional Reporter: Thorsten Scherler Assignee: Thorsten Scherler There is a need of the good old SQLTransformer in c3 as voiced on the ml: http://markmail.org/message/exmsh2fhu2pplbop -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [C3][PROPOSAL] Pipeline CLI
Hi all guys, I assume there's no objection on adding that module, going to create the archetype! Best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Aug 19, 2011 at 10:22 PM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, during the last 2 weeks I've been working as bricklayer (and didn't know it is fun!) and while working I had an idea I want to submit as a proposal: Pipeline CLI Rationale I often use xslproc to debug XSL stylesheets and see how outputs look like, so as user I'd like to have a tool that allows me to test C3 pipelines as well, without requiring the pipeline mus be included in a full C3-based application. Proposal I intend to add a simple module which target is a C3-based CLI tool that allows user define pipelines via CLI, without requiring a configuration file. Users would be able to launch it via shell using the following command (PoC): c3p URL (component (--component-parameter-name=component-parameter-value)*)+ (-Dpipeline-parameter-name=pipeline-parameter-value)* where * component can be an alias (i.e. 'schema' for org.apache.cocoon.sax.component.SchemaProcessorTransformer) or the fully qualified class name (additional components must be included in the classpath); * components parameters are expressed via --component-parameter-name=component-parameter-value syntax, and parameters name are the same defined in the sitemap; * global pipeline parameters are defined via -Dpipeline-parameter-name=pipeline-parameter-value. An example could be c3p file://~/Downloads/sample.xml xslt --source=file://~/Downloads/sample.xsl schema --source=file://~/Downloads/sample.xsd Where if 'finisher' is not defined, it serializes to stdout. I thought c3p would be a good shell/bash cmd name candidate that stands for cocoon3 pipeline. It should require cocoon-pipeline, cocoon-sax, cocoon-optionals as cocoon dependencies and maybe commons-cli to handle cli parameters. Any thought? more ideas? I could start adding the initial maven module during the weekend, if agreed. Many thanks in advance and have a nice weekend, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Failing build
Hi all guys, while trying to compile the new CLI module, I accidentally got an error in the I18NTransformerTest, follow below my environment and the error message. Can you help me please to figure out where the error is? Many thanks in advance, all the best! Simo $ mvn --version Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /Applications/apache-maven-3.0.3 Java version: 1.6.0_26, vendor: Apple Inc. 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.7.1, arch: x86_64, family: mac --- Test set: org.apache.cocoon.sax.component.I18NTransformerTest --- Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 0.07 sec FAILURE! base(org.apache.cocoon.sax.component.I18NTransformerTest) Time elapsed: 0.069 sec ERROR! java.lang.Error: Unresolved compilation problem: The method isEmpty() is undefined for the type String at org.apache.cocoon.sax.component.I18nTransformer.init(I18nTransformer.java:732) at org.apache.cocoon.sax.component.I18nTransformer.init(I18nTransformer.java:723) at org.apache.cocoon.sax.component.I18NTransformerTest.pipeline(I18NTransformerTest.java:67) at org.apache.cocoon.sax.component.I18NTransformerTest.base(I18NTransformerTest.java:134) http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: Failing build
I received the Jenkins notification that build came normal, I guess it is configured to send email only to last committer that commits, not the dev ML :S I think we should ping INFRA to change that setting and receive the failures on dev ML, WDYT? thanks for the fix!! :) All the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/9/16 Francesco Chicchiriccò ilgro...@apache.org: On 16/09/2011 16:39, Simone Tripodi wrote: Hi all guys, while trying to compile the new CLI module, I accidentally got an error in the I18NTransformerTest, follow below my environment and the error message. Can you help me please to figure out where the error is? Well, it smells like a Java 6 feature :-) Of course, it's sufficient to replace all String.isEmpty() with String.length == 0 in I18nTransformer's source code. The amended version has just been committed. Once more, Jenkins did not rise anything about this... -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
[jira] [Commented] (COCOON3-76) Remove jakarta-regexp dependency
[ https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13102112#comment-13102112 ] Simone Tripodi commented on COCOON3-76: --- +1 makes a lot of sense! Remove jakarta-regexp dependency Key: COCOON3-76 URL: https://issues.apache.org/jira/browse/COCOON3-76 Project: Cocoon 3 Issue Type: Improvement Components: cocoon-optional Reporter: Francesco Chicchiriccò Remove jakarta-regexp dependency from all POMs: the only class using this is, at the moment, DirectoryGenerator, in cocoon-optional. This class should be refactored to make use of java.util.regexp.* instead. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[C3][PROPOSAL] Pipeline CLI
Hi all guys, during the last 2 weeks I've been working as bricklayer (and didn't know it is fun!) and while working I had an idea I want to submit as a proposal: Pipeline CLI Rationale I often use xslproc to debug XSL stylesheets and see how outputs look like, so as user I'd like to have a tool that allows me to test C3 pipelines as well, without requiring the pipeline mus be included in a full C3-based application. Proposal I intend to add a simple module which target is a C3-based CLI tool that allows user define pipelines via CLI, without requiring a configuration file. Users would be able to launch it via shell using the following command (PoC): c3p URL (component (--component-parameter-name=component-parameter-value)*)+ (-Dpipeline-parameter-name=pipeline-parameter-value)* where * component can be an alias (i.e. 'schema' for org.apache.cocoon.sax.component.SchemaProcessorTransformer) or the fully qualified class name (additional components must be included in the classpath); * components parameters are expressed via --component-parameter-name=component-parameter-value syntax, and parameters name are the same defined in the sitemap; * global pipeline parameters are defined via -Dpipeline-parameter-name=pipeline-parameter-value. An example could be c3p file://~/Downloads/sample.xml xslt --source=file://~/Downloads/sample.xsl schema --source=file://~/Downloads/sample.xsd Where if 'finisher' is not defined, it serializes to stdout. I thought c3p would be a good shell/bash cmd name candidate that stands for cocoon3 pipeline. It should require cocoon-pipeline, cocoon-sax, cocoon-optionals as cocoon dependencies and maybe commons-cli to handle cli parameters. Any thought? more ideas? I could start adding the initial maven module during the weekend, if agreed. Many thanks in advance and have a nice weekend, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
[c3] code style
Hi all guys, I noticed some code format during commits: please avoid it or do at least in a separate commit, otherwise it makes not easy to understand which are real changes and which are formats in the diff. Moreover, code format in C3 is now inconsistent; we should choose IMHO a common style and apply it as a general accepted rule; I personally like the Maven one[1] but please share which are your preferences and let choose together how the C3 code style shall look like :) Many thanks in advance, all the best!!! Simo [1] http://maven.apache.org/developers/conventions/code.html http://people.apache.org/~simonetripodi/ http://www.99soft.org/
Re: [c3] code style
Hi Steven! sorry for the misunderstanding I made: for 'avoided' I meant that code format (of the whole file) should be avoided in the same commit that contains the fix of an issue or add a new feature; if the commit includes also the code format, it's not easy IMHO understanding what the important modifications are - that's why I suggest to split these operations in 2 separate commits :P We could adopt standard Sun conventions - my only disappoint is about the rule of 80 chars each column :/ We're in the era where everybody big LCD monitors and having a so restricted space is not comfortable, for example in apache-commons we moved to have at least 120, that looks better. maven codestyle is just my preferred one - no particular reason, just looks in the way I like :P - but I don't have any reason to convince everybody to adopt it, my personal rule is to respect the original codebase style - most important is IMHO every Cocoon committer doesn't apply a different/personal style, that's why I started the thread. I don' think we need to open a vote to chose the cocoon3 style, just see democratically which is the preferred one and adopt it. Gratitude for sharing your thoughts, really appreciated!!! Have a nice weekend, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Aug 20, 2011 at 12:13 AM, Steven Dolg steven.d...@indoqa.com wrote: Am 19.08.2011 22:29, schrieb Simone Tripodi: Hi all guys, I noticed some code format during commits: please avoid it or do at least in a separate commit, otherwise it makes not easy to understand which are real changes and which are formats in the diff. Moreover, code format in C3 is now inconsistent; we should choose IMHO a common style and apply it as a general accepted rule; I personally like the Maven one[1] but please share which are your preferences and let choose together how the C3 code style shall look like :) Many thanks in advance, all the best!!! Simo [1] http://maven.apache.org/developers/conventions/code.html http://people.apache.org/~simonetripodi/ http://www.99soft.org/ I'm pretty sure I can live with whatever decision will be made. However, some of the things in the maven style strike me as odd. They advocate not adding documentation for trivial things yet they encourage people to add comments like // -- // Public methods // -- Which is probably the most trivial thing of them all (it's the first word of the method signature and there's no cheating about that). I'm also more and more becoming a fan of longer names for everything. Short and descriptive sounds almost mutually exclusive, unless you think s,re and list are particularly descriptive names. I like Robert C. Martin's approach in Clean Code, but it's too long to explain here. Blanks after opening parentheses and before closing parentheses is probably my biggest pet peeve. Especially when also allowing myMethod() -- where's the space here?! Are there really people who think format( ( int ) file.length( ) ) is any more readable than format((int) file.length())? I think that's inflationary use of whitespace and bad. I can understand the desire to be able to read diffs and understand exactly and completely what changed. OTOH I think the number of restrictions inversely correlates with the likelihood that a good yet not required change is actually made. And I believe that those good yet not required changes are the essence of craftmanship. it's good vs it's working The difference between pat and pattern is negligible - but there is one. Same with formatting, spelling, comments and anything else. But as I said at the beginning: If we decide that formatting is something special, that must happen in a separate commit or even be avoided (really?!), then I will stick to that rule, of course. Steven
Re: Filtering out (some) Sonar violations
great news!!! have a nice WE, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/8/5 Francesco Chicchiriccò ilgro...@apache.org: Hi folks, short time after asking [1], people at infrastructure made a custom ruleset for Cocoon at Sonar [2] and we have no more Blocker or Critical violations. Kudos to the infrastructure team! [1] https://issues.apache.org/jira/browse/INFRA-3828 [2] https://analysis.apache.org/rules_configuration/index/10 On 05/08/2011 11:57, Steven Dolg wrote: Am 05.08.2011 11:25, schrieb Nathaniel, Alfred: Hi Francesco, I am a big fan of Findbugs and persueing a zero-warnings policy. In other projects we use a Findbugs exclude filter file to disable warnings and document the deliberation for doing so. That's what we do as well. TBH, the default ruleset contains more than one rule that I find highly suspicious if not outright stupid. Zero warnings is IMO the only way to go, same as with unit tests. Sonar should foresee to pull such an exclude filter from the project's code base. NB we also exclude XFB_XML_FACTORY_BYPASS with reason axis.client.Stub requires specific axis.message.SOAPHeaderElement. Maybe we should try to get our own set of rules (there are rulesets CXF Rules with Findbugs and My Faces with Findbugs, so I guess that's possible). I think it's easier to start with a more lenient ruleset, work (close) to 0 warnings and then add a couple more restrictions and repeat. Sitting in front of hundreds of warnings can be a frustrating situation... Steven Cheers, Alfred. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 5. August 2011 08:50 To: dev@cocoon.apache.org Subject: Filtering out (some) Sonar violations ... My proposal would be to open a issue to INFRA in order to ask for disabling these two rules: do you see any problem, with this? For my personal experience about Findbugs, PMD and Checkstyle, it is rather impossible to satisfy all the rules (thus bringing the number of violations to zero); however, I personally think that reducing the huge amount that we have at the moment would dramatically improve Cocoon 3's source code quality. ... The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
Re: Cocoon GetTogether?
Francesco, you stole the words from my mouth :) Arrosticini FTW :D Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Aug 5, 2011 at 12:28 PM, Reinhard Pötz reinh...@apache.org wrote: On 08/04/2011 05:08 PM, Simone Tripodi wrote: Hi all guys and sorry for have overlooked that discussion. A GT is what I really wish see realized :) I spoke also with Francesco via chat and we both agreed/wish on give new energy to C3 promoting a GT. I tried to go to Vienna last year to meet Reinhard and Steven, but unfortunately didn't have enough budget to go (here in Italy salaries are not at EU level - unless you are a Politician :P) :( I would like - just my wish - to propose the University of L'Aquila (Italy) as next Cocoon3 GT for 2 main reason (3, since it is the city when I was born :P ): * on April 6, 2009, it was partially destroyed by a earthquake[1] and it's still in terrible conditions - so organizing a so great event would hopefully attract the interest * because of it, the University lost a lot of students, we could maybe help them attracting guys It is just a prototypal idea, I should speak with people I'm still in touch there before doing a real proposal... anyway, how does it sound? TIA, all the best!!! It would be great to have another CocoonGT in Italy. +1 from me! -- 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: Springification of C3 - proof of concept
Hi Igor!!! congrats for your committership and your dedication to this work!!! I really appreciate you shared your results with us! Just my *personal* POV: even if I'm NOT a SpringFramework fan (and I won't be :P) your work shall be included in a way or another in C3. Anyway I would prefer Spring doesn't play the main role: I mean, having 3rd parties integrations it more than fine - we already have indeed modules with 3rd parties integrations, like StringTemplate, JAX-RS, Optionals (Solr, JAXB) - but IMHO Cocoon *core* components should not be dependent by any framework, I wouldn't force C3 users learning Cocoon AND Spring as a starting point, or require Spring as knowledge base to get started with Cocoon. I think that should sound reasonable, WDYT? So, my suggestions, if you are happy to continue on contributing - and I really hope you are :) - is: * checkout the latest C3 code from /trunk; * understand how it is actually organized and check what has been already implemented (for sure you can help us on improving actual JAXB implementation, for example) * starting proposing and discussing modifications/additional components step by step, not sure everybody would agree on adding everything as a single big commit ;) Many thanks in advance, all the best!!! Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Aug 2, 2011 at 1:32 AM, Igor Malinin igor...@gmail.com wrote: Hello. I've promised some (not so long) time ago to share my experiments with C3 and Spring, and now I am ready to show some interesting achievements. Here is the source code: https://github.com/igorzep/cocoon-springification What it does... 1) Use traditional annotated Spring Controllers I think it is better REST than Cocoon today. Those days when Cocoon was a leader in this respect has passed, and it really was the best REST framework from day one when nobody even used this word. But now Spring is really powerful and I think Cocoon should not try to invent own things but integrate with Spring as much as possible. In current form it disables Spring functionality and replace with own much more limited solution. 2) Use Cocoon Sitemap as Spring View Again - traditional Spring way. Also i map Cocoon to WEB-INF so that sitemap is hidden for direct browser access (good trick to workaround lack of private pipelines in C3). 3) Use Spring FORM tag library in SAX pipeline When it is very simple implementation it works quite good already, much better than I expect from it myself... 4) Integrated Validation with Spring and Hibernate Validator Again - traditional Spring 3 way of handling forms, together with previous item can be a good foundation for replacing old Cocoon forms module... 5) EclipseLink JPA Just my favorite, as it implements both JPA and JAXB... 6) Mapping Spring model to XML with JAXB annotations Just a quick hack as everything else... 7) JRebel compatible, just generate rebel.xml for main module Unfortunately EclipseLink JRebel plugin does not work with latest EclipseLink, but can be switched off easily. Otherwise I did a small fix to XSLT transformer, so it rechecks for modifications correctly (not included with sources) and it works much better than Cocoon RCL. Actually Cocoon RCL destroyed root spring context on first invocation and any future requests to EclipseLink didn't work at all. I think that Cocoon RCL should be dropped at all - it is unusable for something serious, if you do something more than totally trivial it takes more time to fight with it, works almost always incorrectly and saves no time as the result... Thanks. Discussions and critics are welcome.
Re: Cocoon GetTogether?
Hi all guys and sorry for have overlooked that discussion. A GT is what I really wish see realized :) I spoke also with Francesco via chat and we both agreed/wish on give new energy to C3 promoting a GT. I tried to go to Vienna last year to meet Reinhard and Steven, but unfortunately didn't have enough budget to go (here in Italy salaries are not at EU level - unless you are a Politician :P) :( I would like - just my wish - to propose the University of L'Aquila (Italy) as next Cocoon3 GT for 2 main reason (3, since it is the city when I was born :P ): * on April 6, 2009, it was partially destroyed by a earthquake[1] and it's still in terrible conditions - so organizing a so great event would hopefully attract the interest * because of it, the University lost a lot of students, we could maybe help them attracting guys It is just a prototypal idea, I should speak with people I'm still in touch there before doing a real proposal... anyway, how does it sound? TIA, all the best!!! Simo [1] http://en.wikipedia.org/wiki/2009_L'Aquila_earthquake http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jul 19, 2011 at 6:44 PM, Lars Huttar lars_hut...@sil.org wrote: On 7/18/2011 4:49 PM, Lars Huttar wrote: As we've been talking about Cocoon Do-ocracy and community contributions, my mind turns to my past attempts to help develop Cocoon, and the vast gap that seems to yawn between me and being able to contribute effectively. While I would love to be able to contribute, there is quite a stack of technologies that seem to require mastery first... e.g. Maven, Wicket, Spring...? I suspect that much of this would be reduced if I could sit down and be walked through a process with a knowledgeable person who can tell me what I do and don't need to learn, and of whom I could ask targeted questions. And that leads me to ask, what are the possibilities of a Cocoon GetTogether this year? next year? (The sooner the better, as far as I'm concerned!) AFAIK the last GT was in 2005? The hackathon sounded very productive. Regards, Lars (Sorry for not replying directly to others' replies, but I don't seem to be receiving them in my inbox (I read them at http://cocoon.markmail.org/search/?q=#query:+page:1+mid:yucxttvietp2ukac+state:results).) Given that there may not be enough people and sponsorship for a Cocoon GT, what about some kind of virtual GT? I.e. a concentrated time of group web presence. We could still have presentations, QA, hackathon, maybe using audio channel such as Blink/Mumble/TeamSpeak... For me, the most valuable part would be a tutorial on getting up to speed on Cocoon development... with the minimum grounding in Maven/Wicket/Spring/Java servlet technologies required, and with plenty of opportunity to ask questions. A couple of simple hello world tutorials would be worth a lot. Regards, Lars
Re: Cocoon GetTogether?
really interesting, both dates and both places sound *really* good :) Have a nice day! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Thu, Aug 4, 2011 at 9:08 PM, Jasha Joachimsthal j.joachimst...@onehippo.com wrote: On 19 July 2011 10:15, Thorsten Scherler scher...@gmail.com wrote: On Tue, 2011-07-19 at 08:42 +0200, Francesco Chicchiriccò wrote: On 19/07/2011 00:21, Torsten Curdt wrote: And that leads me to ask, what are the possibilities of a Cocoon GetTogether this year? next year? (The sooner the better, as far as I'm concerned!) AFAIK the last GT was in 2005? The hackathon sounded very productive. Last GT was in 2007, in Rome (I've found this old post from Jeroen Reijn [1], since the cocoongt.org domain seems to have passed to other hands... GT have always been great events but do we have enough people that would bother to come? ...and especially sponsors that see it worthwhile? Hum, unfortunately I must agree with Torsten's doubts... Maybe we can rediscuss this proposal in a few months, WDYT? There is http://barcampspain.com/ at 8 of October. I will be there and we could do some c3 work if people like to come to the south of spain. salu2 [1] http://blog.jeroenreijn.com/2007/09/cocoon-gt-2007-update.html There will also be a hackathon after GotoCon Amsterdam in the Hippo Office on October 15 :) http://wiki.apache.org/apachecon/AmsterdamHackathon2011 Jasha Joachimsthal Europe - Amsterdam - Oosteinde 11, 1017 WT Amsterdam - +31(0)20 522 4466 US - Boston - 1 Broadway, Cambridge, MA 02142 - +1 877 414 4776 (toll free) www.onehippo.com
Re: [C3] Java version 1.6
Hi all guys!!! I agree with Nathaniel, I had terrible pains with method-not-found exception with Google Doclava simply by targeting to java1.5 but using 1.6 :P Anyway, the animal-sniffer[1] maven plugin helps a lot on keeping code safely 1.5 compatible - Google team used it a lot while developing Google Guice Anyway, I'm +0 for the upgrade and explain my personal motivations following the list provided by Francesco - and please remember I'm more familiar with coreoptional APIs ;) * Collections Framework Enhancements +0: We are strongly relying on LinkedList, HashMap and LinkedHashMap implementations; is there any impl in Java6 that could help on improving the pipeline APIs? * and ServiceLoader +0: there's nothing that commons-discovery[2] cannot do compared to Java built-in ServiceLoader; OTOH, discovery supports more features * Internationalization Enhancements: especially now that we should start working on the new i18n transformer [3] +1 * JMX [4] and Management enhancements: will we ever put this great Cocoon 3 stuff in production? +1 Last but not least, Cocoon 3 depends on many other frameworks and libraries that will eventually require Java 6 (and 7, soon) capabilities. +0: If those dependencies name start with 'S' and terminate with 'pringframework', I would personally love to see them replaced, but that's just *my* POV :P ;) Have a nice day, all the best!!! Simo [1] http://mojo.codehaus.org/animal-sniffer-maven-plugin/ [2] http://commons.apache.org/discovery/ http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Aug 2, 2011 at 3:56 PM, Nathaniel, Alfred alfred.nathan...@six-group.com wrote: Peter Hunsberger wrote: We seem to have this discussion every few years. There's always people that can't upgrade. Personally I think it's time to do it and I wish we had done it long ago. With C3 in particular, people should have no dependencies in production since it is still officially Beta. Even if they do, they can stay on a previous version after all, if it is good enough to use at all why can't they stick with what they are using? Unless someone can come up with a reason not to I'd say it's time to start a vote. True, we had the same discussion years ago to me C2.1 from J1.3 to J1.4. Apart from the improvements we get when using 1.6, my main point is that real 1.5 support is not achieved by using a 1.6 javac with -source=1.5 and -target=1.5. That happily compiles and generates 1.5 byte code containing calls to String.isEmpty. Only when you run that jar in a 1.5 JVM it will die with a method-not-found exception. Unless we have a good crowd of developers who voluntarily stick to 1.5 all the way, it is just wishful thinking that C3 is and remains 1.5 compatible. Even if that hypothetical poor guy exists who would love to use C3 but is stuck at Java5, I don't think we do him a favor. Better force them to go 1.6 than to have them chase the next odd String.isEmpty which leaked into the release. Hands up who is / is willing to run jdk1.5 for C3 development. NB Jenkins is setup with 1.6. Does infra support real 1.5 builds? Cheers, Alfred. The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this e-mail immediately. Thank you.
Re: [C3] Java version 1.6
Hi all guys!!! My question is instead: is there any advantage we can get by targeting Cocoon to Java6? Is there any specific Java6 APIs we need to improve the existing codebase? If yes, please can you describe? TIA, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ 2011/8/1 Francesco Chicchiriccò ilgro...@apache.org: On 01/08/2011 16:26, Nathaniel, Alfred wrote: Hi all, C3 is still set to 1.5 as source and target version. Java5 is end of life since almost two years now. Is there any good reason not to go 1.6? Not that I know, so +1 for me to move to 1.6. Regards. -- Francesco Chicchiriccò Apache Cocoon Committer and PMC Member http://people.apache.org/~ilgrosso/
