+1, and as Christian say, rather than "override guice to provided" in 3) it's easier/better/clearer to exclude the transitive guice dependency (the fact that it could be verbose when you use many extension is a problem with Maven that other libs have too; it's much more concise with Gradle for example, where you can define a "global exclusion (or replacement) rule"). That said, as Willi Schönborn said, extensions could also just depend on guice with <scope>provided</scope> (rather than optional=true). That would only break people who depended on an extension without depending on Guice itself (which nobody, I think, would recommend).
On Friday, December 13, 2013 9:40:36 PM UTC+1, Sam Berlin wrote: > > IMO, based on the fact that everyone agrees we should unbundle Guava, and > with ASM4.0 there's no good reason to keep ASM & CGLIB bundled, then we > should go with the following: > > 1) We change the normal Guice maven bundle (e.g > groupId: com.google.inject, artificantId: guice) to be unbundled. That is, > it depends on Guava, CGLIB & ASM -- it does not bundle them. It does > nothing fancy with its dependencies (e.g, they're just normal 'required' > dependencies, and Maven will pull them down as necessary). > > 2) We change the normal extension maven bundles (e.g, > groupId: com.google.inject.extensions, > artifactIds: guice-assistedinject, guice-multibindings, etc..) to be > unbundled. They depend on 'guice' (and, if necessary, Guava or other > dependencies). Same deal with how Maven > > At this point, we can call it a day -- we've done what pretty much > everyone wants, and that's that. But, if we want to be nice, we can > optionally continue: > > 3) Add a second core Guice maven release: artifactId: guice-nodeps that > embeds its dependencies. > > We can leave it here and say 'extensions' depends on the unbundled > version, or also tell people that want to use nodeps w/ extensions that > they can, in their pom, explicitly override the guice dep to say it's being > provided manually. (I assume that's possible?) ... Or, we can continue: > > 4) Add a second maven release for each extensions with the artifactId > suffixed with -nodeps. > > Or, as an alternate idea to [3,4], we do 5: Just offer a guice-nodeps.jar > (and the extension nodeps jars), and if people want to use the nodeps > version, they download it manually and supply it themselves. > > sam > > > On Fri, Dec 13, 2013 at 2:33 PM, <[email protected] <javascript:>> wrote: > >> Just to understand this correctly: >> You want to have two versions of guice (two poms) and both will have >> dependencies on cglib/asm one of them will declare them ad "provided" the >> other as "compile". Or do you plan to have one version hide this >> dependencies by integrating them into the jar and not declaring them in the >> pom? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "google-guice" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/google-guice. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/groups/opt_out.
