cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robby Pelssers" <>
Subject RE: Using XQJ API with Cocoon3
Date Wed, 13 Jul 2011 08:48:01 GMT
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.


-----Oorspronkelijk bericht-----
Van: Steven Dolg []
Verzonden: wo 13-7-2011 9:30
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


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 

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

> Looking forward to hear from you soon, all the best!!!
> Simo
> On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssers<>  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
>> Kind regards,
>> Robby Pelssers

View raw message