From vchepeli at redhat.com  Thu Feb  1 06:50:34 2018
From: vchepeli at redhat.com (Vitalii Chepeliuk)
Date: Thu, 1 Feb 2018 12:50:34 +0100
Subject: [aerogear-dev] removed local link creating lo:0 for linux in
	oc-cluster-up role
In-Reply-To: <CAAujoi3sJBDiFDBVfX0+Kb=eEGEM4qyQE4fLv+SGDOXWoRwJAg@mail.gmail.com>
References: <CAAujoi3sJBDiFDBVfX0+Kb=eEGEM4qyQE4fLv+SGDOXWoRwJAg@mail.gmail.com>
Message-ID: <CAAujoi0Ofe6TFa5_EAgX2ZCqetfXG-M5Hmm6h6ojGEuBxMxcDQ@mail.gmail.com>

Cheers,

Sent PR <https://github.com/aerogear/mobile-core/pull/42> to fix local link
issue. Hope now everything should work ;)


On Wed, Jan 31, 2018 at 3:42 PM, Vitalii Chepeliuk <vchepeli at redhat.com>
wrote:

> Hey all! I removed these link in oc-cluster-up role
> -- name: Create alias for lo0 (linux)
> - shell: ifconfig lo:0 {{ cluster_public_hostname }} netmask
> 255.255.255.0 up
> - become: yes
> - changed_when: false
> - when: ansible_os_family in ["RedHat", "Debian"]
> Let me know if you have any issues before I send fix
> Issues can happen when clean setup is performed
>
> --
>
> Vitalii Chepeliuk
>
> QUALITY ENGINEER, MOBILE QE
>
> Red Hat Czech
> <https://www.redhat.com/>
>
> Purkynova 111B
>
> Brno, Czech Republic 61245
>
> vchepeli at redhat.com <lgriffin at redhat.com> IM: vchepeli
> <https://red.ht/sig>
>
> @redhatway <https://twitter.com/redhatway>   @redhatinc
> <https://instagram.com/redhatinc>   @redhatsnaps
> <https://snapchat.com/add/redhatsnaps>
>



-- 

Vitalii Chepeliuk

QUALITY ENGINEER, MOBILE QE

Red Hat Czech
<https://www.redhat.com/>

Purkynova 111B

Brno, Czech Republic 61245

vchepeli at redhat.com <lgriffin at redhat.com> IM: vchepeli
<https://red.ht/sig>

@redhatway <https://twitter.com/redhatway>   @redhatinc
<https://instagram.com/redhatinc>   @redhatsnaps
<https://snapchat.com/add/redhatsnaps>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180201/aaa603f2/attachment.html 

From pwright at redhat.com  Thu Feb  1 10:32:29 2018
From: pwright at redhat.com (Paul Wright)
Date: Thu, 1 Feb 2018 15:32:29 +0000
Subject: [aerogear-dev] SDK API doc
Message-ID: <5749d108-985c-250a-422c-27fbaa7c3e91@redhat.com>

Hi,

There is existing tooling to generate API reference doc for Android and 
iOS. I'm thinking we should use that to generate comprehensive API doc 
for both platforms (and later for Cordova).

I believe this gives the best experience to the <platform> developer, on 
the basis that, at any one time, they developer is working on a single 
platform (and typically a colleague is developing the 'other' platform). 
The disadvantages of this approach include the fact that the appearance 
of generic docs/android/ios will all be different, but we can put enough 
navigation into the html to allow users enter and exit this reference 
without too much pain.

However there is also a requirement to show the cross platform nature of 
mobile-next, to demonstrate the generic nature of a particular call. I'd 
like to address this, not in the 'full' API docs, but in examples of 
typical use cases which might look like

getSyncClient().list("tasks");

For more information see <link to android ref docs>

syncClient.listWithDataId("tasks")

For more information see <link to ios ref docs>


WDYT?


-- 
Paul Wright
Mobile Docs (github: finp)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180201/cc7c24d9/attachment-0001.html 

From wtrocki at redhat.com  Thu Feb  1 10:44:45 2018
From: wtrocki at redhat.com (Wojciech Trocki)
Date: Thu, 1 Feb 2018 15:44:45 +0000
Subject: [aerogear-dev] SDK API doc
In-Reply-To: <5749d108-985c-250a-422c-27fbaa7c3e91@redhat.com>
References: <5749d108-985c-250a-422c-27fbaa7c3e91@redhat.com>
Message-ID: <CAO0+n+q4dtzgAkwt7xhMH8Ya6LHhCXdOr2chxyvunu+hGnkHRg@mail.gmail.com>

Awesome idea to use different tooling.

We could generate documentation on release (by tooling) and use state of
the art solutions for each platform.
Each platform is different and there are different tools available so
keeping the format may be hard.

There are plenty of projects that give us this out of the box. Just couple
examples:

https://github.com/realm/jazzy (ios)
http://typedoc.org/ (TypeScript - cordova)

Another really good idea mentioned above is to avoid extensive code
examples in documentation by referencing api docs.
We have done that in RainCatcher and it worked really good

http://raincatcher.feedhenry.io/docs/#_logging (see logger api
documentation)

This will help us to avoid our documentation getting out of sync with the
actual code.
We could host that on github pages for community.
I think that it will be hard to get into details on mailing list so we
could create proposal for API docs.

On Thu, Feb 1, 2018 at 3:32 PM, Paul Wright <pwright at redhat.com> wrote:

> Hi,
>
> There is existing tooling to generate API reference doc for Android and
> iOS. I'm thinking we should use that to generate comprehensive API doc for
> both platforms (and later for Cordova).
>
> I believe this gives the best experience to the <platform> developer, on
> the basis that, at any one time, they developer is working on a single
> platform (and typically a colleague is developing the 'other' platform).
> The disadvantages of this approach include the fact that the appearance of
> generic docs/android/ios will all be different, but we can put enough
> navigation into the html to allow users enter and exit this reference
> without too much pain.
>
> However there is also a requirement to show the cross platform nature of
> mobile-next, to demonstrate the generic nature of a particular call. I'd
> like to address this, not in the 'full' API docs, but in examples of
> typical use cases which might look like
>
> getSyncClient().list("tasks");
>
> For more information see <link to android ref docs>
>
> syncClient.listWithDataId("tasks")
>
> For more information see <link to ios ref docs>
>
>
> WDYT?
>
> --
> Paul Wright
> Mobile Docs (github: finp)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/aerogear/5749d108-985c-250a-422c-27fbaa7c3e91%40redhat.com
> <https://groups.google.com/d/msgid/aerogear/5749d108-985c-250a-422c-27fbaa7c3e91%40redhat.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 

WOJCIECH TROCKI

Red Hat Mobile <https://www.redhat.com/>

IM: wtrocki
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180201/65dd3bf4/attachment.html 

From wtrocki at redhat.com  Thu Feb  1 10:55:26 2018
From: wtrocki at redhat.com (Wojciech Trocki)
Date: Thu, 1 Feb 2018 15:55:26 +0000
Subject: [aerogear-dev] SDK API doc
In-Reply-To: <CAO0+n+q4dtzgAkwt7xhMH8Ya6LHhCXdOr2chxyvunu+hGnkHRg@mail.gmail.com>
References: <5749d108-985c-250a-422c-27fbaa7c3e91@redhat.com>
	<CAO0+n+q4dtzgAkwt7xhMH8Ya6LHhCXdOr2chxyvunu+hGnkHRg@mail.gmail.com>
Message-ID: <CAO0+n+qgokrQtTqd6B1Oab-upe-C5PUvJh0evyJG9Z_LPd1ArQ@mail.gmail.com>

Worth to mention that there is also alternative aproach when all apis are
available together.
For example:

https://github.com/lord/slate

On Thu, Feb 1, 2018 at 3:44 PM, Wojciech Trocki <wtrocki at redhat.com> wrote:

> Awesome idea to use different tooling.
>
> We could generate documentation on release (by tooling) and use state of
> the art solutions for each platform.
> Each platform is different and there are different tools available so
> keeping the format may be hard.
>
> There are plenty of projects that give us this out of the box. Just couple
> examples:
>
> https://github.com/realm/jazzy (ios)
> http://typedoc.org/ (TypeScript - cordova)
>
> Another really good idea mentioned above is to avoid extensive code
> examples in documentation by referencing api docs.
> We have done that in RainCatcher and it worked really good
>
> http://raincatcher.feedhenry.io/docs/#_logging (see logger api
> documentation)
>
> This will help us to avoid our documentation getting out of sync with the
> actual code.
> We could host that on github pages for community.
> I think that it will be hard to get into details on mailing list so we
> could create proposal for API docs.
>
> On Thu, Feb 1, 2018 at 3:32 PM, Paul Wright <pwright at redhat.com> wrote:
>
>> Hi,
>>
>> There is existing tooling to generate API reference doc for Android and
>> iOS. I'm thinking we should use that to generate comprehensive API doc for
>> both platforms (and later for Cordova).
>>
>> I believe this gives the best experience to the <platform> developer, on
>> the basis that, at any one time, they developer is working on a single
>> platform (and typically a colleague is developing the 'other' platform).
>> The disadvantages of this approach include the fact that the appearance of
>> generic docs/android/ios will all be different, but we can put enough
>> navigation into the html to allow users enter and exit this reference
>> without too much pain.
>>
>> However there is also a requirement to show the cross platform nature of
>> mobile-next, to demonstrate the generic nature of a particular call. I'd
>> like to address this, not in the 'full' API docs, but in examples of
>> typical use cases which might look like
>>
>> getSyncClient().list("tasks");
>>
>> For more information see <link to android ref docs>
>>
>> syncClient.listWithDataId("tasks")
>>
>> For more information see <link to ios ref docs>
>>
>>
>> WDYT?
>>
>> --
>> Paul Wright
>> Mobile Docs (github: finp)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Aerogear" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to aerogear+unsubscribe at googlegroups.com.
>> To post to this group, send email to aerogear at googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/aerogear/5749d108-985c-250a-422c-27fbaa7c3e91%40redhat.com
>> <https://groups.google.com/d/msgid/aerogear/5749d108-985c-250a-422c-27fbaa7c3e91%40redhat.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> WOJCIECH TROCKI
>
> Red Hat Mobile <https://www.redhat.com/>
>
> IM: wtrocki
> <https://red.ht/sig>
>



-- 

WOJCIECH TROCKI

Red Hat Mobile <https://www.redhat.com/>

IM: wtrocki
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180201/550efb18/attachment-0001.html 

From jfrizell at redhat.com  Thu Feb  1 11:13:58 2018
From: jfrizell at redhat.com (John Frizelle)
Date: Thu, 1 Feb 2018 16:13:58 +0000
Subject: [aerogear-dev] SDK API doc
In-Reply-To: <CAO0+n+qgokrQtTqd6B1Oab-upe-C5PUvJh0evyJG9Z_LPd1ArQ@mail.gmail.com>
References: <5749d108-985c-250a-422c-27fbaa7c3e91@redhat.com>
	<CAO0+n+q4dtzgAkwt7xhMH8Ya6LHhCXdOr2chxyvunu+hGnkHRg@mail.gmail.com>
	<CAO0+n+qgokrQtTqd6B1Oab-upe-C5PUvJh0evyJG9Z_LPd1ArQ@mail.gmail.com>
Message-ID: <CAJFhnM4LOLsU0+WDOSWkwd8Q12e12J7w95f+zdr4xnXF0TeWfQ@mail.gmail.com>

I think some beautiful marriage between stand alone API docs for the deep
documentation and slate for language specific samples examples is the way
to go here.

I actually really like the slate UI & UX and would be very much in favour
of using it (at least at some layer of our docs)...


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: *+353 87 290 1644 <//+353872901644>*
twitter:* @johnfriz*
skype: *john_frizelle*
mail: *jfrizell at redhat.com <jfrizell at redhat.com>*




On 1 February 2018 at 15:55, Wojciech Trocki <wtrocki at redhat.com> wrote:

> Worth to mention that there is also alternative aproach when all apis are
> available together.
> For example:
>
> https://github.com/lord/slate
>
> On Thu, Feb 1, 2018 at 3:44 PM, Wojciech Trocki <wtrocki at redhat.com>
> wrote:
>
>> Awesome idea to use different tooling.
>>
>> We could generate documentation on release (by tooling) and use state of
>> the art solutions for each platform.
>> Each platform is different and there are different tools available so
>> keeping the format may be hard.
>>
>> There are plenty of projects that give us this out of the box. Just
>> couple examples:
>>
>> https://github.com/realm/jazzy (ios)
>> http://typedoc.org/ (TypeScript - cordova)
>>
>> Another really good idea mentioned above is to avoid extensive code
>> examples in documentation by referencing api docs.
>> We have done that in RainCatcher and it worked really good
>>
>> http://raincatcher.feedhenry.io/docs/#_logging (see logger api
>> documentation)
>>
>> This will help us to avoid our documentation getting out of sync with the
>> actual code.
>> We could host that on github pages for community.
>> I think that it will be hard to get into details on mailing list so we
>> could create proposal for API docs.
>>
>> On Thu, Feb 1, 2018 at 3:32 PM, Paul Wright <pwright at redhat.com> wrote:
>>
>>> Hi,
>>>
>>> There is existing tooling to generate API reference doc for Android and
>>> iOS. I'm thinking we should use that to generate comprehensive API doc for
>>> both platforms (and later for Cordova).
>>>
>>> I believe this gives the best experience to the <platform> developer, on
>>> the basis that, at any one time, they developer is working on a single
>>> platform (and typically a colleague is developing the 'other' platform).
>>> The disadvantages of this approach include the fact that the appearance of
>>> generic docs/android/ios will all be different, but we can put enough
>>> navigation into the html to allow users enter and exit this reference
>>> without too much pain.
>>>
>>> However there is also a requirement to show the cross platform nature of
>>> mobile-next, to demonstrate the generic nature of a particular call. I'd
>>> like to address this, not in the 'full' API docs, but in examples of
>>> typical use cases which might look like
>>>
>>> getSyncClient().list("tasks");
>>>
>>> For more information see <link to android ref docs>
>>>
>>> syncClient.listWithDataId("tasks")
>>>
>>> For more information see <link to ios ref docs>
>>>
>>>
>>> WDYT?
>>>
>>> --
>>> Paul Wright
>>> Mobile Docs (github: finp)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Aerogear" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to aerogear+unsubscribe at googlegroups.com.
>>> To post to this group, send email to aerogear at googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/aerogear/5749d108-985c-250a-422c-27fbaa7c3e91%40redhat.com
>>> <https://groups.google.com/d/msgid/aerogear/5749d108-985c-250a-422c-27fbaa7c3e91%40redhat.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> WOJCIECH TROCKI
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> IM: wtrocki
>> <https://red.ht/sig>
>>
>
>
>
> --
>
> WOJCIECH TROCKI
>
> Red Hat Mobile <https://www.redhat.com/>
>
> IM: wtrocki
> <https://red.ht/sig>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CAO0%2Bn%2BqgokrQtTqd6B1Oab-upe-C5PUvJh0evyJG9Z_LPd1ArQ%
> 40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CAO0%2Bn%2BqgokrQtTqd6B1Oab-upe-C5PUvJh0evyJG9Z_LPd1ArQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180201/da972e5b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180201/da972e5b/attachment-0001.png 

From dpassos at redhat.com  Thu Feb  1 13:29:28 2018
From: dpassos at redhat.com (Daniel Passos)
Date: Thu, 1 Feb 2018 16:29:28 -0200
Subject: [aerogear-dev] Android Core Proposal Merged (and some follow up
	goals)
In-Reply-To: <CADvBQ44NLBtp18o_aC5ou5gCxgqNViq5Ocv+Pfbegd9fAr8yRg@mail.gmail.com>
References: <CADvBQ454ouqqV8Qr7nHssEYxV932Z-JcBqA36VW6-w_Puoe-ng@mail.gmail.com>
	<CAO0+n+qWyxrVY5u=OfOzfrj6wAvSOybE1aettQEFe-5ovF2TKA@mail.gmail.com>
	<CADvBQ44NLBtp18o_aC5ou5gCxgqNViq5Ocv+Pfbegd9fAr8yRg@mail.gmail.com>
Message-ID: <CADF=h2vCDaE+UCwug64ydGvX70g_Vs_h9AD1K=182FxHj2orwA@mail.gmail.com>

TL;DR the goal 1 is my mean goal, as a developer I don't wanna need to
register any service provided by the SDK.

And maybe the goal 2 is not needed I'm not 200% sure now

On Mon, Jan 29, 2018 at 5:44 PM, David Martin <davmarti at redhat.com> wrote:

