I agree which is why having the ability to get the jar built with a different target was proposed. My fear with a property is users will just shove maven.no.test.fail=true ( or something ) in their build.properties and forget its there and defeat the regression aspect of the unit tests.
================================================================= Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 12, 2002 8:44 PM > To: Turbine Maven Users List > Subject: RE: Calling <fail/> if <junit/> fails > > > > Jeff, defaulting to failure is different to forcing failure without an > alternative.... > -- > dIon Gillard, Multitask Consulting > Work: http://www.multitask.com.au > Developers: http://adslgateway.multitask.com.au/developers > > > > > "Brekke, Jeff" > > <Jeff.Brekke@q To: 'Turbine > Maven Users List' > g.com> > <[EMAIL PROTECTED]> > > cc: > > 06/13/02 06:50 Subject: RE: > Calling <fail/> if <junit/> fails > AM > > Please respond > > to "Turbine > > Maven Users > > List" > > > > > > > > > > Martin, > > If someone chose to implement something like this, the testing stuff > wouldn't change at all. Create another jar target only that doesn't > execute > the unit tests. This would done be in core/build.xml and > wouldn't be too > much duplication. > > I really hope that having the tests fail the build when the tests fail > remains the default behavior of Maven. It has been my > experience with both > Turbine and work projects that if failing tests don't fail > the build, most > likely they'll be left failing and the code will not be > corrected or the > tests will go stagnant. > > One of Maven's aspects that attracted me was it was/is a > collection of best > practices with regards to build management/development collected from > various developers experienced in open and closed source java > projects. I > hope Maven doesn't turn into ant or a super-duper build tool with the > flexibility to build anything that ever needs building. This > is probably > why I keep -1'ing this small change wrt failing tests. > > ================================================================= > Jeffrey D. Brekke Quad/Graphics > [EMAIL PROTECTED] http://www.qg.com > > > > -----Original Message----- > > From: Martin van den Bemt [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, June 12, 2002 2:45 PM > > To: Turbine Maven Users List > > Subject: RE: Calling <fail/> if <junit/> fails > > > > > > Hi Jeff, > > > > As I also stated, is that your approach still needs fixing > the current > > test/build.xml to make sure you don't duplicate code.. The > current way > > it is done, doesn't leave even room open to implement this, > unless you > > like unecessery duplication work ;) > > So in short, you are going to end with a property somehow anyway.. > > The rest of my motivations are well expressed already in the earlier > > thread. > > > > Mvgr, > > Martin > > > > On Wed, 2002-06-12 at 20:20, Brekke, Jeff wrote: > > > The general idea is you wouldn't want to produce the final > > jar if the unit > > > tests are failing. Wouldn't failing unit tests indicate > > the code is not > > > working properly? In reality you can proceed to build the > > site with failing > > > tests showing up in the report. The default jar target > > will not complete > > > though with failing unit tests. It's been brought up > > previously and I'm -1 > > > on allowing the user to change this behavior, but would be > > +0 to adding a > > > separate target ( ant maven:jar-not-tested ) to build the > > untested jar > > > without depending on the unit test target. > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
