I was on 1.0. The fix doesnt work on that, so I've upgraded to 1.0.2;
ran into a couple of issues though:

- I changed a file to break the build and fired it off to test this.
The log checking takes forever (cvs -f -d "XXX" -q log). From the
flags this is going to dump the entire history from CVS. Shouldn't
that be more like 'cvs -z3 -f -d "XXX" log -N -d"1 day ago" ' or
something, to trim the output to commits recent enough to affect the
integration, and use compression?

Some times: with '-z3 ... -N -d"1 day ago"' our log is 1.4Mb and dumps
in 10s. With just -z3, the log is 16.2Mb and takes about 15s. With
neither option, it takes 1m 55s(!) and annoys all the developers by
holding locks :)

- So I killed that and tried to get it to do the build again without
the log, which it does when it doesnt see any updates; although the
build is marked 'in progress'. I saw it unstick itself from that state
earlier today, and presumed it did that on the hourly schedule. Being
at the top of the hour, I decided to set up a 5 min schedule to hurry
things up.
Using quartz's fugly cron[1] every 5 mins is:
0 0,5,10,15,20,25,30,35,40,45,50,55 * * * *
this schedule failed to fire, twice. So I bounced continuum, and it
didn't restart:
Caused by: java.lang.UnsupportedOperationException: Support for
specifying both a day-of-week AND a day-of-month parameter is not
implemented.
      at org.quartz.CronTrigger.getTimeAfter(CronTrigger.java:1985)

Ok, so now I could figure out how to log into derby, find the broken
data and fix it - or just reinstall, since I only had one project set
up so far. Guess that'll teach me to mess with the schedules ;) ...

Just mentioning this all in case other people see the problems, I'm
not sure these are worth filing bug reports on.

-Baz

[1] <rant>we found quartz integration in our own product deeply
painful; the db backend was full of bugs and the code is tortuous. So
we went back to the cron manpage. The traditional Vixie design is
pretty damn elegant, schedules just need 134 bits of storage, and
looping for a 'next' date always terminates at most 28 years into the
future. The parser and date iterator took well under 200 LOC...and
we've never touched quartz again.</rant>

On 10/28/05, Emmanuel Venisse <emmanuel@venisse.net> wrote:
> Do you use maven 1.0.2?
>
> It's a problem in maven.bat. I've add the workaround in continuum faq
> http://maven.apache.org/continuum/faqs.html
>
> Emmanuel
>
> Baz a écrit :
> > When I build a maven-1.0 project, its being marked as successful even
> > if the build fails, building on win32.
> >
> > Is this (still) a known issue? I've seen something similar before - as
> > far back as 2002, forehead was swallowing maven's status code. I had
> > to patch that to get it working with anthill.
> > (http://lists.urbancode.com/pipermail/anthill/2002-December/000543.html
> > - I mention it there, but it seems that jira is now defunct and
> > forehead never made the move to codehaus).
> >
> >
> >
>
>