> Sounds good to me. If it works out that 2 is covered by 1, great.
> @Passos @Summers anything you want to add?
>
> Would be great to get feedback from anyone using the sdk already too.
>
> On Mon, 29 Jan 2018 17:56 Wojciech Trocki, <wtrocki at redhat.com> wrote:
>
>> Added small comments on tickets. From my point of view everything looks
>> great.
>> From my point of view Goal 2 may be actually not needed depending on how
>> Goal 1 will be resolved.
>> I we think about it that is just one single ticket that is required to
>> improve overall user experience and API.
>>
>> > keycloakService = core.getService(KeyCloakService.class);
>>
>> I remember that service team required to pass additional parameters and
>> going this way will impose some limitations.
>> What we looking for is probably something like this:
>>
>> Auth keycloak = AeroGearAuth.create(options)
>>
>>
>> On Mon, Jan 29, 2018 at 4:51 PM, David Martin <davmarti at redhat.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> After a massive 100+ comments, I've decided to merge the Android Core
>>> SDK Proposal
>>> https://github.com/aerogear/proposals/pull/9
>>>
>>> * Android Core SDK is available from Maven:
>>> * Repo: https://github.com/aerogear/aerogear-android-sdk
>>> * Example Android App that uses the core SDK:
>>> https://github.com/secondsun/WipDemo/blob/master/app/src/
>>> main/java/org/feedhenry/mcp/prdemo/CoreActivity.java
>>> * What you need to add to your gradle file: https://github.com/
>>> secondsun/WipDemo/blob/master/app/build.gradle#L29
>>>
>>>
>>> The amount of comments, calls and back&forth on irc has reached a
>>> reasonable level of agreement, with some remaining points of contention.
>>> The contention is mainly around the level of complexity that a developer
>>> has to undertake to use the SDK.
>>> After listening to the 3 main voices on this (Summers, Wojciech,
>>> Passos), I can see both points of view.
>>>
>>> (WARNING: A lot of paraphrasing below :) )
>>>
>>> From Passos & Wojciech's point of view, ease of use of the SDK is what's
>>> most important. There should be practically no setup/init required other
>>> than having a mobile-config.json file in the right place, and call a static
>>> method to get an instance of a service (similar to Firebase).
>>>
>>> From Summers point of view, ease of use is also important, but something
>>> we can improve on iteratively. For example, the default use of a Service
>>> will be fine & possible to automate the setup for for 95% of cases.
>>> However, the other 5% is what we need to take into account from the
>>> beginning.
>>>
>>>
>>> So, based on this, I would like if the following 2 things were follow up
>>> goals for the Core SDK.
>>> I believe these changes will take whats currently there (and working),
>>> and move it towards something that is easier to use for developers.
>>>
>>>
>>> Goal 1:
>>> https://issues.jboss.org/browse/AGDROID-712
>>> Remove the need for static block initialisation/registration of service
>>> classes & their dependencies. i.e. this:
>>>
>>> static {
>>>    ServiceModuleRegistry.registerServiceModule("keycloak",
>>> KeyCloakService.class, "http");
>>>  }
>>>
>>> From chatting with Summers, this should be possible now that this PR is
>>> merged https://github.com/aerogear/proposals/pull/16 and the config
>>> file format is nailed down.
>>>
>>>
>>> Goal 2:
>>> https://issues.jboss.org/browse/AGDROID-713
>>> Allow a simpler way of getting an instance of a Service class other than
>>> below.
>>>
>>>    keycloakService = core.getService("keycloak", KeyCloakService.class);
>>>
>>> If there are multiple instances registered for a particular Class, it
>>> may still be necessary to use the above to get a 'named' instance (much
>>> like in dependency injection libs like spring that use annotations).
>>> However, in most cases, the below should be possible:
>>>
>>> keycloakService = core.getService(KeyCloakService.class);
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>> --
>>> David Martin
>>> Red Hat Mobile
>>> Twitter: @irldavem
>>> IRC: @irldavem (#aerogear)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Aerogear" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to aerogear+unsubscribe at googlegroups.com.
>>> To post to this group, send email to aerogear at googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/aerogear/CADvBQ454ouqqV8Qr7nHssEYxV932Z
>>> -JcBqA36VW6-w_Puoe-ng%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/aerogear/CADvBQ454ouqqV8Qr7nHssEYxV932Z-JcBqA36VW6-w_Puoe-ng%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> WOJCIECH TROCKI
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> IM: wtrocki
>> <https://red.ht/sig>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CADvBQ44NLBtp18o_aC5ou5gCxgqNViq5Ocv%
> 2BPfbegd9fAr8yRg%40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CADvBQ44NLBtp18o_aC5ou5gCxgqNViq5Ocv%2BPfbegd9fAr8yRg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180201/1df77ef7/attachment.html 

From dpassos at redhat.com  Fri Feb  2 08:56:27 2018
From: dpassos at redhat.com (Daniel Passos)
Date: Fri, 2 Feb 2018 11:56:27 -0200
Subject: [aerogear-dev] New AeroGear SDK
Message-ID: <CADF=h2uWrJ-J7J0vxWB3MBtJkJP-9cLoqdxX26VRKdnJAtHciA@mail.gmail.com>

Hi,

The AeroGear team is currently working on a new project called Mobile.next
that using OpenShift as runtime platform for mobile services.

You can follow the new project on mobile-core[1] and mobile-cli[2]

As a team, we are going to build a new version of the SDK that will support
the OpenShift platform.
We have decided to start with an Android SDK and then explore other
platforms/languages.

We have created a new repo for the new Android SDK[3].
We also have decided to have only one repo and use the Android application
module[4] feature.

The first two features that we are going to add to the new SDK will be:
    * Core of the SDK [5]
    * Identity management [6]

[1] https://github.com/aerogear/mobile-core
[2] https://github.com/aerogear/mobile-cli
[3] https://github.com/aerogear/aerogear-android-sdk
[4] https://developer.android.com/studio/projects/index.html#
ApplicationModules
[5] https://issues.jboss.org/browse/AGDROID-662
[6] https://issues.jboss.org/browse/AGDROID-668

-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180202/ce86ed2e/attachment.html 

From matzew at apache.org  Sat Feb  3 04:44:48 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Sat, 3 Feb 2018 10:44:48 +0100
Subject: [aerogear-dev] ADM: deprecated
Message-ID: <CAAg5f2TxKr2sZk_KP93bqbU-uGqPio_hOLgWFZsBGz0g-G-kdg@mail.gmail.com>

Hi,

for the .NEXT of push, I do not think that ADM is a thing anymore - we also
never had q's from the community about it

https://github.com/aerogear/java-adm/pull/6

If you have strong feelings on ADM support, please state on the PR.

thanks

-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180203/1778e025/attachment.html 

From pwright at redhat.com  Sun Feb  4 08:52:23 2018
From: pwright at redhat.com (Paul Wright)
Date: Sun, 4 Feb 2018 13:52:23 +0000
Subject: [aerogear-dev] SDK API doc
In-Reply-To: <CAJFhnM4LOLsU0+WDOSWkwd8Q12e12J7w95f+zdr4xnXF0TeWfQ@mail.gmail.com>
References: <5749d108-985c-250a-422c-27fbaa7c3e91@redhat.com>
	<CAO0+n+q4dtzgAkwt7xhMH8Ya6LHhCXdOr2chxyvunu+hGnkHRg@mail.gmail.com>
	<CAO0+n+qgokrQtTqd6B1Oab-upe-C5PUvJh0evyJG9Z_LPd1ArQ@mail.gmail.com>
	<CAJFhnM4LOLsU0+WDOSWkwd8Q12e12J7w95f+zdr4xnXF0TeWfQ@mail.gmail.com>
Message-ID: <2de414a5-8c20-34f9-f643-17b2ced2024c@redhat.com>

Hi John,

Given that we want to document in asciidoc, I'm suggesting that we 
(somehow) use the same technique as used here to display alternative 
syntax (maven and gradle tabs):

https://docs.spring.io/spring-restdocs/docs/current/reference/html5/#getting-started-build-configuration

This technique is based on the following asciidoctor extension:

https://github.com/spring-io/spring-asciidoctor-extensions

Just need to figure out how to include that in our publishing process,

Paul


On 02/01/2018 04:13 PM, John Frizelle wrote:
> I think some beautiful marriage between stand alone API docs for the 
> deep documentation and slate for language specific samples examples is 
> the way to go here.
>
> I actually really like the slate UI & UX and would be very much in 
> favour of using it (at least at some layer of our docs)...
>
>
> --
> John Frizelle
> Chief Architect, Red Hat Mobile
> Consulting Engineer
>
> mobile:*+353 87 290 1644 <tel://+353872901644>*
> twitter:*?@johnfriz*
> skype: *john_frizelle*
> mail: *jfrizell at redhat.com <mailto:jfrizell at redhat.com>*
>
>
>
>
> On 1 February 2018 at 15:55, Wojciech Trocki <wtrocki at redhat.com 
> <mailto:wtrocki at redhat.com>> wrote:
>
>     Worth to mention that there is also alternative aproach when all
>     apis are available together.
>     For example:
>
>     https://github.com/lord/slate
>
>     On Thu, Feb 1, 2018 at 3:44 PM, Wojciech Trocki
>     <wtrocki at redhat.com <mailto:wtrocki at redhat.com>> wrote:
>
>         Awesome idea to use different tooling.
>
>         We could generate documentation on release (by tooling) and
>         use state of the art solutions for each platform.
>         Each platform is different and there are different tools
>         available so keeping the format may be hard.
>
>         There are plenty of projects that give us this out of the box.
>         Just couple examples:
>
>         https://github.com/realm/jazzy (ios)
>         http://typedoc.org/ (TypeScript - cordova)
>
>         Another really good idea mentioned above is to avoid extensive
>         code examples in documentation by referencing api docs.
>         We have done that in RainCatcher and it worked really good
>
>         http://raincatcher.feedhenry.io/docs/#_logging
>         <http://raincatcher.feedhenry.io/docs/#_logging> (see logger
>         api documentation)
>
>         This will help us to avoid our documentation getting out of
>         sync with the actual code.
>         We could host that on github pages for community.
>         I think that it will be hard to get into details on mailing
>         list so we could create proposal for API docs.
>
>         On Thu, Feb 1, 2018 at 3:32 PM, Paul Wright
>         <pwright at redhat.com <mailto:pwright at redhat.com>> wrote:
>
>             Hi,
>
>             There is existing tooling to generate API reference doc
>             for Android and iOS. I'm thinking we should use that to
>             generate comprehensive API doc for both platforms (and
>             later for Cordova).
>
>             I believe this gives the best experience to the <platform>
>             developer, on the basis that, at any one time, they
>             developer is working on a single platform (and typically a
>             colleague is developing the 'other' platform). The
>             disadvantages of this approach include the fact that the
>             appearance of generic docs/android/ios will all be
>             different, but we can put enough navigation into the html
>             to allow users enter and exit this reference without too
>             much pain.
>
>             However there is also a requirement to show the cross
>             platform nature of mobile-next, to demonstrate the generic
>             nature of a particular call. I'd like to address this, not
>             in the 'full' API docs, but in examples of typical use
>             cases which might look like
>
>             getSyncClient().list("tasks");
>
>             For more information see <link to android ref docs>
>
>             syncClient.listWithDataId("tasks")
>
>             For more information see <link to ios ref docs>
>
>
>             WDYT?
>
>             -- 
>             Paul Wright
>             Mobile Docs (github: finp)
>
>             -- 
>             You received this message because you are subscribed to
>             the Google Groups "Aerogear" group.
>             To unsubscribe from this group and stop receiving emails
>             from it, send an email to
>             aerogear+unsubscribe at googlegroups.com
>             <mailto:aerogear+unsubscribe at googlegroups.com>.
>             To post to this group, send email to
>             aerogear at googlegroups.com <mailto:aerogear at googlegroups.com>.
>             To view this discussion on the web visit
>             https://groups.google.com/d/msgid/aerogear/5749d108-985c-250a-422c-27fbaa7c3e91%40redhat.com
>             <https://groups.google.com/d/msgid/aerogear/5749d108-985c-250a-422c-27fbaa7c3e91%40redhat.com?utm_medium=email&utm_source=footer>.
>             For more options, visit https://groups.google.com/d/optout
>             <https://groups.google.com/d/optout>.
>
>
>
>
>         -- 
>
>         WOJCIECH TROCKI
>
>         Red Hat Mobile <https://www.redhat.com/>
>
>         IM: wtrocki
>
>         <https://red.ht/sig>
>
>
>
>
>     -- 
>
>     WOJCIECH TROCKI
>
>     Red Hat Mobile <https://www.redhat.com/>
>
>     IM: wtrocki
>
>     <https://red.ht/sig>
>
>     -- 
>     You received this message because you are subscribed to the Google
>     Groups "Aerogear" group.
>     To unsubscribe from this group and stop receiving emails from it,
>     send an email to aerogear+unsubscribe at googlegroups.com
>     <mailto:aerogear+unsubscribe at googlegroups.com>.
>     To post to this group, send email to aerogear at googlegroups.com
>     <mailto:aerogear at googlegroups.com>.
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/aerogear/CAO0%2Bn%2BqgokrQtTqd6B1Oab-upe-C5PUvJh0evyJG9Z_LPd1ArQ%40mail.gmail.com
>     <https://groups.google.com/d/msgid/aerogear/CAO0%2Bn%2BqgokrQtTqd6B1Oab-upe-C5PUvJh0evyJG9Z_LPd1ArQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>     For more options, visit https://groups.google.com/d/optout
>     <https://groups.google.com/d/optout>.
>
>

-- 
Paul Wright
Mobile Docs (github: finp)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180204/9f8021d7/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180204/9f8021d7/attachment-0001.png 

From davmarti at redhat.com  Mon Feb  5 12:16:52 2018
From: davmarti at redhat.com (David Martin)
Date: Mon, 5 Feb 2018 17:16:52 +0000
Subject: [aerogear-dev] UPS: Admin UI
In-Reply-To: <CAAg5f2Qi6Fwj5FPq-VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q@mail.gmail.com>
References: <CAAg5f2Qi6Fwj5FPq-VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q@mail.gmail.com>
Message-ID: <CADvBQ45yhH_-+Z2gKsU-agjv2ucngsgUgo66-dQ7MdyoMuDinw@mail.gmail.com>

For RHMAP 3/4, the Studio was originally part of a single jar/war
(millicore). It did have a jsp for delivering the index.html (which
wrote a bunch of inline javascript)

The studio was then decoupled from the war file as a separate war
(fh-studio). However, it still had an index.jsp, but called back to
the 'core' to get some of the info needed for that.

This was eventually refactored into a node.js express app (fh-ngui)
and deployed completely separately. It still made calls back to the
core to get some config/user info.

The main benefit I found was the UI could be progressed at a faster
pace as the local development tooling could be tailored better. (just
run the UI server & hook up to an existing core somewhere)
However, it introduced overhead with the addition of a new deployable component.

This was all in a pre-containers world, but it was migrated to a
container world (on openshift).
We never went as far as nginx serving static content, but I could see
that as a logical progression.
It would probably mean a smaller footprint overall.

On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org> wrote:
> Hi,
>
> right now, we have the static resources of the admin ui build to a JAR file
> and a "node tgz". Currently, in the community, we use the bundled JAR and
> deployed to the UPS WAR file. So far, so good
>
> For our modularization I was thinking at different options:
>
> * WildFly Swarm w/ just static (WAR) resources
> * Node.js/Express app
> * Ngnix container, just serviing the content
>
> I've tested 1) I was wondering if we might - for some better resource
> utilization might just go w/ Ngnix, and deploy the static resources of the
> admin UI to there?
>
> How do other think about breaking the UPS down to different technologies and
> aspects?
>
> -Matthias
>
> [1] https://github.com/aerogear/unifiedpush-admin-ui
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq-VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (#aerogear)

From pwright at redhat.com  Mon Feb  5 13:04:13 2018
From: pwright at redhat.com (Paul Wright)
Date: Mon, 5 Feb 2018 18:04:13 +0000
Subject: [aerogear-dev] Adding a dashboard to Grafana
Message-ID: <0c02be2b-3c73-5fad-bca1-54b60cfc0e5e@redhat.com>

//taking cover already as I'm about to ask people to name things

You don't add a table to Postgres, you add a table to a database,

You don't Firefox a web site.

and in general, you don't add <item> to <product>, you add <item> to 
<function or component>

so, I don't like the phrase 'adding a dashboard to Grafana'

I suppose we might 'add a dashboard to the Grafana instance', but that 
seems wordy,

And everyone is busy, so I'm going to say either:

a) add a dashboard to the Grafana instance

b) add a dashboard to <AeroGear Reports>

Note: I've spoken to a few ppl about this, and they're looking at me 
funny, but I'd like to point out that this is what I'm basing my view on 
the fact that a dashboard is not supposed to be a mere visualization:

https://en.wikipedia.org/wiki/Dashboard_(business)

Paul
(waiting for all the counter examples)
-- 

Paul Wright
Mobile Docs (github: finp)


From matzew at apache.org  Mon Feb  5 14:05:21 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Mon, 5 Feb 2018 20:05:21 +0100
Subject: [aerogear-dev] UPS: Admin UI
In-Reply-To: <CADvBQ45yhH_-+Z2gKsU-agjv2ucngsgUgo66-dQ7MdyoMuDinw@mail.gmail.com>
References: <CAAg5f2Qi6Fwj5FPq-VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q@mail.gmail.com>
	<CADvBQ45yhH_-+Z2gKsU-agjv2ucngsgUgo66-dQ7MdyoMuDinw@mail.gmail.com>
Message-ID: <CAAg5f2SUOc_GMStZ76ig60C-=cTin1YXLU-uRyEo8mVRQFJekQ@mail.gmail.com>

Hi, Dave

thanks for the feedback

On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti at redhat.com> wrote:

> For RHMAP 3/4, the Studio was originally part of a single jar/war
> (millicore). It did have a jsp for delivering the index.html (which
> wrote a bunch of inline javascript)
>
> The studio was then decoupled from the war file as a separate war
> (fh-studio). However, it still had an index.jsp, but called back to
> the 'core' to get some of the info needed for that.
>
> This was eventually refactored into a node.js express app (fh-ngui)
> and deployed completely separately. It still made calls back to the
> core to get some config/user info.
>
> The main benefit I found was the UI could be progressed at a faster
> pace as the local development tooling could be tailored better. (just
> run the UI server & hook up to an existing core somewhere)
> However, it introduced overhead with the addition of a new deployable
> component.
>

that's also some of the points. We already have the development moved over
to a different repo.
We currently just stick it's JAR (which might be silly) into the WAR.


>
> This was all in a pre-containers world, but it was migrated to a
> container world (on openshift).
> We never went as far as nginx serving static content, but I could see
> that as a logical progression.
> It would probably mean a smaller footprint overall.
>

cool. It's something I will include in the proposal (not done any testings).


Currently I look removing some good parts of the WAR file for the push
delivery itself.

current approach, which I do like so far, is having each "network" run as a
java process, that wires the "send bits" (e.g. for iOS) togehter via
messaging (kafka).
Here is a metrics screenshot:
https://user-images.githubusercontent.com/157646/35808591-9393ec6c-0a86-11e8-9b6f-f138fe0a5691.png

code is located here:
https://github.com/matzew/aerogear-unifiedpush-server/tree/8d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-agent/src/main/java/org/aerogear/push/apns

It's borrowing some concenpts/code from core UPS. but is really no http
server - just a standard Main, which has a kafka consumer, plugged via ENVs.

I currently deploy to Openshift using the fabric8-maven-plugin (fmp), that
generates all all (docker file, k8s/oc yamls).

I will do the same for FCM.

Once that all is done, we have no "sending" code in the UPS, and we can
move than the UPS itself to WF-Swarm, for a migration to a simpler
develipment/deployment model (and perhaps some more modules in the longer
run)

Proposing:
* fcm-sender.jar (in container)
* apns-sender.jar (in container)
* UPS move to Swarm
* UI in nginx



