I was responding to "or Java 8 itself"
On 06/04/17 16:38, A. Soroka wrote:
No, I didn't mean LinkedHashMap. That's why I said "But other than that, "
about caching. I'm saying that caching is the one thing that I can think of that is
really truly substantive that we are getting from Guava.
There is a Commons caching component:
https://commons.apache.org/proper/commons-jcs//
But I know nothing (yet) about it. It looks like it is targeted a bit
differently.
---
A. Soroka
The University of Virginia Library
On Apr 6, 2017, at 11:34 AM, Andy Seaborne <[email protected]> wrote:
Java8 caching - which I take to mean LinkedHashMap was what TDB used to use and
changed away from. It really isn't sophisticated enough.
I'm not going to rework it all again. Any change has to be better, not just
equivalent, let alone needing a bunch of machinery around it.
Andy
On 06/04/17 16:19, A. Soroka wrote:
Lost this thread for a while, but found it again!
For comparison with Andy's lists below, the Jena Karaf feature calls out:
com.github.andrewoma.dexx/collection
com.github.jsonld-java/jsonld-java
com.fasterxml.jackson.core/jackson-core
com.fasterxml.jackson.core/jackson-databind
com.fasterxml.jackson.core/jackson-annotations
org.apache.httpcomponents/httpcore-osgi
org.apache.httpcomponents/httpclient-osgi
org.apache.commons/commons-csv
org.apache.commons/commons-lang3
commons-io/commons-io
org.apache.thrift/libthrift
Which isn't too surprising. That seems like a pretty reasonable baseline for
our core functionality. Obviously, Fuseki needs to add some stuff to that, as
does the CLI gear.
The caching question is a big one-- that's clearly pretty important
functionality. But other than that, my (very loose and barely informed) sense
is that we aren't using much from Guava that we couldn't get from Commons
libraries or Java 8 itself.
---
A. Soroka
The University of Virginia Library
On Apr 2, 2017, at 11:05 AM, Andy Seaborne <[email protected]> wrote:
On 02/04/17 15:08, A. Soroka wrote:
I’m not sure that it is necessarily safe to stop shading Guava. It is a widely
used library with poor compatibility between versions and our users may
experience Version conflicts in other environments.
I've not got a good notion right now of how heavy our dependency is on Guava
(although I know I have increased it myself by using it various places!)
Does it seem (for the long term) worth investigating the possibilities of
moving off Guava entirely?
Is it more nuanced than that? I have been using Guava's caching whenever I need
a cache. There are other possibilities. (Commons JCS,
commons-collections4#map.LRUMap
Can we agree on what we consider the base dependencies (commons-lang3,
commons-io, commons-codec etc)?
Andy
Mentions in POMs for commons-*
== jena-parent
commons-cli
commons-codec
commons-collections4
commons-csv
commons-fileupload
commons-io
commons-lang3
== jena-fuseki1
commons-io
commons-logging
commons-fileupload
== jena-core
commons-cli
== jena-permissions
commons-collections4
commons-lang3
== jena-text
commons-codec
== jena-fuseki-core
commons-logging
commons-fileupload
commons-io
== jena-arq
commons-csv
commons-lang3
== jena-base
commons-csv
commons-lang3
== jena-osgi/pom.xml
commons-codec
commons-csv
commons-lang3
**** Excluded:
commons-logging
---
A. Soroka
The University of Virginia Library
On Mar 31, 2017, at 9:34 AM, Rob Vesse <[email protected]> wrote:
Yes that would be a good idea
You should just be able to change a single property and see if it Will compile.
See the instructions on the website:
http://jena.apache.org/documentation/hadoop/artifacts.html
Rob
On 31/03/2017 13:57, "A. Soroka" <[email protected]> wrote:
So for next steps, should someone (aka me) try to build against a 3.X Hadoop
to see where the jolts are? Does that make sense as a way to gather more info?
I would just go ahead and do it, but lacking (as I do) any Hadoop dev
experience, I want to make sure that it's a good idea before investing time.
---
A. Soroka
The University of Virginia Library
On Mar 31, 2017, at 5:11 AM, Rob Vesse <[email protected]> wrote:
My impression is that 3.0 is still a long way off a generally available release
since they are still in Alpha at the moment.
I would expect that 2.x would remain the primary distribution for a while yet.
I don’t know how much, If at all, map/reduce has changed so it may already be
possible to build Elephas against 3.X without any changes but then again it
might not.
I’m not sure that it is necessarily safe to stop shading Guava. It is a widely
used library with poor compatibility between versions and our users may
experience Version conflicts in other environments.
Rob
On 29/03/2017 00:18, "Bruno P. Kinoshita" <[email protected]> wrote:
I would think we could go with a minor version for this, no? Or is
Elephas such a big part of our offering that we need to make a major
release to move with Hadoop...?
I would think the same. Unless we have other important features to be released,
maybe something that breaks backward compatibility, etc.
________________________________
From: A. Soroka <[email protected]>
To: [email protected]
Sent: Wednesday, 29 March 2017 3:20 AM
Subject: Re: [jira] [Updated] (HADOOP-10101) Update guava dependency to the
latest version
* Jena would have to move in step with Hadoop and drop support for older
versions.
Maybe we can see what Hadoop itself ends up doing for this problem... they are
targeting their own major release 3 for this. I would think we could go with a
minor version for this, no? Or is Elephas such a big part of our offering that
we need to make a major release to move with Hadoop...?
---
A. Soroka
The University of Virginia Library
On Mar 25, 2017, at 7:15 AM, Andy Seaborne <[email protected]> wrote:
Step 1: upgrade jena-shaded-guava to v21.0
and see if it works.
There are at least two considerations:
* Jena would have to move in step with Hadoop
and drop support for older versions.
* Our downstream users may have guava version choices.
and we have to wait until a Hadoop release to remove it.
Andy
On 25/03/17 01:22, A. Soroka wrote:
Looks like Hadoop has successfully updated their Guava dependency-- this might
provide us the opportunity to stop shading Guava. (yay!)
---
A. Soroka
The University of Virginia Library
Begin forwarded message:
From: "Tsuyoshi Ozawa (JIRA)" <[email protected]>
Subject: [jira] [Updated] (HADOOP-10101) Update guava dependency to the latest
version
Date: March 24, 2017 at 9:18:42 PM EDT
To: [email protected]
[
https://issues.apache.org/jira/browse/HADOOP-10101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tsuyoshi Ozawa updated HADOOP-10101:
------------------------------------
Resolution: Fixed
Fix Version/s: 3.0.0-alpha3
Status: Resolved (was: Patch Available)
Committed this to trunk. Thanks Nicholas and Steve for your review, and thanks
people who joined this issue for your comments.
Update guava dependency to the latest version
---------------------------------------------
Key: HADOOP-10101
URL: https://issues.apache.org/jira/browse/HADOOP-10101
Project: Hadoop Common
Issue Type: Improvement
Affects Versions: 3.0.0-alpha2
Reporter: Rakesh R
Assignee: Tsuyoshi Ozawa
Labels: BB2015-05-TBR
Fix For: 3.0.0-alpha3
Attachments: HADOOP-10101-002.patch, HADOOP-10101-004.patch,
HADOOP-10101-005.patch, HADOOP-10101-006.patch, HADOOP-10101-007.patch,
HADOOP-10101-008.patch, HADOOP-10101-009.patch, HADOOP-10101-009.patch,
HADOOP-10101-010.patch, HADOOP-10101-010.patch, HADOOP-10101-011.patch,
HADOOP-10101.012.patch, HADOOP-10101.013.patch, HADOOP-10101.014.patch,
HADOOP-10101.015.patch, HADOOP-10101.016.patch, HADOOP-10101.017.patch,
HADOOP-10101.018.patch, HADOOP-10101.patch, HADOOP-10101.patch
The existing guava version is 11.0.2 which is quite old. This issue tries to
update the version to as latest version as possible.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
