Re: [C3] Time to define a roadmap

2012-05-21 Thread Francesco Chicchiriccò

On 20/05/2012 16:54, Reinhard Pötz wrote:

On 05/14/2012 09:04 AM, Francesco Chicchiriccò wrote:

Hi all,
it's been quite a while since our latest C3 release (July 1st, 2011)
[1]; even though I personally believe we should at least fix some
aspects before cutting next release, I also think it would be nice to
provide a roadmap for all people - including me - that are already using
C3 on some of their own projects.

Hence:

1. what will we include in beta-1? Is JIRA updated in this respect [2]?
There are quite some other unplanned issues [3].
2. what will we plan after beta-1? beta-2? and afterwards?
3. do we want to consider some milestone release (M1 / M2 / ...)
instead, maybe even BEFORE beta-1, so that we can provide some stable
reference for external project relying upon C3?


IMO the most important missing thing before going beta is supporting 
alternative output types than OutputStream and to get rid of throws 
Exception which is actually of no value.


The latter is rather simple to achieve, the first change needs (a lot 
of) more work, especially regarding caching. Steven and I have started 
to work on a proposal for dynamic output types but we haven't had 
enough time yet to commit it to the whiteboard and write a proposal 
email.




Reinhard, I see your point: do you think it would be possible to release 
something like a milestone in the meanwhile? We would be able, in this 
way, to either not yet fall into beta and to provide C3 users out there 
with a rather stable reference for their projects.


WDYT?

Regards.

--
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/



[jira] [Assigned] (COCOON3-76) Remove jakarta-regexp dependency

2012-05-21 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò reassigned COCOON3-76:
-

Assignee: Francesco Chicchiriccò

 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ò
Assignee: Francesco Chicchiriccò
 Attachments: DirectoryGenerator-COCOON3-76.diff


 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.
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] [Updated] (COCOON3-76) Remove jakarta-regexp dependency

2012-05-21 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò updated COCOON3-76:
--

Attachment: COCOON3-76-find.diff

As reported in the provided StackOverflow question, using find() instead of 
matches() should keep the same behavior as previous.

WDYT? 

 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ò
Assignee: Francesco Chicchiriccò
 Attachments: COCOON3-76-find.diff, DirectoryGenerator-COCOON3-76.diff


 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.
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] [Updated] (COCOON3-76) Remove jakarta-regexp dependency

2012-05-21 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò updated COCOON3-76:
--

Fix Version/s: 3.0.0-beta-1
Affects Version/s: 3.0.0-beta-1

 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
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
 Fix For: 3.0.0-beta-1

 Attachments: COCOON3-76-find.diff, DirectoryGenerator-COCOON3-76.diff


 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.
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: [C3] Time to define a roadmap

2012-05-21 Thread Reinhard Pötz

On 05/21/2012 08:58 AM, Francesco Chicchiriccò wrote:

On 20/05/2012 16:54, Reinhard Pötz wrote:

On 05/14/2012 09:04 AM, Francesco Chicchiriccò wrote:

Hi all,
it's been quite a while since our latest C3 release (July 1st, 2011)
[1]; even though I personally believe we should at least fix some
aspects before cutting next release, I also think it would be nice to
provide a roadmap for all people - including me - that are already using
C3 on some of their own projects.

Hence:

1. what will we include in beta-1? Is JIRA updated in this respect [2]?
There are quite some other unplanned issues [3].
2. what will we plan after beta-1? beta-2? and afterwards?
3. do we want to consider some milestone release (M1 / M2 / ...)
instead, maybe even BEFORE beta-1, so that we can provide some stable
reference for external project relying upon C3?


IMO the most important missing thing before going beta is supporting
alternative output types than OutputStream and to get rid of throws
Exception which is actually of no value.

The latter is rather simple to achieve, the first change needs (a lot
of) more work, especially regarding caching. Steven and I have started
to work on a proposal for dynamic output types but we haven't had
enough time yet to commit it to the whiteboard and write a proposal
email.



Reinhard, I see your point: do you think it would be possible to release
something like a milestone in the meanwhile? We would be able, in this
way, to either not yet fall into beta and to provide C3 users out there
with a rather stable reference for their projects.


