Re: [aerogear-dev] News from iOS Modules front

On Fri, Jul 25, 2014 at 4:11 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Hi Corinne, > > I'm not against removing the prefix, but to keep the consistency, if the > remove is called potatos-iOS, it must have the same name on Cocoapods. > > We discussed this during the F2F about getting rid of the prefix, but I'm > not > sure what has changed now to other team members. Regarding the argument > of keeping it organized, that's not valid to me, is always possible to > create a > folder with all the projects inside. > > But if most of the team disagree, seems like our suggestion during the > meeting is not valid anymore. > * gh/ag/ag-foo -> feels redundant, so gh/ag/foo does make sense, yeah ** forks... there is still the "forked from gh/ag/foo" * on java, we have APIs and JAR names, I'd think the aerogear name is still visible there. the jar for "gh/ag/foo", could still be named aearogear-foo-1.0.0 (including the o.j.a packages) * On JS we have namesspaces on the API (e.g. AG.Notifier) - on iOS we have classes (AGBlah) And I now recall Bruno's original point: making it more interesting to others, hence droppoing the name. Even if the get rid of the ag-foo, and name if "foo", its fineprint does not take away the aerogear brand. -Matthias > > > On 2014-07-25, Corinne Krych wrote: > > > > On 25 Jul 2014, at 09:46, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > > > > > > > > > > > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych < > corinnekrych(a)gmail.com&gt; wrote: > > > > > > On 25 Jul 2014, at 09:13, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > > > > > > > > > > > > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych < > corinnekrych(a)gmail.com&gt; wrote: > > > > Hello Guys, > > > > > > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked > about modularization. We agreed with Android team modularization is > scheduled for 2.0. > > > > > > > > For iOS we have several actions: > > > > > > > > 1. rename existing repos (too bad we don’t follow well Android > convention) > > > > • aerogear-ios-crypto > > > > • aerogear-ios-push (thanks passos for the suggestion) > > > > • aerogear-ios-otp > > > > • aerogear-ios-xcode-template > > > > • aerogear-ios-cookbook > > > > > > > > Since we’re talking about renaming, what about dropping “arerogear” > for the repo name? > > > > > > > > +1 makes sense > > > > > > > > > It looks like we don’t have the same view here. Obviously if we go > renaming we will have to change all the repos. With or without, > coonsistency is key. > > > > > > My main motivation for dropping aerogear prefex was that ag is > already present in the name of the organisation. Besides as we go with fine > grained modularisation, our libs can be used independently, the naming > without prefix is to enforce that. > > > > > > @passos and all others guys not in favor for dropping prefix, may I > ask why? > > > > > > If we put GH and organization appart, will the name "AeroGear" > appears anywhere in the lib name/pod when someone install it through > cocoapods ? > > > > > > > Yeap we’ll keep aerogear as a prefix for cocoapods > > > https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.pod... > > > > Good question: What about the other modules? > > > > > > > > > > > > > > > > all those repos belong to aerogear organization anyway. Maybe > removing the aerogear part will stress more the small libraries aspect. > Maybe sth we already discussed but can’t remember/find it. wdyt? > > > > > > > > 2. Pipe and Store deprecated. All aerogear-ios we’ll stick to 1.7 > version and will be marked deprecated. > > > > But …. don’t be scared new modules will replace them: > > > > > > > > • aerogear-ios-http : Lightweight lib around NSURLSession to ease > HTTP calls with pluggable request and response Serializers. Very very Draft > version [3] with some cookbook recipe [4]. With this module we will work > directly with NSURLSession (iOS foundation networking) instead of using > AFNetworking. Sure Andrea will like it: no dependency :) > > > > • aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all > the good stuff like AccountManager, OAuth2 extensible adapters, fluid http > post/get ... > > > > • aerogear-ios-storage usage of incrementalStorage to plug into > Core Data > > > > > > > > > > > > +1 all of that sounds awesome! > > > > > > > > > > > > Those modules will be written in Swift code. We’ll test them both > in iOS7 and iOS8. > > > > > > > > +1 on Swift! > > > > > > > > > > > > 3. Cookbook recipes rpo > > > > • tag our repo 1.7: we didn’t have a tag strategy for cookbook > demos but with the move from 1.X to 2.) I think we should > > > > * Swift demo naming convention add “-swift” for Swift version like > we did [5]. We should also append “-objc” to other recipes to be consistent. > > > > > > > > yeah > > > > > > > > > > > > 4. Differentiate Swift vs Objective-C libs > > > > How to differenctiate Swift code. Specially for aerogear-ios-push > which will be declined in 2 versions? One suggestion from Matthias was to > have 2 separate branches. > > > > master -> objc-c > > > > until iOS8 is released and stable. > > > > I’m +1 with that idea. > > > > > > > > yeah, let's have ObjC on master now; > > > > The master can, later this year, contain the Swift lib, and we move > ObjC to be deprecated as soon as we do have iOS8 (~September) > > > > > > > > > > > > Let me know if you have suggestions/objections. When we reach an > agreement, I’ll create associated JIRA. > > > > > > > > ++ > > > > Corinne > > > > > > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > > > > [2] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerog... > > > > [3] https://github.com/corinnekrych/aerogear-ios-http > > > > [4] https://github.com/corinnekrych/Weather > > > > [5] > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf