build.xml uploads junitX.jar as junit-depX.jar #309

dsaff opened this Issue Sep 13, 2011 · 10 comments


None yet
4 participants

dsaff commented Sep 13, 2011

This means that although the correct junit-depX.jar files are created locally (that is, without the hamcrest classes), they are ignored, and the junitX.jar file is uploaded under the name junit-depX.jar.

@dsaff dsaff added a commit to dsaff/junit that referenced this issue Sep 13, 2011

@dsaff dsaff Fixes gh-309: build.xml uploads junitX.jar as junit-depX.jar 9de54af

dsaff closed this in 3914b8f Sep 14, 2011


jglick commented Oct 12, 2011

The release notes for 4.10 claim that Hamcrest classes are no longer included, and seem to link to this issue. Yet junit-4.10.jar from Maven Central still includes org.hamcrest and subpackages. Am I missing something?


stefanbirkner commented Oct 12, 2011

You have to use junit-dep-4.10.jar.


jglick commented Oct 12, 2011

I do not know what that is. In Maven Central|junit|junit|4.10|jar there is just a JAR which includes Hamcrest, which seems wrong since org.hamcrest:hamcrest-core:1.1 is already in its dependency list.


jglick commented Oct 13, 2011

I still do not get the intended usage. Every Maven project I have ever seen with unit tests declares a test dep on junit:junit, and this already specifies a dependency on org.hamcrest:hamcrest-core which will then show up in the transitive classpath, so this artifact should not itself include Hamcrest classes.

If in the plain old ZIP distribution, for people using non-repository-based build tools, you want to include multiple JAR variants, that is one thing. But the Maven repository should include just one artifact, junit:junit, which has JUnit classes and nothing else; its dependency list should be only those libraries needed for JUnit classes to run.

So basically at the moment junit:junit is incorrect, and every Maven project in the world has to switch their dependency to junit:junit-dep in order to get a normally functioning transitive classpath.


dsaff commented Oct 17, 2011


JUnit was created. Then Maven was created. Sometime after that, people who were not me started to add junit to maven. Then, whoever they were (I never figured it out), they stopped.

Over time, more and more reports of "regression errors" turned out to be from maven users who assumed they were working with the latest version of JUnit, but in truth, maven was giving them a version sometimes almost 2 years old.

I first asked for community help, which didn't pan out. Then I decided that doing the maven maintenance myself would be the kindest/most efficient thing in the long run. So I looked at what was being done in maven (again, I've never used it myself), and did my best to replicate it as new versions came out.

It might be that the way things are now is completely hosed. If so, the ideal path forward would be for someone who uses and deeply understands Maven to build consensus with other Maven users about the right thing to do, and issue a pull request to put things right.

Do you think you could find that volunteer? I bet it would help a lot of people.




jglick commented Oct 17, 2011

I could presumably create a pull request that would publish the "bare" JAR (what in your downloadable distribution seems to be called junit-dep.jar) as the junit:junit artifact, and omit the combined JAR altogether since I suppose it is not needed by Maven users. (If someone does need it for some reason, junit-all would be the conventional artifact name.)

But I cannot know why the current setup was created. From Git history I can see that you (David) added the targets to do Maven uploading, and in the repository I can see that junit:junit-dep dates back to 4.4.


dsaff commented Oct 18, 2011


Sounds good to me. Would you mind floating the proposal on so anyone who has a problem with it can pipe up?

If the history helps, I added the targets to build.xml long after someone started adding junit and junit-dep to Maven--I don't know what mechanism they were using.

Vampire commented Oct 26, 2011

Maybe it would also make sense to upload a relocation of junit-dep to junit so that builds that users that use junit-dep can still get it. I have seen this for beanshell: which changed from bsh:bsh to org.beanshell:bsh


dsaff commented Oct 26, 2011

Sounds good to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment