First use of Google Auto

[Adrian Cole <ad...@gmail.com>]

Hi, team.

The fantastic folks at Google Auto have a tool that can significantly
improve readability and maintainability of our value types. They also
have a tool that removes the need to manually maintain serviceloader
manifests. All of this magic has no runtime dependency! That means no
more s/MoreObjects/Objects!

The catch is that I've only tried on an XML provider, so we may still
need work to get gson going. Also, if you haven't setup your IDE for
annotation processing, you'll need to do that. Anyway, here's an
example to look at, where I ported Azure to use auto.

https://github.com/jclouds/jclouds-labs/pull/100

I hope we can make more progress like this such that high quality
providers are easier to write, and with less chance of classpath
conflicts!

Cheers,
-A

Re: First use of Google Auto

[Adrian Cole <ad...@gmail.com>]

Auto is compile-time only. For example even the annotations are source
retention vs runtime. This means concerns are solely thrashing of overall
design or risk to the build.

Long way of saying go for it! Just make sure you inherit the version.

I want to write a value type but it takes at least 10m to even log into
moinmoin wiki.

-A
On Nov 5, 2014 3:15 AM, "Inbar Stolberg" <in...@gmail.com> wrote:

> I saw you use rc2 artifact meaning some signatures might change and
> backward support is not guaranteed.
> Any risk here?
>
> If not do we have green light moving domain objects to use auto values?
> On Oct 25, 2014 6:21 AM, "Adrian Cole" <ad...@gmail.com> wrote:
>
> > Hi, team.
> >
> > The fantastic folks at Google Auto have a tool that can significantly
> > improve readability and maintainability of our value types. They also
> > have a tool that removes the need to manually maintain serviceloader
> > manifests. All of this magic has no runtime dependency! That means no
> > more s/MoreObjects/Objects!
> >
> > The catch is that I've only tried on an XML provider, so we may still
> > need work to get gson going. Also, if you haven't setup your IDE for
> > annotation processing, you'll need to do that. Anyway, here's an
> > example to look at, where I ported Azure to use auto.
> >
> > https://github.com/jclouds/jclouds-labs/pull/100
> >
> > I hope we can make more progress like this such that high quality
> > providers are easier to write, and with less chance of classpath
> > conflicts!
> >
> > Cheers,
> > -A
> >
>

Re: First use of Google Auto

[Inbar Stolberg <in...@gmail.com>]

I saw you use rc2 artifact meaning some signatures might change and
backward support is not guaranteed.
Any risk here?

If not do we have green light moving domain objects to use auto values?
On Oct 25, 2014 6:21 AM, "Adrian Cole" <ad...@gmail.com> wrote:

> Hi, team.
>
> The fantastic folks at Google Auto have a tool that can significantly
> improve readability and maintainability of our value types. They also
> have a tool that removes the need to manually maintain serviceloader
> manifests. All of this magic has no runtime dependency! That means no
> more s/MoreObjects/Objects!
>
> The catch is that I've only tried on an XML provider, so we may still
> need work to get gson going. Also, if you haven't setup your IDE for
> annotation processing, you'll need to do that. Anyway, here's an
> example to look at, where I ported Azure to use auto.
>
> https://github.com/jclouds/jclouds-labs/pull/100
>
> I hope we can make more progress like this such that high quality
> providers are easier to write, and with less chance of classpath
> conflicts!
>
> Cheers,
> -A
>