The reason why I asked is that for our nightly builds it would be nice to have the site created even if the unit tests fail. A mail is sent to indicate build success or failure. It would then be the responsibility of each developer working on the project to check the reports to see why the build failed.
Now, I know that each developer should ensure that their checkins compile and don't break any tests. There are always a few who break the mould and don't follow the rules. The reason I asked the question initially is that a piece of code tried to set a value in a hashmap to null. This threw a NullPointerException and this is why the build failed. I can read the output files no problem, but it is easier when you have a browser open to just hit reload to see what has changed. Anyway, thanks for your insights, -John K On Wednesday, June 12, 2002, at 08:50 , Brekke, Jeff wrote: > 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:turbine-maven-user- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:turbine-maven-user- > [EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
