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
