Re: JUnit 4.4 released

David Saff wrote:
> Mauro,
> 
> The idea was to bundle only hamcrest-core, a small package that the
> hamcrest team has told us is likely to change very rarely.  The
> majority of the hamcrest matchers are in hamcrest-library, which can
> be downloaded separately.  So, to get all of JUnit and all of
> Hamcrest, without overlaps, you would download junit-x.x.jar, and
> hamcrest-library-x.x.jar.
> 
> There are downsides to this arrangement.  My initial guess is that the
> number of people who will find themselves with classpath problems
> because they're using an incompatible version of hamcrest-all will be
> less than the number who would have found themselves with classpath
> problems because they don't have hamcrest, or couldn't figure out
> which junit jar to download.
> 
> Of course, experience has a way of proving me wrong.  We'll see.
> 

David,

I do understand the idea behind the decision, but IMO on balance it's likely to lead to problems 
down the line.  Let me outline the reasons again:

- 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.

- while hamcrest-core is likely to change rarely, it is still likely to change
(Murphy's law of dependency:  if a dependency can change, it will :-)

- 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.

- 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.


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.

This seems to me a reasonable compromise that should satisfy all users.

Do you think this could be done?

Thanks and regards,
Mauro


-------------------------------------------------------------------------
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/