On 09/06/15 16:26, aj...@virginia.edu wrote:
Okay, now I get why we're sticking with shading in Guava, at least
for now (since this seems like the kind of problem that OSGi solves
and hopefully Jigsaw will solve).
Are there objections to ejecting shaded Guava from the main dev
effort into its own orbit? Or is there a dev cycle associated to the
main one that makes sense as a home for Guava?
I don't mind either way - doesn't seem like a clear cut right or wrong.
Currently, we have a single build and it produces a single consistent
cut of versions (e.g. the binary distribution includes dependencies).
jena-shade-guava is the same version as main jena version.
One release vote.
How often does Guava versions change?
16,17,18 were close together (a few months) but 18, the latest, was Aug
2014.
Andy
--- A. Soroka The University of Virginia Library
On Jun 8, 2015, at 3:11 PM, Andy Seaborne a...@apache.org wrote:
Hadoop/Elephas is an example of a general problem with Guava. By
reputation, upgrading Guava across versions has been problematic -
subtle and not-so-subtle changes of behaviour or removed code.
When Jena is used as a library, the system or application in which
it is used might use Guava itself - and need a specific version.
But Jena uses Guava and needs a specific version with certain code
in it, which might be different.
We are isolating Jena's use of Guava from the system in which Jena
is used. Hadoop's have very strong requirements on Guava versions
- it might well apply to other user applications as well.
We do exclude/ in the sense that dependency-reduced-pom.xml POM
of jena-shared-guava does not mention com.google.guava:guava.
Elephas picks up the Hadoop dependency.
Andy
On 08/06/15 14:26, aj...@virginia.edu wrote:
I think the idea of breaking the shaded Guava artifact out of
the main cycle is great. It's clearly not a subject of work
under most circumstances and having one less moving part in a
developer's mix is usually a good thing, especially for the
simple-minded ({raises hand}).
Is it only Hadoop's Guava that is at issue? Would it be possible
perhaps to just exclude/ Guava from the Hadoop dependencies in
Elephas? Or does that blow up Hadoop? Or should I go experiment
and find out?
--- A. Soroka The University of Virginia Library
On Jun 8, 2015, at 9:21 AM, Andy Seaborne a...@apache.org
wrote:
Ah right. To summarise what is happening:
The POM file in the maven repo is not the POM file in git.The
shade plugin produces a different POM for the the output
artifact with the shaded dependency removed.
When the project is not open, Eclipse sees the reduced POM,
which does not have a dependency on Google Guava.
When the module jena-shaded-guava is open in Eclipse, Eclipse
sees the POM in the module source which names the dependent
Google Guava in a dependency.
Result: a certain degree of chaos.
Andy
On 06/06/15 03:19, Stian Soiland-Reyes wrote:
Yes, you would need to keep the jena-guava project closed so
you get the Maven-built shaded jar on the classpath, which
has the shaded package name, otherwise you will just see the
upstream Guava through Eclipse's project sharing.
The package name is not shaded for OSGi, it is easy to define
private packages there. It is shaded to avoid duplicate
version mismatches against other dependencies with the real
guava, e.g. Hadoop which as you know has an ancient Guava.
It might be good to keep it out of the normal build/release
cycle, then you would get the jena-guava shade from Maven
central, which should only change when we upgrade Guava, in
which case it could be re-enabled in the SNAPSHOT build or
vote+released as a separate artifact (which might be slightly
odd as it contains no Jena contributions beyond the package
name) On 4 Jun 2015 14:33, aj...@virginia.edu
aj...@virginia.edu wrote:
I have had this problem since I began tinkering. The only
solution I have found is make sure that the
jena-shaded-guava project is never open when any project
that refers to types therein is open. This isn't much of a
burden, and I suppose it has something to do with the Maven
magic that is going on inside jena-shaded-guava.
I'm not totally clear as to why Jena shades Guava into its
own namespace-- is it to avoid OSGi-exporting Guava
packages? (We have something like that going on in another
project on which I work.)
--- A. Soroka The University of Virginia Library
On Jun 4, 2015, at 9:22 AM, Rob Vesse
rve...@dotnetrdf.org wrote:
Folks
Recently I've been having a lot of trouble getting Jena
to build in
Eclipse
which seems to be due to the use of the Shade plugin to
Shade Guava. Any module that has a reference to the
shaded classes ends refuses to build
with
various variations of the following error:
java.lang.NoClassDefFoundError:
org/apache/jena/ext/com/google/common/cache/RemovalNotification
Anybody else been having this issue? If so how did you resolve it?
Sometimes cleaning my workspace and/or doing a
