commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [GUMP@vmgump]: Project commons-email (in module apache-commons) failed
Date Tue, 08 Jan 2013 11:42:06 GMT
On Tue, Jan 8, 2013 at 11:56 AM, sebb <sebbaz@gmail.com> wrote:

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

ok that would be a good option too.


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

As the class to be mocked (URL) is final, the options are somehow limited.
Powermock is the only solution I have found so far for this kind of
situations (available via maven). An option would be to mock the Email
class itself, but then the test is not of much use anymore imho.

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

Agreed.

Thomas

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message