On Aug 23, 2013 9:20 PM, "Igor Fedorenko" <[email protected]> wrote: > > Is scope=provided transitive? I believe it isn't [1], which means that > all maven-core consumers will have to pick a version of guice to be able > to use maven core and manually update guice dependency each time they > update maven dependency version.
The idea would be that maven-core would then declare its own direct dependency on whichever flavour of guice Maven wanted to use (which it would need to do anyway if you wanted to exclude and swap in a different guice edition), because the provided dependency via Sisu would not be transitive. So this would only affect direct consumers of Sisu and not their dependents. That said in an ideal world there would be something like the "provides" alias suggested by Stephen - but as this isn't available yet I'm looking to see if there's a better approach than the current "pick a default and exclude as necessary". > At the same time, replacing guice with a different version does not > require that many exclusions, at least this is the case for m2e embedded > maven runtime [2]. > > I believe current setup provides the best balance between easy of use > and flexibility to customize and my preference is to keep it as is. > > [1] http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope > [2] http://git.eclipse.org/c/m2e/m2e-core.git/tree/m2e-maven-runtime/org.eclipse.m2e.maven.runtime/pom.xml > > -- > Regards, > Igor > > > On 2013-08-22 11:57 PM, Stuart McCulloch wrote: >> >> As one of the main downstream users of Sisu would you prefer it to declare >> a provided scope dependency to (sisu-)guice rather than the current compile >> scope dependency? >> >> Making it provided should make it easier to swap in alternative versions >> while still documenting the dependency - and avoid lots of tedious >> exclusions. The only downside I can see is that downstream users like the >> Maven runtime would then need to explicitly remember to add the >> (sisu-)guice dependency in their final application artifact/assembly (and >> potentially in some tests) as it would no longer be transitively included. >> (though that might be a good thing documentation-wise) >> >> WDYT? >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
