1:52 a.m.
Hi Passos,
Actually this library sepration is not just an android concern. We need modularity for iOS
too. It something we’ve been talking about too in or last iOS meeting [1]. I have created
an epic JIRA [2] to track iOS modularity. Once we agreed on library content, we create
more sub-tasks.
Here is what I was thinking (here i leave android but same for iOS):
aerogear-android-pipe
aerogear-android-secure-pipe (auth, autz) dependant on aerogear-android-pipe
aerogear-android-store
aerogear-android-push-registration (one of the repo need renaming, for ios we have
registration at the end)
aerogear-android-secure-store (keyservices) dependant on aerogear-android-store
aerogear-android-offline dependant on aerogear-android-store
aerogear-android-sync dependant on aerogear-android-pipe (?) and/or
aerogear-android-offline
aerogear-ios-crypto
@abstractj I’d keep auth/authz and encryption separate as it has different dependancy one
on pipe and another on store. Having small modules gives the user more choice. An app
might want auth without encryption for ex.
@passos what is messaging for?
++
Corinne
[1]
http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerog...
[2] https://issues.jboss.org/browse/AGIOS-192
On 08 May 2014, at 21:28, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Aloha,
My 2 cents here, IMO aerogear-android-security only. It includes all
the sec requirements like aerogear-crypto-java or authentication with
OAuth2.
aerogear-android-store is kinda of a dependency for Offline. So I'm not
sure if they must stay separated or be a single module.
On 2014-05-08, Daniel Passos wrote:
> Hi Folks,
>
> Just to y'all know, that is what we are planning for android modules
>
> aerogear-android-core (pipe, auth, autz)
> aerogear-android-store
> aerogear-android-push
> aerogear-android-security|encrypt (keyservices)
> aerogear-android-offline
> aerogear-android-sync
> aerogear-android-messaging
>
> wdyt?
>
> -- Passos
>
>
> On Thu, Mar 6, 2014 at 10:38 AM, Karel Piwko <kpiwko(a)redhat.com> wrote:
>
>> I believe there should be a POM depchain for users that are willing just
>> to use
>> aerogear-android and modular dependencies are for more experienced users.
>>
>> Similarly to *Adding ShrinkWrap Resolvers to your project* at
>> https://github.com/shrinkwrap/resolver/blob/master/README.asciidoc
>>
>> I'm not sure how nicely that would play with Gradle though.
>>
>> Karel
>>
>> On Wed, 05 Mar 2014 09:15:27 -0500
>> Summers Pittman <supittma(a)redhat.com> wrote:
>>
>>> Earlier in development (pre passos) making the Android SDK into modules
>>> was not a concern (in fact it was an anti-concern).
>>>
>>> Now, however, we have a much more complete project and it is time to
>>> have that discussion.
>>>
>>> Right now we have two BIG questions:
>>>
>>> 1) Do we want to break out interfaces and implementation?
>>>
>>> If we do this then we could reuse a lot of code to make a aerogear-java
>>> as well.
>>>
>>> 2) How granular do we want our modules?
>>>
>>> IE If we break out push into aerogear-android-push would that include
>>> GCM, SimplePush, MQTT, etc in one package or would it look like
>>> aerogear-android-push-core, aerogear-android-push-mqtt etc.
>>>
>>> Thoughts?
>>>
>>
>> _______________________________________________
>> 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
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev