The pico container has a solution for the @Inject annotation and enables to set any custom annotation for injection. This way you don't need to bind any of your code to the IoC framework.
It would probably be worth putting a feature request for this... Erik. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Anthony MULLER Sent: December-22-08 5:36 AM To: [email protected] Subject: Re: @Inject annotation 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 -~----------~----~----~----~------~----~------~--~---
