Agreed - this is kind of what I meant when I was unsure about which version jena-shaded-guava/pom.xml should have. It would make more sense for it to match the shaded guava and have its own release cycle - which would also take it out of the Eclipse question, as it would just be a binary JAR (just like the upstream guava it wraps).
You can always propose the release of the new guava as part of the jena release - even if you actually build them separately. What is confusing is that jena-shaded-guava is not meant to be used on its own.. it is as you say something OSGi has solved already, but Jena does not mandate use of OSGi (and I don't think it should - at least not at API level). I think the way forward would be separating out jena-shaded-guava to a jena-exts repository or something similar - or minimally keeping it in the same git repository, but in a folder that is not involved from the master pom.xml. I think this would be clean build-wise, release-wise and Maven-wise. The perhaps confusing bit is the source releases then.. so you would have to download and build jena-exts first - but really can't (should not!) use it on its own. It is also not really a source, as it would just repackage existing binaries.. so it's dubious also by that fact. We can always include the actual guava source - but that would imply a fork, which it isn't (beyond changing package names). On 12 June 2015 at 02:01, [email protected] <[email protected]> wrote: > I work on other projects for which we separate the lifecycles of the main > product and ancillary or supporting products (e.g. configuration for > Checkstyles) and it works well so long as: > > 1) The "sidecar" artifacts are available from Maven Central or an appropriate > more specific repository. This avoids any annoying "double-build" situations. > > 2) The cost of building/publishing the "sidecar" artifacts is low. This is > because it's done less frequently and therefore less expertise develops in > the community about doing it. > > As always in dev workflows, YMMV, but shaded Guava does seem to me like a > good candidate. If the conversation about project code style picks up again > (and I will be trying to move that forward in a message tomorrow) then > artifacts related thereto might also be good candidates. > > --- > A. Soroka > The University of Virginia Library > > On Jun 10, 2015, at 5:47 AM, Andy Seaborne <[email protected]> wrote: > >> On 09/06/15 16:26, [email protected] 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 <[email protected]> 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, [email protected] 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 <[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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