>
> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org>
> wrote:
> > Hi,
> >
> > right now, we have the static resources of the admin ui build to a JAR
> file
> > and a "node tgz". Currently, in the community, we use the bundled JAR and
> > deployed to the UPS WAR file. So far, so good
> >
> > For our modularization I was thinking at different options:
> >
> > * WildFly Swarm w/ just static (WAR) resources
> > * Node.js/Express app
> > * Ngnix container, just serviing the content
> >
> > I've tested 1) I was wondering if we might - for some better resource
> > utilization might just go w/ Ngnix, and deploy the static resources of
> the
> > admin UI to there?
> >
> > How do other think about breaking the UPS down to different technologies
> and
> > aspects?
> >
> > -Matthias
> >
> > [1] https://github.com/aerogear/unifiedpush-admin-ui
> >
> > --
> > Matthias Wessendorf
> >
> > github: https://github.com/matzew
> > twitter: http://twitter.com/mwessendorf
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Aerogear" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to aerogear+unsubscribe at googlegroups.com.
> > To post to this group, send email to aerogear at googlegroups.com.
> > To view this discussion on the web visit
> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq-VdBEw3Ro_
> pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (#aerogear)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CADvBQ45yhH_-%2BZ2gKsU-agjv2ucngsgUgo66-
> dQ7MdyoMuDinw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180205/c8eb3ac9/attachment.html 

From davmarti at redhat.com  Mon Feb  5 14:28:05 2018
From: davmarti at redhat.com (David Martin)
Date: Mon, 05 Feb 2018 19:28:05 +0000
Subject: [aerogear-dev] Adding a dashboard to Grafana
In-Reply-To: <0c02be2b-3c73-5fad-bca1-54b60cfc0e5e@redhat.com>
References: <0c02be2b-3c73-5fad-bca1-54b60cfc0e5e@redhat.com>
Message-ID: <CADvBQ45gqTRbx1xO9G78JT93LvGRvP8E4qYoX+UGCqQAMQz6jw@mail.gmail.com>

>From the docs here
http://docs.grafana.org/guides/getting_started/#dashboards-panels-rows-the-building-blocks-of-grafana
it talks about creating a dashboard, and that dashboards are at the core of
Grafana.

So, 'creating a dashboard in Grafana'?

On Mon, 5 Feb 2018 18:04 Paul Wright, <pwright at redhat.com> wrote:

> //taking cover already as I'm about to ask people to name things
>
> You don't add a table to Postgres, you add a table to a database,
>
> You don't Firefox a web site.
>
> and in general, you don't add <item> to <product>, you add <item> to
> <function or component>
>
> so, I don't like the phrase 'adding a dashboard to Grafana'
>
> I suppose we might 'add a dashboard to the Grafana instance', but that
> seems wordy,
>
> And everyone is busy, so I'm going to say either:
>
> a) add a dashboard to the Grafana instance
>
> b) add a dashboard to <AeroGear Reports>
>
> Note: I've spoken to a few ppl about this, and they're looking at me
> funny, but I'd like to point out that this is what I'm basing my view on
> the fact that a dashboard is not supposed to be a mere visualization:
>
> https://en.wikipedia.org/wiki/Dashboard_(business)
>
> Paul
> (waiting for all the counter examples)
> --
>
> Paul Wright
> Mobile Docs (github: finp)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/aerogear/0c02be2b-3c73-5fad-bca1-54b60cfc0e5e%40redhat.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180205/6c321ce7/attachment-0001.html 

From jgallaso at redhat.com  Tue Feb  6 03:28:13 2018
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Tue, 6 Feb 2018 09:28:13 +0100
Subject: [aerogear-dev] Adding a dashboard to Grafana
In-Reply-To: <CADvBQ45gqTRbx1xO9G78JT93LvGRvP8E4qYoX+UGCqQAMQz6jw@mail.gmail.com>
References: <0c02be2b-3c73-5fad-bca1-54b60cfc0e5e@redhat.com>
	<CADvBQ45gqTRbx1xO9G78JT93LvGRvP8E4qYoX+UGCqQAMQz6jw@mail.gmail.com>
Message-ID: <CAGsbZmGGiNXAaheex4m4Fj_VCz7-HmtcJzVbenxPEJVypJURYQ@mail.gmail.com>

"Adding a Grafana dashboard [to the metrics service]"?



JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>

On 5 February 2018 at 20:28, David Martin <davmarti at redhat.com> wrote:

> From the docs here http://docs.grafana.org/guides/getting_started/#
> dashboards-panels-rows-the-building-blocks-of-grafana it talks about
> creating a dashboard, and that dashboards are at the core of Grafana.
>
> So, 'creating a dashboard in Grafana'?
>
> On Mon, 5 Feb 2018 18:04 Paul Wright, <pwright at redhat.com> wrote:
>
>> //taking cover already as I'm about to ask people to name things
>>
>> You don't add a table to Postgres, you add a table to a database,
>>
>> You don't Firefox a web site.
>>
>> and in general, you don't add <item> to <product>, you add <item> to
>> <function or component>
>>
>> so, I don't like the phrase 'adding a dashboard to Grafana'
>>
>> I suppose we might 'add a dashboard to the Grafana instance', but that
>> seems wordy,
>>
>> And everyone is busy, so I'm going to say either:
>>
>> a) add a dashboard to the Grafana instance
>>
>> b) add a dashboard to <AeroGear Reports>
>>
>> Note: I've spoken to a few ppl about this, and they're looking at me
>> funny, but I'd like to point out that this is what I'm basing my view on
>> the fact that a dashboard is not supposed to be a mere visualization:
>>
>> https://en.wikipedia.org/wiki/Dashboard_(business)
>>
>> Paul
>> (waiting for all the counter examples)
>> --
>>
>> Paul Wright
>> Mobile Docs (github: finp)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Aerogear" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to aerogear+unsubscribe at googlegroups.com.
>> To post to this group, send email to aerogear at googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/aerogear/0c02be2b-3c73-5fad-bca1-54b60cfc0e5e%40redhat.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CADvBQ45gqTRbx1xO9G78JT93LvGRvP8E4qYoX%2BUGCqQAMQz6jw%
> 40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CADvBQ45gqTRbx1xO9G78JT93LvGRvP8E4qYoX%2BUGCqQAMQz6jw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180206/984aa9ac/attachment.html 

From pwright at redhat.com  Tue Feb  6 03:49:41 2018
From: pwright at redhat.com (Paul Wright)
Date: Tue, 6 Feb 2018 08:49:41 +0000
Subject: [aerogear-dev] Adding a dashboard to Grafana
In-Reply-To: <CAGsbZmGGiNXAaheex4m4Fj_VCz7-HmtcJzVbenxPEJVypJURYQ@mail.gmail.com>
References: <0c02be2b-3c73-5fad-bca1-54b60cfc0e5e@redhat.com>
	<CADvBQ45gqTRbx1xO9G78JT93LvGRvP8E4qYoX+UGCqQAMQz6jw@mail.gmail.com>
	<CAGsbZmGGiNXAaheex4m4Fj_VCz7-HmtcJzVbenxPEJVypJURYQ@mail.gmail.com>
Message-ID: <d2c08cec-2f75-855b-df78-96520ae8b13e@redhat.com>

Hi,

Thanks for suggestions, I think 'Creating a dashboard in Grafana' is the 
right way to go.

Let me explain my motivation here, I was reading the doc as an idiot 
(which i found worryingly easy yesterday). If I don't know what Grafana 
is, then mention of 'Grafana dashboards' or 'adding dashboards to 
Grafana' prompts a question 'what is Grafana?'.

I think we want to mention Grafana, for many reasons, but I hope that 
'Creating a dashboard in Grafana' prompts the question 'where is 
Grafana?' and that users unfamiliar with the name will intuit it as an 
App/Location instead of a new piece in a poorly fitting jigsaw.

(Jose, I like your addition of context, mentioning the metrics service, 
but I'm hoping that will be obvious to the user by location of the 
Grafana topics and the introductory text.)

Paul


On 02/06/2018 08:28 AM, Jose Miguel Gallas Olmedo wrote:
> "Adding a Grafana dashboard [to the metrics service]"?
>
>
>
> JOSE MIGUEL GALLAS OLMEDO
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>
> <https://red.ht/sig>
>
>
> On 5 February 2018 at 20:28, David Martin <davmarti at redhat.com 
> <mailto:davmarti at redhat.com>> wrote:
>
>     From the docs here
>     http://docs.grafana.org/guides/getting_started/#dashboards-panels-rows-the-building-blocks-of-grafana
>     <http://docs.grafana.org/guides/getting_started/#dashboards-panels-rows-the-building-blocks-of-grafana>
>     it talks about creating a dashboard, and that dashboards are at
>     the core of Grafana.
>
>     So, 'creating a dashboard in Grafana'?
>
>
>     On Mon, 5 Feb 2018 18:04 Paul Wright, <pwright at redhat.com
>     <mailto:pwright at redhat.com>> wrote:
>
>         //taking cover already as I'm about to ask people to name things
>
>         You don't add a table to Postgres, you add a table to a database,
>
>         You don't Firefox a web site.
>
>         and in general, you don't add <item> to <product>, you add
>         <item> to
>         <function or component>
>
>         so, I don't like the phrase 'adding a dashboard to Grafana'
>
>         I suppose we might 'add a dashboard to the Grafana instance',
>         but that
>         seems wordy,
>
>         And everyone is busy, so I'm going to say either:
>
>         a) add a dashboard to the Grafana instance
>
>         b) add a dashboard to <AeroGear Reports>
>
>         Note: I've spoken to a few ppl about this, and they're looking
>         at me
>         funny, but I'd like to point out that this is what I'm basing
>         my view on
>         the fact that a dashboard is not supposed to be a mere
>         visualization:
>
>         https://en.wikipedia.org/wiki/Dashboard_(business)
>         <https://en.wikipedia.org/wiki/Dashboard_%28business%29>
>
>         Paul
>         (waiting for all the counter examples)
>         --
>
>         Paul Wright
>         Mobile Docs (github: finp)
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "Aerogear" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to aerogear+unsubscribe at googlegroups.com
>         <mailto:aerogear%2Bunsubscribe at googlegroups.com>.
>         To post to this group, send email to aerogear at googlegroups.com
>         <mailto:aerogear at googlegroups.com>.
>         To view this discussion on the web visit
>         https://groups.google.com/d/msgid/aerogear/0c02be2b-3c73-5fad-bca1-54b60cfc0e5e%40redhat.com
>         <https://groups.google.com/d/msgid/aerogear/0c02be2b-3c73-5fad-bca1-54b60cfc0e5e%40redhat.com>.
>         For more options, visit https://groups.google.com/d/optout
>         <https://groups.google.com/d/optout>.
>
>     -- 
>     You received this message because you are subscribed to the Google
>     Groups "Aerogear" group.
>     To unsubscribe from this group and stop receiving emails from it,
>     send an email to aerogear+unsubscribe at googlegroups.com
>     <mailto:aerogear+unsubscribe at googlegroups.com>.
>     To post to this group, send email to aerogear at googlegroups.com
>     <mailto:aerogear at googlegroups.com>.
>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/aerogear/CADvBQ45gqTRbx1xO9G78JT93LvGRvP8E4qYoX%2BUGCqQAMQz6jw%40mail.gmail.com
>     <https://groups.google.com/d/msgid/aerogear/CADvBQ45gqTRbx1xO9G78JT93LvGRvP8E4qYoX%2BUGCqQAMQz6jw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>     For more options, visit https://groups.google.com/d/optout
>     <https://groups.google.com/d/optout>.
>
>

-- 
Paul Wright
Mobile Docs (github: finp)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180206/48edbb2f/attachment-0001.html 

From matzew at apache.org  Tue Feb  6 10:18:47 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 6 Feb 2018 16:18:47 +0100
Subject: [aerogear-dev] Push modules (was Re: UPS: Admin UI)
Message-ID: <CAAg5f2T1hWZMtjHQfjH3U=xWpA014C_rQpMGPUCd9fN=2ffmag@mail.gmail.com>

here is the proposal:
https://github.com/aerogear/proposals/pull/21


On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi, Dave
>
> thanks for the feedback
>
> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti at redhat.com> wrote:
>
>> For RHMAP 3/4, the Studio was originally part of a single jar/war
>> (millicore). It did have a jsp for delivering the index.html (which
>> wrote a bunch of inline javascript)
>>
>> The studio was then decoupled from the war file as a separate war
>> (fh-studio). However, it still had an index.jsp, but called back to
>> the 'core' to get some of the info needed for that.
>>
>> This was eventually refactored into a node.js express app (fh-ngui)
>> and deployed completely separately. It still made calls back to the
>> core to get some config/user info.
>>
>> The main benefit I found was the UI could be progressed at a faster
>> pace as the local development tooling could be tailored better. (just
>> run the UI server & hook up to an existing core somewhere)
>> However, it introduced overhead with the addition of a new deployable
>> component.
>>
>
> that's also some of the points. We already have the development moved over
> to a different repo.
> We currently just stick it's JAR (which might be silly) into the WAR.
>
>
>>
>> This was all in a pre-containers world, but it was migrated to a
>> container world (on openshift).
>> We never went as far as nginx serving static content, but I could see
>> that as a logical progression.
>> It would probably mean a smaller footprint overall.
>>
>
> cool. It's something I will include in the proposal (not done any
> testings).
>
>
> Currently I look removing some good parts of the WAR file for the push
> delivery itself.
>
> current approach, which I do like so far, is having each "network" run as
> a java process, that wires the "send bits" (e.g. for iOS) togehter via
> messaging (kafka).
> Here is a metrics screenshot:
> https://user-images.githubusercontent.com/157646/
> 35808591-9393ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>
> code is located here:
> https://github.com/matzew/aerogear-unifiedpush-server/tree/
> 8d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-
> agent/src/main/java/org/aerogear/push/apns
>
> It's borrowing some concenpts/code from core UPS. but is really no http
> server - just a standard Main, which has a kafka consumer, plugged via ENVs.
>
> I currently deploy to Openshift using the fabric8-maven-plugin (fmp), that
> generates all all (docker file, k8s/oc yamls).
>
> I will do the same for FCM.
>
> Once that all is done, we have no "sending" code in the UPS, and we can
> move than the UPS itself to WF-Swarm, for a migration to a simpler
> develipment/deployment model (and perhaps some more modules in the longer
> run)
>
> Proposing:
> * fcm-sender.jar (in container)
> * apns-sender.jar (in container)
> * UPS move to Swarm
> * UI in nginx
>
>
>
>>
>> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>> > Hi,
>> >
>> > right now, we have the static resources of the admin ui build to a JAR
>> file
>> > and a "node tgz". Currently, in the community, we use the bundled JAR
>> and
>> > deployed to the UPS WAR file. So far, so good
>> >
>> > For our modularization I was thinking at different options:
>> >
>> > * WildFly Swarm w/ just static (WAR) resources
>> > * Node.js/Express app
>> > * Ngnix container, just serviing the content
>> >
>> > I've tested 1) I was wondering if we might - for some better resource
>> > utilization might just go w/ Ngnix, and deploy the static resources of
>> the
>> > admin UI to there?
>> >
>> > How do other think about breaking the UPS down to different
>> technologies and
>> > aspects?
>> >
>> > -Matthias
>> >
>> > [1] https://github.com/aerogear/unifiedpush-admin-ui
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > github: https://github.com/matzew
>> > twitter: http://twitter.com/mwessendorf
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "Aerogear" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to aerogear+unsubscribe at googlegroups.com.
>> > To post to this group, send email to aerogear at googlegroups.com.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq
>> -VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> David Martin
>> Red Hat Mobile
>> Twitter: @irldavem
>> IRC: @irldavem (#aerogear)
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Aerogear" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to aerogear+unsubscribe at googlegroups.com.
>> To post to this group, send email to aerogear at googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/aerogear/CADvBQ45yhH_-%2BZ2gKsU-agjv2ucngsgUgo66-dQ7Mdyo
>> MuDinw%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180206/dafa3e90/attachment.html 

From matzew at apache.org  Wed Feb  7 02:15:50 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 7 Feb 2018 08:15:50 +0100
Subject: [aerogear-dev] Push modules (was Re: UPS: Admin UI)
In-Reply-To: <CAAg5f2T1hWZMtjHQfjH3U=xWpA014C_rQpMGPUCd9fN=2ffmag@mail.gmail.com>
References: <CAAg5f2T1hWZMtjHQfjH3U=xWpA014C_rQpMGPUCd9fN=2ffmag@mail.gmail.com>
Message-ID: <CAAg5f2RBZZx7L5xqQVkjq2NVjyO3sHNJwRFdYSTi4oZ5v=GHNg@mail.gmail.com>

with the POC for agents done (APNs), I will continue the work, to shrink
the "CORE" part of the UPS, using Swarm, JPA, CDI and JAX-RS fractions

On Tue, Feb 6, 2018 at 4:18 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> here is the proposal:
> https://github.com/aerogear/proposals/pull/21
>
>
> On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi, Dave
>>
>> thanks for the feedback
>>
>> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti at redhat.com> wrote:
>>
>>> For RHMAP 3/4, the Studio was originally part of a single jar/war
>>> (millicore). It did have a jsp for delivering the index.html (which
>>> wrote a bunch of inline javascript)
>>>
>>> The studio was then decoupled from the war file as a separate war
>>> (fh-studio). However, it still had an index.jsp, but called back to
>>> the 'core' to get some of the info needed for that.
>>>
>>> This was eventually refactored into a node.js express app (fh-ngui)
>>> and deployed completely separately. It still made calls back to the
>>> core to get some config/user info.
>>>
>>> The main benefit I found was the UI could be progressed at a faster
>>> pace as the local development tooling could be tailored better. (just
>>> run the UI server & hook up to an existing core somewhere)
>>> However, it introduced overhead with the addition of a new deployable
>>> component.
>>>
>>
>> that's also some of the points. We already have the development moved
>> over to a different repo.
>> We currently just stick it's JAR (which might be silly) into the WAR.
>>
>>
>>>
>>> This was all in a pre-containers world, but it was migrated to a
>>> container world (on openshift).
>>> We never went as far as nginx serving static content, but I could see
>>> that as a logical progression.
>>> It would probably mean a smaller footprint overall.
>>>
>>
>> cool. It's something I will include in the proposal (not done any
>> testings).
>>
>>
>> Currently I look removing some good parts of the WAR file for the push
>> delivery itself.
>>
>> current approach, which I do like so far, is having each "network" run as
>> a java process, that wires the "send bits" (e.g. for iOS) togehter via
>> messaging (kafka).
>> Here is a metrics screenshot:
>> https://user-images.githubusercontent.com/157646/35808591-
>> 9393ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>>
>> code is located here:
>> https://github.com/matzew/aerogear-unifiedpush-server/tree/8
>> d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-age
>> nt/src/main/java/org/aerogear/push/apns
>>
>> It's borrowing some concenpts/code from core UPS. but is really no http
>> server - just a standard Main, which has a kafka consumer, plugged via ENVs.
>>
>> I currently deploy to Openshift using the fabric8-maven-plugin (fmp),
>> that generates all all (docker file, k8s/oc yamls).
>>
>> I will do the same for FCM.
>>
>> Once that all is done, we have no "sending" code in the UPS, and we can
>> move than the UPS itself to WF-Swarm, for a migration to a simpler
>> develipment/deployment model (and perhaps some more modules in the longer
>> run)
>>
>> Proposing:
>> * fcm-sender.jar (in container)
>> * apns-sender.jar (in container)
>> * UPS move to Swarm
>> * UI in nginx
>>
>>
>>
>>>
>>> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>> > Hi,
>>> >
>>> > right now, we have the static resources of the admin ui build to a JAR
>>> file
>>> > and a "node tgz". Currently, in the community, we use the bundled JAR
>>> and
>>> > deployed to the UPS WAR file. So far, so good
>>> >
>>> > For our modularization I was thinking at different options:
>>> >
>>> > * WildFly Swarm w/ just static (WAR) resources
>>> > * Node.js/Express app
>>> > * Ngnix container, just serviing the content
>>> >
>>> > I've tested 1) I was wondering if we might - for some better resource
>>> > utilization might just go w/ Ngnix, and deploy the static resources of
>>> the
>>> > admin UI to there?
>>> >
>>> > How do other think about breaking the UPS down to different
>>> technologies and
>>> > aspects?
>>> >
>>> > -Matthias
>>> >
>>> > [1] https://github.com/aerogear/unifiedpush-admin-ui
>>> >
>>> > --
>>> > Matthias Wessendorf
>>> >
>>> > github: https://github.com/matzew
>>> > twitter: http://twitter.com/mwessendorf
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups
>>> > "Aerogear" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an
>>> > email to aerogear+unsubscribe at googlegroups.com.
>>> > To post to this group, send email to aerogear at googlegroups.com.
>>> > To view this discussion on the web visit
>>> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq
>>> -VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> David Martin
>>> Red Hat Mobile
>>> Twitter: @irldavem
>>> IRC: @irldavem (#aerogear)
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Aerogear" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to aerogear+unsubscribe at googlegroups.com.
>>> To post to this group, send email to aerogear at googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/aerogear/CADvBQ45yhH_-%2BZ2gKsU-agjv2ucngsgUgo66-dQ7Mdyo
>>> MuDinw%40mail.gmail.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180207/52dbe89d/attachment-0001.html 

From matzew at apache.org  Wed Feb  7 06:09:52 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 7 Feb 2018 12:09:52 +0100
Subject: [aerogear-dev] GSoC 2018 and UPS
In-Reply-To: <CAAg5f2Rd-8RDH7Vsx38JANwHphVAhGGA22W4OZGz=0JkCJ7ZPw@mail.gmail.com>
References: <CAAg5f2Rrb40B8QtSS__-ap0zCCAOZhbnt58Wrqj4AVv+WV6ZYw@mail.gmail.com>
	<CAAg5f2Rd-8RDH7Vsx38JANwHphVAhGGA22W4OZGz=0JkCJ7ZPw@mail.gmail.com>
Message-ID: <CAAg5f2T9ZC_Kr+z3S7mag4Yfmz=nmONZVosioYtWLO4kMb05AQ@mail.gmail.com>

this is likely no longer relevant (see related threads on UPS proposal)

Any other thoughts, around "push content" for GSoC ?

On Wed, Jan 17, 2018 at 11:48 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Folks, anybody is more than welcome to give feedback on this.
> it may be the new arch for the UPS.next :-)
>
>
>
> On Tue, Jan 16, 2018 at 3:32 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> For UPS.next, I've drafted this:
>>
>>  https://gist.github.com/matzew/159e8ac444822b5509aff0f908d0bdc5
>>
>> It's a good step forward, and in the long run, these modules will also
>> help to easily replace some parts of the server,  e.g. rewrite the "sender"
>> in go
>>
>> Any thoughts ?
>> -M
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180207/51433e6b/attachment.html 

