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
