<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 4:52 PM, Wojciech Trocki <span dir="ltr"><<a href="mailto:wtrocki@redhat.com" target="_blank">wtrocki@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Sorry for not being clear. I mean RainCatcher framework consumers - mobile developers etc.  </div><div class="gmail_extra"><span class="gmail-"><br clear="all"></span></div></blockquote><div><br></div><div>In that case having them clone and edit the Raincatcher modules to extend the framework is wrong.  </div><div><br></div><div>There is no right way to do that, any project based on that model is doomed to fail.  </div><div><br></div><div>Ahem, with that out of my system.</div><div><br></div><div>The reason this is not what we should encourage our users to do is that when we release updates to Raincatcher the responsibility of back porting those those updates will be on the end developers.  Suddenly keeping their Raincatcher modules up to date becomes a massive amount of work that won't get done.  If we uncover severe bugs (such as security bugs) then getting out users to update their dependencies is of the utmost importance.  If updating their dependencies requires rewriting their modules for trivial changes, then they won't do it for important changes either.</div><div><br></div><div>The correct way to fix this is to use Angular's dependency injection mechanisms to override the default Raincatcher behaviors with the user's behaviors when this becomes necessary.  IE we must expose a rich API that we support.  This is much easier to do in Angular 2 with Typescript than in Angular 1 with JavaScript.  </div><div><br></div><div><br></div><div>As a concrete example, let's take a Restful library on Android, aerogear-android-pipe (<a href="https://github.com/aerogear/aerogear-android-pipe">https://github.com/aerogear/aerogear-android-pipe</a>).</div><div><br></div><div>In order to make a RESTful call we use a fluent builder to build the request and handle the response in a callback.  By default we use JSON encoding.</div><div><br></div><div><pre style="color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">PipeManager.config("developers", RestfulPipeConfiguration.class)
           .withUrl(new URL("<a href="http://www.server.com/developer">http://www.server.com/developer</a>"))
           .forClass(Developer.class);

Pipe<Developer> pipe = PipeManager.getPipe("developers");

pipe.read(new AbstractCallback<List<Developer>>() {
    @Override
    public void onSuccess(List<Developer> devs) {
        // Here you have a list of Developers made easy
    }

    @Override
    public void onFailure(Exception e) {
        // Oops! Something is wrong. Probably your internet is down :P
    }
});</pre>Let's say that instead of using JSON the end developer has a requirement to use an XML serialization format.  In this library the developer would implement `RequestBuilder` and `ResponseParser` interfaces and supply them to the library via PipeManager.config.  In the Raincatcher model the user would download the pipe library and edit the code and deploy it herself.  </div><div><br></div><div>However, there is currently a bug in AeroGear Pipe where the request is buffered in memory before it is sent to the server.  If this were to be fixed then users who used our API hooks to enable XML parsing would be able to update their application dependency and rebuild their application.  This is a very low risk operation which can even be automated.</div><div><br></div><div>However, if they had forked our library then they would be responsible for 1) noticing we had updated our library, 2) back porting our fix to their fork, and 3) verifying that they back ported the fix correctly.  This is much riskier and much harder to maintain because it requires more engineering effort both at development time and during maintenance.</div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_extra"><span class="gmail-"><div><div class="gmail-m_-3820355595752789550gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px"><span style="color:rgb(153,153,153);font-size:small">Wojciech Trocki</span></div><div><div><font color="#999999" size="2">Software Engineer</font><font color="#999999" style="font-size:small">, </font><span style="font-size:small;color:rgb(153,153,153)">Red Hat Mobile</span></div></div></div></div></div></div></div></div>
<br></span><div><div class="gmail-h5"><div class="gmail_quote">On Wed, Feb 8, 2017 at 9:49 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Wed, Feb 8, 2017 at 4:44 PM, Wojciech Trocki <span dir="ltr"><<a href="mailto:wtrocki@redhat.com" target="_blank">wtrocki@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I was talking about this today with the team. Reducing number of repositories would clash with current development model where <br>Raincacher developers should fork each module and make changes directly on the fork. </div></blockquote><div><br></div></span><div>By developers do you mean the rmad team or do you mean our end users?</div><div><div class="gmail-m_-3820355595752789550h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">We can merge some repos together, but only after we propose some alternative way to extend "modules". Team already started some small with refactoring to typescript, so we are on the good path.<br>For now we can just pin the most important repositories to the page header. Making sure that repositories hare Readme would be a bonus. <br>See bellow:<div><div><a href="https://github.com/feedhenry-raincatcher" target="_blank">https://github.com/feedhenry-r<wbr>aincatcher</a><span class="gmail-m_-3820355595752789550m_4599241502001303716HOEnZb"><font color="#888888"><br></font></span></div></div></div><div class="gmail_extra"><span class="gmail-m_-3820355595752789550m_4599241502001303716HOEnZb"><font color="#888888"><br clear="all"><div><div class="gmail-m_-3820355595752789550m_4599241502001303716m_-1990161068937637181gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px"><span style="color:rgb(153,153,153);font-size:small">Wojciech Trocki</span></div><div><div><font color="#999999" size="2">Software Engineer</font><font color="#999999" style="font-size:small">, </font><span style="font-size:small;color:rgb(153,153,153)">Red Hat Mobile</span></div></div></div></div></div></div></div></div></font></span><div><div class="gmail-m_-3820355595752789550m_4599241502001303716h5">
<br><div class="gmail_quote">On Wed, Feb 8, 2017 at 6:39 PM, Peter Darrow <span dir="ltr"><<a href="mailto:pdarrow@redhat.com" target="_blank">pdarrow@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">What do you guys think about reducing the number of repositories we're dealing with? We could still publish individual RainCatcher modules to NPM but it might help with visibility / overhead issue of having tons of small repos. Just a thought! </div><div class="gmail-m_-3820355595752789550m_4599241502001303716m_-1990161068937637181HOEnZb"><div class="gmail-m_-3820355595752789550m_4599241502001303716m_-1990161068937637181h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 7, 2017 at 4:40 PM, Summers Pittman <span dir="ltr"><<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Tue, Feb 7, 2017 at 3:02 PM, David Martin <span dir="ltr"><<a href="mailto:davmarti@redhat.com" target="_blank">davmarti@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">I'm a big fan of conventions.<br>
This sounds like a good move.<br>
+1</p></blockquote><div><br></div></span><div>Ha! There's already a JIRA <a href="https://issues.jboss.org/browse/RAINCATCH-1" target="_blank">https://issues.jboss.org/<wbr>browse/RAINCATCH-1</a></div><span><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="gmail_quote"><div><div class="gmail-m_-3820355595752789550m_4599241502001303716m_-1990161068937637181m_1670035962156325814m_9063529658130701733gmail-h5">On 7 Feb 2017 19:06, "Summers Pittman" <<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_-3820355595752789550m_4599241502001303716m_-1990161068937637181m_1670035962156325814m_9063529658130701733gmail-h5"><div dir="ltr">The Raincatcher packages are currently fh-wfm-$moduleName.  There are pull requests (ex <a href="https://github.com/feedhenry-raincatcher/raincatcher-mediator/pull/8" target="_blank">https://github.com/feedhen<wbr>ry-raincatcher/raincatcher-med<wbr>iator/pull/8</a>) to rename them to raincatcher-$moduleName.  This puts them inline with the project naming scheme.<div><br></div><div>The linked pull request has some context around the name change.</div><div><br></div><div>Should we pull the trigger on this rename as part of our refactoring?</div><div><br></div><div>Summers</div></div>
<br></div></div>______________________________<wbr>_________________<br>
Feedhenry-raincatcher mailing list<br>
<a href="mailto:Feedhenry-raincatcher@redhat.com" target="_blank">Feedhenry-raincatcher@redhat.c<wbr>om</a><br>
<a href="https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/feedhenry-raincatche<wbr>r</a><br>
<br></blockquote></div>
</blockquote></span></div><br></div></div>
<br>______________________________<wbr>_________________<br>
Feedhenry-raincatcher mailing list<br>
<a href="mailto:Feedhenry-raincatcher@redhat.com" target="_blank">Feedhenry-raincatcher@redhat.c<wbr>om</a><br>
<a href="https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/feedhenry-raincatche<wbr>r</a><br>
<br></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Feedhenry-raincatcher mailing list<br>
<a href="mailto:Feedhenry-raincatcher@redhat.com" target="_blank">Feedhenry-raincatcher@redhat.c<wbr>om</a><br>
<a href="https://www.redhat.com/mailman/listinfo/feedhenry-raincatcher" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/feedhenry-raincatche<wbr>r</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div></div>