From: Mauro T. <mau...@aq...> - 2007-08-09 20:40:09
|
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 |