incubator-ctakes-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Pei" <Pei.C...@childrens.harvard.edu>
Subject RE: spurious build errors from Jenkins
Date Mon, 03 Dec 2012 15:21:10 GMT
This should be fixed now.
There's a knob in Jenkins to switch off " Incremental build - only build changed modules"
to always build all modules.
Thanks Olivier for the pointer (http://mail-archives.apache.org/mod_mbox/www-builds/201211.mbox/%3CCAPoyBqS9i9AxVAMyzTZeLp3xB%2Bn1Oo0ts8O1x9P-yQ%3DSXY5Lvw%40mail.gmail.com%3E).

--Pei

> -----Original Message-----
> From: Chen, Pei [mailto:Pei.Chen@childrens.harvard.edu]
> Sent: Wednesday, November 28, 2012 4:18 PM
> To: ctakes-dev@incubator.apache.org
> Subject: RE: spurious build errors from Jenkins
> 
> According to the build logs, it looks like it is only building only the module that
> changed from SCM rather than all modules every time.
> Does anyone know if there's a knob to switch and if so, which one to set this
> in Jenkins?  We can take a closer look once we get access to modify the jobs
> again...
> 
> For example: 64 when the only change was to the constituency parser:
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache cTAKES Constituency Parser [INFO] Apache cTAKES
> CoReference Resolver [INFO] Apache cTAKES Relation Extractor [INFO]
> Apache cTAKES Distribution
> 
> Vs: https://builds.apache.org/job/cTAKES-trunk-compiletest/65/consoleFull
> when invoked by clicking on 'build now':
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Apache cTAKES
> [INFO] Apache cTAKES common type system
> [INFO] Apache cTAKES utils
> [INFO] Apache cTAKES core
> [INFO] Apache cTAKES part-of-speech tagger [INFO] Apache cTAKES chunker
> [INFO] Apache cTAKES document preprocessor [INFO] Apache cTAKES
> dictionary lookup [INFO] Apache cTAKES context dependent tokenizer
> [INFO] Apache cTAKES LVG lexical tools [INFO] Apache cTAKES named entity
> contexts [INFO] Apache cTAKES Constituency Parser [INFO] Apache cTAKES
> CoReference Resolver [INFO] Apache cTAKES Drug NER [INFO] Apache
> cTAKES Side Effects [INFO] Apache cTAKES Smoking Status [INFO] Apache
> cTAKES Dependency Parser [INFO] Apache cTAKES Assertion [INFO] Apache
> cTAKES ctakes-clinical-pipeline [INFO] Apache cTAKES Relation Extractor
> [INFO] Apache cTAKES Pad Term Spotter [INFO] Apache cTAKES Temporal
> Information Extraction [INFO] Apache cTAKES Distribution
> 
> > -----Original Message-----
> > From: Steven Bethard [mailto:steven.bethard@Colorado.EDU]
> > Sent: Friday, November 16, 2012 4:17 PM
> > To: ctakes-dev@incubator.apache.org
> > Subject: spurious build errors from Jenkins
> >
> > So as you may have noticed, we just experienced the same kind of
> > spurious build error with ctakes-relation-extractor that we were
> > seeing with ctakes- assertion before. We got errors like:
> >
> > Could not resolve dependencies for project
> > org.apache.ctakes:ctakes-core:jar:3.1.0-incubating-SNAPSHOT:
> > The following artifacts could not be resolved:
> > org.apache.ctakes:ctakes-type-system:jar:3.1.0-incubating-SNAPSHOT,
> > org.apache.ctakes:ctakes-utils:jar:3.1.0-incubating-SNAPSHOT
> >
> > This is exactly the error that we get if you run `mvn compile` from
> > the `ctakes-core` directory, which we should never be doing. And
> > there's no error if we run `mvn compile` from the top-level directory,
> > which is what we should always be doing.
> >
> > So I suspect that Jenkins is somehow configured to run `mvn compile`
> > separately for the separate modules. Can we turn that off, and only
> > run the `mvn compile` from the top level? There should be no need to
> > run it for each module if we run it from the top.
> >
> >
> > Steve
> >
> > P.S. To make Jenkins happy again, all you have to do is start a build
> > manually with the "Build Now" button in Jenkins. But we shouldn't need to
> do that.

Mime
View raw message