From matzew at apache.org  Wed Feb  7 13:43:39 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 7 Feb 2018 19:43:39 +0100
Subject: [aerogear-dev] Push modules (was Re: UPS: Admin UI)
In-Reply-To: <CAAg5f2RBZZx7L5xqQVkjq2NVjyO3sHNJwRFdYSTi4oZ5v=GHNg@mail.gmail.com>
References: <CAAg5f2T1hWZMtjHQfjH3U=xWpA014C_rQpMGPUCd9fN=2ffmag@mail.gmail.com>
	<CAAg5f2RBZZx7L5xqQVkjq2NVjyO3sHNJwRFdYSTi4oZ5v=GHNg@mail.gmail.com>
Message-ID: <CAAg5f2QwnrpFeEKpmMa5RawvTjMPp0kctyefkyEHHFoiKMSD3Q@mail.gmail.com>

Question :-)

On Wed, Feb 7, 2018 at 8:15 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> with the POC for agents done (APNs), I will continue the work, to shrink
> the "CORE" part of the UPS, using Swarm, JPA, CDI and JAX-RS fractions
>

speaking of the "CORE" part ... I think... the simplified push models will
allow us, to also come up w/ a different and simpler data model.

So... Let's say the UPS2 would be a bit different (POC in progress), I
think the really important bit is that the "important" data (e.g
PushApps/Variants and, of course, devices) can be exported from old DB and
'transformed' to new DB.
Sounds good?

Our current analytics, is something, I'd like to revisit. But not 100% sure
yet, but I do see some option, based on lessons learned.
If these data bits are not portable, I'd not cry a river - compared to a
case where "device metadata" would be lost (which is IMO a no-go)

Thoughts ?
-M