Yes, the milestone / release candidate scheme has worked very well for 
us in the past and is currently also used by e.g. Eclipse, Spring or 
Wicket. Many users should be familiar with that.


--
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


[jira] [Commented] (COCOON3-76) Remove jakarta-regexp dependency

2012-05-21 Thread Javier Puerto (JIRA)

[ 
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280021#comment-13280021
 ] 

Javier Puerto commented on COCOON3-76:
--

IMO matches method makes more sense, less ambiguity and also it's the 
behaviour I should expect. The problem is the backwards compatibility.

 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
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
 Fix For: 3.0.0-beta-1

 Attachments: COCOON3-76-find.diff, DirectoryGenerator-COCOON3-76.diff


 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.
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-76) Remove jakarta-regexp dependency

2012-05-21 Thread JIRA

[ 
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280025#comment-13280025
 ] 

Francesco Chicchiriccò commented on COCOON3-76:
---

Well, I think that in C3 we can not be worried about backward compatibility 
issues: I'll apply your patch then.

 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
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
 Fix For: 3.0.0-beta-1

 Attachments: COCOON3-76-find.diff, DirectoryGenerator-COCOON3-76.diff


 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.
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] [Updated] (COCOON3-76) Remove jakarta-regexp dependency

2012-05-21 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò updated COCOON3-76:
--

Attachment: (was: COCOON3-76-find.diff)

 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
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
 Fix For: 3.0.0-beta-1

 Attachments: DirectoryGenerator-COCOON3-76.diff


 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.
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] [Closed] (COCOON3-76) Remove jakarta-regexp dependency

2012-05-21 Thread JIRA

 [ 
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Francesco Chicchiriccò closed COCOON3-76.
-

Resolution: Fixed

 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
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
 Fix For: 3.0.0-beta-1

 Attachments: DirectoryGenerator-COCOON3-76.diff


 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.
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-76) Remove jakarta-regexp dependency

2012-05-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/COCOON3-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280046#comment-13280046
 ] 

Hudson commented on COCOON3-76:
---

Integrated in Cocoon-trunk #177 (See 
[https://builds.apache.org/job/Cocoon-trunk/177/])
[COCOON3-76] Applying provided patch (Revision 1340929)

 Result = SUCCESS
ilgrosso : http://svn.apache.org/viewvc/?view=revrev=1340929
Files : 
* 
/cocoon/cocoon3/trunk/cocoon-optional/src/main/java/org/apache/cocoon/optional/pipeline/components/sax/directory/DirectoryGenerator.java


 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
Affects Versions: 3.0.0-beta-1
Reporter: Francesco Chicchiriccò
Assignee: Francesco Chicchiriccò
 Fix For: 3.0.0-beta-1

 Attachments: DirectoryGenerator-COCOON3-76.diff


 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.
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: anybody using saxon with C3?

2012-05-21 Thread Francesco Chicchiriccò

On 21/05/2012 16:55, Robby Pelssers wrote:


Hi guys,

Just wondering if anyone is already using Saxon (and hence xslt2.0) 
with C3?  Would be great if somebody can give some pointers. I know 
how-to configure C2.2 
http://robbypelssers.blogspot.com/2010/08/using-saxon-instead-of-xalan-with.html 
but I guess things are done differently now.




Hi Robby,
it should be enough to create

META-INF/services/javax.xml.transform.TransformerFactory

with content

net.sf.saxon.TransformerFactoryImpl

in your C3 app.

--
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/



RE: anybody using saxon with C3?

2012-05-21 Thread Robby Pelssers
Thx m8...

I should have googled around for a bit but I want to get up and running fast ;-)

http://stackoverflow.com/questions/2968190/how-to-select-saxon-transformerfactory-in-java

Will let you know if I run into any issues!!

Robby

From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Monday, May 21, 2012 5:03 PM
To: dev@cocoon.apache.org
Subject: Re: anybody using saxon with C3?

On 21/05/2012 16:55, Robby Pelssers wrote:
Hi guys,

Just wondering if anyone is already using Saxon (and hence xslt2.0) with C3?  
Would be great if somebody can give some pointers. I know how-to configure C2.2 
http://robbypelssers.blogspot.com/2010/08/using-saxon-instead-of-xalan-with.html
 but I guess things are done differently now.

