Baz a écrit :
> 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?

I think cvsnt doesn't support z3 compression, but I'm not sure.

> 
> 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 :)

Yes, it's an omission in maven-scm code. If you filed an issue in maven-scm project, we 
can remember it.

> 
> - 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 * * * *

Your expression isn't correct, it must be 0 0,5,10,15,20,25,30,35,40,45,50,55 * * * ?
http://www.opensymphony.com/quartz/api/org/quartz/CronTrigger.html

> 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>

We don't use db job storage, we store only cron expressions.

Emmanuel

> 
> 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).
>>>
>>>
>>>
>>
>>
> 
> 
>