>
> On Tue, Feb 6, 2018 at 4:18 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> here is the proposal:
>> https://github.com/aerogear/proposals/pull/21
>>
>>
>> On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Hi, Dave
>>>
>>> thanks for the feedback
>>>
>>> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti at redhat.com>
>>> wrote:
>>>
>>>> For RHMAP 3/4, the Studio was originally part of a single jar/war
>>>> (millicore). It did have a jsp for delivering the index.html (which
>>>> wrote a bunch of inline javascript)
>>>>
>>>> The studio was then decoupled from the war file as a separate war
>>>> (fh-studio). However, it still had an index.jsp, but called back to
>>>> the 'core' to get some of the info needed for that.
>>>>
>>>> This was eventually refactored into a node.js express app (fh-ngui)
>>>> and deployed completely separately. It still made calls back to the
>>>> core to get some config/user info.
>>>>
>>>> The main benefit I found was the UI could be progressed at a faster
>>>> pace as the local development tooling could be tailored better. (just
>>>> run the UI server & hook up to an existing core somewhere)
>>>> However, it introduced overhead with the addition of a new deployable
>>>> component.
>>>>
>>>
>>> that's also some of the points. We already have the development moved
>>> over to a different repo.
>>> We currently just stick it's JAR (which might be silly) into the WAR.
>>>
>>>
>>>>
>>>> This was all in a pre-containers world, but it was migrated to a
>>>> container world (on openshift).
>>>> We never went as far as nginx serving static content, but I could see
>>>> that as a logical progression.
>>>> It would probably mean a smaller footprint overall.
>>>>
>>>
>>> cool. It's something I will include in the proposal (not done any
>>> testings).
>>>
>>>
>>> Currently I look removing some good parts of the WAR file for the push
>>> delivery itself.
>>>
>>> current approach, which I do like so far, is having each "network" run
>>> as a java process, that wires the "send bits" (e.g. for iOS) togehter via
>>> messaging (kafka).
>>> Here is a metrics screenshot:
>>> https://user-images.githubusercontent.com/157646/35808591-93
>>> 93ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>>>
>>> code is located here:
>>> https://github.com/matzew/aerogear-unifiedpush-server/tree/8
>>> d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-age
>>> nt/src/main/java/org/aerogear/push/apns
>>>
>>> It's borrowing some concenpts/code from core UPS. but is really no http
>>> server - just a standard Main, which has a kafka consumer, plugged via ENVs.
>>>
>>> I currently deploy to Openshift using the fabric8-maven-plugin (fmp),
>>> that generates all all (docker file, k8s/oc yamls).
>>>
>>> I will do the same for FCM.
>>>
>>> Once that all is done, we have no "sending" code in the UPS, and we can
>>> move than the UPS itself to WF-Swarm, for a migration to a simpler
>>> develipment/deployment model (and perhaps some more modules in the longer
>>> run)
>>>
>>> Proposing:
>>> * fcm-sender.jar (in container)
>>> * apns-sender.jar (in container)
>>> * UPS move to Swarm
>>> * UI in nginx
>>>
>>>
>>>
>>>>
>>>> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > right now, we have the static resources of the admin ui build to a
>>>> JAR file
>>>> > and a "node tgz". Currently, in the community, we use the bundled JAR
>>>> and
>>>> > deployed to the UPS WAR file. So far, so good
>>>> >
>>>> > For our modularization I was thinking at different options:
>>>> >
>>>> > * WildFly Swarm w/ just static (WAR) resources
>>>> > * Node.js/Express app
>>>> > * Ngnix container, just serviing the content
>>>> >
>>>> > I've tested 1) I was wondering if we might - for some better resource
>>>> > utilization might just go w/ Ngnix, and deploy the static resources
>>>> of the
>>>> > admin UI to there?
>>>> >
>>>> > How do other think about breaking the UPS down to different
>>>> technologies and
>>>> > aspects?
>>>> >
>>>> > -Matthias
>>>> >
>>>> > [1] https://github.com/aerogear/unifiedpush-admin-ui
>>>> >
>>>> > --
>>>> > Matthias Wessendorf
>>>> >
>>>> > github: https://github.com/matzew
>>>> > twitter: http://twitter.com/mwessendorf
>>>> >
>>>> > --
>>>> > You received this message because you are subscribed to the Google
>>>> Groups
>>>> > "Aerogear" group.
>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>> send an
>>>> > email to aerogear+unsubscribe at googlegroups.com.
>>>> > To post to this group, send email to aerogear at googlegroups.com.
>>>> > To view this discussion on the web visit
>>>> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq
>>>> -VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>
>>>> --
>>>> David Martin
>>>> Red Hat Mobile
>>>> Twitter: @irldavem
>>>> IRC: @irldavem (#aerogear)
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Aerogear" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to aerogear+unsubscribe at googlegroups.com.
>>>> To post to this group, send email to aerogear at googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/aerogear/CADvBQ45yhH_-%2BZ2gKsU-agjv2ucngsgUgo66-dQ7Mdyo
>>>> MuDinw%40mail.gmail.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> github: https://github.com/matzew
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180207/6bef5ac0/attachment-0001.html 

From matzew at apache.org  Wed Feb  7 13:54:55 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 7 Feb 2018 19:54:55 +0100
Subject: [aerogear-dev] Push modules (was Re: UPS: Admin UI)
In-Reply-To: <CAAg5f2QwnrpFeEKpmMa5RawvTjMPp0kctyefkyEHHFoiKMSD3Q@mail.gmail.com>
References: <CAAg5f2T1hWZMtjHQfjH3U=xWpA014C_rQpMGPUCd9fN=2ffmag@mail.gmail.com>
	<CAAg5f2RBZZx7L5xqQVkjq2NVjyO3sHNJwRFdYSTi4oZ5v=GHNg@mail.gmail.com>
	<CAAg5f2QwnrpFeEKpmMa5RawvTjMPp0kctyefkyEHHFoiKMSD3Q@mail.gmail.com>
Message-ID: <CAAg5f2QF2AiZVK+QyYB0mDL5G58LXmUPVNySjrcpgJv58Z012A@mail.gmail.com>

That said, the HTTP API for device registration and sending should stay
compatible

On Wed, Feb 7, 2018 at 7:43 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Question :-)
>
> On Wed, Feb 7, 2018 at 8:15 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> with the POC for agents done (APNs), I will continue the work, to shrink
>> the "CORE" part of the UPS, using Swarm, JPA, CDI and JAX-RS fractions
>>
>
> speaking of the "CORE" part ... I think... the simplified push models will
> allow us, to also come up w/ a different and simpler data model.
>
> So... Let's say the UPS2 would be a bit different (POC in progress), I
> think the really important bit is that the "important" data (e.g
> PushApps/Variants and, of course, devices) can be exported from old DB and
> 'transformed' to new DB.
> Sounds good?
>
> Our current analytics, is something, I'd like to revisit. But not 100%
> sure yet, but I do see some option, based on lessons learned.
> If these data bits are not portable, I'd not cry a river - compared to a
> case where "device metadata" would be lost (which is IMO a no-go)
>
> Thoughts ?
> -M
>
>
>
>>
>> On Tue, Feb 6, 2018 at 4:18 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> here is the proposal:
>>> https://github.com/aerogear/proposals/pull/21
>>>
>>>
>>> On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> Hi, Dave
>>>>
>>>> thanks for the feedback
>>>>
>>>> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti at redhat.com>
>>>> wrote:
>>>>
>>>>> For RHMAP 3/4, the Studio was originally part of a single jar/war
>>>>> (millicore). It did have a jsp for delivering the index.html (which
>>>>> wrote a bunch of inline javascript)
>>>>>
>>>>> The studio was then decoupled from the war file as a separate war
>>>>> (fh-studio). However, it still had an index.jsp, but called back to
>>>>> the 'core' to get some of the info needed for that.
>>>>>
>>>>> This was eventually refactored into a node.js express app (fh-ngui)
>>>>> and deployed completely separately. It still made calls back to the
>>>>> core to get some config/user info.
>>>>>
>>>>> The main benefit I found was the UI could be progressed at a faster
>>>>> pace as the local development tooling could be tailored better. (just
>>>>> run the UI server & hook up to an existing core somewhere)
>>>>> However, it introduced overhead with the addition of a new deployable
>>>>> component.
>>>>>
>>>>
>>>> that's also some of the points. We already have the development moved
>>>> over to a different repo.
>>>> We currently just stick it's JAR (which might be silly) into the WAR.
>>>>
>>>>
>>>>>
>>>>> This was all in a pre-containers world, but it was migrated to a
>>>>> container world (on openshift).
>>>>> We never went as far as nginx serving static content, but I could see
>>>>> that as a logical progression.
>>>>> It would probably mean a smaller footprint overall.
>>>>>
>>>>
>>>> cool. It's something I will include in the proposal (not done any
>>>> testings).
>>>>
>>>>
>>>> Currently I look removing some good parts of the WAR file for the push
>>>> delivery itself.
>>>>
>>>> current approach, which I do like so far, is having each "network" run
>>>> as a java process, that wires the "send bits" (e.g. for iOS) togehter via
>>>> messaging (kafka).
>>>> Here is a metrics screenshot:
>>>> https://user-images.githubusercontent.com/157646/35808591-93
>>>> 93ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>>>>
>>>> code is located here:
>>>> https://github.com/matzew/aerogear-unifiedpush-server/tree/8
>>>> d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-age
>>>> nt/src/main/java/org/aerogear/push/apns
>>>>
>>>> It's borrowing some concenpts/code from core UPS. but is really no http
>>>> server - just a standard Main, which has a kafka consumer, plugged via ENVs.
>>>>
>>>> I currently deploy to Openshift using the fabric8-maven-plugin (fmp),
>>>> that generates all all (docker file, k8s/oc yamls).
>>>>
>>>> I will do the same for FCM.
>>>>
>>>> Once that all is done, we have no "sending" code in the UPS, and we can
>>>> move than the UPS itself to WF-Swarm, for a migration to a simpler
>>>> develipment/deployment model (and perhaps some more modules in the longer
>>>> run)
>>>>
>>>> Proposing:
>>>> * fcm-sender.jar (in container)
>>>> * apns-sender.jar (in container)
>>>> * UPS move to Swarm
>>>> * UI in nginx
>>>>
>>>>
>>>>
>>>>>
>>>>> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org>
>>>>> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > right now, we have the static resources of the admin ui build to a
>>>>> JAR file
>>>>> > and a "node tgz". Currently, in the community, we use the bundled
>>>>> JAR and
>>>>> > deployed to the UPS WAR file. So far, so good
>>>>> >
>>>>> > For our modularization I was thinking at different options:
>>>>> >
>>>>> > * WildFly Swarm w/ just static (WAR) resources
>>>>> > * Node.js/Express app
>>>>> > * Ngnix container, just serviing the content
>>>>> >
>>>>> > I've tested 1) I was wondering if we might - for some better resource
>>>>> > utilization might just go w/ Ngnix, and deploy the static resources
>>>>> of the
>>>>> > admin UI to there?
>>>>> >
>>>>> > How do other think about breaking the UPS down to different
>>>>> technologies and
>>>>> > aspects?
>>>>> >
>>>>> > -Matthias
>>>>> >
>>>>> > [1] https://github.com/aerogear/unifiedpush-admin-ui
>>>>> >
>>>>> > --
>>>>> > Matthias Wessendorf
>>>>> >
>>>>> > github: https://github.com/matzew
>>>>> > twitter: http://twitter.com/mwessendorf
>>>>> >
>>>>> > --
>>>>> > You received this message because you are subscribed to the Google
>>>>> Groups
>>>>> > "Aerogear" group.
>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>> send an
>>>>> > email to aerogear+unsubscribe at googlegroups.com.
>>>>> > To post to this group, send email to aerogear at googlegroups.com.
>>>>> > To view this discussion on the web visit
>>>>> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq
>>>>> -VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> David Martin
>>>>> Red Hat Mobile
>>>>> Twitter: @irldavem
>>>>> IRC: @irldavem (#aerogear)
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Aerogear" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to aerogear+unsubscribe at googlegroups.com.
>>>>> To post to this group, send email to aerogear at googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/aerogear/CADvBQ45yhH_-%2BZ
>>>>> 2gKsU-agjv2ucngsgUgo66-dQ7MdyoMuDinw%40mail.gmail.com.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> github: https://github.com/matzew
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> github: https://github.com/matzew
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180207/2c1d2d56/attachment.html 

From jfrizell at redhat.com  Wed Feb  7 14:23:15 2018
From: jfrizell at redhat.com (John Frizelle)
Date: Wed, 7 Feb 2018 19:23:15 +0000
Subject: [aerogear-dev] Push modules (was Re: UPS: Admin UI)
In-Reply-To: <CAAg5f2QF2AiZVK+QyYB0mDL5G58LXmUPVNySjrcpgJv58Z012A@mail.gmail.com>
References: <CAAg5f2T1hWZMtjHQfjH3U=xWpA014C_rQpMGPUCd9fN=2ffmag@mail.gmail.com>
	<CAAg5f2RBZZx7L5xqQVkjq2NVjyO3sHNJwRFdYSTi4oZ5v=GHNg@mail.gmail.com>
	<CAAg5f2QwnrpFeEKpmMa5RawvTjMPp0kctyefkyEHHFoiKMSD3Q@mail.gmail.com>
	<CAAg5f2QF2AiZVK+QyYB0mDL5G58LXmUPVNySjrcpgJv58Z012A@mail.gmail.com>
Message-ID: <CAJFhnM4tUCG3-nqq-H2t4OgkF4yTp5koz+rAUNX_xcxrNobaNA@mail.gmail.com>

Hi Matthias,

Can we have a discussion about this before it progresses too far.

I have some fairly serious concerns [1] about the resource requirements
needed to run a Kafka deployment in a production environment and am not
convinced that putting Kafka into the mix here is the right approach. Are
we over complicating push to optimise for the corner cases here? What would
a "Starter" deployment look like in terms of resource usage? Would it fit
in an OpenShift Online free tier?

Cheers,
John.


[1] https://docs.confluent.io/current/kafka/deployment.html


--
John Frizelle
Chief Architect, Red Hat Mobile
Consulting Engineer

mobile: *+353 87 290 1644 <//+353872901644>*
twitter:* @johnfriz*
skype: *john_frizelle*
mail: *jfrizell at redhat.com <jfrizell at redhat.com>*




On 7 February 2018 at 18:54, Matthias Wessendorf <matzew at apache.org> wrote:

> That said, the HTTP API for device registration and sending should stay
> compatible
>
> On Wed, Feb 7, 2018 at 7:43 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Question :-)
>>
>> On Wed, Feb 7, 2018 at 8:15 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> with the POC for agents done (APNs), I will continue the work, to shrink
>>> the "CORE" part of the UPS, using Swarm, JPA, CDI and JAX-RS fractions
>>>
>>
>> speaking of the "CORE" part ... I think... the simplified push models
>> will allow us, to also come up w/ a different and simpler data model.
>>
>> So... Let's say the UPS2 would be a bit different (POC in progress), I
>> think the really important bit is that the "important" data (e.g
>> PushApps/Variants and, of course, devices) can be exported from old DB and
>> 'transformed' to new DB.
>> Sounds good?
>>
>> Our current analytics, is something, I'd like to revisit. But not 100%
>> sure yet, but I do see some option, based on lessons learned.
>> If these data bits are not portable, I'd not cry a river - compared to a
>> case where "device metadata" would be lost (which is IMO a no-go)
>>
>> Thoughts ?
>> -M
>>
>>
>>
>>>
>>> On Tue, Feb 6, 2018 at 4:18 PM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> here is the proposal:
>>>> https://github.com/aerogear/proposals/pull/21
>>>>
>>>>
>>>> On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew at apache.org>
>>>> wrote:
>>>>
>>>>> Hi, Dave
>>>>>
>>>>> thanks for the feedback
>>>>>
>>>>> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti at redhat.com>
>>>>> wrote:
>>>>>
>>>>>> For RHMAP 3/4, the Studio was originally part of a single jar/war
>>>>>> (millicore). It did have a jsp for delivering the index.html (which
>>>>>> wrote a bunch of inline javascript)
>>>>>>
>>>>>> The studio was then decoupled from the war file as a separate war
>>>>>> (fh-studio). However, it still had an index.jsp, but called back to
>>>>>> the 'core' to get some of the info needed for that.
>>>>>>
>>>>>> This was eventually refactored into a node.js express app (fh-ngui)
>>>>>> and deployed completely separately. It still made calls back to the
>>>>>> core to get some config/user info.
>>>>>>
>>>>>> The main benefit I found was the UI could be progressed at a faster
>>>>>> pace as the local development tooling could be tailored better. (just
>>>>>> run the UI server & hook up to an existing core somewhere)
>>>>>> However, it introduced overhead with the addition of a new deployable
>>>>>> component.
>>>>>>
>>>>>
>>>>> that's also some of the points. We already have the development moved
>>>>> over to a different repo.
>>>>> We currently just stick it's JAR (which might be silly) into the WAR.
>>>>>
>>>>>
>>>>>>
>>>>>> This was all in a pre-containers world, but it was migrated to a
>>>>>> container world (on openshift).
>>>>>> We never went as far as nginx serving static content, but I could see
>>>>>> that as a logical progression.
>>>>>> It would probably mean a smaller footprint overall.
>>>>>>
>>>>>
>>>>> cool. It's something I will include in the proposal (not done any
>>>>> testings).
>>>>>
>>>>>
>>>>> Currently I look removing some good parts of the WAR file for the push
>>>>> delivery itself.
>>>>>
>>>>> current approach, which I do like so far, is having each "network" run
>>>>> as a java process, that wires the "send bits" (e.g. for iOS) togehter via
>>>>> messaging (kafka).
>>>>> Here is a metrics screenshot:
>>>>> https://user-images.githubusercontent.com/157646/35808591-93
>>>>> 93ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>>>>>
>>>>> code is located here:
>>>>> https://github.com/matzew/aerogear-unifiedpush-server/tree/8
>>>>> d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-age
>>>>> nt/src/main/java/org/aerogear/push/apns
>>>>>
>>>>> It's borrowing some concenpts/code from core UPS. but is really no
>>>>> http server - just a standard Main, which has a kafka consumer, plugged via
>>>>> ENVs.
>>>>>
>>>>> I currently deploy to Openshift using the fabric8-maven-plugin (fmp),
>>>>> that generates all all (docker file, k8s/oc yamls).
>>>>>
>>>>> I will do the same for FCM.
>>>>>
>>>>> Once that all is done, we have no "sending" code in the UPS, and we
>>>>> can move than the UPS itself to WF-Swarm, for a migration to a simpler
>>>>> develipment/deployment model (and perhaps some more modules in the longer
>>>>> run)
>>>>>
>>>>> Proposing:
>>>>> * fcm-sender.jar (in container)
>>>>> * apns-sender.jar (in container)
>>>>> * UPS move to Swarm
>>>>> * UI in nginx
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org>
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > right now, we have the static resources of the admin ui build to a
>>>>>> JAR file
>>>>>> > and a "node tgz". Currently, in the community, we use the bundled
>>>>>> JAR and
>>>>>> > deployed to the UPS WAR file. So far, so good
>>>>>> >
>>>>>> > For our modularization I was thinking at different options:
>>>>>> >
>>>>>> > * WildFly Swarm w/ just static (WAR) resources
>>>>>> > * Node.js/Express app
>>>>>> > * Ngnix container, just serviing the content
>>>>>> >
>>>>>> > I've tested 1) I was wondering if we might - for some better
>>>>>> resource
>>>>>> > utilization might just go w/ Ngnix, and deploy the static resources
>>>>>> of the
>>>>>> > admin UI to there?
>>>>>> >
>>>>>> > How do other think about breaking the UPS down to different
>>>>>> technologies and
>>>>>> > aspects?
>>>>>> >
>>>>>> > -Matthias
>>>>>> >
>>>>>> > [1] https://github.com/aerogear/unifiedpush-admin-ui
>>>>>> >
>>>>>> > --
>>>>>> > Matthias Wessendorf
>>>>>> >
>>>>>> > github: https://github.com/matzew
>>>>>> > twitter: http://twitter.com/mwessendorf
>>>>>> >
>>>>>> > --
>>>>>> > You received this message because you are subscribed to the Google
>>>>>> Groups
>>>>>> > "Aerogear" group.
>>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an
>>>>>> > email to aerogear+unsubscribe at googlegroups.com.
>>>>>> > To post to this group, send email to aerogear at googlegroups.com.
>>>>>> > To view this discussion on the web visit
>>>>>> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq
>>>>>> -VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
>>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> David Martin
>>>>>> Red Hat Mobile
>>>>>> Twitter: @irldavem
>>>>>> IRC: @irldavem (#aerogear)
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Aerogear" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to aerogear+unsubscribe at googlegroups.com.
>>>>>> To post to this group, send email to aerogear at googlegroups.com.
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/aerogear/CADvBQ45yhH_-%2BZ
>>>>>> 2gKsU-agjv2ucngsgUgo66-dQ7MdyoMuDinw%40mail.gmail.com.
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> github: https://github.com/matzew
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> github: https://github.com/matzew
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> github: https://github.com/matzew
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CAAg5f2QF2AiZVK%2BQyYB0mDL5G58LXmUPVNySjrcpgJv
> 58Z012A%40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CAAg5f2QF2AiZVK%2BQyYB0mDL5G58LXmUPVNySjrcpgJv58Z012A%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180207/115708d6/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180207/115708d6/attachment-0001.png 

From matzew at apache.org  Wed Feb  7 15:46:41 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 7 Feb 2018 21:46:41 +0100
Subject: [aerogear-dev] Push modules (was Re: UPS: Admin UI)
In-Reply-To: <CAJFhnM4tUCG3-nqq-H2t4OgkF4yTp5koz+rAUNX_xcxrNobaNA@mail.gmail.com>
References: <CAAg5f2T1hWZMtjHQfjH3U=xWpA014C_rQpMGPUCd9fN=2ffmag@mail.gmail.com>
	<CAAg5f2RBZZx7L5xqQVkjq2NVjyO3sHNJwRFdYSTi4oZ5v=GHNg@mail.gmail.com>
	<CAAg5f2QwnrpFeEKpmMa5RawvTjMPp0kctyefkyEHHFoiKMSD3Q@mail.gmail.com>
	<CAAg5f2QF2AiZVK+QyYB0mDL5G58LXmUPVNySjrcpgJv58Z012A@mail.gmail.com>
	<CAJFhnM4tUCG3-nqq-H2t4OgkF4yTp5koz+rAUNX_xcxrNobaNA@mail.gmail.com>
Message-ID: <CAAg5f2TKDB2r7grT1thAHxmvF6KCvVU8d3ppAdyEuGLkRgA68A@mail.gmail.com>

Hey John,

On Wed, Feb 7, 2018 at 8:23 PM, John Frizelle <jfrizell at redhat.com> wrote:

> Hi Matthias,
>
> Can we have a discussion about this before it progresses too far.
>

sure - that's why I am sending mails here, for discussions :)


>
> I have some fairly serious concerns [1] about the resource requirements
> needed to run a Kafka deployment in a production environment and am not
> convinced that putting Kafka into the mix here is the right approach.
>

I don't think we need to worry about the mentioned linkedin scenario. I
honestly doubt we will ever need that, nor on-prem, neither on the SaaS
world


> Are we over complicating push to optimise for the corner cases here?
>

I don't think so. I see the Push as a _system_ space deployement, where a
few nodes of Kafka would be OK. Especially since it can be used by other
services as well (e.g. analytics etc).


> What would a "Starter" deployment look like in terms of resource usage?
>


I've used the EnMasse template for Openshift w/, and had three nodes for
Kafka and Zookeeper. Kafka was around 600 MB (per node), and ZK around 400
(when I turned on Openshift metrics)



> Would it fit in an OpenShift Online free tier?
>

Dunno  - I don't have an account there.


That said - the current UPS 1.2.x (with decoupled Keycloak) works fine -
especially w/ the fixes that we did last year introducing Netty for network
comms. to APNs. - but it does need 1.7 GB RAM, and scaling the busy parts
(e.g. if only APNs traffic goes up) is not so simple, or even impossible.

The main work, on Kafka, was done last year during GSOC. My POC work here
was really just going on top and introducing smaller services, like the
APNs pod (150 MB RAM) or the WildFly-Swarm based "CORE" module.

I am fine to pause that POC, and focus more on features (E.g. larger
payloads), and get a proposal in based on features.



>
> Cheers,
> John.
>
>
> [1] https://docs.confluent.io/current/kafka/deployment.html
>
>
> --
> John Frizelle
> Chief Architect, Red Hat Mobile
> Consulting Engineer
>
> mobile: *+353 87 290 1644 <//+353872901644>*
> twitter:* @johnfriz*
> skype: *john_frizelle*
> mail: *jfrizell at redhat.com <jfrizell at redhat.com>*
>
>
>
>
> On 7 February 2018 at 18:54, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> That said, the HTTP API for device registration and sending should stay
>> compatible
>>
>> On Wed, Feb 7, 2018 at 7:43 PM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>> Question :-)
>>>
>>> On Wed, Feb 7, 2018 at 8:15 AM, Matthias Wessendorf <matzew at apache.org>
>>> wrote:
>>>
>>>> with the POC for agents done (APNs), I will continue the work, to
>>>> shrink the "CORE" part of the UPS, using Swarm, JPA, CDI and JAX-RS
>>>> fractions
>>>>
>>>
>>> speaking of the "CORE" part ... I think... the simplified push models
>>> will allow us, to also come up w/ a different and simpler data model.
>>>
>>> So... Let's say the UPS2 would be a bit different (POC in progress), I
>>> think the really important bit is that the "important" data (e.g
>>> PushApps/Variants and, of course, devices) can be exported from old DB and
>>> 'transformed' to new DB.
>>> Sounds good?
>>>
>>> Our current analytics, is something, I'd like to revisit. But not 100%
>>> sure yet, but I do see some option, based on lessons learned.
>>> If these data bits are not portable, I'd not cry a river - compared to a
>>> case where "device metadata" would be lost (which is IMO a no-go)
>>>
>>> Thoughts ?
>>> -M
>>>
>>>
>>>
>>>>
>>>> On Tue, Feb 6, 2018 at 4:18 PM, Matthias Wessendorf <matzew at apache.org>
>>>> wrote:
>>>>
>>>>> here is the proposal:
>>>>> https://github.com/aerogear/proposals/pull/21
>>>>>
>>>>>
>>>>> On Mon, Feb 5, 2018 at 8:05 PM, Matthias Wessendorf <matzew at apache.org
>>>>> > wrote:
>>>>>
>>>>>> Hi, Dave
>>>>>>
>>>>>> thanks for the feedback
>>>>>>
>>>>>> On Mon, Feb 5, 2018 at 6:16 PM, David Martin <davmarti at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> For RHMAP 3/4, the Studio was originally part of a single jar/war
>>>>>>> (millicore). It did have a jsp for delivering the index.html (which
>>>>>>> wrote a bunch of inline javascript)
>>>>>>>
>>>>>>> The studio was then decoupled from the war file as a separate war
>>>>>>> (fh-studio). However, it still had an index.jsp, but called back to
>>>>>>> the 'core' to get some of the info needed for that.
>>>>>>>
>>>>>>> This was eventually refactored into a node.js express app (fh-ngui)
>>>>>>> and deployed completely separately. It still made calls back to the
>>>>>>> core to get some config/user info.
>>>>>>>
>>>>>>> The main benefit I found was the UI could be progressed at a faster
>>>>>>> pace as the local development tooling could be tailored better. (just
>>>>>>> run the UI server & hook up to an existing core somewhere)
>>>>>>> However, it introduced overhead with the addition of a new
>>>>>>> deployable component.
>>>>>>>
>>>>>>
>>>>>> that's also some of the points. We already have the development moved
>>>>>> over to a different repo.
>>>>>> We currently just stick it's JAR (which might be silly) into the WAR.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> This was all in a pre-containers world, but it was migrated to a
>>>>>>> container world (on openshift).
>>>>>>> We never went as far as nginx serving static content, but I could see
>>>>>>> that as a logical progression.
>>>>>>> It would probably mean a smaller footprint overall.
>>>>>>>
>>>>>>
>>>>>> cool. It's something I will include in the proposal (not done any
>>>>>> testings).
>>>>>>
>>>>>>
>>>>>> Currently I look removing some good parts of the WAR file for the
>>>>>> push delivery itself.
>>>>>>
>>>>>> current approach, which I do like so far, is having each "network"
>>>>>> run as a java process, that wires the "send bits" (e.g. for iOS) togehter
>>>>>> via messaging (kafka).
>>>>>> Here is a metrics screenshot:
>>>>>> https://user-images.githubusercontent.com/157646/35808591-93
>>>>>> 93ec6c-0a86-11e8-9b6f-f138fe0a5691.png
>>>>>>
>>>>>> code is located here:
>>>>>> https://github.com/matzew/aerogear-unifiedpush-server/tree/8
>>>>>> d01c771a0a89d1243534adef3a924ad284b3c41/push-agents/apns-age
>>>>>> nt/src/main/java/org/aerogear/push/apns
>>>>>>
>>>>>> It's borrowing some concenpts/code from core UPS. but is really no
>>>>>> http server - just a standard Main, which has a kafka consumer, plugged via
>>>>>> ENVs.
>>>>>>
>>>>>> I currently deploy to Openshift using the fabric8-maven-plugin (fmp),
>>>>>> that generates all all (docker file, k8s/oc yamls).
>>>>>>
>>>>>> I will do the same for FCM.
>>>>>>
>>>>>> Once that all is done, we have no "sending" code in the UPS, and we
>>>>>> can move than the UPS itself to WF-Swarm, for a migration to a simpler
>>>>>> develipment/deployment model (and perhaps some more modules in the longer
>>>>>> run)
>>>>>>
>>>>>> Proposing:
>>>>>> * fcm-sender.jar (in container)
>>>>>> * apns-sender.jar (in container)
>>>>>> * UPS move to Swarm
>>>>>> * UI in nginx
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> On 30 January 2018 at 19:40, Matthias Wessendorf <matzew at apache.org>
>>>>>>> wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > right now, we have the static resources of the admin ui build to a
>>>>>>> JAR file
>>>>>>> > and a "node tgz". Currently, in the community, we use the bundled
>>>>>>> JAR and
>>>>>>> > deployed to the UPS WAR file. So far, so good
>>>>>>> >
>>>>>>> > For our modularization I was thinking at different options:
>>>>>>> >
>>>>>>> > * WildFly Swarm w/ just static (WAR) resources
>>>>>>> > * Node.js/Express app
>>>>>>> > * Ngnix container, just serviing the content
>>>>>>> >
>>>>>>> > I've tested 1) I was wondering if we might - for some better
>>>>>>> resource
>>>>>>> > utilization might just go w/ Ngnix, and deploy the static
>>>>>>> resources of the
>>>>>>> > admin UI to there?
>>>>>>> >
>>>>>>> > How do other think about breaking the UPS down to different
>>>>>>> technologies and
>>>>>>> > aspects?
>>>>>>> >
>>>>>>> > -Matthias
>>>>>>> >
>>>>>>> > [1] https://github.com/aerogear/unifiedpush-admin-ui
>>>>>>> >
>>>>>>> > --
>>>>>>> > Matthias Wessendorf
>>>>>>> >
>>>>>>> > github: https://github.com/matzew
>>>>>>> > twitter: http://twitter.com/mwessendorf
>>>>>>> >
>>>>>>> > --
>>>>>>> > You received this message because you are subscribed to the Google
>>>>>>> Groups
>>>>>>> > "Aerogear" group.
>>>>>>> > To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an
>>>>>>> > email to aerogear+unsubscribe at googlegroups.com.
>>>>>>> > To post to this group, send email to aerogear at googlegroups.com.
>>>>>>> > To view this discussion on the web visit
>>>>>>> > https://groups.google.com/d/msgid/aerogear/CAAg5f2Qi6Fwj5FPq
>>>>>>> -VdBEw3Ro_pq4FwqJpPiyGbmj0cEJrfv7Q%40mail.gmail.com.
>>>>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> David Martin
>>>>>>> Red Hat Mobile
>>>>>>> Twitter: @irldavem
>>>>>>> IRC: @irldavem (#aerogear)
>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "Aerogear" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to aerogear+unsubscribe at googlegroups.com.
>>>>>>> To post to this group, send email to aerogear at googlegroups.com.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/aerogear/CADvBQ45yhH_-%2BZ
>>>>>>> 2gKsU-agjv2ucngsgUgo66-dQ7MdyoMuDinw%40mail.gmail.com.
>>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Matthias Wessendorf
>>>>>>
>>>>>> github: https://github.com/matzew
>>>>>> twitter: http://twitter.com/mwessendorf
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matthias Wessendorf
>>>>>
>>>>> github: https://github.com/matzew
>>>>> twitter: http://twitter.com/mwessendorf
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Matthias Wessendorf
>>>>
>>>> github: https://github.com/matzew
>>>> twitter: http://twitter.com/mwessendorf
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> github: https://github.com/matzew
>>> twitter: http://twitter.com/mwessendorf
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Aerogear" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to aerogear+unsubscribe at googlegroups.com.
>> To post to this group, send email to aerogear at googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/aerogear/CAAg5f2QF2AiZVK%2BQyYB0mDL5G58LXmUPVNySjrcpgJv5
>> 8Z012A%40mail.gmail.com
>> <https://groups.google.com/d/msgid/aerogear/CAAg5f2QF2AiZVK%2BQyYB0mDL5G58LXmUPVNySjrcpgJv58Z012A%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CAJFhnM4tUCG3-nqq-H2t4OgkF4yTp5koz%2BrAUNX_
> xcxrNobaNA%40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CAJFhnM4tUCG3-nqq-H2t4OgkF4yTp5koz%2BrAUNX_xcxrNobaNA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180207/8ea095e0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180207/8ea095e0/attachment-0001.png 

From pwright at redhat.com  Mon Feb 12 10:11:07 2018
From: pwright at redhat.com (Paul Wright)
Date: Mon, 12 Feb 2018 15:11:07 +0000
Subject: [aerogear-dev] Location of Docs
Message-ID: <CALLRKFhFVgDt1KiAiJ1R22qmcP+e_+p3g9hbYnrrRoqXFuvKzQ@mail.gmail.com>

Hi,
At a meeting a few weeks ago, we decided not to centralize all the docs for
mobile.next, because:

* keep docs closer to code
* keep docs and code versioned together
* allow devs update docs in same repo as they are working

We also decided not to create sidecar repos, eg a mobile-<service>-docs
repo.

With that in mind, I thought that docs for push would end up in:
https://github.com/aerogear/aerogear-unifiedpush-server

and docs for android sdk would end up in:

https://github.com/aerogear/aerogear-android-sdk

but that was before I discovered that the following is the nearest thing to
a 'metrics' repo that would be suitable for /docs:
https://github.com/aerogearcatalog/metrics-apb

However, I don't think switching org is a good experience for anyone (user
or contributor), so I'm wondering if anyone has a good idea where to docs
should live (relative to the code), eg:

