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 <adrian.f.c...@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 <aphill...@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" <notificati...@github.com> > >>> Date: Oct 8, 2014 4:51 PM > >>> Subject: Re: [jclouds] cinder availability zones api + list call > >>> implemented (#560) > >>> To: "jclouds/jclouds" <jclo...@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/
