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.d...@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<robby.pelss...@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 >>
<<winmail.dat>>
