Re: Use of org.hamcrest.Matchers

[Gintautas Grigelionis]

2018-04-22 22:32 GMT+00:00 Martin Gainty :

> MG>Hi Gintas please see question below
>
> I wish we could replace fetch.xml with an Ivy equivalent :-)
> MG>lib/libraries.properties
> MG>hamcrest-core.version=1.3
> MG>hamcrest-library.version=${hamcrest-core.version}
>
> MG>if fetch.xml is deprecated would'nt you want to deprecate
> lib/libraries.properties as well?
>
>
> Hopefully 2.5.0 is out soon.
>
> Gintas
> MG>let me know
>

It is not necessary to deprecate libraries.properties, see eg Ivy which has
got version.properties recently.
In my current proposal (PR#54) I just put it into "attic" :-)

Gintas

Re: Use of org.hamcrest.Matchers

[Martin Gainty]

MG>Hi Gintas please see question below


From: Gintautas Grigelionis <g.grigelio...@gmail.com>
Sent: Sunday, April 22, 2018 2:30 PM
To: Ant Developers List
Subject: Re: Use of org.hamcrest.Matchers

2018-04-22 13:56 GMT+00:00 Stefan Bodewig <bode...@apache.org>:

On 2018-04-22, Gintautas Grigelionis wrote:
>
> > Hmm... are you sure that Gump has hamcrest-library?
>
> No, you are correct. I was under the impression it was using Hamcrest
> 2.x while it was not - Hamcrest 2.x only contains a single jar and if I
> had looked close enough I would have seen the Matchers class is still
> there inside the gradle built jar.
>
> Gump didn't provide the hamcrest-library but should start doing so with
> the next run.
>

I wish we could replace fetch.xml with an Ivy equivalent :-)
MG>lib/libraries.properties
MG>hamcrest-core.version=1.3
MG>hamcrest-library.version=${hamcrest-core.version}

MG>if fetch.xml is deprecated would'nt you want to deprecate 
lib/libraries.properties as well?


Hopefully 2.5.0 is out soon.

Gintas
MG>let me know

Re: Use of org.hamcrest.Matchers

[Stefan Bodewig]

On 2018-04-22, Gintautas Grigelionis wrote:

> I wish we could replace fetch.xml with an Ivy equivalent :-)

Using that would be against the very spirit of Gump :-)

The spirit of Gump would force Hamcrest 2.x upon Ant, so thought it
already did.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Use of org.hamcrest.Matchers

[Gintautas Grigelionis]

2018-04-22 13:56 GMT+00:00 Stefan Bodewig :

On 2018-04-22, Gintautas Grigelionis wrote:
>
> > Hmm... are you sure that Gump has hamcrest-library?
>
> No, you are correct. I was under the impression it was using Hamcrest
> 2.x while it was not - Hamcrest 2.x only contains a single jar and if I
> had looked close enough I would have seen the Matchers class is still
> there inside the gradle built jar.
>
> Gump didn't provide the hamcrest-library but should start doing so with
> the next run.
>

I wish we could replace fetch.xml with an Ivy equivalent :-)
Hopefully 2.5.0 is out soon.

Gintas

Re: Use of org.hamcrest.Matchers

[Stefan Bodewig]

On 2018-04-22, Gintautas Grigelionis wrote:

> Hmm... are you sure that Gump has hamcrest-library?

No, you are correct. I was under the impression it was using Hamcrest
2.x while it was not - Hamcrest 2.x only contains a single jar and if I
had looked close enough I would have seen the Matchers class is still
there inside the gradle built jar.

Gump didn't provide the hamcrest-library but should start doing so with
the next run.

Thanks

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Use of org.hamcrest.Matchers

[Gintautas Grigelionis]

Hmm... are you sure that Gump has hamcrest-library? By the looks of it, the
classpath contains antlr 3 and bcel 5...

Gintas

2018-04-22 8:45 GMT+00:00 Stefan Bodewig :

> Hi
>
> when Apache Gump builds Ant it builds it against Hamcrest 2.x which used
> to work fine as long as we didn't use many matchers. It looks as if one
> of the breaking changes introduced with Hamcrest 2.x is the removal of
> the Matchers class. See
>
> http://vmgump-vm3.apache.org/ant/dist-ant/gump_work/build_
> ant_dist-ant.html
>
> I know we stopped monitoring Gump builds a long time ago and changing
> the code to adapt to breaking changes in other libraries feels strange,
> but would anybod mind if I changed the imports to ones that should work
> with both Hamcrest 1.x and 2.x? I.e. replace
>
> import static org.hamcrest.Matchers.containsString;
>
> with
>
> import static org.hamcrest.core.StringContains.containsString;
>
> ?
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>