You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Andy Seaborne <an...@apache.org> on 2016/05/11 11:13:59 UTC
Updating dependency versions
Updating the versions of httpclient and httpcore seems to work but there
are a lot of deprecation warnings.
https://github.com/afs/jena/tree/version-upgrades
(no real testing done)
Are there other dependencies we should update?
Any plugins?
Andy
Re: Updating dependency versions
Posted by "A. Soroka" <aj...@virginia.edu>.
Okay, this all makes sense to me. I wasn't going to make this kind of break without a check-in. I'll wait for your commit and then move on with an HttpOp and (new) HttpClientMaker approach. I think packing the client-building API into HttpOp alongside all the operations would be convenient for some folks, but a bit confusing for many others.
---
A. Soroka
The University of Virginia Library
> On May 17, 2016, at 6:51 AM, Andy Seaborne <an...@apache.org> wrote:
>
> What the authentication support provides is a way for the app to setup the environment have HttpOp act on it. Often, the app is not itself dealing with HttpOp, only indirectly via varous ARQ remote operations.
>
> Yes - this may break existing code but I suspect rarely if at all.
>
> The choice seems to be stick with the deprecated HttpClient classes or make some kind of break.
>
> For the majority of auth uses though I am assuming it is "setup the auth in the environment" and use ARQ. This should not need to change.
>
>
> yes - at he moment, authentication is late in the game - too late for the new httpClient API.
>
> I think we need to make Jena API change and break the idea we can modify an HttpClient.
>
> This splits HttpOp into two separate parts: all the calls that take a HttpClient, but not HttpAuthenticator (these are all the calls that are performing the operation on the HttpClient unchanged, and some code to create HttpClients with, optionally, authentication. Indeed, they could be two classes, HttpOp and HttpClientMaker.
>
> HttpClientMaker has operations that takes a HttpClientBuilder and the HttpAuthenticator. If there is one that is make(HttpAuthenticator) using the default builder, the app needs to chnage by write two lines: make HttpClient, call HttpOp, where it was one.
>
> HttpClient hc = HttpClientMaker.make(HttpAuthenticator) ;
> HttpOp.....(hc, ...)
>
>
>
> The internal "exec" becomes simpler.
>
> private static void exec(String url, HttpUriRequest request,
> String acceptHeader,
> HttpResponseHandler handler,
> HttpClient httpClient,
> HttpContext httpContext) {
>
> a first step is to move the auth stuff first and:
>
> private static void exec(String url, HttpUriRequest request,
> String acceptHeader,
> HttpResponseHandler handler,
> HttpClient httpClient,
> HttpContext httpContext,
> HttpAuthenticator authenticator) {
> httpClient = ensureClient(httpClient, authenticator);
> httpContext = ensureContext(httpContext);
> applyAuthentication(asAbstractClient(httpClient), url,
> httpContext, authenticator);
> exec(url, request, acceptHeader, handler,
> httpClient, httpContext);
> }
>
> [As I happen to have done that change locally to check it, I'll commit it anyway.]
>
>
> Andy
>
> On 16/05/16 17:29, A. Soroka wrote:
>> Okay, coming back with a quick design question. The current type for
>> authentication (o.a.j.atlas.web.auth.HttpAuthenticator), works via
>> the following signature:
>>
>> public void apply(AbstractHttpClient client, HttpContext httpContext,
>> URI target);
>>
>> The idea here (IIUC) is to apply authentication to an _extant_ HTTP
>> client, context and URI. The problem for option 2 is that this is
>> pretty late in the game, obviously later than client construction.
>> Is the idea to bake in the HttpAuthenticator as part of the
>> (immutable) state of a subclass of o.a.h.c.HttpClient that
>> automatically applies the behavior at request execution? That tangles
>> Jena and o.a.http.client types in a way that seems to me to be a bit
>> odd, but my sense of Jena's idiom is pretty undeveloped. Just want to
>> make sure I am on the right road. It would mean altering
>> FormsAuthenticator to factor cookies out of the client into the
>> context, and that means an HttpClientContext, so we'd end up with
>> something like:
>>
>> public void apply(HttpClient client, HttpClientContext httpContext,
>> URI target);
>>
>> which would break HttpAuthenticator impls out there in the world, but
>> not horrifically. It would also mean that the client in that
>> signature would have immutable state going forward, and that has more
>> potential, I think, to break impls, but anyone doing a custom
>> authenticator should also be able to factor that state out of the
>> client into the context like I describe above.
>>
>> --- A. Soroka The University of Virginia Library
>>
>>> On May 15, 2016, at 8:33 AM, Andy Seaborne <an...@apache.org>
>>> wrote:
>>>
>>> On 11/05/16 16:38, A. Soroka wrote:
>>>> I recently did some work on a project for those exact
>>>> deprecation warnings (introducing HttpClientBuilder). I would be
>>>> happy to take a crack at those if you want to make me a ticket. I
>>>> don't remember it being too hairy.
>>>
>>> https://issues.apache.org/jira/browse/JENA-576
>>>
>>> The uprade looks easy but there is one area
>>>
>>> In the old API http-client, authentication is done by modifying the
>>> HttpClient object. In the new API, HttpClient (CloseableHttpClient)
>>> is immutable and chnages need to be made at the HttpClientBuilder
>>> stage.
>>>
>>> That impacts the HttpOp interface - some functions are of the form
>>> HttpClient+HttpAuthenticator. And the public alls all go to one
>>> operation that takes HttpClient+HttpAuthenticator.
>>>
>>> So I think (I have not tried) the forms:
>>>
>>> 1/ operation(HttpClient, ....) // No auth unless already in
>>> HttpClient operation(HttpClientBuilder, HttpAuthenticator, ....)
>>>
>>> i.e. HttpClientBuilder if HttpAuthenticator
>>>
>>> 2/ Or move the creation/setup of authentication out of the
>>> operations call flow and provide creator operations.
>>>
>>> Remove all operation(HttpClient, HttpAuthenticator, ....)
>>>
>>> and have
>>>
>>> HttpClient hc
>>>
>>> hc = createHttpClient(HttpAuthenticator, ....) // default
>>> builder. hc = createHttpClient(HttpClientBuilder,
>>> HttpAuthenticator, ....)
>>>
>>> i.e. separate creation and auth setup.
>>>
>>> This, to me, looks more in tune with the new API
>>>
>>> 3/ Stick to the deprecated AbstractHttpClient style.
>>>
>>>
>>> ATM I favour (2). We don't preserve exact current HttpOp API in
>>> (1) or (2) so let's do the better design. 3.2.0 if necessary (but
>>> I don't believe that rigid semantic versions makes sense in large
>>> system with semi-independent sub-systems; version number changes
>>> when many users aren't affected can be more confusion than help;
>>> "semantic version" is a guidance not a rule).
>>>
>>> Andy
>>
>
Re: Updating dependency versions
Posted by Andy Seaborne <an...@apache.org>.
What the authentication support provides is a way for the app to setup
the environment have HttpOp act on it. Often, the app is not itself
dealing with HttpOp, only indirectly via varous ARQ remote operations.
Yes - this may break existing code but I suspect rarely if at all.
The choice seems to be stick with the deprecated HttpClient classes or
make some kind of break.
For the majority of auth uses though I am assuming it is "setup the auth
in the environment" and use ARQ. This should not need to change.
yes - at he moment, authentication is late in the game - too late for
the new httpClient API.
I think we need to make Jena API change and break the idea we can modify
an HttpClient.
This splits HttpOp into two separate parts: all the calls that take a
HttpClient, but not HttpAuthenticator (these are all the calls that are
performing the operation on the HttpClient unchanged, and some code to
create HttpClients with, optionally, authentication. Indeed, they could
be two classes, HttpOp and HttpClientMaker.
HttpClientMaker has operations that takes a HttpClientBuilder and the
HttpAuthenticator. If there is one that is make(HttpAuthenticator)
using the default builder, the app needs to chnage by write two lines:
make HttpClient, call HttpOp, where it was one.
HttpClient hc = HttpClientMaker.make(HttpAuthenticator) ;
HttpOp.....(hc, ...)
The internal "exec" becomes simpler.
private static void exec(String url, HttpUriRequest request,
String acceptHeader,
HttpResponseHandler handler,
HttpClient httpClient,
HttpContext httpContext) {
a first step is to move the auth stuff first and:
private static void exec(String url, HttpUriRequest request,
String acceptHeader,
HttpResponseHandler handler,
HttpClient httpClient,
HttpContext httpContext,
HttpAuthenticator authenticator) {
httpClient = ensureClient(httpClient, authenticator);
httpContext = ensureContext(httpContext);
applyAuthentication(asAbstractClient(httpClient), url,
httpContext, authenticator);
exec(url, request, acceptHeader, handler,
httpClient, httpContext);
}
[As I happen to have done that change locally to check it, I'll commit
it anyway.]
Andy
On 16/05/16 17:29, A. Soroka wrote:
> Okay, coming back with a quick design question. The current type for
> authentication (o.a.j.atlas.web.auth.HttpAuthenticator), works via
> the following signature:
>
> public void apply(AbstractHttpClient client, HttpContext httpContext,
> URI target);
>
> The idea here (IIUC) is to apply authentication to an _extant_ HTTP
> client, context and URI. The problem for option 2 is that this is
> pretty late in the game, obviously later than client construction.
> Is the idea to bake in the HttpAuthenticator as part of the
> (immutable) state of a subclass of o.a.h.c.HttpClient that
> automatically applies the behavior at request execution? That tangles
> Jena and o.a.http.client types in a way that seems to me to be a bit
> odd, but my sense of Jena's idiom is pretty undeveloped. Just want to
> make sure I am on the right road. It would mean altering
> FormsAuthenticator to factor cookies out of the client into the
> context, and that means an HttpClientContext, so we'd end up with
> something like:
>
> public void apply(HttpClient client, HttpClientContext httpContext,
> URI target);
>
> which would break HttpAuthenticator impls out there in the world, but
> not horrifically. It would also mean that the client in that
> signature would have immutable state going forward, and that has more
> potential, I think, to break impls, but anyone doing a custom
> authenticator should also be able to factor that state out of the
> client into the context like I describe above.
>
> --- A. Soroka The University of Virginia Library
>
>> On May 15, 2016, at 8:33 AM, Andy Seaborne <an...@apache.org>
>> wrote:
>>
>> On 11/05/16 16:38, A. Soroka wrote:
>>> I recently did some work on a project for those exact
>>> deprecation warnings (introducing HttpClientBuilder). I would be
>>> happy to take a crack at those if you want to make me a ticket. I
>>> don't remember it being too hairy.
>>
>> https://issues.apache.org/jira/browse/JENA-576
>>
>> The uprade looks easy but there is one area
>>
>> In the old API http-client, authentication is done by modifying the
>> HttpClient object. In the new API, HttpClient (CloseableHttpClient)
>> is immutable and chnages need to be made at the HttpClientBuilder
>> stage.
>>
>> That impacts the HttpOp interface - some functions are of the form
>> HttpClient+HttpAuthenticator. And the public alls all go to one
>> operation that takes HttpClient+HttpAuthenticator.
>>
>> So I think (I have not tried) the forms:
>>
>> 1/ operation(HttpClient, ....) // No auth unless already in
>> HttpClient operation(HttpClientBuilder, HttpAuthenticator, ....)
>>
>> i.e. HttpClientBuilder if HttpAuthenticator
>>
>> 2/ Or move the creation/setup of authentication out of the
>> operations call flow and provide creator operations.
>>
>> Remove all operation(HttpClient, HttpAuthenticator, ....)
>>
>> and have
>>
>> HttpClient hc
>>
>> hc = createHttpClient(HttpAuthenticator, ....) // default
>> builder. hc = createHttpClient(HttpClientBuilder,
>> HttpAuthenticator, ....)
>>
>> i.e. separate creation and auth setup.
>>
>> This, to me, looks more in tune with the new API
>>
>> 3/ Stick to the deprecated AbstractHttpClient style.
>>
>>
>> ATM I favour (2). We don't preserve exact current HttpOp API in
>> (1) or (2) so let's do the better design. 3.2.0 if necessary (but
>> I don't believe that rigid semantic versions makes sense in large
>> system with semi-independent sub-systems; version number changes
>> when many users aren't affected can be more confusion than help;
>> "semantic version" is a guidance not a rule).
>>
>> Andy
>
Re: Updating dependency versions
Posted by "A. Soroka" <aj...@virginia.edu>.
Okay, coming back with a quick design question. The current type for authentication (o.a.j.atlas.web.auth.HttpAuthenticator), works via the following signature:
public void apply(AbstractHttpClient client, HttpContext httpContext, URI target);
The idea here (IIUC) is to apply authentication to an _extant_ HTTP client, context and URI. The problem for option 2 is that this is pretty late in the game, obviously later than client construction. Is the idea to bake in the HttpAuthenticator as part of the (immutable) state of a subclass of o.a.h.c.HttpClient that automatically applies the behavior at request execution? That tangles Jena and o.a.http.client types in a way that seems to me to be a bit odd, but my sense of Jena's idiom is pretty undeveloped. Just want to make sure I am on the right road. It would mean altering FormsAuthenticator to factor cookies out of the client into the context, and that means an HttpClientContext, so we'd end up with something like:
public void apply(HttpClient client, HttpClientContext httpContext, URI target);
which would break HttpAuthenticator impls out there in the world, but not horrifically. It would also mean that the client in that signature would have immutable state going forward, and that has more potential, I think, to break impls, but anyone doing a custom authenticator should also be able to factor that state out of the client into the context like I describe above.
---
A. Soroka
The University of Virginia Library
> On May 15, 2016, at 8:33 AM, Andy Seaborne <an...@apache.org> wrote:
>
> On 11/05/16 16:38, A. Soroka wrote:
>> I recently did some work on a project for those exact deprecation
>> warnings (introducing HttpClientBuilder). I would be happy to take a
>> crack at those if you want to make me a ticket. I don't remember it
>> being too hairy.
>
> https://issues.apache.org/jira/browse/JENA-576
>
> The uprade looks easy but there is one area
>
> In the old API http-client, authentication is done by modifying the HttpClient object. In the new API, HttpClient (CloseableHttpClient) is immutable and chnages need to be made at the HttpClientBuilder stage.
>
> That impacts the HttpOp interface - some functions are of the form HttpClient+HttpAuthenticator. And the public alls all go to one operation that takes HttpClient+HttpAuthenticator.
>
> So I think (I have not tried) the forms:
>
> 1/
> operation(HttpClient, ....) // No auth unless already in HttpClient
> operation(HttpClientBuilder, HttpAuthenticator, ....)
>
> i.e. HttpClientBuilder if HttpAuthenticator
>
> 2/
> Or move the creation/setup of authentication out of the operations call flow and provide creator operations.
>
> Remove all
> operation(HttpClient, HttpAuthenticator, ....)
>
> and have
>
> HttpClient hc
>
> hc = createHttpClient(HttpAuthenticator, ....) // default builder.
> hc = createHttpClient(HttpClientBuilder, HttpAuthenticator, ....)
>
> i.e. separate creation and auth setup.
>
> This, to me, looks more in tune with the new API
>
> 3/
> Stick to the deprecated AbstractHttpClient style.
>
>
> ATM I favour (2). We don't preserve exact current HttpOp API in (1) or (2) so let's do the better design. 3.2.0 if necessary (but I don't believe that rigid semantic versions makes sense in large system with semi-independent sub-systems; version number changes when many users aren't affected can be more confusion than help; "semantic version" is a guidance not a rule).
>
> Andy
Re: Updating dependency versions
Posted by "A. Soroka" <aj...@virginia.edu>.
Okay, I'll try going forward with (2) and barring complications, come back with a PR.
---
A. Soroka
The University of Virginia Library
> On May 15, 2016, at 8:33 AM, Andy Seaborne <an...@apache.org> wrote:
>
> On 11/05/16 16:38, A. Soroka wrote:
>> I recently did some work on a project for those exact deprecation
>> warnings (introducing HttpClientBuilder). I would be happy to take a
>> crack at those if you want to make me a ticket. I don't remember it
>> being too hairy.
>
> https://issues.apache.org/jira/browse/JENA-576
>
> The uprade looks easy but there is one area
>
> In the old API http-client, authentication is done by modifying the HttpClient object. In the new API, HttpClient (CloseableHttpClient) is immutable and chnages need to be made at the HttpClientBuilder stage.
>
> That impacts the HttpOp interface - some functions are of the form HttpClient+HttpAuthenticator. And the public alls all go to one operation that takes HttpClient+HttpAuthenticator.
>
> So I think (I have not tried) the forms:
>
> 1/
> operation(HttpClient, ....) // No auth unless already in HttpClient
> operation(HttpClientBuilder, HttpAuthenticator, ....)
>
> i.e. HttpClientBuilder if HttpAuthenticator
>
> 2/
> Or move the creation/setup of authentication out of the operations call flow and provide creator operations.
>
> Remove all
> operation(HttpClient, HttpAuthenticator, ....)
>
> and have
>
> HttpClient hc
>
> hc = createHttpClient(HttpAuthenticator, ....) // default builder.
> hc = createHttpClient(HttpClientBuilder, HttpAuthenticator, ....)
>
> i.e. separate creation and auth setup.
>
> This, to me, looks more in tune with the new API
>
> 3/
> Stick to the deprecated AbstractHttpClient style.
>
>
> ATM I favour (2). We don't preserve exact current HttpOp API in (1) or (2) so let's do the better design. 3.2.0 if necessary (but I don't believe that rigid semantic versions makes sense in large system with semi-independent sub-systems; version number changes when many users aren't affected can be more confusion than help; "semantic version" is a guidance not a rule).
>
> Andy
Re: Updating dependency versions
Posted by Andy Seaborne <an...@apache.org>.
On 11/05/16 16:38, A. Soroka wrote:
> I recently did some work on a project for those exact deprecation
> warnings (introducing HttpClientBuilder). I would be happy to take a
> crack at those if you want to make me a ticket. I don't remember it
> being too hairy.
https://issues.apache.org/jira/browse/JENA-576
The uprade looks easy but there is one area
In the old API http-client, authentication is done by modifying the
HttpClient object. In the new API, HttpClient (CloseableHttpClient) is
immutable and chnages need to be made at the HttpClientBuilder stage.
That impacts the HttpOp interface - some functions are of the form
HttpClient+HttpAuthenticator. And the public alls all go to one
operation that takes HttpClient+HttpAuthenticator.
So I think (I have not tried) the forms:
1/
operation(HttpClient, ....) // No auth unless already in HttpClient
operation(HttpClientBuilder, HttpAuthenticator, ....)
i.e. HttpClientBuilder if HttpAuthenticator
2/
Or move the creation/setup of authentication out of the operations call
flow and provide creator operations.
Remove all
operation(HttpClient, HttpAuthenticator, ....)
and have
HttpClient hc
hc = createHttpClient(HttpAuthenticator, ....) // default builder.
hc = createHttpClient(HttpClientBuilder, HttpAuthenticator, ....)
i.e. separate creation and auth setup.
This, to me, looks more in tune with the new API
3/
Stick to the deprecated AbstractHttpClient style.
ATM I favour (2). We don't preserve exact current HttpOp API in (1) or
(2) so let's do the better design. 3.2.0 if necessary (but I don't
believe that rigid semantic versions makes sense in large system with
semi-independent sub-systems; version number changes when many users
aren't affected can be more confusion than help; "semantic version" is a
guidance not a rule).
Andy
Re: Updating dependency versions
Posted by "A. Soroka" <aj...@virginia.edu>.
Hm, this is interesting. I just made a PR for these bumps, and while doing the usual "mvn clean install" I got the same jena-jdbc-driver-tdb errors I was getting looking at the release candidate! This is using a completely different source base (a git repo, not a downloaded source package) starting from current master with a few version bumps as discussed below. As you wrote, Andy, I see absolutely nothing in the git history that would account for this.
I'm thinking now that this must be some kind of really weird problem with my machine, which is sad for me, but not Jena's problem.
---
A. Soroka
The University of Virginia Library
> On May 11, 2016, at 12:21 PM, Andy Seaborne <an...@apache.org> wrote:
>
> On 11/05/16 16:38, A. Soroka wrote:
>> I recently did some work on a project for those exact deprecation warnings (introducing HttpClientBuilder). I would be happy to take a crack at those if you want to make me a ticket. I don't remember it being too hairy.
>>
>> Looking at the output of mvn versions:display-dependency-updates, a couple of examples:
>>
>> com.jayway.awaitility:awaitility ...................... 1.6.4 -> 1.7.0
>> com.spatial4j:spatial4j ................................. 0.4.1 -> 0.5
>> org.apache.lucene:* ......................... 4.9.1 -> 6.0.0
>> org.apache.solr:solr-solrj ............................ 4.9.1 -> 6.0.0
>> org.slf4j:* ............................ 1.7.20 -> 1.7.21
>> commons-codec:commons-codec .............................. 1.9 -> 1.10
>> org.apache.commons:commons-collections4 ................... 4.0 -> 4.1
>> org.apache.commons:commons-csv ............................ 1.0 -> 1.3
>> org.apache.commons:commons-lang3 ........................ 3.3.2 -> 3.4
>> org.apache.thrift:libthrift ........................... 0.9.2 -> 0.9.3
>> org.apache.mrunit:mrunit .............................. 1.0.0 -> 1.1.0
>> org.apache.hadoop:* ....................... 2.6.0 -> 2.7.2
>> com.github.rvesse:* ............................. 2.1.0 -> 2.1.1
>
>
>>
>> I know that the big major-version jumps in large frameworks can be
>> dicey and require some real thought, but would you like a PR for some
>> of these minor or micro jumps?
>
> Yes. that would be good.
>
> They look OK except
>
> > org.apache.lucene:* ......................... 4.9.1 -> 6.0.0
> > org.apache.solr:solr-solrj ............................ 4.9.1 -> 6.0.0
>
> These two need care as disk formats may have changed.
>
> > org.apache.hadoop:* ....................... 2.6.0 -> 2.7.2
>
> IIRC This is a major, major thing. (Rob isn't around at the moment and I think it'll have to wait.)
>
> and
>
> > org.apache.mrunit:mrunit .............................. 1.0.0 -> 1.1.0
>
> If that fixes the occasional download issues, I will be very happy! I'm guessing that the 1.0.0 files on central are on bad storage.
>
> Andy
>
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>> On May 11, 2016, at 7:13 AM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>> Updating the versions of httpclient and httpcore seems to work but there are a lot of deprecation warnings.
>>>
>>> https://github.com/afs/jena/tree/version-upgrades
>>>
>>> (no real testing done)
>>>
>>> Are there other dependencies we should update?
>>> Any plugins?
>>>
>>> Andy
>>
>
Re: Updating dependency versions
Posted by "A. Soroka" <aj...@virginia.edu>.
Yeah, I've tried to mess with bumping Hadoop before and it was not a good use of anyone's time, so I'll keep my grubby mitts off it.
I'll put together a tightly-scoped package of minor/micro bumps leaving out Hadoop and Lucene. If you could make me a ticket, I would appreciate that.
---
A. Soroka
The University of Virginia Library
> On May 11, 2016, at 12:21 PM, Andy Seaborne <an...@apache.org> wrote:
>
> On 11/05/16 16:38, A. Soroka wrote:
>> I recently did some work on a project for those exact deprecation warnings (introducing HttpClientBuilder). I would be happy to take a crack at those if you want to make me a ticket. I don't remember it being too hairy.
>>
>> Looking at the output of mvn versions:display-dependency-updates, a couple of examples:
>>
>> com.jayway.awaitility:awaitility ...................... 1.6.4 -> 1.7.0
>> com.spatial4j:spatial4j ................................. 0.4.1 -> 0.5
>> org.apache.lucene:* ......................... 4.9.1 -> 6.0.0
>> org.apache.solr:solr-solrj ............................ 4.9.1 -> 6.0.0
>> org.slf4j:* ............................ 1.7.20 -> 1.7.21
>> commons-codec:commons-codec .............................. 1.9 -> 1.10
>> org.apache.commons:commons-collections4 ................... 4.0 -> 4.1
>> org.apache.commons:commons-csv ............................ 1.0 -> 1.3
>> org.apache.commons:commons-lang3 ........................ 3.3.2 -> 3.4
>> org.apache.thrift:libthrift ........................... 0.9.2 -> 0.9.3
>> org.apache.mrunit:mrunit .............................. 1.0.0 -> 1.1.0
>> org.apache.hadoop:* ....................... 2.6.0 -> 2.7.2
>> com.github.rvesse:* ............................. 2.1.0 -> 2.1.1
>
>
>>
>> I know that the big major-version jumps in large frameworks can be
>> dicey and require some real thought, but would you like a PR for some
>> of these minor or micro jumps?
>
> Yes. that would be good.
>
> They look OK except
>
> > org.apache.lucene:* ......................... 4.9.1 -> 6.0.0
> > org.apache.solr:solr-solrj ............................ 4.9.1 -> 6.0.0
>
> These two need care as disk formats may have changed.
>
> > org.apache.hadoop:* ....................... 2.6.0 -> 2.7.2
>
> IIRC This is a major, major thing. (Rob isn't around at the moment and I think it'll have to wait.)
>
> and
>
> > org.apache.mrunit:mrunit .............................. 1.0.0 -> 1.1.0
>
> If that fixes the occasional download issues, I will be very happy! I'm guessing that the 1.0.0 files on central are on bad storage.
>
> Andy
>
>>
>> ---
>> A. Soroka
>> The University of Virginia Library
>>
>>> On May 11, 2016, at 7:13 AM, Andy Seaborne <an...@apache.org> wrote:
>>>
>>> Updating the versions of httpclient and httpcore seems to work but there are a lot of deprecation warnings.
>>>
>>> https://github.com/afs/jena/tree/version-upgrades
>>>
>>> (no real testing done)
>>>
>>> Are there other dependencies we should update?
>>> Any plugins?
>>>
>>> Andy
>>
>
Re: Updating dependency versions
Posted by Andy Seaborne <an...@apache.org>.
On 11/05/16 16:38, A. Soroka wrote:
> I recently did some work on a project for those exact deprecation warnings (introducing HttpClientBuilder). I would be happy to take a crack at those if you want to make me a ticket. I don't remember it being too hairy.
>
> Looking at the output of mvn versions:display-dependency-updates, a couple of examples:
>
> com.jayway.awaitility:awaitility ...................... 1.6.4 -> 1.7.0
> com.spatial4j:spatial4j ................................. 0.4.1 -> 0.5
> org.apache.lucene:* ......................... 4.9.1 -> 6.0.0
> org.apache.solr:solr-solrj ............................ 4.9.1 -> 6.0.0
> org.slf4j:* ............................ 1.7.20 -> 1.7.21
> commons-codec:commons-codec .............................. 1.9 -> 1.10
> org.apache.commons:commons-collections4 ................... 4.0 -> 4.1
> org.apache.commons:commons-csv ............................ 1.0 -> 1.3
> org.apache.commons:commons-lang3 ........................ 3.3.2 -> 3.4
> org.apache.thrift:libthrift ........................... 0.9.2 -> 0.9.3
> org.apache.mrunit:mrunit .............................. 1.0.0 -> 1.1.0
> org.apache.hadoop:* ....................... 2.6.0 -> 2.7.2
> com.github.rvesse:* ............................. 2.1.0 -> 2.1.1
>
> I know that the big major-version jumps in large frameworks can be
> dicey and require some real thought, but would you like a PR for some
> of these minor or micro jumps?
Yes. that would be good.
They look OK except
> org.apache.lucene:* ......................... 4.9.1 -> 6.0.0
> org.apache.solr:solr-solrj ............................ 4.9.1 -> 6.0.0
These two need care as disk formats may have changed.
> org.apache.hadoop:* ....................... 2.6.0 -> 2.7.2
IIRC This is a major, major thing. (Rob isn't around at the moment and
I think it'll have to wait.)
and
> org.apache.mrunit:mrunit .............................. 1.0.0 -> 1.1.0
If that fixes the occasional download issues, I will be very happy! I'm
guessing that the 1.0.0 files on central are on bad storage.
Andy
>
> ---
> A. Soroka
> The University of Virginia Library
>
>> On May 11, 2016, at 7:13 AM, Andy Seaborne <an...@apache.org> wrote:
>>
>> Updating the versions of httpclient and httpcore seems to work but there are a lot of deprecation warnings.
>>
>> https://github.com/afs/jena/tree/version-upgrades
>>
>> (no real testing done)
>>
>> Are there other dependencies we should update?
>> Any plugins?
>>
>> Andy
>
Re: Updating dependency versions
Posted by "A. Soroka" <aj...@virginia.edu>.
I recently did some work on a project for those exact deprecation warnings (introducing HttpClientBuilder). I would be happy to take a crack at those if you want to make me a ticket. I don't remember it being too hairy.
Looking at the output of mvn versions:display-dependency-updates, a couple of examples:
com.jayway.awaitility:awaitility ...................... 1.6.4 -> 1.7.0
com.spatial4j:spatial4j ................................. 0.4.1 -> 0.5
org.apache.lucene:* ......................... 4.9.1 -> 6.0.0
org.apache.solr:solr-solrj ............................ 4.9.1 -> 6.0.0
org.slf4j:* ............................ 1.7.20 -> 1.7.21
commons-codec:commons-codec .............................. 1.9 -> 1.10
org.apache.commons:commons-collections4 ................... 4.0 -> 4.1
org.apache.commons:commons-csv ............................ 1.0 -> 1.3
org.apache.commons:commons-lang3 ........................ 3.3.2 -> 3.4
org.apache.thrift:libthrift ........................... 0.9.2 -> 0.9.3
org.apache.mrunit:mrunit .............................. 1.0.0 -> 1.1.0
org.apache.hadoop:* ....................... 2.6.0 -> 2.7.2
com.github.rvesse:* ............................. 2.1.0 -> 2.1.1
I know that the big major-version jumps in large frameworks can be dicey and require some real thought, but would you like a PR for some of these minor or micro jumps?
---
A. Soroka
The University of Virginia Library
> On May 11, 2016, at 7:13 AM, Andy Seaborne <an...@apache.org> wrote:
>
> Updating the versions of httpclient and httpcore seems to work but there are a lot of deprecation warnings.
>
> https://github.com/afs/jena/tree/version-upgrades
>
> (no real testing done)
>
> Are there other dependencies we should update?
> Any plugins?
>
> Andy