Pps we can't change restannotationprocessor yet anyway because not only have we not moved off the deprecated approach of expect tests, we still have tests that use the even older restannotationprocessortest!
Iotw, if anyone has time to offer and wanta to make it count, please migrate off deprecated test frameworks (or at least atop making new tests with them!) and onto MWS. Not only is this a better idea anyway, it reduces the backlog of work needed to even start fixing core. -A On Nov 5, 2014 11:17 AM, "Adrian Cole" <adrian.f.c...@gmail.com> wrote: > PS one of my largest disappointments is that folks haven't helped with > things discussed for years on RestAnnotationProcessor. For example, we > had a plan to deprecate and remove the async interfaces that required > a lot of the complexity there. That started and then it literally > waited until I did all of the rest of the cleaning over a weekend. > When we really care about something, and want to make things better, > chipping in to complete rudimentary tasks is the best way to preserve > time for folks like me who can help address complex core issues. > > Relying on one person to not only improve core, but also address > deprecation cleanup of, in this case most async apis outside openstack > is a great way of ensuring success. There's plenty of other known > problem road fixes left as presents for me personally, such as moving > off Expect tests, which are horribly difficult to debug, and trip > builds etc. > > Long story short, (and this is addressed to devs, not Diwaker) put > skin in the game, vote with your pull requests, clear path for core > changes if you can't do them yourselves. This will facilitate the > ability to get changes we all want in. > > /me ends soap box > > On Wed, Nov 5, 2014 at 11:06 AM, Adrian Cole <adrian.f.c...@gmail.com> > wrote: > > Thanks for chiming in. some notes on notes below! > > > >> through jclouds. This conversion not only makes jclouds needlessly at > >> the whim of guava compatibility, but is also unnecessarily expensive. > > > > Perhaps, but are these the biggest pain points for users/devs? The > > Guava compatibility fiasco is admittedly frustrating, but hopefully > > rare going forward. > > Guava prevents blobstore (and jclouds) from being considered many > > android environments. Guava compatibility is not only a frustration, > > but a non-starter for folks who write frameworks. This thread is > > thoroughly discussed elsewhere. We don't need a guava dep for > > blobstore so can avoid this class of problems completely in the > > future. For example, once our views stop propagating guava, we can > > clean it from core. This is clearly not your biggest concern, but > > believe me, being the author of jclouds and not being able to use it > > in most recent companies has made me quite frustrated potential user. > > > > As for pain points, IMO there are other bigger and > > lower hanging fruit that may be worth tackling. > > > > Two concrete examples that are not blobstore specific: > > > > 1. URL encoding/decoding issues: > > https://issues.apache.org/jira/browse/JCLOUDS-217 > > Agreed this isn't blobstore specific and more a favorite bug. > > > > 2. RestAnnotationProcessor magic: there are two sub-issues here > > actually. First is the performance overhead of all the reflection that > > happens to make this work. I've not measured it, but we have run into > > cases in the past where reflection added non-trivial overhead (e.g. > > https://issues.apache.org/jira/browse/JCLOUDS-301). The second (and > > perhaps bigger) issue is that the code base is really hard to > > penetrate for new developers. At work, every new jclouds contributor > > has had a long ramp up and faced a steep learning curve just to figure > > out how things work before being able to make productive changes. > > And yet no-one has helped to fix this. We are amazingly capable of > > complaining for years, right? I already solved this in netflix feign > > and can obviously solve this here. Not blobstore related, but > > certainly and provably solvable. > > > >> In summary, I would like to fork BlobStore so that it can progress in > > > > Can you elaborate a bit more on the plans for existing blobstore and > > impact (if any) on existing consumers? IIUC, the proposal is to leave > > the current blobstore as is and develop the fork in parallel? Will > > there be a switch when compatibility is reached or will users always > > have the choice of using the legacy API? Preferably the latter, but > > that would double the effort for bug fixes and feature additions (e.g. > > implementing S3 V4 signatures). The former will require consumers to > > change their applications and runs the risk of introducing > > regressions. So neither option seems safe. > > Some methods as mention should have been dropped years ago. We can > > deprecate them now. We can also make a janky bridge once the new apis > > are in. Most projects evolve more than once every 5 years. we can do > > better, right? Even if it took us a year, it adds hope. > > > >> If anyone is interested in helping on this, let me know. I'll open a > >> jira in a bit. > > > > Definitely interested! What's the JIRA for this? > > Not created yet, but will do once I finish cleaning up other things :) > > Thanks for the interest! >
