The whole point of using jarjar links is to obscure the fact that Guice uses cglib or collect. Guice is not dependent on these as libs (they way Hibernate is), rather they are part of Guice. If you want to use cglib independently that works just fine by dropping in a cglib-nodep jar.
I really see no point in building a naked version of Guice. If you really need it for some weird reason you can build it from source. Which I think will cause more harm than good because Guice jumps through all kinds of hoops to change cglib's naming policy, etc. Afaic, cglib and collect are private to Guice and should not even be considered as being present. Dhanji. On Sat, Oct 11, 2008 at 2:53 AM, James Strachan <[EMAIL PROTECTED]>wrote: > > 2008/10/10 Kevin Bourrillion <[EMAIL PROTECTED]>: > > James, thanks for the kind words! We will certainly look at these > > possibilities once we hammer out an official 1.0 release of the > collections > > (which was not a high priority in Q3 but is becoming so once again, so it > > should happen by end of year). Any other ideas for how this should work > > technically are welcome in this thread. > > From a maven repo perspective, we'd just have a different artefacts > (in maven-speak an artefact is typically a pom.xml and a jar with > maybe some other files associated like the javadoc/src jar for > debugging). Then folks could use whichever version of guice they > preferred; the jarjar-d one or not > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
