On 8 January 2013 11:42, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: > On Tue, Jan 8, 2013 at 11:56 AM, sebb <seb...@gmail.com> wrote: > >> On 8 January 2013 09:02, Thomas Neidhart <thomas.neidh...@gmail.com> >> wrote: >> > On Tue, Jan 8, 2013 at 6:26 AM, Stefan Bodewig <bode...@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.
If PowerMock is kept, this info should be documented somewhere in the source, e.g. in the test case and/or the pom. >> >> I don't think the tests should be unconditionally disabled. >> > > Agreed. > > Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
