+1 for the approach outlined below, should simplify the build - I’ll clean up my example patch and attach it to issue 709
PS. another option if you want to make clear the packaging has changed would be to use a new groupId, such as “com.google.guice” (which would align better with “com.google.guava”, etc.) On 13 Dec 2013, at 20:40, Sam Berlin <[email protected]> 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]> 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]. > 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. > > > -- > 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. -- 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.
