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.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