* service and sdk docs live the apb repos
* service docs in apb repos, and sdk docs in 'code' repo
* something else

thanks,
Paul

-- 
Paul Wright
Senior Technical Writer
Red Hat, Waterford, Ireland
gitlab: finp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180212/7ef78bf8/attachment.html 

From wtrocki at redhat.com  Mon Feb 12 10:24:35 2018
From: wtrocki at redhat.com (Wojciech Trocki)
Date: Mon, 12 Feb 2018 15:24:35 +0000
Subject: [aerogear-dev] Location of Docs
In-Reply-To: <CALLRKFhFVgDt1KiAiJ1R22qmcP+e_+p3g9hbYnrrRoqXFuvKzQ@mail.gmail.com>
References: <CALLRKFhFVgDt1KiAiJ1R22qmcP+e_+p3g9hbYnrrRoqXFuvKzQ@mail.gmail.com>
Message-ID: <CAO0+n+rSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV=rYgnZ+CzA@mail.gmail.com>

We started writing user stories for SDK's (splitting between contributor
and user roles )
SDK's already have solid base that will be extended over the time, with
similar patterns across platforms.

*IOS: *
https://github.com/aerogear/aerogear-ios-sdk/tree/master/docs

*Android *(WIP - going to be updated soon)
https://github.com/aerogear/aerogear-android-sdk/tree/master/docs

> and docs for android sdk would end up in:

https://github.com/aerogear/aerogear-android-sdk/tree/master/docs/push

Android-sdk repository is just used for Mobile OpenShift Service Catalog
(AeroGear Services)
so push SDK may be probably in separate repository and be imported into
AeroGear Services SDK.

Regards

Wojtek

On Mon, Feb 12, 2018 at 3:11 PM, Paul Wright <pwright at redhat.com> wrote:

> Hi,
> At a meeting a few weeks ago, we decided not to centralize all the docs
> for mobile.next, because:
>
> * keep docs closer to code
> * keep docs and code versioned together
> * allow devs update docs in same repo as they are working
>
> We also decided not to create sidecar repos, eg a mobile-<service>-docs
> repo.
>
> With that in mind, I thought that docs for push would end up in:
> https://github.com/aerogear/aerogear-unifiedpush-server
>
> and docs for android sdk would end up in:
>
> https://github.com/aerogear/aerogear-android-sdk
>
> but that was before I discovered that the following is the nearest thing
> to a 'metrics' repo that would be suitable for /docs:
> https://github.com/aerogearcatalog/metrics-apb
>
> However, I don't think switching org is a good experience for anyone (user
> or contributor), so I'm wondering if anyone has a good idea where to docs
> should live (relative to the code), eg:
>
> * service and sdk docs live the apb repos
> * service docs in apb repos, and sdk docs in 'code' repo
> * something else
>
> thanks,
> Paul
>
> --
> Paul Wright
> Senior Technical Writer
> Red Hat, Waterford, Ireland
> gitlab: finp
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRo
> qXFuvKzQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRoqXFuvKzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 

WOJCIECH TROCKI

Red Hat Mobile <https://www.redhat.com/>

IM: wtrocki
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180212/e666aa7d/attachment.html 

From jgallaso at redhat.com  Tue Feb 13 02:49:24 2018
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Tue, 13 Feb 2018 08:49:24 +0100
Subject: [aerogear-dev] Location of Docs
In-Reply-To: <CAO0+n+rSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV=rYgnZ+CzA@mail.gmail.com>
References: <CALLRKFhFVgDt1KiAiJ1R22qmcP+e_+p3g9hbYnrrRoqXFuvKzQ@mail.gmail.com>
	<CAO0+n+rSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV=rYgnZ+CzA@mail.gmail.com>
Message-ID: <CAGsbZmHiwXqYJTHcYRMSv8gBdt5-EyzGjcDfP+cT8Jzoh2fYNA@mail.gmail.com>

Hi Paul,

think docs should live into their respective repos (including references
and guides) since it's always easier for everyone to find them.
Documentation about services in the -apb repos, SDKs in -sdk repos and so
on.

At a meeting a few weeks ago, we decided not to centralize all the docs for
> mobile.next, because:
> * keep docs closer to code
> * keep docs and code versioned together
> * allow devs update docs in same repo as they are working
> We also decided not to create sidecar repos, eg a mobile-<service>-docs
> repo.


Assuming *we *as in *we, Aerogear, *several of docs from
https://github.com/aerogear/mobile-docs/
<https://github.com/aerogear/mobile-docs/tree/master/services> should be
moved into their respective repos.

I however think mobile-docs would be good to have general documentation and
how-tos that affects several services or the platform itself like
*adding-services-to-ansible-broker.adoc*.

Regards,

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>

On 12 February 2018 at 16:24, Wojciech Trocki <wtrocki at redhat.com> wrote:

> We started writing user stories for SDK's (splitting between contributor
> and user roles )
> SDK's already have solid base that will be extended over the time, with
> similar patterns across platforms.
>
> *IOS: *
> https://github.com/aerogear/aerogear-ios-sdk/tree/master/docs
>
> *Android *(WIP - going to be updated soon)
> https://github.com/aerogear/aerogear-android-sdk/tree/master/docs
>
> > and docs for android sdk would end up in:
>
> https://github.com/aerogear/aerogear-android-sdk/tree/master/docs/push
>
> Android-sdk repository is just used for Mobile OpenShift Service Catalog
> (AeroGear Services)
> so push SDK may be probably in separate repository and be imported into
> AeroGear Services SDK.
>
> Regards
>
> Wojtek
>
> On Mon, Feb 12, 2018 at 3:11 PM, Paul Wright <pwright at redhat.com> wrote:
>
>> Hi,
>> At a meeting a few weeks ago, we decided not to centralize all the docs
>> for mobile.next, because:
>>
>> * keep docs closer to code
>> * keep docs and code versioned together
>> * allow devs update docs in same repo as they are working
>>
>> We also decided not to create sidecar repos, eg a mobile-<service>-docs
>> repo.
>>
>> With that in mind, I thought that docs for push would end up in:
>> https://github.com/aerogear/aerogear-unifiedpush-server
>>
>> and docs for android sdk would end up in:
>>
>> https://github.com/aerogear/aerogear-android-sdk
>>
>> but that was before I discovered that the following is the nearest thing
>> to a 'metrics' repo that would be suitable for /docs:
>> https://github.com/aerogearcatalog/metrics-apb
>>
>> However, I don't think switching org is a good experience for anyone
>> (user or contributor), so I'm wondering if anyone has a good idea where to
>> docs should live (relative to the code), eg:
>>
>> * service and sdk docs live the apb repos
>> * service docs in apb repos, and sdk docs in 'code' repo
>> * something else
>>
>> thanks,
>> Paul
>>
>> --
>> Paul Wright
>> Senior Technical Writer
>> Red Hat, Waterford, Ireland
>> gitlab: finp
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Aerogear" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to aerogear+unsubscribe at googlegroups.com.
>> To post to this group, send email to aerogear at googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRo
>> qXFuvKzQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRoqXFuvKzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
>
> WOJCIECH TROCKI
>
> Red Hat Mobile <https://www.redhat.com/>
>
> IM: wtrocki
> <https://red.ht/sig>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CAO0%2Bn%2BrSV8fD5A4fuTJiKrXoba2MpnXrSB
> 1CLrmV%3DrYgnZ%2BCzA%40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CAO0%2Bn%2BrSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV%3DrYgnZ%2BCzA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180213/ce58ed60/attachment-0001.html 

From pwright at redhat.com  Tue Feb 13 03:59:18 2018
From: pwright at redhat.com (Paul Wright)
Date: Tue, 13 Feb 2018 08:59:18 +0000
Subject: [aerogear-dev] Location of Docs
In-Reply-To: <CAGsbZmHiwXqYJTHcYRMSv8gBdt5-EyzGjcDfP+cT8Jzoh2fYNA@mail.gmail.com>
References: <CALLRKFhFVgDt1KiAiJ1R22qmcP+e_+p3g9hbYnrrRoqXFuvKzQ@mail.gmail.com>
	<CAO0+n+rSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV=rYgnZ+CzA@mail.gmail.com>
	<CAGsbZmHiwXqYJTHcYRMSv8gBdt5-EyzGjcDfP+cT8Jzoh2fYNA@mail.gmail.com>
Message-ID: <CALLRKFiZdBBHt=+rg2qJtYxCiOqcgGF2cwmseCwjn3J8wo7jNw@mail.gmail.com>

Thanks Jose,
I will follow up and move things appropriately after we agree on the layout.
So what you're saying (and I like it) is:

https://github.com/aerogear:
* mobile-docs
* <sdk>/docs
* mobile-cli/docs

https://github.com/aerogearcatalog
* <service>-apb/docs

I'm assuming that the release tagging for <service>-apb repo is always the
'version number' we want to communicate to end users?

It's unfortunate that it's split over two github organizations, but we can
'fix that in docs' if agreed,

Paul

On Tue, Feb 13, 2018 at 7:49 AM, Jose Miguel Gallas Olmedo <
jgallaso at redhat.com> wrote:

> Hi Paul,
>
> think docs should live into their respective repos (including references
> and guides) since it's always easier for everyone to find them.
> Documentation about services in the -apb repos, SDKs in -sdk repos and so
> on.
>
> At a meeting a few weeks ago, we decided not to centralize all the docs
>> for mobile.next, because:
>> * keep docs closer to code
>> * keep docs and code versioned together
>> * allow devs update docs in same repo as they are working
>> We also decided not to create sidecar repos, eg a mobile-<service>-docs
>> repo.
>
>
> Assuming *we *as in *we, Aerogear, *several of docs from
> https://github.com/aerogear/mobile-docs/
> <https://github.com/aerogear/mobile-docs/tree/master/services> should be
> moved into their respective repos.
>
> I however think mobile-docs would be good to have general documentation
> and how-tos that affects several services or the platform itself like
> *adding-services-to-ansible-broker.adoc*.
>
> Regards,
>
> JOSE MIGUEL GALLAS OLMEDO
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>
> <https://red.ht/sig>
>
> On 12 February 2018 at 16:24, Wojciech Trocki <wtrocki at redhat.com> wrote:
>
>> We started writing user stories for SDK's (splitting between contributor
>> and user roles )
>> SDK's already have solid base that will be extended over the time, with
>> similar patterns across platforms.
>>
>> *IOS: *
>> https://github.com/aerogear/aerogear-ios-sdk/tree/master/docs
>>
>> *Android *(WIP - going to be updated soon)
>> https://github.com/aerogear/aerogear-android-sdk/tree/master/docs
>>
>> > and docs for android sdk would end up in:
>>
>> https://github.com/aerogear/aerogear-android-sdk/tree/master/docs/push
>>
>> Android-sdk repository is just used for Mobile OpenShift Service Catalog
>> (AeroGear Services)
>> so push SDK may be probably in separate repository and be imported into
>> AeroGear Services SDK.
>>
>> Regards
>>
>> Wojtek
>>
>> On Mon, Feb 12, 2018 at 3:11 PM, Paul Wright <pwright at redhat.com> wrote:
>>
>>> Hi,
>>> At a meeting a few weeks ago, we decided not to centralize all the docs
>>> for mobile.next, because:
>>>
>>> * keep docs closer to code
>>> * keep docs and code versioned together
>>> * allow devs update docs in same repo as they are working
>>>
>>> We also decided not to create sidecar repos, eg a mobile-<service>-docs
>>> repo.
>>>
>>> With that in mind, I thought that docs for push would end up in:
>>> https://github.com/aerogear/aerogear-unifiedpush-server
>>>
>>> and docs for android sdk would end up in:
>>>
>>> https://github.com/aerogear/aerogear-android-sdk
>>>
>>> but that was before I discovered that the following is the nearest thing
>>> to a 'metrics' repo that would be suitable for /docs:
>>> https://github.com/aerogearcatalog/metrics-apb
>>>
>>> However, I don't think switching org is a good experience for anyone
>>> (user or contributor), so I'm wondering if anyone has a good idea where to
>>> docs should live (relative to the code), eg:
>>>
>>> * service and sdk docs live the apb repos
>>> * service docs in apb repos, and sdk docs in 'code' repo
>>> * something else
>>>
>>> thanks,
>>> Paul
>>>
>>> --
>>> Paul Wright
>>> Senior Technical Writer
>>> Red Hat, Waterford, Ireland
>>> gitlab: finp
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Aerogear" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to aerogear+unsubscribe at googlegroups.com.
>>> To post to this group, send email to aerogear at googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRo
>>> qXFuvKzQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRoqXFuvKzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> WOJCIECH TROCKI
>>
>> Red Hat Mobile <https://www.redhat.com/>
>>
>> IM: wtrocki
>> <https://red.ht/sig>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Aerogear" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to aerogear+unsubscribe at googlegroups.com.
>> To post to this group, send email to aerogear at googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/aerogear/CAO0%2Bn%2BrSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV%
>> 3DrYgnZ%2BCzA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/aerogear/CAO0%2Bn%2BrSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV%3DrYgnZ%2BCzA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>


-- 
Paul Wright
Senior Technical Writer
Red Hat, Waterford, Ireland
gitlab: finp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180213/0de2097a/attachment.html 

From jgallaso at redhat.com  Tue Feb 13 06:15:18 2018
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Tue, 13 Feb 2018 12:15:18 +0100
Subject: [aerogear-dev] Location of Docs
In-Reply-To: <CALLRKFiZdBBHt=+rg2qJtYxCiOqcgGF2cwmseCwjn3J8wo7jNw@mail.gmail.com>
References: <CALLRKFhFVgDt1KiAiJ1R22qmcP+e_+p3g9hbYnrrRoqXFuvKzQ@mail.gmail.com>
	<CAO0+n+rSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV=rYgnZ+CzA@mail.gmail.com>
	<CAGsbZmHiwXqYJTHcYRMSv8gBdt5-EyzGjcDfP+cT8Jzoh2fYNA@mail.gmail.com>
	<CALLRKFiZdBBHt=+rg2qJtYxCiOqcgGF2cwmseCwjn3J8wo7jNw@mail.gmail.com>
Message-ID: <CAGsbZmEwUjcoY0_QPHJzvcgsO2FNG8bOraCKigxEv6zGKikc_Q@mail.gmail.com>

>
> So what you're saying (and I like it) is:


@Paul That's correct.

