+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" <adrian.f.c...@gmail.com> escribió: > 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/ >
