cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Dolg <steven.d...@indoqa.com>
Subject Re: Using XQJ API with Cocoon3
Date Thu, 14 Jul 2011 12:02:08 GMT
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<steven.dolg@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.pelssers@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
>>>>
>>


Mime
View raw message