Actually I was thinking if it wouldn't be better to name it *mobile-guides* (or
something similar) instead of mobile-docs? It might be confusing to have so
many "docs" around. But I might be wrong, it's just an idea.

I'm assuming that the release tagging for <service>-apb repo is always the
> 'version number' we want to communicate to end users?


I'm not sure about the tagging but @David might know the answer?


JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>

On 13 February 2018 at 09:59, Paul Wright <pwright at redhat.com> wrote:

> Thanks Jose,
> I will follow up and move things appropriately after we agree on the
> layout.
> So what you're saying (and I like it) is:
>
> https://github.com/aerogear:
> * mobile-docs
> * <sdk>/docs
> * mobile-cli/docs
>
> https://github.com/aerogearcatalog
> * <service>-apb/docs
>
> I'm assuming that the release tagging for <service>-apb repo is always the
> 'version number' we want to communicate to end users?
>
> It's unfortunate that it's split over two github organizations, but we can
> 'fix that in docs' if agreed,
>
> Paul
>
> On Tue, Feb 13, 2018 at 7:49 AM, Jose Miguel Gallas Olmedo <
> jgallaso at redhat.com> wrote:
>
>> Hi Paul,
>>
>> think docs should live into their respective repos (including references
>> and guides) since it's always easier for everyone to find them.
>> Documentation about services in the -apb repos, SDKs in -sdk repos and so
>> on.
>>
>> At a meeting a few weeks ago, we decided not to centralize all the docs
>>> for mobile.next, because:
>>> * keep docs closer to code
>>> * keep docs and code versioned together
>>> * allow devs update docs in same repo as they are working
>>> We also decided not to create sidecar repos, eg a mobile-<service>-docs
>>> repo.
>>
>>
>> Assuming *we *as in *we, Aerogear, *several of docs from
>> https://github.com/aerogear/mobile-docs/
>> <https://github.com/aerogear/mobile-docs/tree/master/services> should be
>> moved into their respective repos.
>>
>> I however think mobile-docs would be good to have general documentation
>> and how-tos that affects several services or the platform itself like
>> *adding-services-to-ansible-broker.adoc*.
>>
>> Regards,
>>
>> JOSE MIGUEL GALLAS OLMEDO
>>
>> ASSOCIATE QE, mobile
>>
>> Red Hat
>>
>> <https://www.redhat.com/>
>>
>> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>> On 12 February 2018 at 16:24, Wojciech Trocki <wtrocki at redhat.com> wrote:
>>
>>> We started writing user stories for SDK's (splitting between contributor
>>> and user roles )
>>> SDK's already have solid base that will be extended over the time, with
>>> similar patterns across platforms.
>>>
>>> *IOS: *
>>> https://github.com/aerogear/aerogear-ios-sdk/tree/master/docs
>>>
>>> *Android *(WIP - going to be updated soon)
>>> https://github.com/aerogear/aerogear-android-sdk/tree/master/docs
>>>
>>> > and docs for android sdk would end up in:
>>>
>>> https://github.com/aerogear/aerogear-android-sdk/tree/master/docs/push
>>>
>>> Android-sdk repository is just used for Mobile OpenShift Service Catalog
>>> (AeroGear Services)
>>> so push SDK may be probably in separate repository and be imported into
>>> AeroGear Services SDK.
>>>
>>> Regards
>>>
>>> Wojtek
>>>
>>> On Mon, Feb 12, 2018 at 3:11 PM, Paul Wright <pwright at redhat.com> wrote:
>>>
>>>> Hi,
>>>> At a meeting a few weeks ago, we decided not to centralize all the docs
>>>> for mobile.next, because:
>>>>
>>>> * keep docs closer to code
>>>> * keep docs and code versioned together
>>>> * allow devs update docs in same repo as they are working
>>>>
>>>> We also decided not to create sidecar repos, eg a mobile-<service>-docs
>>>> repo.
>>>>
>>>> With that in mind, I thought that docs for push would end up in:
>>>> https://github.com/aerogear/aerogear-unifiedpush-server
>>>>
>>>> and docs for android sdk would end up in:
>>>>
>>>> https://github.com/aerogear/aerogear-android-sdk
>>>>
>>>> but that was before I discovered that the following is the nearest
>>>> thing to a 'metrics' repo that would be suitable for /docs:
>>>> https://github.com/aerogearcatalog/metrics-apb
>>>>
>>>> However, I don't think switching org is a good experience for anyone
>>>> (user or contributor), so I'm wondering if anyone has a good idea where to
>>>> docs should live (relative to the code), eg:
>>>>
>>>> * service and sdk docs live the apb repos
>>>> * service docs in apb repos, and sdk docs in 'code' repo
>>>> * something else
>>>>
>>>> thanks,
>>>> Paul
>>>>
>>>> --
>>>> Paul Wright
>>>> Senior Technical Writer
>>>> Red Hat, Waterford, Ireland
>>>> gitlab: finp
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Aerogear" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to aerogear+unsubscribe at googlegroups.com.
>>>> To post to this group, send email to aerogear at googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRo
>>>> qXFuvKzQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRoqXFuvKzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> WOJCIECH TROCKI
>>>
>>> Red Hat Mobile <https://www.redhat.com/>
>>>
>>> IM: wtrocki
>>> <https://red.ht/sig>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Aerogear" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to aerogear+unsubscribe at googlegroups.com.
>>> To post to this group, send email to aerogear at googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/aerogear/CAO0%2Bn%2BrSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV%3
>>> DrYgnZ%2BCzA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/aerogear/CAO0%2Bn%2BrSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV%3DrYgnZ%2BCzA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>
>
> --
> Paul Wright
> Senior Technical Writer
> Red Hat, Waterford, Ireland
> gitlab: finp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180213/38b1769a/attachment-0001.html 

From davmarti at redhat.com  Tue Feb 13 06:57:03 2018
From: davmarti at redhat.com (David Martin)
Date: Tue, 13 Feb 2018 11:57:03 +0000
Subject: [aerogear-dev] Location of Docs
In-Reply-To: <CAGsbZmEwUjcoY0_QPHJzvcgsO2FNG8bOraCKigxEv6zGKikc_Q@mail.gmail.com>
References: <CALLRKFhFVgDt1KiAiJ1R22qmcP+e_+p3g9hbYnrrRoqXFuvKzQ@mail.gmail.com>
	<CAO0+n+rSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV=rYgnZ+CzA@mail.gmail.com>
	<CAGsbZmHiwXqYJTHcYRMSv8gBdt5-EyzGjcDfP+cT8Jzoh2fYNA@mail.gmail.com>
	<CALLRKFiZdBBHt=+rg2qJtYxCiOqcgGF2cwmseCwjn3J8wo7jNw@mail.gmail.com>
	<CAGsbZmEwUjcoY0_QPHJzvcgsO2FNG8bOraCKigxEv6zGKikc_Q@mail.gmail.com>
Message-ID: <CADvBQ44AJ7xz+G8yaq3DViz=M7KgU47qf+CftOC3Ko6syfnT_Q@mail.gmail.com>

On 13 February 2018 at 11:15, Jose Miguel Gallas Olmedo <jgallaso at redhat.com
> wrote:

> So what you're saying (and I like it) is:
>
>
> @Paul That's correct.
>
> Actually I was thinking if it wouldn't be better to name it
> *mobile-guides* (or something similar) instead of mobile-docs? It might
> be confusing to have so many "docs" around. But I might be wrong, it's just
> an idea.
>
> I'm assuming that the release tagging for <service>-apb repo is always the
>> 'version number' we want to communicate to end users?
>
>
> I'm not sure about the tagging but @David might know the answer?
>
There is tagging on (some?) apbs with a version to date.
e.g.
https://github.com/aerogearcatalog/keycloak-apb/tree/0.0.6
But that may have been from the proof of concept phase.
I'm sure we can rely on some version tagging going forward though as we do
a 'release' of 5.x (whatever that means)


>
>
> JOSE MIGUEL GALLAS OLMEDO
>
> ASSOCIATE QE, mobile
>
> Red Hat
>
> <https://www.redhat.com/>
>
> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>
> <https://red.ht/sig>
>
> On 13 February 2018 at 09:59, Paul Wright <pwright at redhat.com> wrote:
>
>> Thanks Jose,
>> I will follow up and move things appropriately after we agree on the
>> layout.
>> So what you're saying (and I like it) is:
>>
>> https://github.com/aerogear:
>> * mobile-docs
>> * <sdk>/docs
>> * mobile-cli/docs
>>
>> https://github.com/aerogearcatalog
>> * <service>-apb/docs
>>
>> I'm assuming that the release tagging for <service>-apb repo is always
>> the 'version number' we want to communicate to end users?
>>
>> It's unfortunate that it's split over two github organizations, but we
>> can 'fix that in docs' if agreed,
>>
>> Paul
>>
>> On Tue, Feb 13, 2018 at 7:49 AM, Jose Miguel Gallas Olmedo <
>> jgallaso at redhat.com> wrote:
>>
>>> Hi Paul,
>>>
>>> think docs should live into their respective repos (including references
>>> and guides) since it's always easier for everyone to find them.
>>> Documentation about services in the -apb repos, SDKs in -sdk repos and so
>>> on.
>>>
>>> At a meeting a few weeks ago, we decided not to centralize all the docs
>>>> for mobile.next, because:
>>>> * keep docs closer to code
>>>> * keep docs and code versioned together
>>>> * allow devs update docs in same repo as they are working
>>>> We also decided not to create sidecar repos, eg a mobile-<service>-docs
>>>> repo.
>>>
>>>
>>> Assuming *we *as in *we, Aerogear, *several of docs from
>>> https://github.com/aerogear/mobile-docs/
>>> <https://github.com/aerogear/mobile-docs/tree/master/services> should
>>> be moved into their respective repos.
>>>
>>> I however think mobile-docs would be good to have general documentation
>>> and how-tos that affects several services or the platform itself like
>>> *adding-services-to-ansible-broker.adoc*.
>>>
>>> Regards,
>>>
>>> JOSE MIGUEL GALLAS OLMEDO
>>>
>>> ASSOCIATE QE, mobile
>>>
>>> Red Hat
>>>
>>> <https://www.redhat.com/>
>>>
>>> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>>>
>>> <https://red.ht/sig>
>>>
>>> On 12 February 2018 at 16:24, Wojciech Trocki <wtrocki at redhat.com>
>>> wrote:
>>>
>>>> We started writing user stories for SDK's (splitting between
>>>> contributor and user roles )
>>>> SDK's already have solid base that will be extended over the time, with
>>>> similar patterns across platforms.
>>>>
>>>> *IOS: *
>>>> https://github.com/aerogear/aerogear-ios-sdk/tree/master/docs
>>>>
>>>> *Android *(WIP - going to be updated soon)
>>>> https://github.com/aerogear/aerogear-android-sdk/tree/master/docs
>>>>
>>>> > and docs for android sdk would end up in:
>>>>
>>>> https://github.com/aerogear/aerogear-android-sdk/tree/master/docs/push
>>>>
>>>> Android-sdk repository is just used for Mobile OpenShift Service
>>>> Catalog (AeroGear Services)
>>>> so push SDK may be probably in separate repository and be imported into
>>>> AeroGear Services SDK.
>>>>
>>>> Regards
>>>>
>>>> Wojtek
>>>>
>>>> On Mon, Feb 12, 2018 at 3:11 PM, Paul Wright <pwright at redhat.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> At a meeting a few weeks ago, we decided not to centralize all the
>>>>> docs for mobile.next, because:
>>>>>
>>>>> * keep docs closer to code
>>>>> * keep docs and code versioned together
>>>>> * allow devs update docs in same repo as they are working
>>>>>
>>>>> We also decided not to create sidecar repos, eg a
>>>>> mobile-<service>-docs repo.
>>>>>
>>>>> With that in mind, I thought that docs for push would end up in:
>>>>> https://github.com/aerogear/aerogear-unifiedpush-server
>>>>>
>>>>> and docs for android sdk would end up in:
>>>>>
>>>>> https://github.com/aerogear/aerogear-android-sdk
>>>>>
>>>>> but that was before I discovered that the following is the nearest
>>>>> thing to a 'metrics' repo that would be suitable for /docs:
>>>>> https://github.com/aerogearcatalog/metrics-apb
>>>>>
>>>>> However, I don't think switching org is a good experience for anyone
>>>>> (user or contributor), so I'm wondering if anyone has a good idea where to
>>>>> docs should live (relative to the code), eg:
>>>>>
>>>>> * service and sdk docs live the apb repos
>>>>> * service docs in apb repos, and sdk docs in 'code' repo
>>>>> * something else
>>>>>
>>>>> thanks,
>>>>> Paul
>>>>>
>>>>> --
>>>>> Paul Wright
>>>>> Senior Technical Writer
>>>>> Red Hat, Waterford, Ireland
>>>>> gitlab: finp
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Aerogear" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to aerogear+unsubscribe at googlegroups.com.
>>>>> To post to this group, send email to aerogear at googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/aerogear/CALLRKFhFVgDt1KiA
>>>>> iJ1R22qmcP%2Be_%2Bp3g9hbYnrrRoqXFuvKzQ%40mail.gmail.com
>>>>> <https://groups.google.com/d/msgid/aerogear/CALLRKFhFVgDt1KiAiJ1R22qmcP%2Be_%2Bp3g9hbYnrrRoqXFuvKzQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> WOJCIECH TROCKI
>>>>
>>>> Red Hat Mobile <https://www.redhat.com/>
>>>>
>>>> IM: wtrocki
>>>> <https://red.ht/sig>
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Aerogear" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to aerogear+unsubscribe at googlegroups.com.
>>>> To post to this group, send email to aerogear at googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>>> gid/aerogear/CAO0%2Bn%2BrSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV%3
>>>> DrYgnZ%2BCzA%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/aerogear/CAO0%2Bn%2BrSV8fD5A4fuTJiKrXoba2MpnXrSB1CLrmV%3DrYgnZ%2BCzA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>
>>
>> --
>> Paul Wright
>> Senior Technical Writer
>> Red Hat, Waterford, Ireland
>> gitlab: finp
>>
>
>


