>> Out of curiosity :
>> Why didn't you use XMLCalabash ? ( A pure Xproc impl in java )
>>
>
> Before any technical analysis of the product, the fact that it is GPL simply
> forbids its use in an Apache project.
>
> It also has an "interesting" (not!) feature [1] that collects anonymous
> usage dat
Ralph Goers wrote:
On May 1, 2009, at 4:45 AM, Sylvain Wallez wrote:
dynnamitt wrote:
Thanks man, I didn't know about that Phone-home feat.
I did not however see GPL as an issue since the JVM(7) itself soon
becomes a member.
Does this mean that all apache apps will be stuck in JVM6 land ??
On May 1, 2009, at 4:45 AM, Sylvain Wallez wrote:
dynnamitt wrote:
Thanks man, I didn't know about that Phone-home feat.
I did not however see GPL as an issue since the JVM(7) itself soon
becomes a member.
Does this mean that all apache apps will be stuck in JVM6 land ??
The GPL is "imp
dynnamitt wrote:
Thanks man, I didn't know about that Phone-home feat.
I did not however see GPL as an issue since the JVM(7) itself soon becomes a
member.
Does this mean that all apache apps will be stuck in JVM6 land ??
The GPL is "imposed freedom", in that it states that any derived wor
t floods it? Will it crash your own server?
>
> Sylvain
>
> [1] http://xmlcalabash.com/docs/phonehome.html
>
> --
> Sylvain Wallez - http://bluxte.net
>
>
>
--
View this message in context:
http://www.nabble.com/Cocoon-and-Sling-tp22926362p23331392.html
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
dynnamitt wrote:
Out of curiosity :
Why didn't you use XMLCalabash ?
( A pure Xproc impl in java )
Before any technical analysis of the product, the fact that it is GPL
simply forbids its use in an Apache project.
It also has an "interesting" (not!) feature [1] that collects anonymous
http://www.w3.org/TR/xproc/
> [4]
> http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/xproc/
> [5]
> http://cwiki.apache.org/confluence/display/SLINGxSITE/XSLT+Processing+Pipeline
>
>
--
View this message in context:
http://www.nabble.com/Cocoon-and-Sling-tp22926362p23322603.html
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
I think it makes sense to evolve Cocoon to have a central portion of
it revolve around pipeline processing and various ways of doing it.
It would make sense to just come to one place rather than to have to
go to two.
On Apr 7, 2009, at 3:32 AM, Juan José Vázquez Delgado wrote:
Hi all,
2009/4/8 Juan José Vázquez Delgado :
> ...This stuff is not a new kind of sitemap implementation really. In
> fact, I decided to go to XProc because AFAIK Cocoon sitemap doesn´t
> separate the request resolution from XML pipeline processing and Sling
> already resolves request resolution on its own
> However, I'm not sure pluggable sitemap processors are the kind of
> complexity I'd want to see either...
This stuff is not a new kind of sitemap implementation really. In
fact, I decided to go to XProc because AFAIK Cocoon sitemap doesn´t
separate the request resolution from XML pipeline proces
On Tue, 2009-04-07 at 12:32 +0200, Juan José Vázquez Delgado wrote:
...
> >From now on, I wonder whether Sling is the right place to keep on
> implementing W3C XProc or it´s Cocoon instead. Is this stuff
> interesting to Cocoon community and team?.
sounds interesting.
salu2
--
Thorsten Scherler
2009/4/7 Juan José Vázquez Delgado
>
> Hi all,
>
> As discussed in a previous thread [1], some people think it would be a
> good idea to take advantage of Cocoon´s pipelining and Sling request
> processing capabilities working together.
>
> We (Sling team) have implemented a first approach to this
Hi all,
As discussed in a previous thread [1], some people think it would be a
good idea to take advantage of Cocoon´s pipelining and Sling request
processing capabilities working together.
We (Sling team) have implemented a first approach to this cooperation
using Cocoon 3 pipeline engine [2] an
13 matches
Mail list logo
