Cannot use PowerMockRunner with JUnit versions including characters

[GoogleCodeExporter]

E.g. for JUnit 4.9b2:

ava.lang.NumberFormatException: For input string: "9b2"
       at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:
48)
       at java.lang.Integer.parseInt(Integer.java:458)
       at java.lang.Short.parseShort(Short.java:120)
       at java.lang.Short.parseShort(Short.java:78)
       at
org.powermock.modules.junit4.common.internal.impl.VersionCompatibility.getJUnitV
ersion(VersionCompatibility.java:
38)
       at
org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:
31)
       at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
       at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorI
mpl.java:
39)
       at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorA
ccessorImpl.java:
27)
       at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
       at
org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:
31)
       at
org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.jav
a:
24)
       at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:
57)
       at
org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDef
aultPossibilitiesBuilder.java:
29)
       at
org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:
57)
       at
org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:
24)
       at
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:62)

Original issue reported on code.google.com by johan.ha...@gmail.com on 6 Apr 2012 at 7:31

[GoogleCodeExporter]

For obvious reasons this also affects junit 4.11-beta-1, which I am keen to use 
as it is the first version that does not include the hamcrest classes in the 
jar, which introduces all sorts of potential nasty runtime issues.

Original comment by mahoney...@gmail.com on 7 Nov 2012 at 1:12

[GoogleCodeExporter]

Incidentally the code in VersionCompatibility.getJUnitVersion makes no sense at 
all - there's a try block around a simple return statement with no logic in it! 
It cannot possibly throw an exception.

Original comment by mahoney...@gmail.com on 7 Nov 2012 at 1:15

[GoogleCodeExporter]

A simple solution would be to not try and parse this yourself, and instead use 
the following maven dependency:

    <dependency>
      <groupId>org.apache.maven</groupId>
      <artifactId>maven-artifact</artifactId>
      <version>3.0.4</version>
    </dependency>

You can then get the major & minor versions as follows:
ArtifactVersion artifactVersion = new DefaultArtifactVersion( Version.id() );
int majorVersion = artifactVersion.getMajorVersion();
int minorVersion = artifactVersion.getMinorVersion();

Original comment by mahoney...@gmail.com on 7 Nov 2012 at 1:37

[GoogleCodeExporter]

It seems rather overkill to bring in a dependency just to parse the version. 
Please help out and provide a patch and I'll include it in the next release 
that will be released soon!

Original comment by johan.ha...@gmail.com on 7 Nov 2012 at 5:07

[GoogleCodeExporter]

Patch attached. It seems to me much more sensible to use well tested, working 
code that does not have to be maintained in this project.

Original comment by mahoney...@gmail.com on 13 Nov 2012 at 12:23

Attachments:

• allow_junit_4_11_beta_1.patch

[GoogleCodeExporter]

Better patch - fixed my broken indentation of a pom & mildly cleaned up 
PowerMockRunner.

Original comment by mahoney...@gmail.com on 13 Nov 2012 at 12:45

Attachments:

• allow_junit_4_11_beta_1.2.patch

[GoogleCodeExporter]

I'm sorry but I cannot accept this patch since it uses the "maven-artifact" 
dependency. I don't think it's appropriate to depend on a new framework just 
for parsing a version number. This, I believe, has to be fixed without an 
additional dependency.

Original comment by johan.ha...@gmail.com on 13 Nov 2012 at 6:17

[GoogleCodeExporter]

FWIW I hadn't seen your comment before producing the first patch.

"I don't think it's appropriate to depend on a new framework"

Why not? What's the downside? Just about everyone uses a dependency management 
system now, so no-one will ever even notice.

The upside is that there are now fewer lines of untested & provenly not working 
code in powermock that are actually preventing powermock working for people 
using the latest release of JUnit right now.

Original comment by mahoney...@gmail.com on 13 Nov 2012 at 7:08

[GoogleCodeExporter]

Well one of the downsides is that you may end up with conflicting dependencies. 
So let's say that you're already using a dependency of another version then you 
may end up with different API depending which one you put first in classpath 
and stuff may go really bad. Spring, for example, has troubles with this since 
they (used) to depend on junit (with dependencies) which pulled in transitive 
dependencies that could conflict with the things you already were using. This 
is things you want to avoid. I've ran into similar situation many times with 
frameworks depending on different versions of HTTP Client or Hamcrest. Now I 
wouldn't suggest that you write your own HTTP Client framework instead of using 
it as a dependency but for smaller things (and parsing a version string is 
relatively small thing) I think it's better to have control over it yourself 
and you avoid classpath collisions.

Original comment by johan.ha...@gmail.com on 13 Nov 2012 at 9:16

[GoogleCodeExporter]

There's for example a lot of exemples on 
http://stackoverflow.com/questions/198431/how-do-you-compare-two-version-strings
-in-java  on how to parse versions in Java.

Original comment by johan.ha...@gmail.com on 13 Nov 2012 at 9:18

[GoogleCodeExporter]

A third option would perhaps be to incorporate Mavens code in PowerMock if it's 
not too big and its licence allows for it. 

Original comment by johan.ha...@gmail.com on 13 Nov 2012 at 9:20

[GoogleCodeExporter]

Ok so I've no given this a go myself. Please check out and build PowerMock from 
trunk (ignore tests if using Java 7) and give it a spin and see if it works.

Original comment by johan.ha...@gmail.com on 13 Nov 2012 at 9:55