Wherever you decide to put it I think it's a great idea. Found myself in certain unit test situations where this would've been very helpful.
j On 2/10/06, Allison, Bob <[EMAIL PROTECTED]> wrote: > > Now that I think about it, though, for 2.1 would there be a way to > package the entire set of compile phases (generate-xx-sources, > process-xx-sources, generate-xx-resources, process-xx-resources, > compile-xx, process-xx-classes, package-xx) in something that would > allow a project or plugin to define a complete, independent compile > sequence for whatever files they need? I'm thinking along the lines of > the clean plugin's lifecycle. If you had a "ubercompiler" plugin which > had its own lifecycle, then it would be fairly easy to use it for a test > compile lifecycle and a mock-object lifecycle and anything else people > need. > > -----Original Message----- > From: Allison, Bob [mailto:[EMAIL PROTECTED] > Sent: Friday, February 10, 2006 06:12 > To: Maven Developers List > Subject: RE: Creating mock objects for core components > > > My personal preference would be src/mock/... structured like > src/test/... and be able to build an output artifact jar with classifier > "mock" as part of the normal build. To do this, unfortunately, requires > resolution of MCOMPILER-13. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos > Sanchez > Sent: Thursday, February 09, 2006 17:06 > To: Maven Developers List > Subject: Creating mock objects for core components > > > Hi, > > I think it'd be useful to create a project with mock objects, eg > Artifact, MavenProject,... as I have already seen some implementations > in plugins test (eg. jar plugin), to avoid repetition and make it easy > to test stuff. it doesn't mean start making mocks right now, but > setting up a place where to put the stuff as we make it. > > What's the suggested approach? > > a) create a new project with only mocks for each project already > existing > - maven-model-mock > - maven-artifact-mock > pros: clean api > cons: many new projects > > b) put the mocks in the test folder and deploy the test jars > pros: no new projects, mocks are close to implementations, same > lifecycle > cons: dirty api, tests also included in jar, we should follow > backwards compatibility in tests, no way to say what is supposed to be > used and what not > > c) create a new folder src/mock/main (and src/mock/test if we really > need it) > pros: both of the other two > cons: change directory structure now ? > > WDYT? > > --------------------------------------------------------------------- > 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] > >