I'm in favor of this as well. Guava wasn't around when Guice first came out, but now that it is it makes sense as a public dependency. It's consistent with most libraries, will prevent redundancy for Guice/Guava users and, as mentioned, ProGuard on the application can eliminate unused parts of Guava. If Guice already depended on Guava directly, *users* would be able to fix issue 288 just by upgrading to Guava r10 when it comes out, with no need to do anything on the Guice end! Guice does need to avoid @Beta APIs of course.
-- Colin On Tue, Jul 5, 2011 at 8:44 PM, [email protected] <[email protected]> wrote: > On Jul 5, 12:20 pm, Stuart McCulloch <[email protected]> wrote: > > 5) Make Guava an external dependency, since a lot of people already use > Guava (leads to potential versioning issues) > > If we avoid @Beta APIs, the versioning downside of a direct dependency > on Guava is quite small. The Guava Authors have committed to keeping > all of their non-beta APIs for deprecation+18 months. > > I'm currently leaning towards shipping Guava as a public dependency. > Where that's a problem the application itself should use ProGuard or > jarjar to shrink their complete binary. > > -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
