On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: Hello iOS folks I’ve started looking at sync part, I’ve created a separate repo [1]. For now, this lib is dependant on iOS-core. does is worth having it separate for folks that what to use core without sync? yes Same question applies for encrypted store. Right now encrypted store are part of iOS-core. do we want to separate it for people who want core without encrypted store ? I do like the idea of separation

what about people who all it all, encrypted store+sync, we’ll have to manage correctly transitive dependencies. could we bundle something like an 'AeroGear-All-You-Can-Eat-iOS' (similar like something you can do w/ the maven-shade-plugin?). Adding Andrea, perhaps he has an idea on that

wdty? ++ Corinne [1] https://github.com/corinnekrych/aerogear-sync-ios _______________________________________________ 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

Hi, I do agree with the separation of the libraries, so that a user can use only the libraries that he needs. It's a cleaner approach and eventually would keep also the size of the imported libraries at the minimum, saving some space is always a good option when going on mobile even if nowadays the space is not a concern anymore :-) I would personally avoid having one single repo with all the code that builds a library with different 'granularity' (so an all-library-repository that has the option of building a subset of its packages), I would have one dedicated repository for each library that have to be built.

For what I have seen, the approach that I would like most is the same that is being adopted by the EAP in the Maven world (https://github.com/jboss-developer/jboss-eap-boms): the definition of a bom with a set of submodules that specify all the different combinations of libraries to be built, each library having its own definition and repository. I don't know if a similar approach could be achievable with CocoaPods.

I will try to investigate further.

Andrea ----- Messaggio originale ----- > Da: "Corinne Krych" <corinnekrych(a)gmail.com&gt; > A: "AeroGear Developer Mailing List" <aerogear-dev(a)lists.jboss.org&gt; > Cc: avibelli(a)redhat.com > Inviato: Martedì, 4 febbraio 2014 13:39:29 > Oggetto: Re: [aerogear-dev] [iOS] small libs > > > On 04 Feb 2014, at 09:15, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Tue, Feb 4, 2014 at 9:11 AM, Corinne Krych <corinnekrych(a)gmail.com&gt; >> wrote: >> Hello iOS folks >> >> I’ve started looking at sync part, I’ve created a separate repo [1]. For >> now, this lib is dependant on iOS-core. does is worth having it separate >> for folks that what to use core without sync? >> >> yes >> >> Same question applies for encrypted store. Right now encrypted store are >> part of iOS-core. do we want to separate it for people who want core >> without encrypted store ? >> >> I do like the idea of separation > > Just for that i’ve created > https://issues.jboss.org/browse/AGIOS-160 > >> >> what about people who all it all, encrypted store+sync, we’ll have to >> manage correctly transitive dependencies. >> >> could we bundle something like an 'AeroGear-All-You-Can-Eat-iOS' (similar >> like something you can do w/ the maven-shade-plugin?). Adding Andrea, >> perhaps he has an idea on that > > Yep i guess we could have an aerogear-ios repo which gather all you can eat > Podspec > aerogear-ios could be renamed aerogear-core-ios. Coiuld be revisited in 2.0+ > Track in that JIRA > https://issues.jboss.org/browse/AGIOS-161 > >> >> >> wdty? >> >> ++ >> Corinne >> [1] https://github.com/corinnekrych/aerogear-sync-ios >> _______________________________________________ >> 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 > >

I believe that CocoaPods address this concern via subspecs - https://github.com/CocoaPods/CocoaPods/wiki/The-podspec-format http://guides.cocoapods.org/making/specs-and-specs-repo.html However, AIUI, this would require all Aerogear iOS related code to share one Git repository or at least have some git submodules setup. Submodule setup will be nasty for releasing new versions. PodSpec guide additionally says that spec should include all subspec by default, if user wants to be selective, he can do so by enumerating subspecs. http://guides.cocoapods.org/syntax/podspec.html#default_subspec My $0.02, Karel On Tue, 4 Feb 2014 09:11:27 +0100 Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: > Hello iOS folks > > I've started looking at sync part, I've created a separate repo [1]. For now, > this lib is dependant on iOS-core. does is worth having it separate for folks > that what to use core without sync? Same question applies for encrypted > store. Right no encrypted store are part of iOS-core. do we want to separate > it for people who want core without encrypted store ? what about people who > all it all, encrypted store+sync, we'll have to manage correctly transitive > dependencies. wdty? > > ++ > Corinne > [1] https://github.com/corinnekrych/aerogear-sync-ios > _______________________________________________ > 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