You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jclouds.apache.org by Adrian Cole <ad...@gmail.com> on 2014/10/09 03:53:47 UTC
Worst experience ever. Was Re: [jclouds] cinder availability zones
api + list call implemented (#560)
Hi, team.
Having done sweeping change across a dozen providers I totally feel this
pain.
In short, we know there are terrible malpractice like abstract builder for
one field in existing code, yet we don't do anything about it. Then, when
someone new comes in, somewhere between us telling them to delete extra
spaces, we ack that the thing we know sucks is something they pasted.
It is reasonable for them to not know the right answer or to be overwhelmed
by what seems to be a timesoaking response to an innocent change.
It isn't hard to fixup the existing providers so that they are already good
examples by the time someone goes to change them. I.e. they don't carry
behavior we know is awful. I tried to do some of that when I did the
unasyncing.
This stuff happens, basically a norm of tech debt. Now that we have
checkstyle sorted, perhaps we can start paying down this sort of debt?
I will volunteer to undebt one provider for each provider someone else
volunteers for. Anyone with me?
-A
---------- Forwarded message ----------
From: "inbar stolberg" <no...@github.com>
Date: Oct 8, 2014 4:51 PM
Subject: Re: [jclouds] cinder availability zones api + list call
implemented (#560)
To: "jclouds/jclouds" <jc...@noreply.github.com>
Cc:
In
apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
> + * See the License for the specific language governing permissions and
> + * limitations under the License.
> + */
> +
> +package org.jclouds.openstack.cinder.v1.extensions;
> +
> +/**
> + * Extension namespaces
> + */
> +public final class ExtensionNamespaces {
> +
> + /**
> + * Admin Action extension
> + */
> + public static final String ADMIN_ACTIONS = "http://docs.openstack.org/ext/admin-actions/api/v1.1";
> +
90% of this code is copy paste of existing code from the same branch not
old code either ...
I have no problem fixing this but doesnt seem like there is cosistency in
the code if i can copy paste some thing and get rejected over 100 lines....
:/
—
Reply to this email directly or view it on GitHub
<https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Ignasi Barrera <na...@apache.org>.
+1000 to this proposal. It's time to get our hands dirty and clean up our
technical debt with the same energy Adrian had this weekend when
unasynching.
Andrew's list seems to be a good starting one, and I'd only add:
* Recover the essence of labs. For *all* labs repos. If they're peoduction
ready, promote. Otherwise change aggressively. Deprecation makes no sense
there and we should push providers to be promoted or deleted. TTL in labs
has to be limited.
This said, I volunteer to cleanup (refactoring all tests and all mentioned):
* chef
* digitalocean (this is pretty clean, Adrian, mind having a look to use it
as a reference?)
* cloudsigma
* elasrichosts
* abiquo
Let's get things done.
El 09/10/2014 05:35, "Adrian Cole" <ad...@gmail.com> escribió:
> https://github.com/rcoedo/assertj-mws/issues/1
>
> On Wed, Oct 8, 2014 at 8:29 PM, Adrian Cole <ad...@gmail.com>
> wrote:
> > You'll notice there's very little code to author an assertion (<200
> > lines in this case), so I'm not sure it is worthwhile making a
> > dependency, bothering someone to publish to maven and keep it current.
> > That said, this one is nicely written and actually includes tests...
> > tough call.
> >
> > On Wed, Oct 8, 2014 at 8:06 PM, Andrew Gaul <ga...@apache.org> wrote:
> >> Roman Coedo started on assertj-mws; could you share some feedback with
> >> him?
> >>
> >> https://github.com/rcoedo/assertj-mws
> >>
> >> On Wed, Oct 08, 2014 at 07:47:45PM -0700, Adrian Cole wrote:
> >>> Also, I think we waste breath on some things that we haven't really
> >>> started doing.
> >>>
> >>> Ex. if I had to say that in a unit test, we prefer assert
> >>> !list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
> >>>
> >>> One thing I would love to see is to start using Truth or assertj which
> >>> have fluent ways to act on things like collections without one wanting
> >>> to cut themselves. For example, we could generate assertj assertions
> >>> for our common models, which could make things like MockWebServer,
> >>> BlobStore, FluentIterable, etc. assertions far more delightful to
> >>> write.
> >>>
> >>> -A
> >>>
> >>> On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com>
> wrote:
> >>> > I think google looks to be in pretty good shape, including
> appropriate
> >>> > use of weird builder
> >>> >
> >>> > ex. weird builder is kindof ok when there exists a base resource from
> >>> > which everything else is derived. ex Resource vs Instance.
> >>> >
> >>> >
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
> >>> >
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
> >>> >
> >>> > However, things not sensible to extend have concrete builders.
> >>> >
> >>> >
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
> >>> >
> >>> > I haven't reviewed through all of google, but each time I've
> >>> > accidentally entered, it has looked pretty good.
> >>> >
> >>> > -A
> >>> >
> >>> > On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <
> aphillips@qrmedia.com> wrote:
> >>> >>> I will volunteer to undebt one provider for each provider someone
> else
> >>> >>> volunteers for. Anyone with me?
> >>> >>
> >>> >>
> >>> >> I'm up! Any specific one that you feel would be a good example?
> >>> >>
> >>> >> Before we start, though: do we have an up-to-date list of what we
> consider
> >>> >> Good Practice and what we want to clean up here? I fully sympathize
> with
> >>> >> Inbar, but I think part of the problem here is that beyond
> copy-pasting
> >>> >> existing code I don't think we have anything outside of people's
> heads that
> >>> >> describes what we're actually looking for. The few dev guides we
> have [1, 2,
> >>> >> 3] certainly aren't enough.
> >>> >>
> >>> >> I obviously would love to be a position where all code has been
> cleaned up
> >>> >> to the point that copy-paste is in line with the jclouds State Of
> The Art.
> >>> >> Even if that is not the case, it would at least be great if
> contributors
> >>> >> could have somewhere to go for advice. And we should probably agree
> that
> >>> >> we'll prefer current guidelines over consistency with the rest of
> an older
> >>> >> codebase.
> >>> >>
> >>> >> Getting back to this one: draft of what we're looking for?
> >>> >>
> >>> >> * MWS tests
> >>> >> * No abstract builders
> >>> >> * Use Objects.equal in equals()
> >>> >> * Move common @Path to top of interface
> >>> >> * private, error-throwing constructors for domain objects created by
> >>> >> builders
> >>> >>
> >>> >> Is this the kind of stuff you have in mind? I'm just looking the PR
> by Inbar
> >>> >> that triggered this here...
> >>> >>
> >>> >> Regards
> >>> >>
> >>> >> ap
> >>> >>
> >>> >> [1] https://wiki.apache.org/jclouds/Coding%20Standards
> >>> >> [2] https://wiki.apache.org/jclouds/Best%20Practices
> >>> >> [3]
> https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
> >>> >>
> >>> >>
> >>> >>
> >>> >>>
> >>> >>> -A
> >>> >>> ---------- Forwarded message ----------
> >>> >>> From: "inbar stolberg" <no...@github.com>
> >>> >>> Date: Oct 8, 2014 4:51 PM
> >>> >>> Subject: Re: [jclouds] cinder availability zones api + list call
> >>> >>> implemented (#560)
> >>> >>> To: "jclouds/jclouds" <jc...@noreply.github.com>
> >>> >>> Cc:
> >>> >>>
> >>> >>> In
> >>> >>>
> >>> >>>
> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
> >>> >>>
> >>> >>>> + * See the License for the specific language governing
> permissions and
> >>> >>>> + * limitations under the License.
> >>> >>>> + */
> >>> >>>> +
> >>> >>>> +package org.jclouds.openstack.cinder.v1.extensions;
> >>> >>>> +
> >>> >>>> +/**
> >>> >>>> + * Extension namespaces
> >>> >>>> + */
> >>> >>>> +public final class ExtensionNamespaces {
> >>> >>>> +
> >>> >>>> + /**
> >>> >>>> + * Admin Action extension
> >>> >>>> + */
> >>> >>>> + public static final String ADMIN_ACTIONS =
> >>> >>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
> >>> >>>> +
> >>> >>>
> >>> >>>
> >>> >>> 90% of this code is copy paste of existing code from the same
> branch not
> >>> >>> old code either ...
> >>> >>> I have no problem fixing this but doesnt seem like there is
> cosistency in
> >>> >>> the code if i can copy paste some thing and get rejected over 100
> >>> >>> lines....
> >>> >>> :/
> >>> >>>
> >>> >>> —
> >>> >>> Reply to this email directly or view it on GitHub
> >>> >>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
> >>> >>>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Andrew Phillips
> >>> >> qrmedia
> >>> >>
> >>> >> Unless expressly stated otherwise, this message is confidential.
> >>> >> Access to this e-mail by anyone else is unauthorised. If you are
> >>> >> not an addressee, any disclosure or copying of the contents of
> >>> >> this e-mail or any action taken (or not taken) in reliance on it
> >>> >> is unauthorised and may be unlawful. If you are not an addressee,
> >>> >> please inform the sender immediately.
> >>> >>
> >>> >> This message is confidential and may not be redistributed or
> >>> >> broadcast in whole or part in any form, including but not limited
> >>> >> to any form of internet transmission including email, usenet,
> >>> >> newsgroups, www, irc, icq, etc.
> >>> >> All liability for errors and viruses is disclaimed.
> >>
> >> --
> >> Andrew Gaul
> >> http://gaul.org/
>
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
https://github.com/rcoedo/assertj-mws/issues/1
On Wed, Oct 8, 2014 at 8:29 PM, Adrian Cole <ad...@gmail.com> wrote:
> You'll notice there's very little code to author an assertion (<200
> lines in this case), so I'm not sure it is worthwhile making a
> dependency, bothering someone to publish to maven and keep it current.
> That said, this one is nicely written and actually includes tests...
> tough call.
>
> On Wed, Oct 8, 2014 at 8:06 PM, Andrew Gaul <ga...@apache.org> wrote:
>> Roman Coedo started on assertj-mws; could you share some feedback with
>> him?
>>
>> https://github.com/rcoedo/assertj-mws
>>
>> On Wed, Oct 08, 2014 at 07:47:45PM -0700, Adrian Cole wrote:
>>> Also, I think we waste breath on some things that we haven't really
>>> started doing.
>>>
>>> Ex. if I had to say that in a unit test, we prefer assert
>>> !list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
>>>
>>> One thing I would love to see is to start using Truth or assertj which
>>> have fluent ways to act on things like collections without one wanting
>>> to cut themselves. For example, we could generate assertj assertions
>>> for our common models, which could make things like MockWebServer,
>>> BlobStore, FluentIterable, etc. assertions far more delightful to
>>> write.
>>>
>>> -A
>>>
>>> On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com> wrote:
>>> > I think google looks to be in pretty good shape, including appropriate
>>> > use of weird builder
>>> >
>>> > ex. weird builder is kindof ok when there exists a base resource from
>>> > which everything else is derived. ex Resource vs Instance.
>>> >
>>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
>>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
>>> >
>>> > However, things not sensible to extend have concrete builders.
>>> >
>>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
>>> >
>>> > I haven't reviewed through all of google, but each time I've
>>> > accidentally entered, it has looked pretty good.
>>> >
>>> > -A
>>> >
>>> > On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> >>> I will volunteer to undebt one provider for each provider someone else
>>> >>> volunteers for. Anyone with me?
>>> >>
>>> >>
>>> >> I'm up! Any specific one that you feel would be a good example?
>>> >>
>>> >> Before we start, though: do we have an up-to-date list of what we consider
>>> >> Good Practice and what we want to clean up here? I fully sympathize with
>>> >> Inbar, but I think part of the problem here is that beyond copy-pasting
>>> >> existing code I don't think we have anything outside of people's heads that
>>> >> describes what we're actually looking for. The few dev guides we have [1, 2,
>>> >> 3] certainly aren't enough.
>>> >>
>>> >> I obviously would love to be a position where all code has been cleaned up
>>> >> to the point that copy-paste is in line with the jclouds State Of The Art.
>>> >> Even if that is not the case, it would at least be great if contributors
>>> >> could have somewhere to go for advice. And we should probably agree that
>>> >> we'll prefer current guidelines over consistency with the rest of an older
>>> >> codebase.
>>> >>
>>> >> Getting back to this one: draft of what we're looking for?
>>> >>
>>> >> * MWS tests
>>> >> * No abstract builders
>>> >> * Use Objects.equal in equals()
>>> >> * Move common @Path to top of interface
>>> >> * private, error-throwing constructors for domain objects created by
>>> >> builders
>>> >>
>>> >> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
>>> >> that triggered this here...
>>> >>
>>> >> Regards
>>> >>
>>> >> ap
>>> >>
>>> >> [1] https://wiki.apache.org/jclouds/Coding%20Standards
>>> >> [2] https://wiki.apache.org/jclouds/Best%20Practices
>>> >> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>>> >>
>>> >>
>>> >>
>>> >>>
>>> >>> -A
>>> >>> ---------- Forwarded message ----------
>>> >>> From: "inbar stolberg" <no...@github.com>
>>> >>> Date: Oct 8, 2014 4:51 PM
>>> >>> Subject: Re: [jclouds] cinder availability zones api + list call
>>> >>> implemented (#560)
>>> >>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>>> >>> Cc:
>>> >>>
>>> >>> In
>>> >>>
>>> >>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>>> >>>
>>> >>>> + * See the License for the specific language governing permissions and
>>> >>>> + * limitations under the License.
>>> >>>> + */
>>> >>>> +
>>> >>>> +package org.jclouds.openstack.cinder.v1.extensions;
>>> >>>> +
>>> >>>> +/**
>>> >>>> + * Extension namespaces
>>> >>>> + */
>>> >>>> +public final class ExtensionNamespaces {
>>> >>>> +
>>> >>>> + /**
>>> >>>> + * Admin Action extension
>>> >>>> + */
>>> >>>> + public static final String ADMIN_ACTIONS =
>>> >>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>>> >>>> +
>>> >>>
>>> >>>
>>> >>> 90% of this code is copy paste of existing code from the same branch not
>>> >>> old code either ...
>>> >>> I have no problem fixing this but doesnt seem like there is cosistency in
>>> >>> the code if i can copy paste some thing and get rejected over 100
>>> >>> lines....
>>> >>> :/
>>> >>>
>>> >>> —
>>> >>> Reply to this email directly or view it on GitHub
>>> >>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Andrew Phillips
>>> >> qrmedia
>>> >>
>>> >> Unless expressly stated otherwise, this message is confidential.
>>> >> Access to this e-mail by anyone else is unauthorised. If you are
>>> >> not an addressee, any disclosure or copying of the contents of
>>> >> this e-mail or any action taken (or not taken) in reliance on it
>>> >> is unauthorised and may be unlawful. If you are not an addressee,
>>> >> please inform the sender immediately.
>>> >>
>>> >> This message is confidential and may not be redistributed or
>>> >> broadcast in whole or part in any form, including but not limited
>>> >> to any form of internet transmission including email, usenet,
>>> >> newsgroups, www, irc, icq, etc.
>>> >> All liability for errors and viruses is disclaimed.
>>
>> --
>> Andrew Gaul
>> http://gaul.org/
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
You'll notice there's very little code to author an assertion (<200
lines in this case), so I'm not sure it is worthwhile making a
dependency, bothering someone to publish to maven and keep it current.
That said, this one is nicely written and actually includes tests...
tough call.
On Wed, Oct 8, 2014 at 8:06 PM, Andrew Gaul <ga...@apache.org> wrote:
> Roman Coedo started on assertj-mws; could you share some feedback with
> him?
>
> https://github.com/rcoedo/assertj-mws
>
> On Wed, Oct 08, 2014 at 07:47:45PM -0700, Adrian Cole wrote:
>> Also, I think we waste breath on some things that we haven't really
>> started doing.
>>
>> Ex. if I had to say that in a unit test, we prefer assert
>> !list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
>>
>> One thing I would love to see is to start using Truth or assertj which
>> have fluent ways to act on things like collections without one wanting
>> to cut themselves. For example, we could generate assertj assertions
>> for our common models, which could make things like MockWebServer,
>> BlobStore, FluentIterable, etc. assertions far more delightful to
>> write.
>>
>> -A
>>
>> On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com> wrote:
>> > I think google looks to be in pretty good shape, including appropriate
>> > use of weird builder
>> >
>> > ex. weird builder is kindof ok when there exists a base resource from
>> > which everything else is derived. ex Resource vs Instance.
>> >
>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
>> >
>> > However, things not sensible to extend have concrete builders.
>> >
>> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
>> >
>> > I haven't reviewed through all of google, but each time I've
>> > accidentally entered, it has looked pretty good.
>> >
>> > -A
>> >
>> > On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> >>> I will volunteer to undebt one provider for each provider someone else
>> >>> volunteers for. Anyone with me?
>> >>
>> >>
>> >> I'm up! Any specific one that you feel would be a good example?
>> >>
>> >> Before we start, though: do we have an up-to-date list of what we consider
>> >> Good Practice and what we want to clean up here? I fully sympathize with
>> >> Inbar, but I think part of the problem here is that beyond copy-pasting
>> >> existing code I don't think we have anything outside of people's heads that
>> >> describes what we're actually looking for. The few dev guides we have [1, 2,
>> >> 3] certainly aren't enough.
>> >>
>> >> I obviously would love to be a position where all code has been cleaned up
>> >> to the point that copy-paste is in line with the jclouds State Of The Art.
>> >> Even if that is not the case, it would at least be great if contributors
>> >> could have somewhere to go for advice. And we should probably agree that
>> >> we'll prefer current guidelines over consistency with the rest of an older
>> >> codebase.
>> >>
>> >> Getting back to this one: draft of what we're looking for?
>> >>
>> >> * MWS tests
>> >> * No abstract builders
>> >> * Use Objects.equal in equals()
>> >> * Move common @Path to top of interface
>> >> * private, error-throwing constructors for domain objects created by
>> >> builders
>> >>
>> >> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
>> >> that triggered this here...
>> >>
>> >> Regards
>> >>
>> >> ap
>> >>
>> >> [1] https://wiki.apache.org/jclouds/Coding%20Standards
>> >> [2] https://wiki.apache.org/jclouds/Best%20Practices
>> >> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>> >>
>> >>
>> >>
>> >>>
>> >>> -A
>> >>> ---------- Forwarded message ----------
>> >>> From: "inbar stolberg" <no...@github.com>
>> >>> Date: Oct 8, 2014 4:51 PM
>> >>> Subject: Re: [jclouds] cinder availability zones api + list call
>> >>> implemented (#560)
>> >>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>> >>> Cc:
>> >>>
>> >>> In
>> >>>
>> >>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>> >>>
>> >>>> + * See the License for the specific language governing permissions and
>> >>>> + * limitations under the License.
>> >>>> + */
>> >>>> +
>> >>>> +package org.jclouds.openstack.cinder.v1.extensions;
>> >>>> +
>> >>>> +/**
>> >>>> + * Extension namespaces
>> >>>> + */
>> >>>> +public final class ExtensionNamespaces {
>> >>>> +
>> >>>> + /**
>> >>>> + * Admin Action extension
>> >>>> + */
>> >>>> + public static final String ADMIN_ACTIONS =
>> >>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>> >>>> +
>> >>>
>> >>>
>> >>> 90% of this code is copy paste of existing code from the same branch not
>> >>> old code either ...
>> >>> I have no problem fixing this but doesnt seem like there is cosistency in
>> >>> the code if i can copy paste some thing and get rejected over 100
>> >>> lines....
>> >>> :/
>> >>>
>> >>> —
>> >>> Reply to this email directly or view it on GitHub
>> >>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Andrew Phillips
>> >> qrmedia
>> >>
>> >> Unless expressly stated otherwise, this message is confidential.
>> >> Access to this e-mail by anyone else is unauthorised. If you are
>> >> not an addressee, any disclosure or copying of the contents of
>> >> this e-mail or any action taken (or not taken) in reliance on it
>> >> is unauthorised and may be unlawful. If you are not an addressee,
>> >> please inform the sender immediately.
>> >>
>> >> This message is confidential and may not be redistributed or
>> >> broadcast in whole or part in any form, including but not limited
>> >> to any form of internet transmission including email, usenet,
>> >> newsgroups, www, irc, icq, etc.
>> >> All liability for errors and viruses is disclaimed.
>
> --
> Andrew Gaul
> http://gaul.org/
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Andrew Gaul <ga...@apache.org>.
Roman Coedo started on assertj-mws; could you share some feedback with
him?
https://github.com/rcoedo/assertj-mws
On Wed, Oct 08, 2014 at 07:47:45PM -0700, Adrian Cole wrote:
> Also, I think we waste breath on some things that we haven't really
> started doing.
>
> Ex. if I had to say that in a unit test, we prefer assert
> !list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
>
> One thing I would love to see is to start using Truth or assertj which
> have fluent ways to act on things like collections without one wanting
> to cut themselves. For example, we could generate assertj assertions
> for our common models, which could make things like MockWebServer,
> BlobStore, FluentIterable, etc. assertions far more delightful to
> write.
>
> -A
>
> On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com> wrote:
> > I think google looks to be in pretty good shape, including appropriate
> > use of weird builder
> >
> > ex. weird builder is kindof ok when there exists a base resource from
> > which everything else is derived. ex Resource vs Instance.
> >
> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
> >
> > However, things not sensible to extend have concrete builders.
> >
> > https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
> >
> > I haven't reviewed through all of google, but each time I've
> > accidentally entered, it has looked pretty good.
> >
> > -A
> >
> > On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
> >>> I will volunteer to undebt one provider for each provider someone else
> >>> volunteers for. Anyone with me?
> >>
> >>
> >> I'm up! Any specific one that you feel would be a good example?
> >>
> >> Before we start, though: do we have an up-to-date list of what we consider
> >> Good Practice and what we want to clean up here? I fully sympathize with
> >> Inbar, but I think part of the problem here is that beyond copy-pasting
> >> existing code I don't think we have anything outside of people's heads that
> >> describes what we're actually looking for. The few dev guides we have [1, 2,
> >> 3] certainly aren't enough.
> >>
> >> I obviously would love to be a position where all code has been cleaned up
> >> to the point that copy-paste is in line with the jclouds State Of The Art.
> >> Even if that is not the case, it would at least be great if contributors
> >> could have somewhere to go for advice. And we should probably agree that
> >> we'll prefer current guidelines over consistency with the rest of an older
> >> codebase.
> >>
> >> Getting back to this one: draft of what we're looking for?
> >>
> >> * MWS tests
> >> * No abstract builders
> >> * Use Objects.equal in equals()
> >> * Move common @Path to top of interface
> >> * private, error-throwing constructors for domain objects created by
> >> builders
> >>
> >> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
> >> that triggered this here...
> >>
> >> Regards
> >>
> >> ap
> >>
> >> [1] https://wiki.apache.org/jclouds/Coding%20Standards
> >> [2] https://wiki.apache.org/jclouds/Best%20Practices
> >> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
> >>
> >>
> >>
> >>>
> >>> -A
> >>> ---------- Forwarded message ----------
> >>> From: "inbar stolberg" <no...@github.com>
> >>> Date: Oct 8, 2014 4:51 PM
> >>> Subject: Re: [jclouds] cinder availability zones api + list call
> >>> implemented (#560)
> >>> To: "jclouds/jclouds" <jc...@noreply.github.com>
> >>> Cc:
> >>>
> >>> In
> >>>
> >>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
> >>>
> >>>> + * See the License for the specific language governing permissions and
> >>>> + * limitations under the License.
> >>>> + */
> >>>> +
> >>>> +package org.jclouds.openstack.cinder.v1.extensions;
> >>>> +
> >>>> +/**
> >>>> + * Extension namespaces
> >>>> + */
> >>>> +public final class ExtensionNamespaces {
> >>>> +
> >>>> + /**
> >>>> + * Admin Action extension
> >>>> + */
> >>>> + public static final String ADMIN_ACTIONS =
> >>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
> >>>> +
> >>>
> >>>
> >>> 90% of this code is copy paste of existing code from the same branch not
> >>> old code either ...
> >>> I have no problem fixing this but doesnt seem like there is cosistency in
> >>> the code if i can copy paste some thing and get rejected over 100
> >>> lines....
> >>> :/
> >>>
> >>> —
> >>> Reply to this email directly or view it on GitHub
> >>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
> >>>
> >>
> >>
> >>
> >> --
> >> Andrew Phillips
> >> qrmedia
> >>
> >> Unless expressly stated otherwise, this message is confidential.
> >> Access to this e-mail by anyone else is unauthorised. If you are
> >> not an addressee, any disclosure or copying of the contents of
> >> this e-mail or any action taken (or not taken) in reliance on it
> >> is unauthorised and may be unlawful. If you are not an addressee,
> >> please inform the sender immediately.
> >>
> >> This message is confidential and may not be redistributed or
> >> broadcast in whole or part in any form, including but not limited
> >> to any form of internet transmission including email, usenet,
> >> newsgroups, www, irc, icq, etc.
> >> All liability for errors and viruses is disclaimed.
--
Andrew Gaul
http://gaul.org/
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
Also, I think we waste breath on some things that we haven't really
started doing.
Ex. if I had to say that in a unit test, we prefer assert
!list.isEmpty() vs list.size() > 0, I'd want to shoot myself.
One thing I would love to see is to start using Truth or assertj which
have fluent ways to act on things like collections without one wanting
to cut themselves. For example, we could generate assertj assertions
for our common models, which could make things like MockWebServer,
BlobStore, FluentIterable, etc. assertions far more delightful to
write.
-A
On Wed, Oct 8, 2014 at 7:40 PM, Adrian Cole <ad...@gmail.com> wrote:
> I think google looks to be in pretty good shape, including appropriate
> use of weird builder
>
> ex. weird builder is kindof ok when there exists a base resource from
> which everything else is derived. ex Resource vs Instance.
>
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
>
> However, things not sensible to extend have concrete builders.
>
> https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
>
> I haven't reviewed through all of google, but each time I've
> accidentally entered, it has looked pretty good.
>
> -A
>
> On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>>> I will volunteer to undebt one provider for each provider someone else
>>> volunteers for. Anyone with me?
>>
>>
>> I'm up! Any specific one that you feel would be a good example?
>>
>> Before we start, though: do we have an up-to-date list of what we consider
>> Good Practice and what we want to clean up here? I fully sympathize with
>> Inbar, but I think part of the problem here is that beyond copy-pasting
>> existing code I don't think we have anything outside of people's heads that
>> describes what we're actually looking for. The few dev guides we have [1, 2,
>> 3] certainly aren't enough.
>>
>> I obviously would love to be a position where all code has been cleaned up
>> to the point that copy-paste is in line with the jclouds State Of The Art.
>> Even if that is not the case, it would at least be great if contributors
>> could have somewhere to go for advice. And we should probably agree that
>> we'll prefer current guidelines over consistency with the rest of an older
>> codebase.
>>
>> Getting back to this one: draft of what we're looking for?
>>
>> * MWS tests
>> * No abstract builders
>> * Use Objects.equal in equals()
>> * Move common @Path to top of interface
>> * private, error-throwing constructors for domain objects created by
>> builders
>>
>> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
>> that triggered this here...
>>
>> Regards
>>
>> ap
>>
>> [1] https://wiki.apache.org/jclouds/Coding%20Standards
>> [2] https://wiki.apache.org/jclouds/Best%20Practices
>> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>>
>>
>>
>>>
>>> -A
>>> ---------- Forwarded message ----------
>>> From: "inbar stolberg" <no...@github.com>
>>> Date: Oct 8, 2014 4:51 PM
>>> Subject: Re: [jclouds] cinder availability zones api + list call
>>> implemented (#560)
>>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>>> Cc:
>>>
>>> In
>>>
>>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>>>
>>>> + * See the License for the specific language governing permissions and
>>>> + * limitations under the License.
>>>> + */
>>>> +
>>>> +package org.jclouds.openstack.cinder.v1.extensions;
>>>> +
>>>> +/**
>>>> + * Extension namespaces
>>>> + */
>>>> +public final class ExtensionNamespaces {
>>>> +
>>>> + /**
>>>> + * Admin Action extension
>>>> + */
>>>> + public static final String ADMIN_ACTIONS =
>>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>>>> +
>>>
>>>
>>> 90% of this code is copy paste of existing code from the same branch not
>>> old code either ...
>>> I have no problem fixing this but doesnt seem like there is cosistency in
>>> the code if i can copy paste some thing and get rejected over 100
>>> lines....
>>> :/
>>>
>>> —
>>> Reply to this email directly or view it on GitHub
>>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>>>
>>
>>
>>
>> --
>> Andrew Phillips
>> qrmedia
>>
>> Unless expressly stated otherwise, this message is confidential.
>> Access to this e-mail by anyone else is unauthorised. If you are
>> not an addressee, any disclosure or copying of the contents of
>> this e-mail or any action taken (or not taken) in reliance on it
>> is unauthorised and may be unlawful. If you are not an addressee,
>> please inform the sender immediately.
>>
>> This message is confidential and may not be redistributed or
>> broadcast in whole or part in any form, including but not limited
>> to any form of internet transmission including email, usenet,
>> newsgroups, www, irc, icq, etc.
>> All liability for errors and viruses is disclaimed.
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
I think google looks to be in pretty good shape, including appropriate
use of weird builder
ex. weird builder is kindof ok when there exists a base resource from
which everything else is derived. ex Resource vs Instance.
https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Resource.java
https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Instance.java
However, things not sensible to extend have concrete builders.
https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/ListPage.java
I haven't reviewed through all of google, but each time I've
accidentally entered, it has looked pretty good.
-A
On Wed, Oct 8, 2014 at 7:11 PM, Andrew Phillips <ap...@qrmedia.com> wrote:
>> I will volunteer to undebt one provider for each provider someone else
>> volunteers for. Anyone with me?
>
>
> I'm up! Any specific one that you feel would be a good example?
>
> Before we start, though: do we have an up-to-date list of what we consider
> Good Practice and what we want to clean up here? I fully sympathize with
> Inbar, but I think part of the problem here is that beyond copy-pasting
> existing code I don't think we have anything outside of people's heads that
> describes what we're actually looking for. The few dev guides we have [1, 2,
> 3] certainly aren't enough.
>
> I obviously would love to be a position where all code has been cleaned up
> to the point that copy-paste is in line with the jclouds State Of The Art.
> Even if that is not the case, it would at least be great if contributors
> could have somewhere to go for advice. And we should probably agree that
> we'll prefer current guidelines over consistency with the rest of an older
> codebase.
>
> Getting back to this one: draft of what we're looking for?
>
> * MWS tests
> * No abstract builders
> * Use Objects.equal in equals()
> * Move common @Path to top of interface
> * private, error-throwing constructors for domain objects created by
> builders
>
> Is this the kind of stuff you have in mind? I'm just looking the PR by Inbar
> that triggered this here...
>
> Regards
>
> ap
>
> [1] https://wiki.apache.org/jclouds/Coding%20Standards
> [2] https://wiki.apache.org/jclouds/Best%20Practices
> [3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>
>
>
>>
>> -A
>> ---------- Forwarded message ----------
>> From: "inbar stolberg" <no...@github.com>
>> Date: Oct 8, 2014 4:51 PM
>> Subject: Re: [jclouds] cinder availability zones api + list call
>> implemented (#560)
>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>> Cc:
>>
>> In
>>
>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>>
>>> + * See the License for the specific language governing permissions and
>>> + * limitations under the License.
>>> + */
>>> +
>>> +package org.jclouds.openstack.cinder.v1.extensions;
>>> +
>>> +/**
>>> + * Extension namespaces
>>> + */
>>> +public final class ExtensionNamespaces {
>>> +
>>> + /**
>>> + * Admin Action extension
>>> + */
>>> + public static final String ADMIN_ACTIONS =
>>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>>> +
>>
>>
>> 90% of this code is copy paste of existing code from the same branch not
>> old code either ...
>> I have no problem fixing this but doesnt seem like there is cosistency in
>> the code if i can copy paste some thing and get rejected over 100
>> lines....
>> :/
>>
>> —
>> Reply to this email directly or view it on GitHub
>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>>
>
>
>
> --
> Andrew Phillips
> qrmedia
>
> Unless expressly stated otherwise, this message is confidential.
> Access to this e-mail by anyone else is unauthorised. If you are
> not an addressee, any disclosure or copying of the contents of
> this e-mail or any action taken (or not taken) in reliance on it
> is unauthorised and may be unlawful. If you are not an addressee,
> please inform the sender immediately.
>
> This message is confidential and may not be redistributed or
> broadcast in whole or part in any form, including but not limited
> to any form of internet transmission including email, usenet,
> newsgroups, www, irc, icq, etc.
> All liability for errors and viruses is disclaimed.
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Andrew Phillips <ap...@qrmedia.com>.
> I will volunteer to undebt one provider for each provider someone else
> volunteers for. Anyone with me?
I'm up! Any specific one that you feel would be a good example?
Before we start, though: do we have an up-to-date list of what we
consider Good Practice and what we want to clean up here? I fully
sympathize with Inbar, but I think part of the problem here is that
beyond copy-pasting existing code I don't think we have anything
outside of people's heads that describes what we're actually looking
for. The few dev guides we have [1, 2, 3] certainly aren't enough.
I obviously would love to be a position where all code has been
cleaned up to the point that copy-paste is in line with the jclouds
State Of The Art. Even if that is not the case, it would at least be
great if contributors could have somewhere to go for advice. And we
should probably agree that we'll prefer current guidelines over
consistency with the rest of an older codebase.
Getting back to this one: draft of what we're looking for?
* MWS tests
* No abstract builders
* Use Objects.equal in equals()
* Move common @Path to top of interface
* private, error-throwing constructors for domain objects created by builders
Is this the kind of stuff you have in mind? I'm just looking the PR by
Inbar that triggered this here...
Regards
ap
[1] https://wiki.apache.org/jclouds/Coding%20Standards
[2] https://wiki.apache.org/jclouds/Best%20Practices
[3] https://wiki.apache.org/jclouds/Create%20a%20New%20API%20or%20Provider
>
> -A
> ---------- Forwarded message ----------
> From: "inbar stolberg" <no...@github.com>
> Date: Oct 8, 2014 4:51 PM
> Subject: Re: [jclouds] cinder availability zones api + list call
> implemented (#560)
> To: "jclouds/jclouds" <jc...@noreply.github.com>
> Cc:
>
> In
> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>
>> + * See the License for the specific language governing permissions and
>> + * limitations under the License.
>> + */
>> +
>> +package org.jclouds.openstack.cinder.v1.extensions;
>> +
>> +/**
>> + * Extension namespaces
>> + */
>> +public final class ExtensionNamespaces {
>> +
>> + /**
>> + * Admin Action extension
>> + */
>> + public static final String ADMIN_ACTIONS =
>> "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>> +
>
> 90% of this code is copy paste of existing code from the same branch not
> old code either ...
> I have no problem fixing this but doesnt seem like there is cosistency in
> the code if i can copy paste some thing and get rejected over 100 lines....
> :/
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>
--
Andrew Phillips
qrmedia
Unless expressly stated otherwise, this message is confidential.
Access to this e-mail by anyone else is unauthorised. If you are
not an addressee, any disclosure or copying of the contents of
this e-mail or any action taken (or not taken) in reliance on it
is unauthorised and may be unlawful. If you are not an addressee,
please inform the sender immediately.
This message is confidential and may not be redistributed or
broadcast in whole or part in any form, including but not limited
to any form of internet transmission including email, usenet,
newsgroups, www, irc, icq, etc.
All liability for errors and viruses is disclaimed.
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Andrew Phillips <ap...@qrmedia.com>.
> building on that, I think the first priority of reviewer time includes.
>
> What is this changing?
> Why is jclouds better off with this change?
> If feature, who is using this, and for what?
Big +1 for copying those points straight to the Committer Guide [1].
And, much more importantly of course, for trying to ensure they are
enshrined in our collective thinking!
ap
[1] https://wiki.apache.org/jclouds/Committers%20Guide
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Adrian Cole <ad...@gmail.com>.
building on that, I think the first priority of reviewer time includes.
What is this changing?
Why is jclouds better off with this change?
If feature, who is using this, and for what?
A lot of our reviews are extremely focused on the mechanics of code,
and that makes it possible to skip the first step.. what exactly are
we building here?
-A
On Wed, Oct 8, 2014 at 8:07 PM, Andrew Gaul <ga...@apache.org> wrote:
> Not picking on this pull request in particular, but I find stylistic
> feedback to be a poor use of code reviews. We should use humans to
> identify logic errors, missing tests, and higher-level code quality
> (HashCode vs. byte[], Objects.equals, etc.). We should use machines to
> codify lower-level issues (whitespace, brace placement, etc.) or just
> let it go. Could the reviewers making large numbers of stylistic
> comments investigate enabling additional Checkstyle violations to
> automate these suggestions?
>
> On Wed, Oct 08, 2014 at 06:53:47PM -0700, Adrian Cole wrote:
>> Hi, team.
>>
>> Having done sweeping change across a dozen providers I totally feel this
>> pain.
>>
>> In short, we know there are terrible malpractice like abstract builder for
>> one field in existing code, yet we don't do anything about it. Then, when
>> someone new comes in, somewhere between us telling them to delete extra
>> spaces, we ack that the thing we know sucks is something they pasted.
>>
>> It is reasonable for them to not know the right answer or to be overwhelmed
>> by what seems to be a timesoaking response to an innocent change.
>>
>> It isn't hard to fixup the existing providers so that they are already good
>> examples by the time someone goes to change them. I.e. they don't carry
>> behavior we know is awful. I tried to do some of that when I did the
>> unasyncing.
>>
>> This stuff happens, basically a norm of tech debt. Now that we have
>> checkstyle sorted, perhaps we can start paying down this sort of debt?
>>
>> I will volunteer to undebt one provider for each provider someone else
>> volunteers for. Anyone with me?
>>
>> -A
>> ---------- Forwarded message ----------
>> From: "inbar stolberg" <no...@github.com>
>> Date: Oct 8, 2014 4:51 PM
>> Subject: Re: [jclouds] cinder availability zones api + list call
>> implemented (#560)
>> To: "jclouds/jclouds" <jc...@noreply.github.com>
>> Cc:
>>
>> In
>> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>>
>> > + * See the License for the specific language governing permissions and
>> > + * limitations under the License.
>> > + */
>> > +
>> > +package org.jclouds.openstack.cinder.v1.extensions;
>> > +
>> > +/**
>> > + * Extension namespaces
>> > + */
>> > +public final class ExtensionNamespaces {
>> > +
>> > + /**
>> > + * Admin Action extension
>> > + */
>> > + public static final String ADMIN_ACTIONS = "http://docs.openstack.org/ext/admin-actions/api/v1.1";
>> > +
>>
>> 90% of this code is copy paste of existing code from the same branch not
>> old code either ...
>> I have no problem fixing this but doesnt seem like there is cosistency in
>> the code if i can copy paste some thing and get rejected over 100 lines....
>> :/
>>
>> —
>> Reply to this email directly or view it on GitHub
>> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
>
> --
> Andrew Gaul
> http://gaul.org/
Re: Worst experience ever. Was Re: [jclouds] cinder availability
zones api + list call implemented (#560)
Posted by Andrew Gaul <ga...@apache.org>.
Not picking on this pull request in particular, but I find stylistic
feedback to be a poor use of code reviews. We should use humans to
identify logic errors, missing tests, and higher-level code quality
(HashCode vs. byte[], Objects.equals, etc.). We should use machines to
codify lower-level issues (whitespace, brace placement, etc.) or just
let it go. Could the reviewers making large numbers of stylistic
comments investigate enabling additional Checkstyle violations to
automate these suggestions?
On Wed, Oct 08, 2014 at 06:53:47PM -0700, Adrian Cole wrote:
> Hi, team.
>
> Having done sweeping change across a dozen providers I totally feel this
> pain.
>
> In short, we know there are terrible malpractice like abstract builder for
> one field in existing code, yet we don't do anything about it. Then, when
> someone new comes in, somewhere between us telling them to delete extra
> spaces, we ack that the thing we know sucks is something they pasted.
>
> It is reasonable for them to not know the right answer or to be overwhelmed
> by what seems to be a timesoaking response to an innocent change.
>
> It isn't hard to fixup the existing providers so that they are already good
> examples by the time someone goes to change them. I.e. they don't carry
> behavior we know is awful. I tried to do some of that when I did the
> unasyncing.
>
> This stuff happens, basically a norm of tech debt. Now that we have
> checkstyle sorted, perhaps we can start paying down this sort of debt?
>
> I will volunteer to undebt one provider for each provider someone else
> volunteers for. Anyone with me?
>
> -A
> ---------- Forwarded message ----------
> From: "inbar stolberg" <no...@github.com>
> Date: Oct 8, 2014 4:51 PM
> Subject: Re: [jclouds] cinder availability zones api + list call
> implemented (#560)
> To: "jclouds/jclouds" <jc...@noreply.github.com>
> Cc:
>
> In
> apis/openstack-cinder/src/main/java/org/jclouds/openstack/cinder/v1/extensions/ExtensionNamespaces.java:
>
> > + * See the License for the specific language governing permissions and
> > + * limitations under the License.
> > + */
> > +
> > +package org.jclouds.openstack.cinder.v1.extensions;
> > +
> > +/**
> > + * Extension namespaces
> > + */
> > +public final class ExtensionNamespaces {
> > +
> > + /**
> > + * Admin Action extension
> > + */
> > + public static final String ADMIN_ACTIONS = "http://docs.openstack.org/ext/admin-actions/api/v1.1";
> > +
>
> 90% of this code is copy paste of existing code from the same branch not
> old code either ...
> I have no problem fixing this but doesnt seem like there is cosistency in
> the code if i can copy paste some thing and get rejected over 100 lines....
> :/
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/jclouds/jclouds/pull/560/files#r18620246>.
--
Andrew Gaul
http://gaul.org/