cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: JUnit tests and packages
Date Mon, 04 Aug 2003 08:06:09 GMT
Mark Leicester wrote:

>I am writing some Cocoon components to deal with MIDI file (generator and serializer),
that I would like to make available at some stage if they are wanted.

Sure they're wanted, as long as you're willing to donate them !

>In my normal course of development I create JUnit tests (ok, I admit this is a recent
'normal'; I've only recently seen the light). Where should I put my test classes? For example,
I am creating an o.a.c.generation.MIDIGenerator, at moment. I have put my TestMIDIGenerator
class into o.a.c.test.generation. Is that sensible? Do you have any other preferred suggestions?
I see that the Chaperon block includes some unit tests, but otherwise they are not widely
implemented. Is the widespread use of JUnit tests desirable? If so, in due course I'd like
create unit tests for other Cocoon components too.

JUnit tests are more than desirable, and if we don't have much of them, 
it's because we're lazy butts. So if you want to contribute some, this 
is a very welcomed effort.

>I've been lurking on the lists for a long time. I introduced Cocoon 2.0 into my company's
development team back in 2001. Now, regrettably, the consensus reached in my company with
respect to web application frameworks is that the Struts approach is simpler and more robust.
Rather than it having been a Cocoon vs. Struts argument, this decision had more to do with
many of our developers' preferences for Java data structures over XML, e.g. "too many layers
= bad performance", "XML makes coding unnecessarily complex" etc. As you may have experienced
in your own working lives, these sorts of arguments can cripple progress in a small team environment
so I have reluctantly ceded Cocoon and XML from the core of our information strategy.

Sad, but well-known story... The advent of flowscript and Woody will 
leave little room for Struts, feature-wise. Now that's true that Cocoon 
is a big beast that takes long to master. Only after this one can see 
the incredible benefits in brings.

>On the plus side this means that now I realise that the best way to continue to work with
Cocoon, which I love dearly and see a great future for, is to contribute directly to the main
Cocoon development effort. I hope I can help!

Every contribution is welcome, and yours is definitely on the creative 
side that makes Cocoon like no other software: are there other 
frameworks on earth that can both connect to SAP and produce MIDI files 
at the same time ?

Sylvain (waiting to listen to Cocoon music ;-)

Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message