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 <[email protected]> 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, "[email protected]" <[email protected]> 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 <[email protected]> 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 mvn package at the command
>>>> line seems to help but other times it doesn't
>>>>
>>>> Rob
>>>>
>>>>
>>>>
>>>
>>>
>>
>
