Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[sisu-users] Upcoming change affecting Maven consumers of Sisu: making Guice a provided scope dependency

Heads-up about an upcoming change affecting people consuming Sisu via Maven; you don't need to read this if you consume Sisu via P2 or OSGi...

~~~

Sisu-Inject currently has a direct Maven dependency to Guice 3.0:

    <dependency>
      <groupId>com.google.inject</groupId>
      <artifactId>guice</artifactId>
      <version>3.0</version>
    </dependency>

This was added as a convenience to downstream Maven consumers, so they didn't have to remember the minimum requirements needed to run Sisu.
It doesn't actually affect the compilation classpath at build time because that's computed by Tycho based on the target platform defined in "build.target".

Sisu-Plexus has a similar direct Maven dependency, but this time to the "no-AOP" flavour of Sisu-Guice 3.1.6:

    <dependency>
      <groupId>org.sonatype.sisu</groupId>
      <artifactId>sisu-guice</artifactId>
      <classifier>no_aop</classifier>
      <version>3.1.6</version>
    </dependency>

The reason for the change in artifact is because Sisu-Plexus needs the ProvisionListener API that was added to the Guice codebase after the 3.0 release.
Sisu-Guice arose out of a need for interim releases of the latest Guice codebase. It also incorporates various fixes that have been reported upstream but
are not yet available in an official Guice release. The "no-AOP" flavour was chosen because it is leaner and the Plexus adapter doesn't require AOP.

Recently there was a request from the Maven team to make it easier to swap in alternative editions of Guice. The current direct dependency coupled with
the different GAVC coordinates means you need to first exclude the unwanted Guice dependency and then add the wanted Guice dependency alongside
your original Sisu dependency. For example, if you wanted to use Sisu-Guice because it fixes a potential memory leak (issue 288) then you would write:

    <dependency>
      <groupId>org.sonatype.sisu</groupId>
      <artifactId>sisu-guice</artifactId>
      <version>3.1.6</version>
    </dependency>
    <dependency>
      <groupId>org.eclipse.sisu</groupId>
      <artifactId>org.eclipse.sisu.inject</artifactId>
      <version>0.0.0.M5</version>
      <exclusions>
        <exclusion>
          <groupId>com.google.inject</groupId>
          <artifactId>guice</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

This works, but if you accidentally miss an exclusion then the version of Guice you end up with will depend on the ordering of your dependencies.

Therefore I'm planning to change the scope of the Guice dependency to "provided" which means that it is no longer transitive:

    http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope

The dependency would still be in the pom.xml to document the requirements, but would no longer "leak" transitively onto the application classpath.
This means that people consuming Sisu via Maven would now need to explicitly add a dependency to whichever edition of Guice they want to use:

    <dependency>
      <groupId>org.sonatype.sisu</groupId>
      <artifactId>sisu-guice</artifactId>
      <version>3.1.6</version>
    </dependency>
    <dependency>
      <groupId>org.eclipse.sisu</groupId>
      <artifactId>org.eclipse.sisu.inject</artifactId>
      <version>0.0.0.M5</version>
    </dependency>

But you'd need to do this anyway when swapping in an alternative edition and it saves on having to remember to exclude the old dependency.

I'm planning to make this change soon - if anyone has doubts or strong objections then please let me know.

See also the discussion at http://www.mail-archive.com/dev@xxxxxxxxxxxxxxxx/msg98078.html

--
Cheers, Stuart

Back to the top