The goal of Guice is for your code to not truly depend on it. However, the fact that @Inject and interfaces like Provider are not in the JDK -- yet!<http://jcp.org/en/jsr/detail?id=330>-- means you do end up having to depend on Guice in these small ways. Still, you can keep your Module definitions in a separate artifact, and you can offer Spring configurations as well or even static factories that wire up your nice DI-friendly classes by hand if that's something you want to do. The guice JAR file that would be required at runtime could be very small.
On Fri, Jun 5, 2009 at 1:32 PM, Gili <[email protected]> wrote: > > Hi, > > I'm about to publish an open-source Java library and I was thinking > that it would benefit from using Guice in a couple of places to > improve testability. My next thought is that users would avoid my > library if I force Guice on them. I don't want to cross the line > between providing a library to providing a framework. > > Has anyone else run across this before? Is this the reason we rarely > see Guice or Spring being used by other open-source libraries? > > I use Guice everywhere in my internal application code, but I'd be > reluctant to use a library if it exposed IoC through its API. > > Gili > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
