https://github.com/rcoedo/assertj-mws/issues/1
On Wed, Oct 8, 2014 at 8:29 PM, Adrian Cole <adrian.f.c...@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 <g...@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 <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/