+1, It makes sense for the shaded Guava to have same version number as Guava Maven-wise.
Just a note, given that Jena has a single git repository and release process, then there could be a future Jena release where there is no new Guava to upgrade to (or we don't want to). Maven-wise we would then have to give it a new version number like 26.0.1 just to make it unique for the release, looking like a patch when nothing changed. (This is not really an issue, and probably already happens to some quiet modules like jena-iri anyway). (Or.. More of a hack: Selectively include it in <modules> during release, or not have it in the same vote-build-release at all) On 30 Mar 2015 20:12, "Andy Seaborne" <[email protected]> wrote: > On 30/03/15 17:28, Stian Soiland-Reyes wrote: > >> +1 (forgot to reply to this!) >> >> Shall we call the shaded guava module for jena-shaded-guava then? >> > > Seems reasonable - put in as that name (despite the pull request!) > > > (What version should it have? Should it be in the regular build?) >> > > I've left in the main build only, not -Pdev. > > >> I suggest the package name org.apache.jena.impl.ext.com.google.common - >> "impl" and the length showd you shouldn't use it outside jena. :-) >> > > "ext" and "impl" does not make sense to me and it's long enough! > > org.apache.jena.ext.com.google.common > > (it's "com.sun.org.apache.xerces", "com.sun.xml.internal.org.jvnet") > > > People can use it outside jena if they want - it's uncontaminated. > > > There's an argument for making the version number the same as guavas. > Opinions? > > Andy > > On 22 Mar 2015 12:09, "Andy Seaborne" <[email protected]> wrote: >> >> At the risk of many modules, combining oaj.atlas and guava into a >>> "non-RDF" package now seems wrong to me. Instead, a module for just >>> shading guava then separately oaj.atlas (eventually). >>> >>> Is many modules a problem? (I don't think - for Jena3 we can even have >>> jena-system.jar as a uber jar, including space reduced with ProGuard or >>> similar). >>> >>> RE: #48 I don't see that including in jena-core and shading has an >>> advantages and the use one package name in one place and different >>> packages >>> in another seems like a disadvantage. >>> >>> I don't think bumping all the versions is necessary either; it's all >>> behind the delivery jars. >>> >>> JENA-905 collects things together as this is being split over email and >>> github. >>> >>> Andy >>> >>> On 20/03/15 16:35, Stian Soiland-Reyes wrote: >>> >>> +1 to the 'before' option. >>>> >>>> On 20 March 2015 at 15:34, Andy Seaborne <[email protected]> wrote: >>>> >>>> On 19/03/15 18:23, Stephen Allen wrote: >>>>> >>>>> >>>>>> I've used the Guava cache before and I really like the design. >>>>>> >>>>>> We obviously may have some issues with it being a dependency as was >>>>>> discussed in the email thread you linked. For my usage, I would have >>>>>> no >>>>>> problem keeping my application up to date with the latest Guava (as >>>>>> long >>>>>> as >>>>>> Jena keeps up to date). But maybe we would need to shade it so other >>>>>> people won't get conflicting versions. Presumably when/if Jigsaw >>>>>> arrives >>>>>> we won't have to worry about this problem any more. >>>>>> >>>>>> If we do decide to make Guava a dependency, it would be nice >>>>>> (although a >>>>>> big change) to take a pass through and eliminate utility >>>>>> methods/classes >>>>>> that we have that are provided by Guava (I'm thinking of >>>>>> org.apache.jena.atlas.iterator.Iter specifically). >>>>>> >>>>>> -Stephen >>>>>> >>>>>> >>>>> >>>>> Hi Stephen, >>>>> >>>>> Guava seems the best I've come across so far. Shading seems like a good >>>>> idea >>>>> as an insurance policy. It's not hard (I just tried it out). >>>>> >>>>> If we shade it, we can do that before or after the RDF code. >>>>> >>>>> If "before", we add a new module to produce org.apache.jena.guava.** >>>>> and >>>>> code against that. This is the version I prefer. >>>>> >>>>> If "after", we write code against com.google.guava.** and shade the >>>>> output >>>>> jars. Each jar has to be done so it's a bit tedious. >>>>> >>>>> If "before" we can put org.apache.jena.atlasin that module, produce >>>>> "jena-ourbasetuff.jar" as a very early step in the build. Any other >>>>> non-RDF >>>>> code canmigrate as people see fit. >>>>> >>>>> Using ProGuard to shrink the jar is orthogonal IMO (though the guava >>>>> jar >>>>> is >>>>> 2.3M so while non-trivial for Android, it's not that large for >>>>> desktop/server use). >>>>> >>>>> Re: Jigsaw. Maybe - I don't know whether the code has to migrate to >>>>> java9 or >>>>> whether exiting code can be wrapped. Even with org.apache.jena.guava >>>>> but >>>>> otherwise the same code, switching to raw use should be quite easy >>>>> (famous >>>>> last words!). >>>>> >>>>> As to clean up - anyone is welcome to tidy anything up. If Jena3 is >>>>> Java8, >>>>> then maybe we can jump to Java8 streams , Optional, etc. Guava seems >>>>> to >>>>> have an goal of portability across Android, GWT and is currently Java >>>>> 1.6. >>>>> >>>>> Andy >>>>> >>>>> [1] https://code.google.com/p/guava-libraries/wiki/FunctionalExplained >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >> >