-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (#aerogear)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180213/ca2e87c9/attachment-0001.html 

From vsazel at redhat.com  Wed Feb 14 05:04:09 2018
From: vsazel at redhat.com (Vojtech Sazel)
Date: Wed, 14 Feb 2018 10:04:09 +0000
Subject: [aerogear-dev] Android Aerogrear E2E testing proposal
Message-ID: <CAGTW8rFvXeddq5HAFF-oQ3B=1hEUeNBzScJq5TNyT+4T__SDEA@mail.gmail.com>

Hi,

with Thomas we created the proposal for E2E testing.

It has two parts:
* E2E test suite - proposed framework to be used in writing tests
* E2E test infrastructure - where to run the tests and how to run them

https://github.com/aerogear/proposals/pull/24

@Adam please move your comments from Goggle Doc to the github.

-- 

VOJT?CH S?ZEL

SENIOR SOFTWARE ENGINEER, RED HAT MOBILE

Red Hat

<https://www.redhat.com/>

Remote Czech Republic

vsazel at redhat.com    IM: vsazel
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180214/f6b1cd36/attachment.html 

From pwright at redhat.com  Thu Feb 15 07:26:08 2018
From: pwright at redhat.com (Paul Wright)
Date: Thu, 15 Feb 2018 12:26:08 +0000
Subject: [aerogear-dev] Analytics for aerogear.org website
Message-ID: <91806342-8f61-6298-17c7-25d4bc082c13@redhat.com>

Hi,

Can someone reach out to me regarding analytics for https://aerogear.org/

We're currently trying to figure out how to transition to new site and 
docs, and would like some data to drive decisions around redirects and 
archiving,

thanks,

Paul

-- 
Paul Wright
Mobile Docs (github: finp)


From matzew at apache.org  Tue Feb 20 08:01:16 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 20 Feb 2018 14:01:16 +0100
Subject: [aerogear-dev] MARA Framework / OWASP mobile security
Message-ID: <CAAg5f2QBVxOdMgBmCL6CjDYaAiDPyVh0ghR_EPnrVT_V3oE+YA@mail.gmail.com>

MARA is a Mobile Application Reverse engineering and Analysis Framework:
https://github.com/xtiankisutsa/MARA_Framework

Sounds interesting - anyone seen this ?

-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180220/cb1529b9/attachment.html 

From dpassos at redhat.com  Wed Feb 21 12:33:57 2018
From: dpassos at redhat.com (Daniel Passos)
Date: Wed, 21 Feb 2018 14:33:57 -0300
Subject: [aerogear-dev] MARA Framework / OWASP mobile security
In-Reply-To: <CAAg5f2QBVxOdMgBmCL6CjDYaAiDPyVh0ghR_EPnrVT_V3oE+YA@mail.gmail.com>
References: <CAAg5f2QBVxOdMgBmCL6CjDYaAiDPyVh0ghR_EPnrVT_V3oE+YA@mail.gmail.com>
Message-ID: <CADF=h2vBYGZ=QAwDDeOGzK+XpJGVYKxZxEGjfOOE9yDVyZRgWA@mail.gmail.com>

I did some tests with AbstracJ year ago or so using it.

On Tue, Feb 20, 2018 at 10:01 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> MARA is a Mobile Application Reverse engineering and Analysis Framework:
> https://github.com/xtiankisutsa/MARA_Framework
>
> Sounds interesting - anyone seen this ?
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CAAg5f2QBVxOdMgBmCL6CjDYaAiDPyVh0ghR_EPnrVT_V3oE%2BYA%
> 40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CAAg5f2QBVxOdMgBmCL6CjDYaAiDPyVh0ghR_EPnrVT_V3oE%2BYA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180221/786c6a31/attachment.html 

From dpassos at redhat.com  Wed Feb 21 13:02:59 2018
From: dpassos at redhat.com (Daniel Passos)
Date: Wed, 21 Feb 2018 15:02:59 -0300
Subject: [aerogear-dev] Deprecate AeroGear auth libraries
In-Reply-To: <CADF=h2tpgyK3gb_pDCfZFseWVhzN0q=WxAk7cDAC=G+5eG3y=Q@mail.gmail.com>
References: <CADF=h2tpgyK3gb_pDCfZFseWVhzN0q=WxAk7cDAC=G+5eG3y=Q@mail.gmail.com>
Message-ID: <CADF=h2u8Z-eGvnQb7n4Ufzm2NM4m6Kp+_DSF6VKHZStheEUncg@mail.gmail.com>

I have moved aerogear-android-auth to aerogear-attic

https://github.com/aerogear-attic/aerogear-android-auth

On Mon, Dec 18, 2017 at 12:37 PM, Daniel Passos <dpassos at redhat.com> wrote:

> Hi,
>
> Today we have libraries to handle Auth stuff for HTTP Basic and HTTP
> Digest, this libraries is no longer maintained for a long time and I think
> no one is using this kind of Auth anymore. Should we archive it and move to
> the aerogear-attic[1]
>
> [1] https://github.com/aerogear-attic
>
> --
> -- Passos
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180221/4aaaec6d/attachment.html 

From dpassos at redhat.com  Wed Feb 21 14:33:59 2018
From: dpassos at redhat.com (Daniel Passos)
Date: Wed, 21 Feb 2018 16:33:59 -0300
Subject: [aerogear-dev] Deprecated aerogear-cordova-geo
In-Reply-To: <CADF=h2thhSmqb+KHTJFU_5ZxwDeyvZq01J5VQwX-CtOobtBnXA@mail.gmail.com>
References: <CADF=h2thhSmqb+KHTJFU_5ZxwDeyvZq01J5VQwX-CtOobtBnXA@mail.gmail.com>
Message-ID: <CADF=h2u4oScAy0WeNVO6tNTJVrR0ekDrn_Wfy1kNcP2PTWG+Mw@mail.gmail.com>

Project moved to https://github.com/aerogear-attic/aerogear-cordova-geo

On Mon, Dec 18, 2017 at 12:38 PM, Daniel Passos <dpassos at redhat.com> wrote:

> Hi,
>
> Should we deprecated aerogear-cordova-geo[1]?
>
> Cordova is the only one has the Geo library and the last commit on this
> library was in Sep 7, 2015
>
> [1] https://github.com/aerogear/aerogear-cordova-geo
>
> --
> -- Passos
>



-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180221/fb4d9d74/attachment.html 

From eshortis at redhat.com  Wed Feb 21 14:58:54 2018
From: eshortis at redhat.com (Evan Shortiss)
Date: Wed, 21 Feb 2018 11:58:54 -0800
Subject: [aerogear-dev] Ionic Deploy Demo (hot/remote application updates)
Message-ID: <CA+BWC0KGS9_EhuM7MzGw0DxYd6q4F9O16AEscOX=KCc=vdKq7A@mail.gmail.com>

Hi folks,

This is a neat demo[1] of the Ionic Deploy feature that supports. Some
points and thoughts on it:

   - Facilitates updating the HTML, CSS, and JS of a Cordova application
   - Probably works best with Cordova applications built using Ionic's tools
   - Requires a Cordova plugin to fetch updates
   - Can store X versions in history on device for rollback
   - Supports "channels" so you can enrol beta testers by subscribing their
   application to the "beta" instead of "production" channel
   - Requires you to push code to their Git remote, but according to a
   webinar they will add webhook support
   - Can be configured remotely to behave in 3 different patterns:
      - Always check for and download updates on the splashscreen
      - Check in the background and apply next time application is launched
      - Allow developers to define strategy themselves in JS code


It's a paid for feature as part of their Ionic Pro platform. I haven't used
the Pro platform yet, but looks like it will have/has some features similar
to Firebase, e.g static hosting, crash reporting, remote testing and more.

[1] - https://www.youtube.com/watch?v=I7PC3O4q1ug

-- 

EVAN SHORTISS

MOBILE DEVELOPER

Red Hat NA <https://www.redhat.com/>

Los Angeles

evan.shortiss at redhat.com    M: +1-781-354-2834     IM: @evanshortiss
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
@redhatnews <https://twitter.com/redhatnews>   Red Hat
<https://www.linkedin.com/company/red-hat>   Red Hat
<https://www.facebook.com/RedHatInc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180221/e8d6332a/attachment-0001.html 

From dpassos at redhat.com  Wed Feb 21 15:25:36 2018
From: dpassos at redhat.com (Daniel Passos)
Date: Wed, 21 Feb 2018 17:25:36 -0300
Subject: [aerogear-dev] AeroGear Cordova Push 3.1.1 Release
Message-ID: <CADF=h2t_GKsEYRMF_cYzuDTBpou9oixvK+_V8m2bOQkrSC05RQ@mail.gmail.com>

Hi,

I have released AeroGear Push 3.1.1 with 2 community contributions

https://github.com/aerogear/aerogear-cordova-push/pull/118
https://github.com/aerogear/aerogear-cordova-push/pull/119

-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180221/bbe43a77/attachment.html 

From mwessend at redhat.com  Wed Feb 21 19:07:47 2018
From: mwessend at redhat.com (Matthias Wessendorf)
Date: Thu, 22 Feb 2018 00:07:47 +0000
Subject: [aerogear-dev] AeroGear Cordova Push 3.1.1 Release
In-Reply-To: <CADF=h2t_GKsEYRMF_cYzuDTBpou9oixvK+_V8m2bOQkrSC05RQ@mail.gmail.com>
References: <CADF=h2t_GKsEYRMF_cYzuDTBpou9oixvK+_V8m2bOQkrSC05RQ@mail.gmail.com>
Message-ID: <CAKUFdH0n4qUtqwXX68RYEtMedPE5Kifrj72hn7vHmGon2exdqQ@mail.gmail.com>

sweet!

thanks for pushing it!

On Wed 21. Feb 2018 at 21:26, Daniel Passos <dpassos at redhat.com> wrote:

> Hi,
>
> I have released AeroGear Push 3.1.1 with 2 community contributions
>
> https://github.com/aerogear/aerogear-cordova-push/pull/118
> https://github.com/aerogear/aerogear-cordova-push/pull/119
>
> --
> -- Passos
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/aerogear/CADF%3Dh2t_GKsEYRMF_cYzuDTBpou9oixvK%2B_V8m2bOQkrSC05RQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CADF%3Dh2t_GKsEYRMF_cYzuDTBpou9oixvK%2B_V8m2bOQkrSC05RQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180222/1594dd1f/attachment.html 

From dpassos at redhat.com  Thu Feb 22 08:20:50 2018
From: dpassos at redhat.com (Daniel Passos)
Date: Thu, 22 Feb 2018 10:20:50 -0300
Subject: [aerogear-dev] AeroGear Cordova Crypto 0.0.4 Release
Message-ID: <CADF=h2ve88uWkpY9+vT2R6hHR7hKTrH8fwQjJTUpr_BjqjGWeg@mail.gmail.com>

Hi,

I have release AeroGear Crypto 0.0.4

It includes a bug fix found and fixed by the community[1]

[1] https://github.com/aerogear/aerogear-cordova-crypto/pull/16

-- 
-- Passos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180222/f1898afc/attachment.html 

From mwessend at redhat.com  Thu Feb 22 09:20:13 2018
From: mwessend at redhat.com (Matthias Wessendorf)
Date: Thu, 22 Feb 2018 15:20:13 +0100
Subject: [aerogear-dev] AeroGear Cordova Crypto 0.0.4 Release
In-Reply-To: <CADF=h2ve88uWkpY9+vT2R6hHR7hKTrH8fwQjJTUpr_BjqjGWeg@mail.gmail.com>
References: <CADF=h2ve88uWkpY9+vT2R6hHR7hKTrH8fwQjJTUpr_BjqjGWeg@mail.gmail.com>
Message-ID: <CAKUFdH03=mio4qNS0TgEnn65brq4HgMdu1sCcTKG1VeaNYmFLA@mail.gmail.com>

nice! Thanks for looking into this!

On Thu, Feb 22, 2018 at 2:20 PM, Daniel Passos <dpassos at redhat.com> wrote:

> Hi,
>
> I have release AeroGear Crypto 0.0.4
>
> It includes a bug fix found and fixed by the community[1]
>
> [1] https://github.com/aerogear/aerogear-cordova-crypto/pull/16
>
> --
> -- Passos
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CADF%3Dh2ve88uWkpY9%2BvT2R6hHR7hKTrH8fwQjJTUpr_
> BjqjGWeg%40mail.gmail.com
> <https://groups.google.com/d/msgid/aerogear/CADF%3Dh2ve88uWkpY9%2BvT2R6hHR7hKTrH8fwQjJTUpr_BjqjGWeg%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180222/f595f30b/attachment.html 

From matzew at apache.org  Thu Feb 22 09:47:36 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 22 Feb 2018 15:47:36 +0100
Subject: [aerogear-dev] Check-style / findbugs
Message-ID: <CAAg5f2RncdDCyd2iRo8mN1SJk5hfwPEUsPzwYCXWtTWYjv5oSA@mail.gmail.com>

Hi,

I noticed the we currently don't run check-style (e.g. to avoid annoying
unused imports) and find-bugs, to show problematic code, during the build.

If there are no major concers, I am going to give this a shot

-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180222/55c7298c/attachment.html 

From weil at redhat.com  Thu Feb 22 09:55:56 2018
From: weil at redhat.com (Wei Li)
Date: Thu, 22 Feb 2018 14:55:56 +0000
Subject: [aerogear-dev] Check-style / findbugs
In-Reply-To: <CAAg5f2RncdDCyd2iRo8mN1SJk5hfwPEUsPzwYCXWtTWYjv5oSA@mail.gmail.com>
References: <CAAg5f2RncdDCyd2iRo8mN1SJk5hfwPEUsPzwYCXWtTWYjv5oSA@mail.gmail.com>
Message-ID: <CAHmyU2qNyOGyLnT9uVVfRt03926q-D-3JBQQY-anihTPxLihNw@mail.gmail.com>

+1

On Thu, Feb 22, 2018 at 2:47 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> I noticed the we currently don't run check-style (e.g. to avoid annoying
> unused imports) and find-bugs, to show problematic code, during the build.
>
> If there are no major concers, I am going to give this a shot
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile <https://www.redhat.com/>

weil at redhat.com    M: +353862393272
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180222/3cefa17d/attachment.html 

From matzew at apache.org  Thu Feb 22 10:02:01 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Thu, 22 Feb 2018 16:02:01 +0100
Subject: [aerogear-dev] Android API Level: 24 ?
Message-ID: <CAAg5f2TwwvfChTnztzdhx+u7GOJTT2YJGse8hn+VhNPpj_U3zA@mail.gmail.com>

Hi,

we are currently on 21 - but,... w/ 24, we would get decent java 8 API
support (e.g. java streams), instead of 'just' lambdas.

Of course, we few devices would be left out ...

what's the thinking?

-M

[1] https://developer.android.com/about/dashboards/index.html


-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180222/f276e18f/attachment-0001.html 

From mwessend at redhat.com  Thu Feb 22 11:22:19 2018
From: mwessend at redhat.com (Matthias Wessendorf)
Date: Thu, 22 Feb 2018 16:22:19 +0000
Subject: [aerogear-dev] Android API Level: 24 ?
In-Reply-To: <CADvBQ458c1jq9LS_gxQMMJiuLGryZ6hw5PwboA0LixxJEFw8Kg@mail.gmail.com>
References: <CAAg5f2TwwvfChTnztzdhx+u7GOJTT2YJGse8hn+VhNPpj_U3zA@mail.gmail.com>
	<CADvBQ458c1jq9LS_gxQMMJiuLGryZ6hw5PwboA0LixxJEFw8Kg@mail.gmail.com>
Message-ID: <CAKUFdH2XfNE6kuEe=TPXhaV3eHF-GJqV9FgrsjcZxtyQc4jEdQ@mail.gmail.com>

yeah... true :-)

On Thu 22. Feb 2018 at 16:38, David Martin <davmarti at redhat.com> wrote:

> According to Android Studio, when you create a new project:
>
> By targeting API 21 and later, your app will run on approximately
> 71.3% of devices.
> By targeting API 24 and later, your app will run on approximately 8.1%
> of devices.
>
> 8.1% is very different than that page (which adds up to 29.6%)
>
> Either way, 29.6% coverage seems way too low to me.
>
> On 22 February 2018 at 15:02, Matthias Wessendorf <matzew at apache.org>
> wrote:
> > Hi,
> >
> > we are currently on 21 - but,... w/ 24, we would get decent java 8 API
> > support (e.g. java streams), instead of 'just' lambdas.
> >
> > Of course, we few devices would be left out ...
> >
> > what's the thinking?
> >
> > -M
> >
> > [1] https://developer.android.com/about/dashboards/index.html
> >
> >
> > --
> > Matthias Wessendorf
> >
> > github: https://github.com/matzew
> > twitter: http://twitter.com/mwessendorf
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Aerogear" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to aerogear+unsubscribe at googlegroups.com.
> > To post to this group, send email to aerogear at googlegroups.com.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/aerogear/CAAg5f2TwwvfChTnztzdhx%2Bu7GOJTT2YJGse8hn%2BVhNPpj_U3zA%40mail.gmail.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> David Martin
> Red Hat Mobile
> Twitter: @irldavem
> IRC: @irldavem (#aerogear)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/aerogear/CADvBQ458c1jq9LS_gxQMMJiuLGryZ6hw5PwboA0LixxJEFw8Kg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Project lead AeroGear.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180222/d444d349/attachment.html 

From jgallaso at redhat.com  Fri Feb 23 03:56:27 2018
From: jgallaso at redhat.com (Jose Miguel Gallas Olmedo)
Date: Fri, 23 Feb 2018 09:56:27 +0100
Subject: [aerogear-dev] Check-style / findbugs
In-Reply-To: <CAHmyU2qNyOGyLnT9uVVfRt03926q-D-3JBQQY-anihTPxLihNw@mail.gmail.com>
References: <CAAg5f2RncdDCyd2iRo8mN1SJk5hfwPEUsPzwYCXWtTWYjv5oSA@mail.gmail.com>
	<CAHmyU2qNyOGyLnT9uVVfRt03926q-D-3JBQQY-anihTPxLihNw@mail.gmail.com>
Message-ID: <CAGsbZmFeOHhLPjwTPRa6Kk0X6NxPEwxQTTc3vSo=cWCTEGNoXg@mail.gmail.com>

Not the smallest concern! +100

JOSE MIGUEL GALLAS OLMEDO

ASSOCIATE QE, mobile

Red Hat

<https://www.redhat.com/>

M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>

On 22 February 2018 at 15:55, Wei Li <weil at redhat.com> wrote:

> +1
>
> On Thu, Feb 22, 2018 at 2:47 PM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> I noticed the we currently don't run check-style (e.g. to avoid annoying
>> unused imports) and find-bugs, to show problematic code, during the build.
>>
>> If there are no major concers, I am going to give this a shot
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
>
> WEI LI
>
> SENIOR SOFTWARE ENGINEER
>
> Red Hat Mobile <https://www.redhat.com/>
>
> weil at redhat.com    M: +353862393272
> <https://red.ht/sig>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Aerogear" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to aerogear+unsubscribe at googlegroups.com.
> To post to this group, send email to aerogear at googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/aerogear/CAHmyU2qNyOGyLnT9uVVfRt03926q-D-3JBQQY-anihTPxLihNw%40mail.
> gmail.com
> <https://groups.google.com/d/msgid/aerogear/CAHmyU2qNyOGyLnT9uVVfRt03926q-D-3JBQQY-anihTPxLihNw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180223/fc9fcaf8/attachment.html 

From matzew at apache.org  Tue Feb 27 02:39:31 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 27 Feb 2018 08:39:31 +0100
Subject: [aerogear-dev] WF 12 - CR1
Message-ID: <CAAg5f2Qi=PAsk0H+whH1c03v-eCh6+MwK2MHQX8F604v8WOzKA@mail.gmail.com>

Hi,

I saw that WF 12's first candidate release was published last night. I will
give it a try, and file JIRAs as needed for the base of our UPS image and
the UPS itself.

Cheers,
Matthias

-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180227/9f819f22/attachment.html 

From matzew at apache.org  Tue Feb 27 08:15:24 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Tue, 27 Feb 2018 14:15:24 +0100
Subject: [aerogear-dev] WF 12 - CR1
In-Reply-To: <CAAg5f2Qi=PAsk0H+whH1c03v-eCh6+MwK2MHQX8F604v8WOzKA@mail.gmail.com>
References: <CAAg5f2Qi=PAsk0H+whH1c03v-eCh6+MwK2MHQX8F604v8WOzKA@mail.gmail.com>
Message-ID: <CAAg5f2RtyTPE4i-AR_fDmPGswR3AgT90GPYm3aND4X3qeHO-PQ@mail.gmail.com>

works perfectly fine (tested w/ iOS push)

-M

On Tue, Feb 27, 2018 at 8:39 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

> Hi,
>
> I saw that WF 12's first candidate release was published last night. I
> will give it a try, and file JIRAs as needed for the base of our UPS image
> and the UPS itself.
>
> Cheers,
> Matthias
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180227/8865a393/attachment.html 

From matzew at apache.org  Wed Feb 28 00:52:27 2018
From: matzew at apache.org (Matthias Wessendorf)
Date: Wed, 28 Feb 2018 06:52:27 +0100
Subject: [aerogear-dev] WF 12 - CR1
In-Reply-To: <CAAg5f2RtyTPE4i-AR_fDmPGswR3AgT90GPYm3aND4X3qeHO-PQ@mail.gmail.com>
References: <CAAg5f2Qi=PAsk0H+whH1c03v-eCh6+MwK2MHQX8F604v8WOzKA@mail.gmail.com>
	<CAAg5f2RtyTPE4i-AR_fDmPGswR3AgT90GPYm3aND4X3qeHO-PQ@mail.gmail.com>
Message-ID: <CAAg5f2QeaGBvSpjTcBKxw02PRUCCMcPB_whfNoXBL=GsrmO7-g@mail.gmail.com>

also,

using the '-Dee8.preview.mode=true' flag works fine -> good stuff :)

On Tue, Feb 27, 2018 at 2:15 PM, Matthias Wessendorf <matzew at apache.org>
wrote:

> works perfectly fine (tested w/ iOS push)
>
> -M
>
> On Tue, Feb 27, 2018 at 8:39 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>> Hi,
>>
>> I saw that WF 12's first candidate release was published last night. I
>> will give it a try, and file JIRAs as needed for the base of our UPS image
>> and the UPS itself.
>>
>> Cheers,
>> Matthias
>>
>> --
>> Matthias Wessendorf
>>
>> github: https://github.com/matzew
>> twitter: http://twitter.com/mwessendorf
>>
>
>
>
> --
> Matthias Wessendorf
>
> github: https://github.com/matzew
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

github: https://github.com/matzew
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20180228/341e2293/attachment-0001.html