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 <steven.d...@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<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 >>> > >
