Agree, until Java 8 arrives to masses, Guava is very useful.
----
Shading is certainly an option.
----
I was wondering how much of Guava code we could strip by limiting to just
the classes we use directly/transitively.
With a minimal compilation (minimizeJar [1]) results are not convincing:
1437 classes (original guava) -> 919 (minimized guava - limited to only
what we use / use transitively)
Here is a configuration:
https://gist.github.com/lfryc/b86d64c2a20843db0ec2
But no one says we do even need to use it minimizeJar. ;-)
[1]
http://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#minimi...
On Wed, Feb 12, 2014 at 9:55 PM, Brian Leathem <bleathem(a)gmail.com> wrote:
On Wed 12 Feb 2014 12:39:46 PM PST, Lukáš Fryč wrote:
>
> It would be nice to remove one more dependency.
+1. I don't like the idea of dropping it altogether though. Many of
the abstractions it introduces are quite useful and lead to cleaner code.
> On Tue, Feb 11, 2014 at 7:07 PM, Cody Lerum
> <richfaces-dev(a)lists.jboss.org <mailto:richfaces-dev@lists.jboss.org>>
> wrote:
>
> Maybe RF shouldn't depend on Guava or at a minimum shouldn't
> depend on anything annotated @Beta as Closables was
> (
http://docs.guava-libraries.googlecode.com/git-history/v13.0.1/javadoc/in...
)
+1 for sticking to the stable API.
We could re-explore the idea of shading guava into the richfaces jar
under a different package name. The downside here is it would be easy
to forget about upgrading the library, however this would no longer
effect user applications nor interact with leaky containers.
Brian