You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@jclouds.apache.org by Adrian Cole <no...@github.com> on 2014/11/18 20:24:01 UTC

[jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Auto are being good libraries by shading their internal use of guava.

https://github.com/google/auto/pull/160

I noticed that there's no longer a transitive dep on auto-service from auto-value anymore. Let's call these out independently
You can merge this Pull Request by running:

  git pull https://github.com/adriancole/jclouds adrian.sync-auto

Or you can view, comment on it, or merge it online at:

  https://github.com/jclouds/jclouds/pull/609

-- Commit Summary --

  * Add dependency management for each auto project independently vs relying on transitivity.

-- File Changes --

    M project/pom.xml (15)

-- Patch Links --

https://github.com/jclouds/jclouds/pull/609.patch
https://github.com/jclouds/jclouds/pull/609.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Andrew Phillips <no...@github.com>.
> @@ -210,6 +210,8 @@
>      <surefire.version>2.17</surefire.version>
>      <assertj-core.version>1.6.1</assertj-core.version>
>      <assertj-guava.version>1.2.0</assertj-guava.version>
> +    <auto-factory.version>0.1-beta1</auto-factory.version>

> nudged on this

Thanks!

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609/files#r20556011

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by BuildHive <no...@github.com>.
[jclouds » jclouds #1931](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1931/) SUCCESS
This pull request looks good
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609#issuecomment-63570076

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-pull-requests-java-7 #307](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests-java-7/307/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609#issuecomment-63533034

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Andrew Phillips <no...@github.com>.
> @@ -210,6 +210,8 @@
>      <surefire.version>2.17</surefire.version>
>      <assertj-core.version>1.6.1</assertj-core.version>
>      <assertj-guava.version>1.2.0</assertj-guava.version>
> +    <auto-factory.version>0.1-beta1</auto-factory.version>

Do we know when an rc or initial release for this is planned?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609/files#r20550084

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-pull-requests-java-7 #306](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests-java-7/306/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609#issuecomment-63531827

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-pull-requests #1395](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1395/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609#issuecomment-63533770

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Adrian Cole <no...@github.com>.
> @@ -306,6 +308,16 @@
>          <version>${assertj-guava.version}</version>
>        </dependency>
>        <dependency>
> +        <groupId>com.google.auto.factory</groupId>
> +        <artifactId>auto-factory</artifactId>
> +        <version>${auto-factory.version}</version>
> +      </dependency>
> +      <dependency>
> +        <groupId>com.google.auto.service</groupId>

Only thing is not all modules are apis or providers. If we added a provided
dep to all things the the annotation processor would run on all things,
even those that it doesn't apply to, such as http drivers. Maybe that's
ok.. @demobox wdyt?

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609/files#r20893250

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by BuildHive <no...@github.com>.
[jclouds » jclouds #1930](https://buildhive.cloudbees.com/job/jclouds/job/jclouds/1930/) SUCCESS
This pull request looks good
[(what's this?)](https://www.cloudbees.com/what-is-buildhive)

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609#issuecomment-63563031

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Andrew Phillips <no...@github.com>.
I'm assuming the versions listed are the ones we were pulling in transitively anyway? In that case, +1 from me.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609#issuecomment-63571044

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Adrian Cole <no...@github.com>.
ps. this calls out the fact that auto projects move at different pace.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609#issuecomment-63530180

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Adrian Cole <no...@github.com>.
> @@ -210,6 +210,8 @@
>      <surefire.version>2.17</surefire.version>
>      <assertj-core.version>1.6.1</assertj-core.version>
>      <assertj-guava.version>1.2.0</assertj-guava.version>
> +    <auto-factory.version>0.1-beta1</auto-factory.version>

nudged on this.. I know things are converging over there, but don't know
exact date.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609/files#r20553105

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Andrew Phillips <no...@github.com>.
> @@ -306,6 +308,16 @@
>          <version>${assertj-guava.version}</version>
>        </dependency>
>        <dependency>
> +        <groupId>com.google.auto.factory</groupId>
> +        <artifactId>auto-factory</artifactId>
> +        <version>${auto-factory.version}</version>
> +      </dependency>
> +      <dependency>
> +        <groupId>com.google.auto.service</groupId>

> I'd rather not add it by default

TL;DR: +1 to that. Unless we get feedback that copy-pasting a couple of deps is so annoying that we need to avoid the need for it, I'd rather keep our user impact down by keeping the list of transitive deps as small as possible.

The set of dependencies that we propagate to all modules that inherit from jclouds-project should be as small as possible. I agree with @jdaggett that we want to use `Auto*` wherever possible, but putting the deps in `<dependency>` doesn't enforce that anyway, and copy-pasting a couple of deps when creating a POM doesn't seem like a huge overhead at this point (certainly not when compared to the overall size of our POMs...but that's another discussion ;-) )


---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609/files#r20896378

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by CloudBees pull request builder plugin <no...@github.com>.
[jclouds-pull-requests #1394](https://jclouds.ci.cloudbees.com/job/jclouds-pull-requests/1394/) SUCCESS
This pull request looks good

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609#issuecomment-63533048

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Ignasi Barrera <no...@github.com>.
> @@ -306,6 +308,16 @@
>          <version>${assertj-guava.version}</version>
>        </dependency>
>        <dependency>
> +        <groupId>com.google.auto.factory</groupId>
> +        <artifactId>auto-factory</artifactId>
> +        <version>${auto-factory.version}</version>
> +      </dependency>
> +      <dependency>
> +        <groupId>com.google.auto.service</groupId>

If a dependency is not going to be used, I'd rather not add it by default (it could also be inherited as a transitive dependency if at some point by another project).

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609/files#r20893734

Re: [jclouds] Add dependency management for each auto project independently vs relying on transitivity (#609)

Posted by Jeremy Daggett <no...@github.com>.
> @@ -306,6 +308,16 @@
>          <version>${assertj-guava.version}</version>
>        </dependency>
>        <dependency>
> +        <groupId>com.google.auto.factory</groupId>
> +        <artifactId>auto-factory</artifactId>
> +        <version>${auto-factory.version}</version>
> +      </dependency>
> +      <dependency>
> +        <groupId>com.google.auto.service</groupId>

@adriancole Since `AutoService` is now it's own dependency, I feel that this should be in the `<dependencies>` stanza instead. I believe that we should be using `AutoService` across all of the project(s) for API/Provider service loader metadata generation. Is there a reason not to do this? I do understand the need for different versions of `AutoValue`, but that shouldn't apply in this specific case.

---
Reply to this email directly or view it on GitHub:
https://github.com/jclouds/jclouds/pull/609/files#r20889387