Do you agree?
-- James Mitchell Software Engineer / Open Source Evangelist EdgeTech, Inc. 678.910.8017 AIM: jmitchtx
----- Original Message ----- From: "Martin Cooper" <[EMAIL PROTECTED]>
To: "Struts Developers List" <dev@struts.apache.org>
Sent: Sunday, February 27, 2005 1:05 PM
Subject: Re: struts build change questions
On Sun, 27 Feb 2005 12:32:31 -0500, James Mitchell <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]> 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" <[EMAIL PROTECTED]>
> To: "James Mitchell" <[EMAIL PROTECTED]>
> 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 >> <[EMAIL PROTECTED]>
>> 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" <[EMAIL PROTECTED]>
>>> 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
>>> > <[EMAIL PROTECTED]>
>>> > 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: [EMAIL PROTECTED]
>>> >> For additional commands, e-mail: [EMAIL PROTECTED]
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> > For additional commands, e-mail: [EMAIL PROTECTED]
>>> >
>>> >
>>>
>>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
