Re: [MO-java-dev] Why is it so complicated???

[Jeff M. <je...@mk...>]

On Sun, 2003-03-23 at 22:04, Tim wrote:
> Guys - I've always used an internal connextra version of the mock objects
> stuff. Now I'm no longer with connextra I thought I would try using the
> official release and see if I could maybe integrate some stuff... but why is
> it so complicated?
> 
> Its certainly not easy to just pull this down in eclipse and use it... there
> are jdk versions to worry about (yes I know this is an issue but only for
> very advanced stuff - surely?), and the directory structures don't easily
> map into the eclipse view of the world (I guess you guys all use some
> complicated scheme in intellij? But why not use eclipse as the lowest common
> denominator? I want a head version in my environment that I can easily apply
> fixes to and check in - I have access to lots of code and ideas, but it has
> to be simple for me to make modifications with an onsite partner and put
> them back in (without lots of messing around - this is why lots of good
> stuff got left out, because for ages connextra used visual age and it was
> too much work to put stuff back in, so we just didn't).

It's quite easy to build from CVS if you use the lowest common
denominator which is ant. Both Eclipse and IntelliJ support executing
ant build files and it's also what allows nightly builds to be performed
by Gump http://cvs.apache.org/builds/gump/latest/mockobjects.html

I've got no problem with re-arranging things to make the layout clear
and the build file is far from as simple as I think it could be, but I'd
be very un-happy to see us abandon it infavour of something else. ANy
effort in changing the project layout should be based arround this
system and making it nicer to intergrate with IDE's rather than
concentrating on one IDE and leaving the build file as a vestigial
process. It's also the basis for some work I've started for producing
RPM spec files which will make installation on RPM based systems much
easier to handle.

> 
> Having played with the dynamic mock stuff I am suprised that all the people
> that I've seen post messages about using it - haven't complained about the
> horrible error messages (the original non dynamic version went to great
> pains to provide useful error messages that would help you quickly locate an
> error and fix it - see my paper A Plea for Assert Equals). I'm also suprised
> no-one has needed an UnorderedExpectationList... I think this is really an
> indication that people just haven't used this stuff in anger, or seen how it
> works at connextra to know that there is much better.
> 
> Anyway - all this aside, I'm a bit perturbed by all this complication and
> would like to try creating a whole new Project that takes the best from both
> worlds. With the dynamic stuff you can drastically cut down the hard coded
> mocks you need (e.g. httpServletRequest can use a dynamic version) although
> some clases that don't have interfaces (like stream stuff) will need hard
> coded versions. Plus there are some useful helper classes that are kicking
> around in the connextra code base that they have agreed to donate.
> 
> So I'm thinking maybe having a mockobjects-java-dynamic (or
> mockobjects2-java?) module with a simple src subdirectory and just pulling
> all of the relevent pieces in one by one as I need them (I am doing some
> work for a company called e2x and we are using the mocks in anger - with
> myself and john nolan on site to supervise their usage). If I can do this -
> and get a good starting point, then everyone can jump in and do all the
> magic that you normally do to make it all open-sourcy.
> 

I really think this is the wrong thing to do. If there's something wrong
with things at the moment then we should be trying to migrate what we
have rather than abandon it and all the work that has gone into it and
the people who are already using it. Open source projects work best when
every moves together at the same pace. The whole thing it about tiny
steps. If nothing else trying to start a  new project put's you under
pressure as your then the single point of failure, everyones stood
around waiting for the hero's to rush in and save them.

"everyone can jump in and do all the magic that you normally do to make
it all open-sourcy" -- and the award for best supporting programmer goes
to ...

> what do you think? We have to make life simpler for ourselves and stop
> having to answer the "method x is not implemented in that mock here's my
> patch" hard work that seems to be going on at the moment.

I like this approach. One of the reasons I've no been hot on the dynamic
stuff is that I see it as encouraging people to be continually
re-inventing the wheel rather than pooling our efforts and reusing each
others code. It's not that hard to create a patch it's not that hard to
apply one. Every other "open-sourcy" project seems to manage it why is
it beyond our capabilities.

> 
> Tim
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.463 / Virus Database: 262 - Release Date: 17/03/2003
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open! 
> Get cracking and register here for some mind boggling fun and 
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev