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@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/index.html)

+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

_______________________________________________

richfaces-dev mailing list

richfaces-dev@lists.jboss.org

https://lists.jboss.org/mailman/listinfo/richfaces-dev

I have created [RF-13548] Clean using of guava dependency across framework - JBoss Issue Tracker to track cleaning of Guava dependency.

Just for information, there is a list of APIs we use:

richfaces5]$ find -name "*.java" -exec grep "import com.google.common" {} \; | sort | uniq -c

     14 import com.google.common.base.Function;
      4 import com.google.common.base.Joiner;
      4 import com.google.common.base.Objects;
      3 import com.google.common.base.Objects.ToStringHelper;
     12 import com.google.common.base.Predicate;
      5 import com.google.common.base.Predicates;
      5 import com.google.common.base.Splitter;
     36 import com.google.common.base.Strings;
      4 import com.google.common.cache.CacheBuilder;
      4 import com.google.common.cache.CacheLoader;
      4 import com.google.common.cache.LoadingCache;
      6 import com.google.common.collect.AbstractIterator;
      1 import com.google.common.collect.ArrayListMultimap;
      1 import com.google.common.collect.ClassToInstanceMap;
      1 import com.google.common.collect.ForwardingIterator;
      1 import com.google.common.collect.HashMultimap;
      1 import com.google.common.collect.ImmutableClassToInstanceMap;
      7 import com.google.common.collect.ImmutableList;
      4 import com.google.common.collect.ImmutableMap;
      3 import com.google.common.collect.ImmutableMap.Builder;
      7 import com.google.common.collect.ImmutableSet;
      1 import com.google.common.collect.ImmutableSet.Builder;
     17 import com.google.common.collect.Iterables;
     23 import com.google.common.collect.Iterators;
      1 import com.google.common.collect.LinkedListMultimap;
      1 import com.google.common.collect.ListMultimap;
     22 import com.google.common.collect.Lists;
      1 import com.google.common.collect.MapMaker;
     13 import com.google.common.collect.Maps;
      3 import com.google.common.collect.Multimap;
      1 import com.google.common.collect.MutableClassToInstanceMap;
      2 import com.google.common.collect.ObjectArrays;
      1 import com.google.common.collect.SetMultimap;
     10 import com.google.common.collect.Sets;
      3 import com.google.common.collect.UnmodifiableIterator;
      1 import com.google.common.io.ByteStreams;
      4 import com.google.common.io.Closeables;
      1 import com.google.common.io.Files;
      1 import com.google.common.io.InputSupplier;
      1 import com.google.common.primitives.Primitives;
      1 import com.google.common.util.concurrent.ThreadFactoryBuilder;

That just from Framework code, no tests or helper modules, complete enumeration is here: all over the code base

Since Pavel asked in JIRA whether we could drop Guava in favor of Java 7, there is an answer:

Code base make use of following APIs:

• functional (Java 8)
• joiners/splitters (none)
• cache builders/loaders (none)
• collections
  • multimaps (none)
  • auto-closeables (Java 7)
  • stream / file manipulation (none)
• ...

I agree with Cody that Guava is something what final application developer should decide about.

---

As I said, a re-factoring is not simply addressable at this point,

but I believe we can shade Guava library (even in minimized form) into RichFaces.

It will avoid collisions and ensure stability of API for us.

I'm not afraid we will forget about upgrading - when there is a critical issue in Guava (such as a bug we track down or security issue), we will be forced to upgrade.

In major (and sometimes minor) revisions we upgrade from time to time.

Additionally it would be good to take the list of interfaces I listed above and make sure we don't depend on @Beta interfaces.

---

What do you think?

Let's go ahead and try shading.  We should probably create some high-level package into which we place our shaded classes.  Something like org.richfaces.shaded.guava.  We'll use RF-13548 to track this effort.

Note: IIRC the Apache shade plugin caused an issue with productisation.  Let's continue despite this potential problem and deal with it when/if it comes up.

Brian

Brian, do you want to implement shading in all versions of RichFaces, i.e. 5.0, 4.5 and 4.3?

Hi,

Sorry for reviving this old topic.

I see (but I don't understand)

• RF 4.5 seems to be using Guava 17 ([RF-13773] Upgrade Guava Dependency to 17.0 - JBoss Issue Tracker)
• RF 5.0 seems to be using Guava 16 ([RF-13247] Upgrade the Guava dependency to the 16.0.1 - JBoss Issue Tracker)

However, what I'm most interested about is this concept of shading Guava within RF jar. It seems the idea was generally agreed about. In what versions is it going to be introduced?

I'm interested since I'm application developer and RF apparently prevents me from upgrading Guava.

Best regards,

Piotr

RF 5 development stopped last June. We will not be continuing with RF 5 development as per: http://www.bleathem.ca/blog/2014/07/richfaces-will-pursue-stability-over-innovation.html

Neither will we pursue shading guava in RichFaces. Instead, we re-factored our usage of guava to use only the stable portions of the API. This should enable you to upgrade guava in your applications.