Mailing-List: contact users-help@buildr.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@buildr.apache.org
Received-SPF: pass (nike.apache.org: domain of djspiewak@gmail.com designates
 209.85.217.218 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=VVSCW4FVU2PrQmI25ssFRkpTcPVJuB3sbJSooe7ym6rLRJo4TwKISurDLtwEf44wbL
         N0YccmZXqe/c6LJoWnzENd4UbkN0UWiH275v6Qb67hc9/nsonjh85l9CXhT8XstyBSBT
         2o9Qk2lWUr9d8NrLixI0oWwOmI7UFfSBpYpcs=
MIME-Version: 1.0
In-Reply-To: <1249912527.3874.277.camel@localhost.localdomain.tld>
References: <1248685948.3748.14.camel@localhost.localdomain.tld>
	<1249890113.3874.66.camel@localhost.localdomain.tld>
 <5582dd3b0908100207t1d841c1ag81fc8b23a163fe12@mail.gmail.com>
	<1249912527.3874.277.camel@localhost.localdomain.tld>
From: Daniel Spiewak <djspiewak@gmail.com>
Date: Mon, 10 Aug 2009 09:06:19 -0500
Message-ID: <5c99d0330908100706p403e4b7aw696154ea66c25d63@mail.gmail.com>
Subject: Re: Build completes successfully on configuration failures and
	skipped tests
To: users@buildr.apache.org
Content-Type: multipart/alternative; boundary=00151750dec63b4d6f0470ca18e4

--00151750dec63b4d6f0470ca18e4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Just a side-note, but if you are experiencing problems where the Scala
compiler fails but the build continues, this has been fixed quite recently
in trunk/.

Daniel

On Mon, Aug 10, 2009 at 8:55 AM, Martin Grotzke <
martin.grotzke@javakaffee.de> wrote:

> Yes, I'll do this soon. Unfortunately we're experiencing other new
> issues where I'm not sure if it's related to builder or just scala...
> (writing in a new email right now)
>
> Cheers,
> Martin
>
>
> On Mon, 2009-08-10 at 02:07 -0700, Alex Boisvert wrote:
> > Can you create a Jira issue and attach a sample project that demonstrates
> > the issue?  (Or point me to it if it already exists)
> >
> > alex
> >
> >
> > On Mon, Aug 10, 2009 at 12:41 AM, Martin Grotzke <
> > martin.grotzke@javakaffee.de> wrote:
> >
> > > Hi,
> > >
> > > this is still an issue for us. Can anybody help with this?
> > >
> > > Cheers,
> > > Martin
> > >
> > >
> > > On Mon, 2009-07-27 at 11:12 +0200, Martin Grotzke wrote:
> > > > Hi,
> > > >
> > > > we have the issue, that the build completes successfully if with
> > > > configuration failures and skipped tests.
> > > >
> > > > This is the output of the test run (buildr clean test):
> > > >
> > > > ===============================================
> > > > ff-webapp
> > > > Total tests run: 55, Failures: 0, Skips: 55
> > > > Configuration Failures: 1, Skips: 66
> > > > ===============================================
> > > >
> > > > Completed in 29.550s
> > > >
> > > > (the shown output is just the summary for the run of one of the
> > > > subprojects).
> > > >
> > > > The configuration failure is e.g.
> > > >
> > > > FAILED CONFIGURATION: @BeforeClass setupIntegrationTest
> > > > com.google.inject.CreationException: Guice creation errors:
> > > >
> > > > 1) A binding to com.proj.core.common.UrlService was already
> configured at
> > >
> com.proj.core.backend.CoreBackendModule.configureServices(CoreBackendModule.java:98).
> > > >   at
> > >
> com.proj.core.domain.CoreDomainModule.configure(CoreDomainModule.java:47)
> > > >
> > > > 1 error
> > > >         at
> > >
> com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(Errors.java:358)
> > > >         at
> > >
> com.google.inject.internal.InjectorBuilder.initializeStatically(InjectorBuilder.java:153)
> > > >         at
> > >
> com.google.inject.internal.InjectorBuilder.build(InjectorBuilder.java:106)
> > > >         at com.google.inject.Guice.createInjector(Guice.java:93)
> > > >         at com.google.inject.Guice.createInjector(Guice.java:70)
> > > >         at
> > > com.proj.core.IntegrationTest.setupGuice(IntegrationTest.java:84)
> > > >         at
> > >
> com.proj.core.IntegrationTest.setupIntegrationTest(IntegrationTest.java:63)
> > > > ... Removed 22 stack frames
> > > >
> > > > Is it intended, that configuration failures don't break the tests?
> Btw.,
> > > > the test.using :fail_on_failure is left as default...
> > > >
> > > > Thanx && Cheers,
> > > > Martin
> > > >
> > > >
> > >
>

--00151750dec63b4d6f0470ca18e4--