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

[dsaff]

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.

[jglick]

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]

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

[jglick]

I do not know what that is. In Maven Central http://search.maven.org/#artifactdetails|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.

[stefanbirkner]

Here is the link to Maven Search: http://search.maven.org/#artifactdetails|junit|junit-dep|4.10|jar

[jglick]

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]

Jesse,

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.

Thanks,

David

[jglick]

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]

Jesse,

Sounds good to me. Would you mind floating the proposal on junit@yahoogroups.com 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]

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: http://search.maven.org/remotecontent?filepath=bsh/bsh/2.0b4/bsh-2.0b4.pom which changed from bsh:bsh to org.beanshell:bsh

[dsaff]

Sounds good to me.