Here's another way to look at this: If it's necessary for the binary distro to include dependencies (which makes a lot of sense) isn't that a job for Maven, not Git? In other words, since Guava is not _really_ a part of Jena's codebase, but a part of its dependencies, isn't it perfectly appropriate for its versioning to be independent and its management to occur via Maven?
To Andy's point about the timing of the various versions of Guava, I offer another question: is Jena repeatedly releasing an artifact (shaded Guava) with a different version number and exactly the same content? --- A. Soroka The University of Virginia Library On Jun 12, 2015, at 4:57 AM, Stian Soiland-Reyes <[email protected]> wrote: > 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
