struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: struts build change questions
Date Sun, 27 Feb 2005 18:05:39 GMT
On Sun, 27 Feb 2005 12:32:31 -0500, James Mitchell <jmitchell@apache.org> wrote:
> Ok, now this is interesting.  "mock" depends on "core", and "core tests"
> depend on "mock".  Maven wants to build/test for each distribution, so the
> "first time" developer is in a chicken-and-egg state trying to "maven
> build-all" or even "maven dist" one at a time.
> 
> I would say we put the mock objects back into core/src/test and simply
> package them separately after (postGoal) the core 'dist'.
> 
> Your thoughts?

The first question that comes to my mind is "why does mock depend on
core?". Is this something that could be fixed, or is there a hopeless
dependency? It would be a shame to have to put it back in now, having
just pulled it out. ;-)

--
Martin Cooper


> --
> James Mitchell
> Software Engineer / Open Source Evangelist
> EdgeTech, Inc.
> 678.910.8017
> AIM: jmitchtx
> 
> ----- Original Message -----
> From: "James Mitchell" <jmitchell@apache.org>
> To: "Struts Developers List" <dev@struts.apache.org>
> Sent: Sunday, February 27, 2005 12:34 AM
> Subject: Re: struts build change questions
> 
> > done
> >
> >
> >
> > --
> > James Mitchell
> > Software Engineer / Open Source Evangelist
> > EdgeTech, Inc.
> > 678.910.8017
> > AIM: jmitchtx
> >
> > ----- Original Message -----
> > From: "Craig McClanahan" <craigmcc@gmail.com>
> > To: "James Mitchell" <jmitchell@apache.org>
> > Cc: "Struts Developers List" <dev@struts.apache.org>
> > Sent: Saturday, February 26, 2005 1:16 AM
> > Subject: Re: struts build change questions
> >
> >
> >> On Sat, 26 Feb 2005 00:18:25 -0500, James Mitchell <jmitchell@apache.org>
> >> wrote:
> >>> I agree on all points.
> >>>
> >>> So, you think I should yank it up to struts/current/ ?
> >>>
> >>
> >> +1
> >>
> >> Craig
> >>
> >>> --
> >>> James Mitchell
> >>> Software Engineer / Open Source Evangelist
> >>> EdgeTech, Inc.
> >>> 678.910.8017
> >>> AIM: jmitchtx
> >>>
> >>> ----- Original Message -----
> >>> From: "Craig McClanahan" <craigmcc@gmail.com>
> >>> To: "Struts Developers List" <dev@struts.apache.org>
> >>> Sent: Friday, February 25, 2005 11:56 PM
> >>> Subject: Re: struts build change questions
> >>>
> >>> > On Fri, 25 Feb 2005 23:40:41 -0500, James Mitchell
> >>> > <jmitchell@apache.org>
> >>> > wrote:
> >>> >> <snip/>
> >>> >>
> >>> >> > It seems to me that a framework which ships (and supports)
a
> >>> >> > ready-made set of mock classes will have an advantage in today's
> >>> >> > world.
> >>> >>
> >>> >> Yes.  It's interesting how things work out.  Over the years I used
to
> >>> >> swear
> >>> >> by in-container based test suites, but after fighting with Cactus
and
> >>> >> fiddling with a few others I have a new appreciation for Mock vs.
> >>> >> in-container testing.
> >>> >>
> >>> >> Aren't there already Mock test frameworks out there that we can
use?
> >>> >> I
> >>> >> mean, why reinvent the wheel?  I could see a problem if the license
> >>> >> were
> >>> >> incompatible.  Your thoughts?
> >>> >>
> >>> >
> >>> > From what I have seen (not exhaustive review, but high level
> >>> > observation):
> >>> >
> >>> > * There are indeed a large number of MockXXX libraries in the world.
> >>> >
> >>> > * So many of them, in fact, that it's hard to decide what combination
> >>> > you
> >>> > need
> >>> >  to cover all the base classes you need.
> >>> >
> >>> > * Because there is no standardization of what a mock should do, there
> >>> > is
> >>> >  a wide variety of extra API in the various versions.
> >>> >
> >>> > * The available mock libraries tend not to be a product of the
> >>> > frameworks
> >>> >  they contain mock implementations for, meaning:
> >>> >  - Not necessarily synchronized with the latest changes in the
> >>> > framework
> >>> >  - Not necessarily suitable for testing intra-framework classes (i.e.
> >>> > more
> >>> >    focused on user apps)
> >>> >  - Not necessarily at the same quality level as the framework under
> >>> > test.
> >>> >
> >>> > * No matter what the quality, the need to go someplace else (or
> >>> > several
> >>> >  someplaces else) to gather suitable test frameworks is a burden on
> >>> > the
> >>> >  user of the framework.
> >>> >
> >>> > Contrast that with a world where:
> >>> >
> >>> > * Each release of a framework has a corresponding release of
> >>> >  a mock objects framework that has been synchronized with the
> >>> >  latest changes in the functionality.
> >>> >
> >>> > * The test framework is used by both the developers of the framework,
> >>> >  and the developers of apps based on the framework, which will tend
> >>> >  to reduce the inevitable behavior differences between the mocks and
> >>> > the
> >>> >  "real thing".
> >>> >
> >>> > * No shopping around the Internet for multiple pieces of code that
you
> >>> >  need to integrate, or evaluate licenses for, or badger to update when
> >>> >  something changes in the underlying framework.
> >>> >
> >>> > It's not an issue of where you get the original code from (I wrote
> >>> > basically all of the code in Shale's test framework, so I am willing
> >>> > to vouche for it and support it; if we can find a suitable starting
> >>> > point somewhere for Struts that is willing to contribute code,
> >>> > great!).  It's the fact that the mock objects are supported by the
> >>> > same folks that are supporting the framework is a very important value
> >>> > add.
> >>> >
> >>> > Note that, because I'm a fan of mock objects, this particular solution
> >>> > is focused around JUnit-based unit tests.  That's not the only
> >>> > possible answer to what kinds of testing gadgets you need (Cactus,
for
> >>> > example, makes it easy to build a different sort of test); but it's
> >>> > certainly the foundation level.  I believe something like this should
> >>> > become a standard deliverable of a framework (whether it is actually
> >>> > developed by the same developers, or only in close cooperation with
> >>> > them, is less important).
> >>> >
> >>> >> <snip/>
> >>> >>
> >>> >> > FWIW, in retrospect, I see that I chose "core-library" in
both
> >>> >> > faces
> >>> >> > and shale.  Might be worth considering.
> >>> >>
> >>> >> You mean name the jar produced by struts/current/core/ as
> >>> >> "core-library-x.y.z.jar" ?
> >>> >> That seems a bit ambiguous doesn't it?  I mean, core library for
> >>> >> what?
> >>> >> Wouldn't that be confusing having a naming clash with Shale?
> >>> >>
> >>> >
> >>> > It might indeed ... shale-core.jar would likely make more sense if
> >>> > Shale ends up being the final name.  But that doesn't necesarily
> >>> > dictate that the source repository needs to have the same name (where
> >>> > there is no opportunity for confusion).
> >>> >
> >>> > After all, people persist in the habit of adding version numbers to
> >>> > jar file names (a habit I detest, but that's a whole different story),
> >>> > so the directory name doesn't match the JAR file name anyway, in many
> >>> > cases.
> >>> >
> >>> > Craig
> >>> >
> >>> >> <snip/>
> >>> >>
> >>> >> > Craig
> >>> >>
> >>> >> --
> >>> >> James Mitchell
> >>> >> Software Engineer / Open Source Evangelist
> >>> >> EdgeTech, Inc.
> >>> >> 678.910.8017
> >>> >> AIM: jmitchtx
> >>> >>
> >>> >> ---------------------------------------------------------------------
> >>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>> >>
> >>> >>
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> > For additional commands, e-mail: dev-help@struts.apache.org
> >>> >
> >>> >
> >>>
> >>>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message