AeroGear Crypto Java 0.1.2 released
by Bruno Oliveira
Good morning, just to let you know we released today the bits for digital signatures and some bug fixes.
Have a happy new year sweet hearts.
--
abstractj
2 years, 10 months
Deprecate AeroGear auth libraries
by Daniel Passos
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
7 years, 1 month
UPS: Admin UI
by Matthias Wessendorf
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
7 years, 1 month
Android Core Proposal Merged (and some follow up goals)
by David Martin
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/fe...
* 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)
7 years, 1 month
Re: [aerogear-dev] Docs process
by David Martin
Sending on list
@Paul, how about this approach when creating docs tasks in Epics.
* Identify the 'action' that is the focus of the docs task, and include
that in the jira title/description.
So taking this task as an example,
"Document how the Single Auth Provider works and is configured"
https://issues.jboss.org/browse/AEROGEAR-1917
this could be rephrased to something like:
"Document how an OpenShift user can be given access to a Mobile Service".
This would contain a lot of similar content to what Steven has already
written (as it explains how the openshift roles for that namespace
give/restrict access to a service via the oauth proxy).
But it also hints at there being a goal for that doc.
Having this info in the task when it is started could help influence and
shape how the doc is written so it is closer to what you want at PR time
On 31 January 2018 at 12:09, Paul Wright <pwright(a)redhat.com> wrote:
> Hi David,
>
> Preamble: this is still a bit nebulous, but might become a proposal for a
> docs process:
>
> I've got a few examples of mobile.next docs items, and here's the issue
>
> 1. Eng want to write specific pieces required by an epic
>
> 2. Docs want to publish end-user docs with context, fitting into an
> overall flow/user story/structure
>
> An example is https://github.com/aerogear/mobile-docs/pull/7/files
>
> I'm struggling to find context for this piece, but at the same time the
> guys want to close out the epic.
>
> Another example is the readme at https://github.com/aerogear/mi
> nishift-mobilecore-addon
>
> (which will land in mobile-docs as https://github.com/finp/mobile
> -docs/blob/AEROGEAR-1982/getting-started/minishift_install.adoc)
>
> Given this:
>
> * I don't want to block eng
>
> * I don't want to 'light' review material
>
> * some docs have a life outside of mobile-docs repo
>
> I'm thinking of the following procedure:
>
> 1. Write your docs in the repo of choice (and merge, eg finishing epic)
>
> 2. I'll create a placeholder in mobile-docs for that doc , eg
>
> mobile-docs/services/metrics-single-auth-provider.adoc
>
> with a reference to the source material (in code repo)
>
> 3. Create a follow up task to 'create upstream doc and reconcile with code
> repo'
>
> The idea being that eventually, the doc in the code repo is equivalent to
> mobile-docs repo, but that becomes async, not depending on me to sort
> everything out to satisfy some epic closure pressure.
>
> Obviously, this is not ideal, because developer has moved on by the time
> I'm reviewing doc, but not everything will require as much context filling
> as https://github.com/aerogear/mobile-docs/pull/7/files
>
>
> WDYT?
>
> Paul
>
>
>
>
> --
> Paul Wright
> Mobile Docs (github: finp)
>
>
--
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (#aerogear)
7 years, 1 month
Re: [aerogear-dev] Aerogear Digger with Jenkins Wendy CI pair-programming session
by Vojtech Sazel
I meant it was supposed to be completely public, even for outside world.
Hope there is no problem with that.
On Wed, Jan 31, 2018 at 12:05 PM, Jose Miguel Gallas Olmedo <
jgallaso(a)redhat.com> wrote:
> Yes it was!
>
>
> 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 31 January 2018 at 11:42, Vojtech Sazel <vsazel(a)redhat.com> wrote:
>
>> Sorry, that calendar event was not public.
>> But I have the recording here:
>>
>> *https://bluejeans.com/s/H491F <https://bluejeans.com/s/H491F>*
>>
>> On Wed, Jan 31, 2018 at 8:45 AM, Vojtech Sazel <vsazel(a)redhat.com> wrote:
>>
>>> Hi,
>>>
>>> today we are going to have a session in set up of building of an Android
>>> application in Jenkins Wendy CI.
>>> I'll try there to set it up instructed by Adam Saleh.
>>>
>>> It's in shared calendar. I'll try to record it.
>>>
>>> https://calendar.google.com/event?action=TEMPLATE&tmeid=N2xl
>>> c3M5MjRjZjIwMzJtcGYxZzg4M3M2N3QgcmVkaGF0LmNvbV9raWNlZjV1djJw
>>> NmM1OXBpYWVrdjl1Y29rb0Bn&tmsrc=redhat.com_kicef5uv2p6c59piae
>>> kv9ucoko%40group.calendar.google.com
>>>
>>> --
>>>
>>> VOJTĚCH SÁZEL
>>>
>>> SENIOR QUALITY ENGINEER, MOBILE QE
>>>
>>> Red Hat
>>>
>>> <https://www.redhat.com/>
>>>
>>> Remote Czech Republic
>>>
>>> vsazel(a)redhat.com IM: vsazel
>>> <https://red.ht/sig>
>>>
>>
>>
>>
>> --
>>
>> VOJTĚCH SÁZEL
>>
>> SENIOR QUALITY ENGINEER, MOBILE QE
>>
>> Red Hat
>>
>> <https://www.redhat.com/>
>>
>> Remote Czech Republic
>>
>> vsazel(a)redhat.com IM: vsazel
>> <https://red.ht/sig>
>>
>
>
--
VOJTĚCH SÁZEL
SENIOR QUALITY ENGINEER, MOBILE QE
Red Hat
<https://www.redhat.com/>
Remote Czech Republic
vsazel(a)redhat.com IM: vsazel
<https://red.ht/sig>
7 years, 1 month
