+1 for (1) - which means it is OK as in master now - keep job easy for Release Manager.
I can only see a theoretical issue if someone way in the future is mixing old and new jena modules (which is asking for trouble anyway :-) and the newer Jena rely on brand new guava features. (Or as now, we rely on CacheBuilder which is @Beta and might not survive in later guavas) On 1 Apr 2015 12:03, "Andy Seaborne" <[email protected]> wrote: > On 31/03/15 21:33, Stian Soiland-Reyes wrote: > >> +1, It makes sense for the shaded Guava to have same version number as >> Guava Maven-wise. >> > > Good points about managing the version number across releases. Given > those, I'm not minded to use the Guava version number. > > Doing a release requires a great deal of care because it is done only a > occasionally, and because it is quite high stakes. Keeping the RM's job as > simple and straight forward as possible is important; let the RM > concentrate on the release specifics, not the process. > > The Jenkins snapshot deploy job is the same as the release build, give or > take -Papache-release + release plugin. > > The last release was too complicated. The time needed to get a release > done is worse than linear on the complexity. > > The choices I see as practical are: > 1/ Jena-related version number. > 2/ Separate release. > > and as 2.13.1 << 18.0 we can choose (1) now and jump to (2) if there is an > issue. AKA leave as-is until a genuine advantage is presented. > > We are getting some stable modules, jena-iri being an example, but while > there are a small number, rebuilds are just plain simpler. > > Andy > > 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
