Re: JUnit 4.4 released

"David Saff" <[email protected]> Mon, 13 Aug 2007 10:42:23 -0400
Newsgroups gmane.comp.java.junit.devel,gmane.comp.java.junit.user
Message-ID <[email protected]>
Mauro,

On 8/9/07, Mauro Talevi <[email protected]> wrote:
> - you ae selling as a benefit having a single jar as opposed to two - junit and hamcrest-core - when
> the user would still have to download separatedly hamcrest-library.  Does not make a big difference
> to download 2 or 3 files, IMHO.

Actually, on my latest project, I've just been using the matchers in
junit-4.4.jar, and it's been going great.  So at least this user is
doing fine with one jar.  :-)

Do you yourself need hamcrest-library for what you're doing?

> - the classpath problems would not manifest themselves if the hamcrest-core dependency was missing,
> or in any case it would be easy to spot fail-fast problems, as opposed to really nasty problems due
> to different versions of hamcrest-core, one embedded and one not, in the classpath.

It is easy to spot fail-fast problems, but not necessarily easy to fix
them--we have at least one user a month who posts to the user list
confused about how to get just the single junit.jar on their
classpath.

I'm saying that both are problems, and any solution is a trade-off.
My personal hunch is that if you ask Java developers the first jar
they ever put on their classpath, JUnit scores high, and I'm very
concerned about making that experience any more complicated than
necessary.

On the other hand, so much of the complexity here is unnecessary.  I
believe that a vanilla Java installation should include a jpkg command
line, so that the answer to the first JUnit FAQ could be:

jpkg install junit

It would be great if end-users didn't have to care how many jar files
were installed to make that work, or even what a jar file is.

>
> - by bundling hamcrest-core you are also surrendering the advantage of a clear versioned dependency
>     structure, which is extremely important with so many open-source libraries, all interconnected
> among them.  A lot of people nowadays use maven or maven-like repositories for their project
> dependencies.

I'd love to see more people use maven (it's the closest thing to the
mythical jpkg we have), so making life hard for them is not good.
However, I think that there's still more people who are downloading
the jar manually from the website, and still more who just use
whatever ships with their IDE, so balance is important.

> Ideally, I would like to see junit released with all its constituent libraries - mandatory or
> optional - separate.  And perhaps have a junit-all that bundles all of the them, including
> hamcrest-library, as a utility packaging for those that choose to use it.  Other users may choose
> not to.
>
> Alternately, I would be grateful if junit could also release the unbundled jar - call it junit-dep
> or whatever, which requires the external dependency to be present in the classpath.

I think that the second is the right solution.  Look for further news
soon.  Thanks,

   David

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/