Re: JUnit 4.4 released

David,

David Saff wrote:

> - To allow compatibility with a wide variety of possible matchers,
>   we have decided to include the classes from hamcrest-core,
>   from the [Hamcrest][] project.  This is the first time that
>   third-party classes have been included in JUnit.
> 
> [Hamcrest]: http://code.google.com/p/hamcrest/
> 

Bundling classes from a dependent library in the jar will lead to classloader hell unless you
change package name for the bundled classes.  jMock has Hamcrest as a mandatory but separate 
dependency.   Any reason you did not consider to do the same?  The compatibility motivation you cite 
  is not clear.  It is exactly for compatibility reasons that jars should be kept separate.  If a 
user wants to upgrade to a different version of hamcrest, it will conflict with the classes bundled.

Alternatively, you could provide a *separate* jar (eg junit-all.jar) which bundles with the 
dependencies, but keeping junit.jar without dependendencies bundled.

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/