It appears that we needed the full hamcrest library at compile time
for just one assert in WicketTester. I've rewritten that assert to
assertTrue() to keep the hamcrest dependencies at scope test. This
keeps our dependencies at the bare minimum (unless we are going to
implement our own hamcrest matchers, but I'd rather have that be an
optional module should we choose to go down that path)

Martijn


On Mon, Aug 3, 2015 at 11:54 AM, Martijn Dashorst
<[email protected]> wrote:
> And not helped by the differences between maven and m2eclipse. I'll
> look into the build error after lunch.
>
> Martijn
>
>
> On Mon, Aug 3, 2015 at 11:53 AM, Martijn Dashorst
> <[email protected]> wrote:
>> Fixed. Not helped by the awesome documentation of hamcrest...
>>
>> Martijn
>>
>> On Mon, Aug 3, 2015 at 11:37 AM, Martin Grigorov <[email protected]> 
>> wrote:
>>> Hi,
>>>
>>> I'm +1 for 2.0 unless it breaks something bad.
>>> AFAIK junit.next will come without hamcrest.
>>>
>>> Martin Grigorov
>>> Freelancer. Available for hire!
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Mon, Aug 3, 2015 at 11:50 AM, Martijn Dashorst <
>>> [email protected]> wrote:
>>>
>>>> Do we want to use the new 2.0.0.0 version of hamcrest, or stick with
>>>> the dependency from junit (1.3)?
>>>>
>>>> I ask because we have a dependency convergence error in our poms since
>>>> junit includes 1.3 and our POMs say 2.0.0.0.
>>>>
>>>> I've excluded hamcrest from junit, but then we run into a compilation
>>>> error (in WicketTester), that I can probably fix, but is that what we
>>>> want?
>>>>
>>>> So which way do we want to go?
>>>>
>>>> Martijn
>>>>
>>>> --
>>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>>>
>>
>>
>>
>> --
>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

Reply via email to