Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates
 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJSjvwvtdm4X0tJt2UQr9MMmn0g1BvNxxFBTFbqHmm+BmNGMZw@mail.gmail.com>
References: <20130108024433.4DABF14712E@vmgump.apache.org>
	<87fw2cckjc.fsf@v35516.1blu.de>
	<CAJSjvwvtdm4X0tJt2UQr9MMmn0g1BvNxxFBTFbqHmm+BmNGMZw@mail.gmail.com>
Date: Tue, 8 Jan 2013 10:56:08 +0000
Message-ID: 
 <CAOGo0VZFozKx56g3V0M1Z4akJUDvRZ4bw_wmn_gGiP3Fz8GoTw@mail.gmail.com>
Subject: Re: [GUMP@vmgump]: Project commons-email (in module apache-commons)
 failed
From: sebb <sebbaz@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On 8 January 2013 09:02, Thomas Neidhart <thomas.neidhart@gmail.com> wrote:
> On Tue, Jan 8, 2013 at 6:26 AM, Stefan Bodewig <bodewig@apache.org> wrote:
>
>> On 2013-01-08, Gump wrote:
>>
>> >       at java.lang.Short.parseShort(Short.java:143)
>> >       at
>> org.powermock.modules.junit4.common.internal.impl.VersionCompatibility.getJUnitVersion(VersionCompatibility.java:40)
>>
>> ...
>>
>> >   initializationError(org.apache.commons.mail.MultiPartEmailTest): Value
>> out of range. Value:"08012013" Radix:10
>>
>> Oompf.
>>
>> Gump sets JUnit's version to the current date while building it (right
>> now in the format DDMMYYYY but this will change soonish).  This doesn't
>> fit into a short.
>>
>> Is there any way around this version check or do we need to change the
>> way Gump builds JUnit to make it work?
>>
>
> This is due to the powermock dependency that has been introduced lately.
> The implemented version check seems to be broken (see
> http://code.google.com/p/powermock/issues/detail?id=381) and is pretty
> useless anyway, but there seems to be no way to disable it for now.
>
> I would like to keep powermock, but we could disable the tests in question
> until the version format changes?

Another approach is to revert to the previous code, and check whether
the .invalid host name is resolved; if so, print a warning and skip
the test(s).

Or use a mocking solution that's not broken in this way.

I don't think the tests should be unconditionally disabled.

> Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org