Hi Robby,
it should be enough to create

META-INF/services/javax.xml.transform.TransformerFactory

with content

net.sf.saxon.TransformerFactoryImpl

in your C3 app.


--

Francesco Chicchiriccò



Apache Cocoon PMC and Apache Syncope PPMC Member

http://people.apache.org/~ilgrosso/


could not download XercesImpl from maven repo

2012-05-21 Thread Robby Pelssers
Hi all,

I had to change XercesImpl version from

dependency
groupIdxerces/groupId
artifactIdxercesImpl/artifactId
version2.10.1/version
/dependency
to
dependency
groupIdxerces/groupId
artifactIdxercesImpl/artifactId
version2.10.0/version
/dependency

In order to get things working.  I used the archetypes to get started by the 
way.  Anyone else had similar issues?

Robby


question related to using servlet: in @src

2012-05-21 Thread Robby Pelssers
Hi all,

I noticed the cocoon protocol got ditched in favour of the servlet protocol.

However something puzzles me as test1 is not working but test2 is.  I studied 
the sitemap from sample block and they use it all over the place. What am I 
missing here?

  map:match pattern=testdata
map:generate src=data/PH3330L.xml/
map:serialize/
  /map:match

  map:match pattern=test1
map:generate src=servlet:/testdata/
map:transform src=xslt/test.xslt/
map:serialize/
  /map:match

  map:match pattern=test2
map:generate src=data/PH3330L.xml/
map:transform src=xslt/test.xslt/
map:serialize/
  /map:match


This is the stacktrace:

exception-report class=java.net.URISyntaxException timestamp=Mon, 21 May 
2012 23:48:09 +0200messageIllegal character in scheme name at index 18: 
com.nxp.spider2.vp_generation.service+:/testdata/messagestacktracejava.net.URISyntaxException:
 Illegal character in scheme name at index 18: 
com.nxp.spider2.vp_generation.service+:/testdata

at java.net.URI$Parser.fail(URI.java:2810)

at java.net.URI$Parser.checkChars(URI.java:2983)

at java.net.URI$Parser.parse(URI.java:3010)

at java.net.URI.init(URI.java:735)

at 
org.apache.cocoon.servletservice.AbsoluteServletConnection.init(AbsoluteServletConnection.java:70)

at 
org.apache.cocoon.servletservice.url.ServletURLConnection.init(ServletURLConnection.java:92)

at 
org.apache.cocoon.servletservice.url.ServletURLStreamHandler.openConnection(ServletURLStreamHandler.java:30)

at java.net.URL.openConnection(URL.java:945)

at 
org.apache.cocoon.sax.component.XMLGenerator$URLGenerator.execute(XMLGenerator.java:433)

at 
org.apache.cocoon.sax.component.XMLGenerator.execute(XMLGenerator.java:121)

at 
org.apache.cocoon.pipeline.AbstractPipeline.invokeStarter(AbstractPipeline.java:150)

at 
org.apache.cocoon.pipeline.CachingPipeline.execute(CachingPipeline.java:146)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:318)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)

at 
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)

at 
org.apache.cocoon.servlet.collector.ResponseHeaderCollector.interceptInvoke(ResponseHeaderCollector.java:94)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at 
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)

  at 
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)

at 
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

at 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:90)

at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)

at 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:202)

at $Proxy29.execute(Unknown Source)

at 
org.apache.cocoon.sitemap.InvocationImpl.execute(InvocationImpl.java:163)

at 
org.apache.cocoon.sitemap.node.PipelineNode.invoke(PipelineNode.java:68)

at 
org.apache.cocoon.sitemap.node.AbstractSitemapNode.invoke(AbstractSitemapNode.java:100)

at 
org.apache.cocoon.sitemap.node.PipelinesNode.invoke(PipelinesNode.java:49)

at 
org.apache.cocoon.sitemap.node.AbstractSitemapNode.invoke(AbstractSitemapNode.java:100)

at 
org.apache.cocoon.sitemap.node.Sitemap.invoke(Sitemap.java:42)