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]
