You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Robby Pelssers <ro...@ciber.com> on 2011/07/05 14:42:09 UTC
Using XQJ API with Cocoon3
Hi all,
As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
A first little exercise is mentioned on my blog but it's far from production ready.
- TODO: allow wrapping query result in 1 root tag
- Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
Kind regards,
Robby Pelssers
Re: Using XQJ API with Cocoon3
Posted by Simone Tripodi <si...@apache.org>.
Hi Steven,
sorry to be late but I'm in the middle of moving my job and still
don-t have a proper personal laptop :P
The number of 3rd parties modules we've been integrating has quickly
increasing, just have a look at sax components[1], I would like to
suggest to split them in separated modules, WDYT?
Have a nice day, all the best!
Simo
[1] http://tinyurl.com/3r6ofl9
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Jul 14, 2011 at 2:02 PM, Steven Dolg <st...@indoqa.com> wrote:
> Am 14.07.2011 11:12, schrieb Simone Tripodi:
>>
>> Hi Steven!!!
>> +1 to your suggestion. I've never been fan of 'optional' module that
>> aggregates every 3rd parties integrations, I'd like to see it rather
>> splitted in a multi-module structure.
>> Please let me know if you want me to work on it, I'll fill an issue on
>> JIRA and work.
>
> I'm not really up-to-date with what's currently in there, so my comment was
> more of a general nature.
>
> But it might be worth it to take a look and see if we could split this into
> several independent modules that serve a specific purpose.
> Coherence and coupling, ya'know... :P
>
> Cheers,
> Steven
>
>> TIA, have a nice day!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Wed, Jul 13, 2011 at 9:30 AM, Steven Dolg<st...@indoqa.com>
>> wrote:
>>>
>>> Am 05.07.2011 14:49, schrieb Simone Tripodi:
>>>>
>>>> Hi Robby!!!
>>>> as I wrote you on Twitter, this is something *really* interesting that
>>>> must be included in the Cocoon distribution :)
>>>>
>>>> We can include that module quite easy, all you have to do is
>>>>
>>>> * checkout/update the C3 /trunk;
>>>> * add needed dependencies in the<dependenciesManagement> in the
>>>> /parent/pom.xml
>>>> * add your code in the /cocoon-optional module in a proper package -
>>>> see the existing codebase as samples how we already managed 3rd
>>>> parties integrations
>>>> * make a patch and submit it on JIRA
>>>
>>> Hey,
>>>
>>> a little late to the party, but I wanted to add some comments.
>>>
>>> We should take a look at introducing "topic" specific modules.
>>> I fear that the optional module turns into a giant clump of all things
>>> unrelated.
>>>
>>> That's pretty much the opposite of the original intention:
>>> Have small, lightweight modules that you choose to use based on your
>>> actual
>>> requirements, allowing you to tailor your application package exactly to
>>> your needs.
>>> If I'm forced to use the optional module that brings dozens
>>> (::hyperbole::)
>>> of undesired features and dependencies just because I need one very
>>> specific
>>> feature, I'd be a little upset.
>>> (I don't like uploading 100 MB war files :/ )
>>>
>>>
>>> But I wholeheartedly agree to the feature idea. DO WANT! :P
>>>
>>> Cheers,
>>> Steven
>>>>
>>>> Looking forward to hear from you soon, all the best!!!
>>>> Simo
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://www.99soft.org/
>>>>
>>>>
>>>>
>>>> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers<ro...@ciber.com>
>>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> As Cocoon is an excellent framework for dealing with XML and hence in a
>>>>> lot of cases is stored in a XML Database it makes sense to offer
>>>>> out-of-the
>>>>> box functionality to extract data from it. From my personal experience
>>>>> I
>>>>> think most XMLDB implementers have abondoned the XMLDB API initiative
>>>>> and
>>>>> are focusing on XQuery for Java (XQJ) instead.
>>>>>
>>>>> I just started playing with the API today and wrote a bit of code to
>>>>> get
>>>>> more acquainted. I would like to start a little thread to find out if
>>>>> we
>>>>> can add a new XQJGenerator to the optional cocoon module.
>>>>>
>>>>> A first little exercise is mentioned on my blog but it's far from
>>>>> production ready.
>>>>>
>>>>> - TODO: allow wrapping query result in 1 root tag
>>>>> - Problem: the XQJ interface jar is packaged along with the
>>>>> implementations (Sedna, Exist, Marklogic). This means I had to
>>>>> actually
>>>>> declare a maven dependency on the implementation specific jar (in this
>>>>> case
>>>>> sedna-xqj-beta-5.jar).
>>>>>
>>>>> For the ones who think this would be a great add-on, check my first
>>>>> post
>>>>> at
>>>>> http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>>>>
>>>>> Kind regards,
>>>>> Robby Pelssers
>>>>>
>>>
>
>
Re: Using XQJ API with Cocoon3
Posted by Steven Dolg <st...@indoqa.com>.
Am 14.07.2011 11:12, schrieb Simone Tripodi:
> Hi Steven!!!
> +1 to your suggestion. I've never been fan of 'optional' module that
> aggregates every 3rd parties integrations, I'd like to see it rather
> splitted in a multi-module structure.
> Please let me know if you want me to work on it, I'll fill an issue on
> JIRA and work.
I'm not really up-to-date with what's currently in there, so my comment
was more of a general nature.
But it might be worth it to take a look and see if we could split this
into several independent modules that serve a specific purpose.
Coherence and coupling, ya'know... :P
Cheers,
Steven
> TIA, have a nice day!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Wed, Jul 13, 2011 at 9:30 AM, Steven Dolg<st...@indoqa.com> wrote:
>> Am 05.07.2011 14:49, schrieb Simone Tripodi:
>>> Hi Robby!!!
>>> as I wrote you on Twitter, this is something *really* interesting that
>>> must be included in the Cocoon distribution :)
>>>
>>> We can include that module quite easy, all you have to do is
>>>
>>> * checkout/update the C3 /trunk;
>>> * add needed dependencies in the<dependenciesManagement> in the
>>> /parent/pom.xml
>>> * add your code in the /cocoon-optional module in a proper package -
>>> see the existing codebase as samples how we already managed 3rd
>>> parties integrations
>>> * make a patch and submit it on JIRA
>> Hey,
>>
>> a little late to the party, but I wanted to add some comments.
>>
>> We should take a look at introducing "topic" specific modules.
>> I fear that the optional module turns into a giant clump of all things
>> unrelated.
>>
>> That's pretty much the opposite of the original intention:
>> Have small, lightweight modules that you choose to use based on your actual
>> requirements, allowing you to tailor your application package exactly to
>> your needs.
>> If I'm forced to use the optional module that brings dozens (::hyperbole::)
>> of undesired features and dependencies just because I need one very specific
>> feature, I'd be a little upset.
>> (I don't like uploading 100 MB war files :/ )
>>
>>
>> But I wholeheartedly agree to the feature idea. DO WANT! :P
>>
>> Cheers,
>> Steven
>>> Looking forward to hear from you soon, all the best!!!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers<ro...@ciber.com>
>>> wrote:
>>>> Hi all,
>>>>
>>>> As Cocoon is an excellent framework for dealing with XML and hence in a
>>>> lot of cases is stored in a XML Database it makes sense to offer out-of-the
>>>> box functionality to extract data from it. From my personal experience I
>>>> think most XMLDB implementers have abondoned the XMLDB API initiative and
>>>> are focusing on XQuery for Java (XQJ) instead.
>>>>
>>>> I just started playing with the API today and wrote a bit of code to get
>>>> more acquainted. I would like to start a little thread to find out if we
>>>> can add a new XQJGenerator to the optional cocoon module.
>>>>
>>>> A first little exercise is mentioned on my blog but it's far from
>>>> production ready.
>>>>
>>>> - TODO: allow wrapping query result in 1 root tag
>>>> - Problem: the XQJ interface jar is packaged along with the
>>>> implementations (Sedna, Exist, Marklogic). This means I had to actually
>>>> declare a maven dependency on the implementation specific jar (in this case
>>>> sedna-xqj-beta-5.jar).
>>>>
>>>> For the ones who think this would be a great add-on, check my first post
>>>> at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>>>
>>>> Kind regards,
>>>> Robby Pelssers
>>>>
>>
Re: Using XQJ API with Cocoon3
Posted by Simone Tripodi <si...@apache.org>.
Hi Steven!!!
+1 to your suggestion. I've never been fan of 'optional' module that
aggregates every 3rd parties integrations, I'd like to see it rather
splitted in a multi-module structure.
Please let me know if you want me to work on it, I'll fill an issue on
JIRA and work.
TIA, have a nice day!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Jul 13, 2011 at 9:30 AM, Steven Dolg <st...@indoqa.com> wrote:
> Am 05.07.2011 14:49, schrieb Simone Tripodi:
>>
>> Hi Robby!!!
>> as I wrote you on Twitter, this is something *really* interesting that
>> must be included in the Cocoon distribution :)
>>
>> We can include that module quite easy, all you have to do is
>>
>> * checkout/update the C3 /trunk;
>> * add needed dependencies in the<dependenciesManagement> in the
>> /parent/pom.xml
>> * add your code in the /cocoon-optional module in a proper package -
>> see the existing codebase as samples how we already managed 3rd
>> parties integrations
>> * make a patch and submit it on JIRA
>
> Hey,
>
> a little late to the party, but I wanted to add some comments.
>
> We should take a look at introducing "topic" specific modules.
> I fear that the optional module turns into a giant clump of all things
> unrelated.
>
> That's pretty much the opposite of the original intention:
> Have small, lightweight modules that you choose to use based on your actual
> requirements, allowing you to tailor your application package exactly to
> your needs.
> If I'm forced to use the optional module that brings dozens (::hyperbole::)
> of undesired features and dependencies just because I need one very specific
> feature, I'd be a little upset.
> (I don't like uploading 100 MB war files :/ )
>
>
> But I wholeheartedly agree to the feature idea. DO WANT! :P
>
> Cheers,
> Steven
>>
>> Looking forward to hear from you soon, all the best!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers<ro...@ciber.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> As Cocoon is an excellent framework for dealing with XML and hence in a
>>> lot of cases is stored in a XML Database it makes sense to offer out-of-the
>>> box functionality to extract data from it. From my personal experience I
>>> think most XMLDB implementers have abondoned the XMLDB API initiative and
>>> are focusing on XQuery for Java (XQJ) instead.
>>>
>>> I just started playing with the API today and wrote a bit of code to get
>>> more acquainted. I would like to start a little thread to find out if we
>>> can add a new XQJGenerator to the optional cocoon module.
>>>
>>> A first little exercise is mentioned on my blog but it's far from
>>> production ready.
>>>
>>> - TODO: allow wrapping query result in 1 root tag
>>> - Problem: the XQJ interface jar is packaged along with the
>>> implementations (Sedna, Exist, Marklogic). This means I had to actually
>>> declare a maven dependency on the implementation specific jar (in this case
>>> sedna-xqj-beta-5.jar).
>>>
>>> For the ones who think this would be a great add-on, check my first post
>>> at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>>
>>> Kind regards,
>>> Robby Pelssers
>>>
>
>
Re: [proposal] cocoonstuff.org
Posted by Thorsten Scherler <sc...@gmail.com>.
On Mon, 2011-07-18 at 20:56 +0200, Reinhard Pötz wrote:
> On 07/13/2011 09:30 AM, Steven Dolg wrote:
> > We should take a look at introducing "topic" specific modules.
> > I fear that the optional module turns into a giant clump of all things
> > unrelated.
>
> Generally +1 to topic specific modules. As Steven already knows from
> Indoqa projects, I'm a fan of many small modules ;-)
>
> In regard to the still small C3 community (not in terms of people but
> rather in terms of SVN changes and mailing list activity) we should
> think about having a "Cocoon Stuff" project (analogous to Wicket Stuff)
> where everybody that is interested gets commit rights. This also clearly
> indicates what we as Apache Cocoon community consider being officially
> maintained.
> (BTW, the Wicket community is very restrictive in moving code from
> wicketstuff.org into the wicket-core codebase because of the mentioned
> maintenance reasons).
>
> The wicket folks had a vote between hosting their stuff project either
> at Github or at Apache-Extras (powered by Google Code). Github won and
> the result can be found at http://wicketstuff.org/ and
> https://github.com/wicketstuff/core
>
> But there is also a downside:
>
> - Cocoon release will become (slightly) more work in the future
> because two code bases have to be released
>
> - cocoonstuff.org releases are not ASF releases and we can't
> rely on the ASF litigation protection mechanisms anymore
> (which is also true for most opensource software out there)
>
> (NB: That is the reason why we need 3 +1 votes of PMC members before
> we can do a release and tag it with the Apache name)
>
> - that the transition has to be done:
> * contact the Apache Board about reserving the cocoonstuff.org domain
> * decide what goes to cocoonstuff.org and what remains at
> cocoon.apache.org
> * rename all packages accordingly
> * create a cocoonstuff-samples module
> * decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for
> all cocoonstuff modules
> * decide about the release voting precedure
> * setup a cocoonstuff.org website (if we use Github we could also use
> it for hosting static websites)
> * find out how to get the Maven artifacts deployed to the
> central Maven repository
> * find a solution for continuous integration (Jenkins) and providing
> snapshot releases (Nexus?)
>
> But IMO there is also an additional benefit: Creating cocoonstuff would
> lower the barrier for contributions and could attract more people to get
> involved with C3.
>
> WDOT?
>
Actually to lower the barrier for sending patches I really welcome.
While still very new using git I must admit the push concept to send
changes to the rep is very helpful to quickly review/apply patches.
The main concern I have is that it could split the community and that is
the least thing that we want ATM. If we see the cocoonstuff.org like a
project incubator for new components of our project and communication is
here I think it can work.
salu2
--
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/
Re: [proposal] cocoonstuff.org
Posted by Simone Tripodi <si...@apache.org>.
Hi all guys!!!
>>> What about a probably restrictive but clearer "Cocoon is a versatile
>>> pipeline processing engine, particularly suited for XML processing and
>>> multi-format document publication, but also capable of processing binary
>>> content such as images. It provides integration modules with popular
>>> frameworks like Spring, Wicket and JAX-RS"?
I really like that sentence, kudos!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
Re: [proposal] cocoonstuff.org
Posted by Sylvain Wallez <sy...@apache.org>.
Le 28/07/11 15:28, Peter Hunsberger a écrit :
>> What about a probably restrictive but clearer "Cocoon is a versatile pipeline processing engine, particularly suited for XML processing and multi-format document publication, but also capable of processing binary content such as images. It provides integration modules with popular frameworks like Spring, Wicket and JAX-RS"?
> Maybe not the best sentence in the world, but I like the intent here.
Well, I'm neither a marketing guy nor a native english speaker ;-)
> Again I'd say +1
Thanks!
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [proposal] cocoonstuff.org
Posted by Peter Hunsberger <pe...@gmail.com>.
>
> Hmm... needing additional documentation is often the sign of some sort of problem. In this case, we may simply have too many modules. Why don't we have a "cocoon-core" module, so that people can know where to look at to understand what Cocoon is about? And this core module should not only be the cocoon-pipeline module, but should also include cocoon-util (3 classes!), cocoon-sax, cocoon-sitemap, cocoon-controller (3 classes again) and even cocoon-stax (Stax is provided in JDK 1.6).
>
This sounds like a good idea, +1
> Also, along with providing more meat in the core, let's be opinionated and clearly say what Cocoon is about. For 2.2, the website says "Apache Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built around the concepts of separation of concerns and component-based development."
>
> Er... and what does this mean for a newcomer, particularly when Spring already has this huge amount of components and whose large number of interfaces and abstract classes could well be confused with "separation of concerns" ?
>
> What about a probably restrictive but clearer "Cocoon is a versatile pipeline processing engine, particularly suited for XML processing and multi-format document publication, but also capable of processing binary content such as images. It provides integration modules with popular frameworks like Spring, Wicket and JAX-RS"?
>
Maybe not the best sentence in the world, but I like the intent here.
Again I'd say +1
Re: [proposal] cocoonstuff.org
Posted by Sylvain Wallez <sy...@apache.org>.
Le 21/07/11 20:54, Reinhard Pötz a écrit :
<snip/>
> Nevertheless C3 already counts more than 20 subdirectories which is
> discouraging for people that want to get familiar with the code base.
> Especially if you don't need all the webapp/REST stuff you only need
> cocoon-pipeline, cocoon-sax, parent and maybe cocoon-optional.
> One could say that this problem can be solved with good documentation
> but the psychological barrier doesn't go away.
Hmm... needing additional documentation is often the sign of some sort
of problem. In this case, we may simply have too many modules. Why don't
we have a "cocoon-core" module, so that people can know where to look at
to understand what Cocoon is about? And this core module should not only
be the cocoon-pipeline module, but should also include cocoon-util (3
classes!), cocoon-sax, cocoon-sitemap, cocoon-controller (3 classes
again) and even cocoon-stax (Stax is provided in JDK 1.6).
Also, along with providing more meat in the core, let's be opinionated
and clearly say what Cocoon is about. For 2.2, the website says "Apache
Cocoon is a Spring-based framework (since version 2.2 of Cocoon) built
around the concepts of separation of concerns and component-based
development."
Er... and what does this mean for a newcomer, particularly when Spring
already has this huge amount of components and whose large number of
interfaces and abstract classes could well be confused with "separation
of concerns" ?
What about a probably restrictive but clearer "Cocoon is a versatile
pipeline processing engine, particularly suited for XML processing and
multi-format document publication, but also capable of processing binary
content such as images. It provides integration modules with popular
frameworks like Spring, Wicket and JAX-RS"?
With a bigger core and a clear tag line, we end up with a project that
has 3 times less modules and where additional modules have a clear goal
of integrating with a 3rd party library/framework (or providing a very
specific feature, which often means also a 3rd party library). And more
importantly, we have a core module that can actually *do* something and
is not an almost empty shell of abstact concepts like cocoon-pipeline is.
Sorry for this rant, but Cocoon has 2.x has grown into a toolbox for its
committers (and I take my share in this), becoming more and more complex
and abstract, being a different thing for each of its developers, and
has lost its ability to be understood by newcomers. I think learning
from this is particularly important if we want to rebuild a vibrant
community around Cocoon 3.x
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: [proposal] cocoonstuff.org
Posted by Reinhard Pötz <re...@apache.org>.
On 07/19/2011 12:17 AM, Sylvain Wallez wrote:
> Le 18/07/11 20:56, Reinhard Pötz a écrit :
>> On 07/13/2011 09:30 AM, Steven Dolg wrote:
>>> We should take a look at introducing "topic" specific modules.
>>> I fear that the optional module turns into a giant clump of all things
>>> unrelated.
>>
>> Generally +1 to topic specific modules. As Steven already knows from
>> Indoqa projects, I'm a fan of many small modules ;-)
>>
>> In regard to the still small C3 community (not in terms of people but
>> rather in terms of SVN changes and mailing list activity) we should
>> think about having a "Cocoon Stuff" project (analogous to Wicket
>> Stuff) where everybody that is interested gets commit rights. This
>> also clearly indicates what we as Apache Cocoon community consider
>> being officially maintained.
>> (BTW, the Wicket community is very restrictive in moving code from
>> wicketstuff.org into the wicket-core codebase because of the mentioned
>> maintenance reasons).
>>
>> The wicket folks had a vote between hosting their stuff project either
>> at Github or at Apache-Extras (powered by Google Code). Github won and
>> the result can be found at http://wicketstuff.org/ and
>> https://github.com/wicketstuff/core
>>
>> But there is also a downside:
>>
>> - Cocoon release will become (slightly) more work in the future
>> because two code bases have to be released
>>
>> - cocoonstuff.org releases are not ASF releases and we can't
>> rely on the ASF litigation protection mechanisms anymore
>> (which is also true for most opensource software out there)
>>
>> (NB: That is the reason why we need 3 +1 votes of PMC members before
>> we can do a release and tag it with the Apache name)
>>
>> - that the transition has to be done:
>> * contact the Apache Board about reserving the cocoonstuff.org domain
>> * decide what goes to cocoonstuff.org and what remains at
>> cocoon.apache.org
>> * rename all packages accordingly
>> * create a cocoonstuff-samples module
>> * decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for
>> all cocoonstuff modules
>> * decide about the release voting precedure
>> * setup a cocoonstuff.org website (if we use Github we could also use
>> it for hosting static websites)
>> * find out how to get the Maven artifacts deployed to the
>> central Maven repository
>> * find a solution for continuous integration (Jenkins) and providing
>> snapshot releases (Nexus?)
>>
>> But IMO there is also an additional benefit: Creating cocoonstuff
>> would lower the barrier for contributions and could attract more
>> people to get involved with C3.
>>
>> WDOT?
>
> Hmm...
>
> I definitely agree that modules specific to a 3rd party library or a JSR
> that's not included in the JDK are to be packaged as separate artifacts.
> As Steven rightfully points out, it's a real pain to download and
> package a huge load of libraries you don't need. And this what has been
> done in Cocoon since 2.0 with the large collection of blocks.
>
> Now hosting these modules away from apache.org is a different thing that
> has strong implications on community dynamics. The C3 community is
> slowly growing after having been almost dormant for months (years?),
> which is a very good thing, and I fear that a cocoonstuff.org would just
> harm this nascent effort by splitting the still brittle community. Also,
> a separate environment comes with additional time spent in
> administrative stuff (look at your long task list!) that could probably
> be used more wisely to build a stable C3.
>
> So if the purpose is to lower the barrier for contribution, then why not
> just having a "contrib" directory in SVN, clearly showing that these
> aren't core modules, but still under the oversight of the PMC and the
> ASF at large?
>
> Of course, managing Git pull requests would be more convenient than
> applying patches in Jira, but still, at this point, this is probably
> easier than having a completely separate infrastructure.
After reading Torsten's and your comments I agree that setting up
cocoonstuff.org is too early.
Nevertheless C3 already counts more than 20 subdirectories which is
discouraging for people that want to get familiar with the code base.
Especially if you don't need all the webapp/REST stuff you only need
cocoon-pipeline, cocoon-sax, parent and maybe cocoon-optional.
One could say that this problem can be solved with good documentation
but the psychological barrier doesn't go away.
Maybe it would be good enough to restructure the directory tree so that
everybody can decide what he needs:
cocoon3/trunk/pipeline ..... plain Java pipelines
cocoon3/trunk/sitemap ...... sitemap implementation (currently only the
XMLSitemap impl)
cocoon3/trunk/webapp ....... using C3 for web applications
cocoon3/trunk/[stuff]* ..... all additional stuff that is clearly
marked as not being ready for prime time
(*) needs a better name
I don't know what to do with
. documentation (split it into the three sections or have one central
directory),
. the parent POM (one for each section or one global parent POM.
However, one parent POM has the disadvantage, that you couldn't
just checkout
https://svn.apache.org/repos/asf/cocoon/cocoon3/trunk/pipeline
which isn't ideal IMO)
. the archetypes (should probably go to the webapp section)
but this could be decided if others agree that the global direction of
my proposal is useful.
--
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 reinhard@apache.org
________________________________________________________________________
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
Re: [proposal] cocoonstuff.org
Posted by Vadim Gritsenko <va...@reverycodes.com>.
On Jul 18, 2011, at 6:28 PM, Torsten Curdt wrote:
>> So if the purpose is to lower the barrier for contribution, then why not
>> just having a "contrib" directory in SVN, clearly showing that these aren't
>> core modules, but still under the oversight of the PMC and the ASF at large?
+1
> I fear that's not really lowering the barrier of entry. Still
> committers are the "gate keepers"
If "contrib" is implemented, it can come with lower barriers to become a committer too. Limit SVN rights just to contrib directory, and let people earn trust to become full committers with access to all of /cocoon.
>> Of course, managing Git pull requests would be more convenient than applying
>> patches in Jira, but still, at this point, this is probably easier than
>> having a completely separate infrastructure.
>
> but after all there is already...
>
> https://github.com/apache/cocoon
>
> if we could accept pull requests from people with ICLAs on file - that
> would be a great step forward to lower the barrier for contributions.
If workable, this might be a fine plan too.
Vadim
Re: [proposal] cocoonstuff.org
Posted by Torsten Curdt <tc...@vafer.org>.
> Hmm...
</snip>
+1 sharing these thoughts
> Also, a separate
> environment comes with additional time spent in administrative stuff (look
> at your long task list!) that could probably be used more wisely to build a
> stable C3.
+1
> So if the purpose is to lower the barrier for contribution, then why not
> just having a "contrib" directory in SVN, clearly showing that these aren't
> core modules, but still under the oversight of the PMC and the ASF at large?
I fear that's not really lowering the barrier of entry. Still
committers are the "gate keepers"
> Of course, managing Git pull requests would be more convenient than applying
> patches in Jira, but still, at this point, this is probably easier than
> having a completely separate infrastructure.
but after all there is already...
https://github.com/apache/cocoon
if we could accept pull requests from people with ICLAs on file - that
would be a great step forward to lower the barrier for contributions.
cheers,
Torsten
Re: [proposal] cocoonstuff.org
Posted by Sylvain Wallez <sy...@apache.org>.
Le 18/07/11 20:56, Reinhard Pötz a écrit :
> On 07/13/2011 09:30 AM, Steven Dolg wrote:
>> We should take a look at introducing "topic" specific modules.
>> I fear that the optional module turns into a giant clump of all things
>> unrelated.
>
> Generally +1 to topic specific modules. As Steven already knows from
> Indoqa projects, I'm a fan of many small modules ;-)
>
> In regard to the still small C3 community (not in terms of people but
> rather in terms of SVN changes and mailing list activity) we should
> think about having a "Cocoon Stuff" project (analogous to Wicket
> Stuff) where everybody that is interested gets commit rights. This
> also clearly indicates what we as Apache Cocoon community consider
> being officially maintained.
> (BTW, the Wicket community is very restrictive in moving code from
> wicketstuff.org into the wicket-core codebase because of the mentioned
> maintenance reasons).
>
> The wicket folks had a vote between hosting their stuff project either
> at Github or at Apache-Extras (powered by Google Code). Github won and
> the result can be found at http://wicketstuff.org/ and
> https://github.com/wicketstuff/core
>
> But there is also a downside:
>
> - Cocoon release will become (slightly) more work in the future
> because two code bases have to be released
>
> - cocoonstuff.org releases are not ASF releases and we can't
> rely on the ASF litigation protection mechanisms anymore
> (which is also true for most opensource software out there)
>
> (NB: That is the reason why we need 3 +1 votes of PMC members before
> we can do a release and tag it with the Apache name)
>
> - that the transition has to be done:
> * contact the Apache Board about reserving the cocoonstuff.org domain
> * decide what goes to cocoonstuff.org and what remains at
> cocoon.apache.org
> * rename all packages accordingly
> * create a cocoonstuff-samples module
> * decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for
> all cocoonstuff modules
> * decide about the release voting precedure
> * setup a cocoonstuff.org website (if we use Github we could also use
> it for hosting static websites)
> * find out how to get the Maven artifacts deployed to the
> central Maven repository
> * find a solution for continuous integration (Jenkins) and providing
> snapshot releases (Nexus?)
>
> But IMO there is also an additional benefit: Creating cocoonstuff
> would lower the barrier for contributions and could attract more
> people to get involved with C3.
>
> WDOT?
Hmm...
I definitely agree that modules specific to a 3rd party library or a JSR
that's not included in the JDK are to be packaged as separate artifacts.
As Steven rightfully points out, it's a real pain to download and
package a huge load of libraries you don't need. And this what has been
done in Cocoon since 2.0 with the large collection of blocks.
Now hosting these modules away from apache.org is a different thing that
has strong implications on community dynamics. The C3 community is
slowly growing after having been almost dormant for months (years?),
which is a very good thing, and I fear that a cocoonstuff.org would just
harm this nascent effort by splitting the still brittle community. Also,
a separate environment comes with additional time spent in
administrative stuff (look at your long task list!) that could probably
be used more wisely to build a stable C3.
So if the purpose is to lower the barrier for contribution, then why not
just having a "contrib" directory in SVN, clearly showing that these
aren't core modules, but still under the oversight of the PMC and the
ASF at large?
Of course, managing Git pull requests would be more convenient than
applying patches in Jira, but still, at this point, this is probably
easier than having a completely separate infrastructure.
My 0.02 cents.
Sylvain
--
Sylvain Wallez - http://bluxte.net
[proposal] cocoonstuff.org
Posted by Reinhard Pötz <re...@apache.org>.
On 07/13/2011 09:30 AM, Steven Dolg wrote:
> We should take a look at introducing "topic" specific modules.
> I fear that the optional module turns into a giant clump of all things
> unrelated.
Generally +1 to topic specific modules. As Steven already knows from
Indoqa projects, I'm a fan of many small modules ;-)
In regard to the still small C3 community (not in terms of people but
rather in terms of SVN changes and mailing list activity) we should
think about having a "Cocoon Stuff" project (analogous to Wicket Stuff)
where everybody that is interested gets commit rights. This also clearly
indicates what we as Apache Cocoon community consider being officially
maintained.
(BTW, the Wicket community is very restrictive in moving code from
wicketstuff.org into the wicket-core codebase because of the mentioned
maintenance reasons).
The wicket folks had a vote between hosting their stuff project either
at Github or at Apache-Extras (powered by Google Code). Github won and
the result can be found at http://wicketstuff.org/ and
https://github.com/wicketstuff/core
But there is also a downside:
- Cocoon release will become (slightly) more work in the future
because two code bases have to be released
- cocoonstuff.org releases are not ASF releases and we can't
rely on the ASF litigation protection mechanisms anymore
(which is also true for most opensource software out there)
(NB: That is the reason why we need 3 +1 votes of PMC members before
we can do a release and tag it with the Apache name)
- that the transition has to be done:
* contact the Apache Board about reserving the cocoonstuff.org domain
* decide what goes to cocoonstuff.org and what remains at
cocoon.apache.org
* rename all packages accordingly
* create a cocoonstuff-samples module
* decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for
all cocoonstuff modules
* decide about the release voting precedure
* setup a cocoonstuff.org website (if we use Github we could also use
it for hosting static websites)
* find out how to get the Maven artifacts deployed to the
central Maven repository
* find a solution for continuous integration (Jenkins) and providing
snapshot releases (Nexus?)
But IMO there is also an additional benefit: Creating cocoonstuff would
lower the barrier for contributions and could attract more people to get
involved with C3.
WDOT?
--
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 reinhard@apache.org
________________________________________________________________________
Furthermore, I think Oracle has to honor the JSPA agreement.
http://s.apache.org/JCPIsDead http://s.apache.org/tck-trap
RE: Using XQJ API with Cocoon3
Posted by Robby Pelssers <ro...@ciber.com>.
Hi Steven,
I agree that an XQJ generator would be a perfect fit for a separate maven project. Either you need it or you don't and you get the freedom by (not) declaring the dependency. I think for non-general purpose code this makes perfect sense.
Robby
-----Oorspronkelijk bericht-----
Van: Steven Dolg [mailto:steven.dolg@indoqa.com]
Verzonden: wo 13-7-2011 9:30
Aan: dev@cocoon.apache.org
Onderwerp: Re: Using XQJ API with Cocoon3
Am 05.07.2011 14:49, schrieb Simone Tripodi:
> Hi Robby!!!
> as I wrote you on Twitter, this is something *really* interesting that
> must be included in the Cocoon distribution :)
>
> We can include that module quite easy, all you have to do is
>
> * checkout/update the C3 /trunk;
> * add needed dependencies in the<dependenciesManagement> in the
> /parent/pom.xml
> * add your code in the /cocoon-optional module in a proper package -
> see the existing codebase as samples how we already managed 3rd
> parties integrations
> * make a patch and submit it on JIRA
Hey,
a little late to the party, but I wanted to add some comments.
We should take a look at introducing "topic" specific modules.
I fear that the optional module turns into a giant clump of all things
unrelated.
That's pretty much the opposite of the original intention:
Have small, lightweight modules that you choose to use based on your
actual requirements, allowing you to tailor your application package
exactly to your needs.
If I'm forced to use the optional module that brings dozens
(::hyperbole::) of undesired features and dependencies just because I
need one very specific feature, I'd be a little upset.
(I don't like uploading 100 MB war files :/ )
But I wholeheartedly agree to the feature idea. DO WANT! :P
Cheers,
Steven
> Looking forward to hear from you soon, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers<ro...@ciber.com> wrote:
>> Hi all,
>>
>> As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
>>
>> I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
>>
>> A first little exercise is mentioned on my blog but it's far from production ready.
>>
>> - TODO: allow wrapping query result in 1 root tag
>> - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
>>
>> For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>
>> Kind regards,
>> Robby Pelssers
>>
Re: Using XQJ API with Cocoon3
Posted by Steven Dolg <st...@indoqa.com>.
Am 05.07.2011 14:49, schrieb Simone Tripodi:
> Hi Robby!!!
> as I wrote you on Twitter, this is something *really* interesting that
> must be included in the Cocoon distribution :)
>
> We can include that module quite easy, all you have to do is
>
> * checkout/update the C3 /trunk;
> * add needed dependencies in the<dependenciesManagement> in the
> /parent/pom.xml
> * add your code in the /cocoon-optional module in a proper package -
> see the existing codebase as samples how we already managed 3rd
> parties integrations
> * make a patch and submit it on JIRA
Hey,
a little late to the party, but I wanted to add some comments.
We should take a look at introducing "topic" specific modules.
I fear that the optional module turns into a giant clump of all things
unrelated.
That's pretty much the opposite of the original intention:
Have small, lightweight modules that you choose to use based on your
actual requirements, allowing you to tailor your application package
exactly to your needs.
If I'm forced to use the optional module that brings dozens
(::hyperbole::) of undesired features and dependencies just because I
need one very specific feature, I'd be a little upset.
(I don't like uploading 100 MB war files :/ )
But I wholeheartedly agree to the feature idea. DO WANT! :P
Cheers,
Steven
> Looking forward to hear from you soon, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers<ro...@ciber.com> wrote:
>> Hi all,
>>
>> As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
>>
>> I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
>>
>> A first little exercise is mentioned on my blog but it's far from production ready.
>>
>> - TODO: allow wrapping query result in 1 root tag
>> - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
>>
>> For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>
>> Kind regards,
>> Robby Pelssers
>>
Re: Using XQJ API with Cocoon3
Posted by David Crossley <cr...@apache.org>.
Simone Tripodi wrote:
> Hi Robby,
> AFAIK 3rd parties MPL licensed can be included, see
> http://www.apache.org/legal/resolved.html
Yes. I investigated that once before:
http://s.apache.org/gx
Just follow the "Category B" instructions.
-David
Re: Using XQJ API with Cocoon3
Posted by Simone Tripodi <si...@apache.org>.
Hi Robby,
AFAIK 3rd parties MPL licensed can be included, see
http://www.apache.org/legal/resolved.html
HTH, have a nice day!
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Jul 5, 2011 at 9:57 PM, Robby Pelssers <ro...@ciber.com> wrote:
> I found out that Saxonica offers an XQJ implementation which allows you to use XQJ without the need to have an actual database up and running.
> There is a Saxon-HE version which has a Mozilla Public License. Does anyone have any idea if I could use this version together with Cocoon3 to write my unit tests?
>
>
> Kind regards,
> Robby
>
> -----Oorspronkelijk bericht-----
> Van: Robby Pelssers [mailto:robby.pelssers@ciber.com]
> Verzonden: di 5-7-2011 19:59
> Aan: dev@cocoon.apache.org
> Onderwerp: RE: Using XQJ API with Cocoon3
>
> Yes, it's an official JSR Specification available at http://www.jcp.org/en/jsr/detail?id=225
>
> In the download section for the final 1.0 spec I could find the jar included in the zip. But i did try to find any XQJ jar in mvn repository and couldn't find one. Maybe we should upload the jar to a public maven repo ourselves?
>
> But what would be the group- and artifact id in that case? And it still leaves the issue that the implementations ship with the interface as well.
>
> Robby
>
>
> -----Oorspronkelijk bericht-----
> Van: simone.tripodi@gmail.com namens Simone Tripodi
> Verzonden: di 5-7-2011 18:04
> Aan: dev@cocoon.apache.org
> Onderwerp: Re: Using XQJ API with Cocoon3
>
> Hi Robby,
> rather a 'must to have' it is IMHO a 'very cool to have' ;)
> just a silly question - and please take in consideration that I'm not
> familiar with the XQuery world - isn't there a JSR specification?
> Many thanks in advance, have a nice day!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Jul 5, 2011 at 5:20 PM, Robby Pelssers <ro...@ciber.com> wrote:
>> Hi Simone,
>>
>> as this is my last week before my holidays I don't think i will manage to get things really tested properly. But I look forward contributing input for this component as it really is a must-have if you want to hook up with any XMLDB supporting XQJ.
>>
>> The only real showstopper at this moment is that i have no clue how I can avoid declaring a dependency on the XMLDB specific implementation.
>>
>> The XQJGenerator so far is 100% using only the interfaces but they are packaged with the implementation :-( I will address this issue with
>> both Sedna and BaseX and see if someone can create seperate jar for interface and let them all seperate implementation code from the interface in 2 separate jars. If the interface would be available from Maven central would also be a big bonus.
>>
>> Keep you posted,
>> Robby
>>
>>
>>
>>
>> -----Oorspronkelijk bericht-----
>> Van: simone.tripodi@gmail.com namens Simone Tripodi
>> Verzonden: di 5-7-2011 14:49
>> Aan: dev@cocoon.apache.org
>> Onderwerp: Re: Using XQJ API with Cocoon3
>>
>> Hi Robby!!!
>> as I wrote you on Twitter, this is something *really* interesting that
>> must be included in the Cocoon distribution :)
>>
>> We can include that module quite easy, all you have to do is
>>
>> * checkout/update the C3 /trunk;
>> * add needed dependencies in the <dependenciesManagement> in the
>> /parent/pom.xml
>> * add your code in the /cocoon-optional module in a proper package -
>> see the existing codebase as samples how we already managed 3rd
>> parties integrations
>> * make a patch and submit it on JIRA
>>
>> Looking forward to hear from you soon, all the best!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers <ro...@ciber.com> wrote:
>>> Hi all,
>>>
>>> As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
>>>
>>> I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
>>>
>>> A first little exercise is mentioned on my blog but it's far from production ready.
>>>
>>> - TODO: allow wrapping query result in 1 root tag
>>> - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
>>>
>>> For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>>
>>> Kind regards,
>>> Robby Pelssers
>>>
>>
>>
>
>
>
RE: Using XQJ API with Cocoon3
Posted by Robby Pelssers <ro...@ciber.com>.
I found out that Saxonica offers an XQJ implementation which allows you to use XQJ without the need to have an actual database up and running.
There is a Saxon-HE version which has a Mozilla Public License. Does anyone have any idea if I could use this version together with Cocoon3 to write my unit tests?
Kind regards,
Robby
-----Oorspronkelijk bericht-----
Van: Robby Pelssers [mailto:robby.pelssers@ciber.com]
Verzonden: di 5-7-2011 19:59
Aan: dev@cocoon.apache.org
Onderwerp: RE: Using XQJ API with Cocoon3
Yes, it's an official JSR Specification available at http://www.jcp.org/en/jsr/detail?id=225
In the download section for the final 1.0 spec I could find the jar included in the zip. But i did try to find any XQJ jar in mvn repository and couldn't find one. Maybe we should upload the jar to a public maven repo ourselves?
But what would be the group- and artifact id in that case? And it still leaves the issue that the implementations ship with the interface as well.
Robby
-----Oorspronkelijk bericht-----
Van: simone.tripodi@gmail.com namens Simone Tripodi
Verzonden: di 5-7-2011 18:04
Aan: dev@cocoon.apache.org
Onderwerp: Re: Using XQJ API with Cocoon3
Hi Robby,
rather a 'must to have' it is IMHO a 'very cool to have' ;)
just a silly question - and please take in consideration that I'm not
familiar with the XQuery world - isn't there a JSR specification?
Many thanks in advance, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Jul 5, 2011 at 5:20 PM, Robby Pelssers <ro...@ciber.com> wrote:
> Hi Simone,
>
> as this is my last week before my holidays I don't think i will manage to get things really tested properly. But I look forward contributing input for this component as it really is a must-have if you want to hook up with any XMLDB supporting XQJ.
>
> The only real showstopper at this moment is that i have no clue how I can avoid declaring a dependency on the XMLDB specific implementation.
>
> The XQJGenerator so far is 100% using only the interfaces but they are packaged with the implementation :-( I will address this issue with
> both Sedna and BaseX and see if someone can create seperate jar for interface and let them all seperate implementation code from the interface in 2 separate jars. If the interface would be available from Maven central would also be a big bonus.
>
> Keep you posted,
> Robby
>
>
>
>
> -----Oorspronkelijk bericht-----
> Van: simone.tripodi@gmail.com namens Simone Tripodi
> Verzonden: di 5-7-2011 14:49
> Aan: dev@cocoon.apache.org
> Onderwerp: Re: Using XQJ API with Cocoon3
>
> Hi Robby!!!
> as I wrote you on Twitter, this is something *really* interesting that
> must be included in the Cocoon distribution :)
>
> We can include that module quite easy, all you have to do is
>
> * checkout/update the C3 /trunk;
> * add needed dependencies in the <dependenciesManagement> in the
> /parent/pom.xml
> * add your code in the /cocoon-optional module in a proper package -
> see the existing codebase as samples how we already managed 3rd
> parties integrations
> * make a patch and submit it on JIRA
>
> Looking forward to hear from you soon, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers <ro...@ciber.com> wrote:
>> Hi all,
>>
>> As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
>>
>> I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
>>
>> A first little exercise is mentioned on my blog but it's far from production ready.
>>
>> - TODO: allow wrapping query result in 1 root tag
>> - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
>>
>> For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>
>> Kind regards,
>> Robby Pelssers
>>
>
>
RE: Using XQJ API with Cocoon3
Posted by Robby Pelssers <ro...@ciber.com>.
Yes, it's an official JSR Specification available at http://www.jcp.org/en/jsr/detail?id=225
In the download section for the final 1.0 spec I could find the jar included in the zip. But i did try to find any XQJ jar in mvn repository and couldn't find one. Maybe we should upload the jar to a public maven repo ourselves?
But what would be the group- and artifact id in that case? And it still leaves the issue that the implementations ship with the interface as well.
Robby
-----Oorspronkelijk bericht-----
Van: simone.tripodi@gmail.com namens Simone Tripodi
Verzonden: di 5-7-2011 18:04
Aan: dev@cocoon.apache.org
Onderwerp: Re: Using XQJ API with Cocoon3
Hi Robby,
rather a 'must to have' it is IMHO a 'very cool to have' ;)
just a silly question - and please take in consideration that I'm not
familiar with the XQuery world - isn't there a JSR specification?
Many thanks in advance, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Jul 5, 2011 at 5:20 PM, Robby Pelssers <ro...@ciber.com> wrote:
> Hi Simone,
>
> as this is my last week before my holidays I don't think i will manage to get things really tested properly. But I look forward contributing input for this component as it really is a must-have if you want to hook up with any XMLDB supporting XQJ.
>
> The only real showstopper at this moment is that i have no clue how I can avoid declaring a dependency on the XMLDB specific implementation.
>
> The XQJGenerator so far is 100% using only the interfaces but they are packaged with the implementation :-( I will address this issue with
> both Sedna and BaseX and see if someone can create seperate jar for interface and let them all seperate implementation code from the interface in 2 separate jars. If the interface would be available from Maven central would also be a big bonus.
>
> Keep you posted,
> Robby
>
>
>
>
> -----Oorspronkelijk bericht-----
> Van: simone.tripodi@gmail.com namens Simone Tripodi
> Verzonden: di 5-7-2011 14:49
> Aan: dev@cocoon.apache.org
> Onderwerp: Re: Using XQJ API with Cocoon3
>
> Hi Robby!!!
> as I wrote you on Twitter, this is something *really* interesting that
> must be included in the Cocoon distribution :)
>
> We can include that module quite easy, all you have to do is
>
> * checkout/update the C3 /trunk;
> * add needed dependencies in the <dependenciesManagement> in the
> /parent/pom.xml
> * add your code in the /cocoon-optional module in a proper package -
> see the existing codebase as samples how we already managed 3rd
> parties integrations
> * make a patch and submit it on JIRA
>
> Looking forward to hear from you soon, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers <ro...@ciber.com> wrote:
>> Hi all,
>>
>> As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
>>
>> I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
>>
>> A first little exercise is mentioned on my blog but it's far from production ready.
>>
>> - TODO: allow wrapping query result in 1 root tag
>> - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
>>
>> For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>
>> Kind regards,
>> Robby Pelssers
>>
>
>
Re: Using XQJ API with Cocoon3
Posted by Simone Tripodi <si...@apache.org>.
Hi Robby,
rather a 'must to have' it is IMHO a 'very cool to have' ;)
just a silly question - and please take in consideration that I'm not
familiar with the XQuery world - isn't there a JSR specification?
Many thanks in advance, have a nice day!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Jul 5, 2011 at 5:20 PM, Robby Pelssers <ro...@ciber.com> wrote:
> Hi Simone,
>
> as this is my last week before my holidays I don't think i will manage to get things really tested properly. But I look forward contributing input for this component as it really is a must-have if you want to hook up with any XMLDB supporting XQJ.
>
> The only real showstopper at this moment is that i have no clue how I can avoid declaring a dependency on the XMLDB specific implementation.
>
> The XQJGenerator so far is 100% using only the interfaces but they are packaged with the implementation :-( I will address this issue with
> both Sedna and BaseX and see if someone can create seperate jar for interface and let them all seperate implementation code from the interface in 2 separate jars. If the interface would be available from Maven central would also be a big bonus.
>
> Keep you posted,
> Robby
>
>
>
>
> -----Oorspronkelijk bericht-----
> Van: simone.tripodi@gmail.com namens Simone Tripodi
> Verzonden: di 5-7-2011 14:49
> Aan: dev@cocoon.apache.org
> Onderwerp: Re: Using XQJ API with Cocoon3
>
> Hi Robby!!!
> as I wrote you on Twitter, this is something *really* interesting that
> must be included in the Cocoon distribution :)
>
> We can include that module quite easy, all you have to do is
>
> * checkout/update the C3 /trunk;
> * add needed dependencies in the <dependenciesManagement> in the
> /parent/pom.xml
> * add your code in the /cocoon-optional module in a proper package -
> see the existing codebase as samples how we already managed 3rd
> parties integrations
> * make a patch and submit it on JIRA
>
> Looking forward to hear from you soon, all the best!!!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers <ro...@ciber.com> wrote:
>> Hi all,
>>
>> As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
>>
>> I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
>>
>> A first little exercise is mentioned on my blog but it's far from production ready.
>>
>> - TODO: allow wrapping query result in 1 root tag
>> - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
>>
>> For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>>
>> Kind regards,
>> Robby Pelssers
>>
>
>
RE: Using XQJ API with Cocoon3
Posted by Robby Pelssers <ro...@ciber.com>.
Hi Simone,
as this is my last week before my holidays I don't think i will manage to get things really tested properly. But I look forward contributing input for this component as it really is a must-have if you want to hook up with any XMLDB supporting XQJ.
The only real showstopper at this moment is that i have no clue how I can avoid declaring a dependency on the XMLDB specific implementation.
The XQJGenerator so far is 100% using only the interfaces but they are packaged with the implementation :-( I will address this issue with
both Sedna and BaseX and see if someone can create seperate jar for interface and let them all seperate implementation code from the interface in 2 separate jars. If the interface would be available from Maven central would also be a big bonus.
Keep you posted,
Robby
-----Oorspronkelijk bericht-----
Van: simone.tripodi@gmail.com namens Simone Tripodi
Verzonden: di 5-7-2011 14:49
Aan: dev@cocoon.apache.org
Onderwerp: Re: Using XQJ API with Cocoon3
Hi Robby!!!
as I wrote you on Twitter, this is something *really* interesting that
must be included in the Cocoon distribution :)
We can include that module quite easy, all you have to do is
* checkout/update the C3 /trunk;
* add needed dependencies in the <dependenciesManagement> in the
/parent/pom.xml
* add your code in the /cocoon-optional module in a proper package -
see the existing codebase as samples how we already managed 3rd
parties integrations
* make a patch and submit it on JIRA
Looking forward to hear from you soon, all the best!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers <ro...@ciber.com> wrote:
> Hi all,
>
> As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
>
> I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
>
> A first little exercise is mentioned on my blog but it's far from production ready.
>
> - TODO: allow wrapping query result in 1 root tag
> - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
>
> For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>
> Kind regards,
> Robby Pelssers
>
Re: Using XQJ API with Cocoon3
Posted by Simone Tripodi <si...@apache.org>.
Hi Robby!!!
as I wrote you on Twitter, this is something *really* interesting that
must be included in the Cocoon distribution :)
We can include that module quite easy, all you have to do is
* checkout/update the C3 /trunk;
* add needed dependencies in the <dependenciesManagement> in the
/parent/pom.xml
* add your code in the /cocoon-optional module in a proper package -
see the existing codebase as samples how we already managed 3rd
parties integrations
* make a patch and submit it on JIRA
Looking forward to hear from you soon, all the best!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers <ro...@ciber.com> wrote:
> Hi all,
>
> As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead.
>
> I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module.
>
> A first little exercise is mentioned on my blog but it's far from production ready.
>
> - TODO: allow wrapping query result in 1 root tag
> - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar).
>
> For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html
>
> Kind regards,
> Robby Pelssers
>