Community
Participate
Working Groups
From Antonio by email: "org.hamcrest.matchers_1.2 is a bit confusing: it seems to have both binary and source versions mixed up in the same directories, and the unit tests are throwing a fit with finding two compiled versions of the same class. Shouldn't we either build the .class files from sources, or just distribute the included .class files? Doing both seems a bit confusing to me."
This shouldn't be a problem, as long as org.hamcrest.matchers appears above org.junit in the plug-in dependencies of org.eclipse.epsilon.test.dependencies: JUnit has, for a while, shipped with a version of Hamcrest. However, Helios bundles quite an old version of JUnit+Hamcrest, which lacks a lot of useful features, so we use Hamcrest 1.2 and put it before the JUnit dependency. I'm hoping that Indigo will include a more recent version of JUnit+Hamcrest, and then we won't need to keep our own copy of Hamcrest in our SVN. Given that we might be able to delete our copy of Hamcrest soon, I think that we don't need to clean our Hamcrest project right now. We can either delete it or clean it after Indigo is released.
Hamcrest is used mainly in the test projects. The only non-test code where it appears to be used is EmfMetamodelDirectory in the the hutn.dt plugin. I haven't looked at the code there too closely but it would seem fairly straightforward to replace the Hamcrest calls with Hamcresst-independent code. If we do this, we can move hamcrest under the /test directory in the SVN and remove it from the binary distribution.
I've fixed this in r2207: HUTN's development tools plugin (and feature) no longer depend on Hamcrest. I've moved the org.hamcrest.matchers_1.2 directory under the tests directory.
Fixed in the latest interim version (1.0.0.201304211529).
Fixed in 1.1
