3.0.1 was a long time ago!
All the parsing code goes through RDFParser whichever API route you try.
RDFParser.fromString(validRDFPost)
.base("http://base";)
.lang(RDFPOST)
.parse(parsed);
The code needs to read URLs and provide control of the HTTP connection
to be used so the user can setup whatever HTTP interaction they need.
That's HttpClient - the built-in networking isn't very easy to provide
per-connection controls.
HttpClient is null.
Don't exclude HttpClient.
There isn't a common abstraction acorss HTTP libraries.
I have had a go at switching all network interaction to using
java.net.http (Java11-onwards). As Jena currently uses HttPClient v4,
and the v5 interfaces are quite different change was eventually coming
anyway.
But obv - Java11.
https://github.com/afs/jena-http
Andy
On 26/03/2020 23:11, Martynas Jusevičius wrote:
> Thanks.
>
> I'm trying 3.14.0 for now. Refactored RDFPostReader without much
> trouble, but now I get
>
> java.lang.NoClassDefFoundError: org/apache/http/client/HttpClient
> at org.apache.jena.riot.RDFParser.create(RDFParser.java:114)
>
> because RDFParser now has a field of type HttpClient :/ I guess it
> didn't in 3.0.1.
>
> I had excluded HTTP Client because Core is using Jersey Client:
>
> <dependency>
> <groupId>org.apache.jena</groupId>
> <artifactId>jena-arq</artifactId>
> <version>3.14.0</version>
> <exclusions>
> <exclusion>
> <groupId>org.apache.httpcomponents</groupId>
> <artifactId>httpclient</artifactId>
> </exclusion>
> <exclusion>
> <groupId>org.apache.httpcomponents</groupId>
> <artifactId>httpclient-cache</artifactId>
> </exclusion>
> </exclusions>
> </dependency>
>
> This makes me wonder why the parsers/writers are dealing directly with
> HTTP. I already had this problem with the JsonLDWriter:
>
https://mail-archives.apache.org/mod_mbox/jena-users/201712.mbox/%3ccae35vmygk-biq1fayp3zooyimikzhvja8dtuged3jayr98u...@mail.gmail.com%3e
>
> Not sure how to proceed.
>
