Thanks for your feedbacks! I work for a major software editor and "dependencies" with external 3tr party, like Guice can be see as a problem. Personally, I don't care about this point (having @Inject from Google package in my code).
But, we are working on a kind of platform and independence is one of the main concerns. So, ok Provider and Module are already in the code but there are easily hidden into the bootstrap code. I can not do anything for @Inject annotation... I will look at links from Stuart... Cheers! Anthony 2008/12/13 Dhanji R. Prasanna <[email protected]> > > Kevin, > > I don't think there's any need to separate the annotations either. > Java jars sit there innocuously unless they're being used. The only > (sortof) argument might be where struts2's @Inject interferes with > Guice's. > > But I've not heard anyone complain about that before. > > Dhanji. > > On Sat, Dec 13, 2008 at 6:25 AM, Kevin Bourrillion <[email protected]> > wrote: > > Hi Anthony, > > > > First off, your code is going to depend on some interfaces like Module > and > > Provider anyway, so your change with the annotations doesn't really > change > > anything. I do think it would make sense for us to put these common > > interfaces and annotations into their own small JAR file, so you can feel > > more light and airy when you depend on only that, and there is a feature > > request filed for it (I don't remember if Bob and Jesse agree, though). > > > > Beyond that, I think that some people, when seeing "import > > com.google.inject.Inject", simply imagine a problem where none really > > exists. We all work so hard at keeping dependencies out of our code that > > when we see that we react against it at a gut level. But in reality, > your > > classes have no runtime dependency on Guice. If they run as part of an > > application that doesn't wish to use Guice, the Guice jar file needn't > even > > be present on the server at all. > > > > The idea of "dependency" or "tight coupling" is that "the one cannot > > function without the other." But with annotations, this isn't the case. > > They're just decoration that don't, and can't, actually do anything. They > > sit there, innocuously, in case tools will wish to read them, and > otherwise > > have no effect whatsoever. They don't impede you from testing your code, > or > > from using the classes with Spring or just using them normally. > > > > Hopefully this explains why we have never been convinced there's an > actual > > problem here. > > > > > > On Fri, Dec 12, 2008 at 6:49 AM, Anthony MULLER < > [email protected]> > > wrote: > >> > >> Hello, > >> > >> I have a little request about next release of Guice. Currently, we have > to > >> use @Inject into the code to say that we want Guice "inject here". > >> > >> My concern is we have "import com.google.inject.Inject;" into the > class... > >> It is not really 'my' concern but some guys find it is intrusive... > >> > >> So, my proposal is to indicate to Guice the annotation class to use : > >> Guice.setInjectAnnotationType(my.package.MyInject.class); > >> > >> So, Guice looks now for MyInject annotation (instead of standard Inject > >> one) and I don't have the com.google.inject.Inject import in my class... > >> > >> What do you think about this? > >> > >> Regards, > >> Anthony > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
