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/
