You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@continuum.apache.org by Baz <br...@gmail.com> on 2005/10/28 15:41:44 UTC
build fails not noticed for maven1/win32?
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).
Re: build fails not noticed for maven1/win32?
Posted by Baz <br...@gmail.com>.
On 10/28/05, Emmanuel Venisse <em...@venisse.net> wrote:
> I think cvsnt doesn't support z3 compression, but I'm not sure.
The times I posted were done with cvsnt on both client and server
side, so there's definitely z3 support in there. I saw a continuum log
message in there that said 'server doesn't accept gzip encoding' (I'm
away from the logs now, paraphrasing), so maybe scm disabled the flag
for some reason.
> Yes, it's an omission in maven-scm code. If you filed an issue in maven-scm project, we
> can remember it.
Ok, I'll file a bug on maven-scm, thanks.
> 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
Eww!! Reading that page, I could write: "0 0-55/5 * * * ?" or "0
0-55/5 * ? * *" (ie "any day of the week and every day of the month",
or "every day of the week and any day of the month".) Which is has no
semantic difference from the POSIX cron syntax for both - "0-55/5 * *
* *" , just syntactic hairsplitting - not continuums fault of course.
What were they thinking?
However, the actual problem here is that continuum accepted the
pattern, but only failed on restart, when it was impossible to undo.
> We don't use db job storage, we store only cron expressions.
>
> Emmanuel
I was only getting my general dislike of quartz off my chest :)
Re: build fails not noticed for ANT/win32
Posted by Emmanuel Venisse <em...@venisse.net>.
It's a problem with ant.bat. You have the workaround in faqs
http://maven.apache.org/continuum/faqs.html#how-does-continuum-detect-a-successful-build
Emmanuel
Antoine Brun a écrit :
> Hello,
>
> I have recently set up a continuum server in order to automate our ant
> projets integration and I am just realizing that ant build error like
> javac target compilation error are not detected as errors by continuum.
> Does anyone knows anything about this? is it an Ant issue? I might be
> missing something in my ant targets definitions.
>
> below the ant output:
>
> compile:
> [javac] Compiling 10 source files to
> C:\dev\continuum-1.0.1\apps\continuum\working-directory\8\bin
> [javac]
> C:\dev\continuum-1.0.1\apps\continuum\working-directory\8\src\opsys\phoenix\tools\ConfManager.java:172:
> incompatible types
> [javac] found : void
> [javac] required: opsys.solea.manager.ManagerController
> [javac] controller = ManagerController.setProperties(props);
> [javac] ^
> [javac] 1 error
>
> BUILD FAILED
> C:\dev\continuum-1.0.1\apps\continuum\working-directory\8\build.xml:13:
> The following error occurred while executing this line:
> C:\dev\continuum-1.0.1\apps\continuum\working-directory\8\build.xml:82:
> Compile failed; see the compiler error output for details.
>
> the javac target:
>
> <target name="compile" depends="init">
> <javac debug="yes" srcdir="${basedir}/src"
> destdir="${basedir}/bin" fork="true" source="1.5" nowarn="on"
> failonerror="true">
> <classpath refid="compile.appli.classpath" />
> </javac>
> <copy todir="${basedir}/bin">
> <fileset dir="${basedir}/src" includes="**/*Help.html
> **/*.gif **/*.png" excludes="**/*.java CVS CVS/* **/CVS **/CVS/*" />
> </copy>
> </target>
>
>
> Thank you,
>
>
> Antoine Brun
>
>
>
>
>
Re: build fails not noticed for ANT/win32
Posted by Antoine Brun <ab...@opsys.fr>.
Hello,
I have recently set up a continuum server in order to automate our ant
projets integration and I am just realizing that ant build error like
javac target compilation error are not detected as errors by continuum.
Does anyone knows anything about this? is it an Ant issue? I might be
missing something in my ant targets definitions.
below the ant output:
compile:
[javac] Compiling 10 source files to C:\dev\continuum-1.0.1\apps\continuum\working-directory\8\bin
[javac] C:\dev\continuum-1.0.1\apps\continuum\working-directory\8\src\opsys\phoenix\tools\ConfManager.java:172: incompatible types
[javac] found : void
[javac] required: opsys.solea.manager.ManagerController
[javac] controller = ManagerController.setProperties(props);
[javac] ^
[javac] 1 error
BUILD FAILED
C:\dev\continuum-1.0.1\apps\continuum\working-directory\8\build.xml:13: The following error occurred while executing this line:
C:\dev\continuum-1.0.1\apps\continuum\working-directory\8\build.xml:82: Compile failed; see the compiler error output for details.
the javac target:
<target name="compile" depends="init">
<javac debug="yes" srcdir="${basedir}/src" destdir="${basedir}/bin" fork="true" source="1.5" nowarn="on" failonerror="true">
<classpath refid="compile.appli.classpath" />
</javac>
<copy todir="${basedir}/bin">
<fileset dir="${basedir}/src" includes="**/*Help.html **/*.gif **/*.png" excludes="**/*.java CVS CVS/* **/CVS **/CVS/*" />
</copy>
</target>
Thank you,
Antoine Brun
Re: build fails not noticed for maven1/win32?
Posted by Emmanuel Venisse <em...@venisse.net>.
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 <em...@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).
>>>
>>>
>>>
>>
>>
>
>
>
Re: build fails not noticed for maven1/win32?
Posted by Baz <br...@gmail.com>.
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 <em...@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).
> >
> >
> >
>
>
Re: build fails not noticed for maven1/win32?
Posted by Emmanuel Venisse <em...@venisse.net>.
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).
>
>
>