+1 (forgot to reply to this!) Shall we call the shaded guava module for jena-shaded-guava then?
(What version should it have? Should it be in the regular build?) 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. :-) 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 >>> >> >> >> >> >
