You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Juan José Vázquez Delgado <ju...@gmail.com> on 2009/04/07 12:32:41 UTC
Cocoon and Sling
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] and the W3C XProc recomendation [3]
in order to specify the pipelines to be performed. At least in the
beginning, the Cocoon sitemap concept has been discarded because of
quite overlapping between this one and Sling resource resolution.
The code is available here [4] and details about how it works here [5].
>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?.
Regards,
Juanjo.
[1] http://markmail.org/message/owefsfj4eqbc4ifq#query:OSGi%20integration
[2] http://cocoon.apache.org//3.0/
[3] 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
Re: Cocoon and Sling
Posted by Thorsten Scherler <th...@apache.org>.
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 <thorsten.at.apache.org>
Open Source <consulting, training and solutions>
Re: Cocoon and Sling
Posted by Sylvain Wallez <sy...@apache.org>.
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 ??
>>
>> The GPL is "imposed freedom", in that it states that any derived
>> works of a GPL'ed product should also be GPL licensed itself, and
>> thus that its source code should be distributed with the product.
>>
>> When your product (or Cocoon for that matter) uses classes from
>> XMLCalabash, it becomes a derived product and thus must be GPL'ed.
>> This is why any GPL library is a big no-no at Apache, since the
>> Apache license is much more liberal and allows proprietary usage.
>>
>> The case of the JVM is different, because a Java application is not a
>> derived work of the JVM, and only relies on the Java specification
>> and the .class file format. You can then run your program on any
>> virtual machine that understands this class file format.
>>
>> And by the way, Apache has an Apache-licensed virtual machine:
>> http://harmony.apache.org/
>
> Actually, this isn't quite accurate. Java applications are "derivitive
> works" (by the GPL definition) of the Java Library. However, OpenJDK
> uses GPL with the classpath exception for the library. The classpath
> exception is similar to the LGPL in that it says that your derived
> work can be under a different license. See
> http://freejdk.org/faqs/openjdk_license.html.
Hmm... true, but GPL virality only applies to distribution, i.e. when
you ship in a same package a GPL'ed JDK and an application. When the
end-user installs a Java application in an environment that already has
a JDK, this user is the one doing the assembly, out of the control of
the initial developer.
The JDK APIs specification and the class file format specification
aren't GPL'ed, meaning you can develop a non-GPL'ed application using
any implementation of these specifications, even simple stubs that just
make the compiler happy.
Anyway, the rule of thumb for Dynnamitt is that adding a GPL'ed library
to an Apache project is simply not possible.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Cocoon and Sling
Posted by Ralph Goers <ra...@dslextreme.com>.
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 "imposed freedom", in that it states that any derived
> works of a GPL'ed product should also be GPL licensed itself, and
> thus that its source code should be distributed with the product.
>
> When your product (or Cocoon for that matter) uses classes from
> XMLCalabash, it becomes a derived product and thus must be GPL'ed.
> This is why any GPL library is a big no-no at Apache, since the
> Apache license is much more liberal and allows proprietary usage.
>
> The case of the JVM is different, because a Java application is not
> a derived work of the JVM, and only relies on the Java specification
> and the .class file format. You can then run your program on any
> virtual machine that understands this class file format.
>
> And by the way, Apache has an Apache-licensed virtual machine: http://harmony.apache.org/
>
Actually, this isn't quite accurate. Java applications are "derivitive
works" (by the GPL definition) of the Java Library. However, OpenJDK
uses GPL with the classpath exception for the library. The classpath
exception is similar to the LGPL in that it says that your derived
work can be under a different license. See http://freejdk.org/faqs/openjdk_license.html
.
Ralph
Re: Cocoon and Sling
Posted by Sylvain Wallez <sy...@apache.org>.
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 works
of a GPL'ed product should also be GPL licensed itself, and thus that
its source code should be distributed with the product.
When your product (or Cocoon for that matter) uses classes from
XMLCalabash, it becomes a derived product and thus must be GPL'ed. This
is why any GPL library is a big no-no at Apache, since the Apache
license is much more liberal and allows proprietary usage.
The case of the JVM is different, because a Java application is not a
derived work of the JVM, and only relies on the Java specification and
the .class file format. You can then run your program on any virtual
machine that understands this class file format.
And by the way, Apache has an Apache-licensed virtual machine:
http://harmony.apache.org/
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Cocoon and Sling
Posted by dynnamitt <kj...@gmail.com>.
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 ??
regards,
dynnamitt.
Sylvain Wallez wrote:
>
> 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
> usage data and send it who knows where for who knows what! Beyond
> privacy and security concerns, it also leads to some operational
> concerns. What happens if the "home" site is down, or if you have a busy
> website that 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.
Re: Cocoon and Sling
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
>> 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 data and send it who knows where for who knows what! Beyond privacy
> and security concerns, it also leads to some operational concerns. What
> happens if the "home" site is down, or if you have a busy website that
> floods it? Will it crash your own server?
On the other hand, It would not be easy to integrate XMLCalabash with
Sling as it is designed. XMLCalabash is intended to work alone and I
don´t find out a natural strategy in order to get both working
together.
BR,
Juanjo.
> [1] http://xmlcalabash.com/docs/phonehome.html
Re: Cocoon and Sling
Posted by Sylvain Wallez <sy...@apache.org>.
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
usage data and send it who knows where for who knows what! Beyond
privacy and security concerns, it also leads to some operational
concerns. What happens if the "home" site is down, or if you have a busy
website that floods it? Will it crash your own server?
Sylvain
[1] http://xmlcalabash.com/docs/phonehome.html
--
Sylvain Wallez - http://bluxte.net
Re: Cocoon and Sling
Posted by dynnamitt <kj...@gmail.com>.
Out of curiosity :
Why didn't you use XMLCalabash ?
( A pure Xproc impl in java )
regards
Kjetil Dynnamittt
Juan José Vázquez Delgado wrote:
>
> 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] and the W3C XProc recomendation [3]
> in order to specify the pipelines to be performed. At least in the
> beginning, the Cocoon sitemap concept has been discarded because of
> quite overlapping between this one and Sling resource resolution.
>
> The code is available here [4] and details about how it works here [5].
>
> 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?.
>
> Regards,
>
> Juanjo.
>
> [1] http://markmail.org/message/owefsfj4eqbc4ifq#query:OSGi%20integration
> [2] http://cocoon.apache.org//3.0/
> [3] 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.
Re: Cocoon and Sling
Posted by Bertrand Delacretaz <bd...@apache.org>.
2009/4/8 Juan José Vázquez Delgado <ju...@gmail.com>:
> ...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....
I think XProc is a good choice for Sling because, as Juanjo indicates,
we're only interested in pure (and simple) pipeline processing. XProc
is a documented standard, so using it to script pipelines in Sling
means we don't have to reinvent things or document a new language.
-Bertrand
Re: Cocoon and Sling
Posted by Juan José Vázquez Delgado <ju...@gmail.com>.
> 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 processing and Sling
already resolves request resolution on its own.
The need would be having a pluggable XML pipeline processing in order
to work successfully with other frameworks such as Sling.
BR,
Juanjo.
Re: Cocoon and Sling
Posted by Peter Hunsberger <pe...@gmail.com>.
2009/4/7 Juan José Vázquez Delgado <ju...@gmail.com>
>
> 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] and the W3C XProc recomendation [3]
> in order to specify the pipelines to be performed. At least in the
> beginning, the Cocoon sitemap concept has been discarded because of
> quite overlapping between this one and Sling resource resolution.
>
> The code is available here [4] and details about how it works here [5].
>
> 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?.
>
This is sort of interesting, but I can't really say I'd personally
want to use XProc with Cocoon 3.0. Many years ago I proposed
implementing the Cocoon sitemap using XSLT (essentially combining the
current sitemap with the flow processor all in one spot and one
language); IMO XProc looks like a rather poor reimplementation of
XSLT, almost as complex, with a quarter of the capabilities? Some
days I wonder if the W3C hasn't gotten just a little too carried away
with some of these standards?
If the Cocoon project was to take on an XProc implementation I'd
really want to see it a completely optional implementation for Cocoon
3.0, it's not the kind of complexity I want in the base code.
However, I'm not sure pluggable sitemap processors are the kind of
complexity I'd want to see either...
--
Peter Hunsberger
Re: Cocoon and Sling
Posted by Ralph Goers <ra...@dslextreme.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,
>
> 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] and the W3C XProc recomendation [3]
> in order to specify the pipelines to be performed. At least in the
> beginning, the Cocoon sitemap concept has been discarded because of
> quite overlapping between this one and Sling resource resolution.
>
> The code is available here [4] and details about how it works here
> [5].
>
> 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?.
>
> Regards,
>
> Juanjo.
>
> [1] http://markmail.org/message/owefsfj4eqbc4ifq#query:OSGi
> %20integration
> [2] http://cocoon.apache.org//3.0/
> [3] 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