From matzew at apache.org Fri Aug 1 00:35:34 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 06:35:34 +0200 Subject: [aerogear-dev] [UnifiedPush Server] release timelines Message-ID: Hi team, based on [1] I thought about our release timelines until 1.0.0.Final, and shortly after. - 1.0.0.Beta2 : 07/Aug/14 This needs to include Keycloak-beta4, and might slip by one day, but not much more of a delay. *Please note:* There is already works going on to have our parent and UPS working w/ beta4 - it?s just a matter of merging the branch, once the release is out. Number of open JIRAs for this release is looking good! - 1.0.0 : 18/Aug/14 *Keycloak:* This will use keycloak?s beta4 as well, unless we find BLOCKERS in their beta4... (As said before KC is mostly hidden inside the server, and we can not wait for their 1.0.0.Final in September) This release will be mostly around docs and perhaps some more UX review of the quickstart demos. It is possible that the UX review does not happen. *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives us one week of deep testing (of server, docs, demos) before the final release. Next: *celebrate*!!!!!!!! [image: :tada:] After the 1.0.0.Final of UPS, I?d suggest a two week-based release series of small fixes and improvements, as well as taking up new Keycloak releases - 1.0.1 : 01/Sep/14 *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few items from the JIRA. - 1.0.2 : 15/Sep/14 *Keycloak:* main reason is pick-up of their 1.0.0.Final - 1.0.3 :29/Sep/14 Might not be needed - but added it to JIRA, just in case? Let me know your thoughts and I will update the roadmap! -Matthias [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/cb96d24b/attachment.html From daniel.bevenius at gmail.com Fri Aug 1 02:16:39 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 1 Aug 2014 08:16:39 +0200 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: Message-ID: Sounds good to me! On 1 August 2014 06:35, Matthias Wessendorf wrote: > Hi team, > > based on [1] I thought about our release timelines until 1.0.0.Final, and > shortly after. > > - > > 1.0.0.Beta2 > : > 07/Aug/14 > > This needs to include Keycloak-beta4, and might slip by one day, but not > much more of a delay. > > *Please note:* There is already works going on to have our parent and UPS > working w/ beta4 - it?s just a matter of merging the branch, once the > release is out. > > Number of open JIRAs for this release is looking good! > > - > > 1.0.0 > : > 18/Aug/14 > > *Keycloak:* This will use keycloak?s beta4 as well, unless we find > BLOCKERS in their beta4... (As said before KC is mostly hidden inside the > server, and we can not wait for their 1.0.0.Final in September) > > This release will be mostly around docs and perhaps some more UX review of > the quickstart demos. It is possible that the UX review does not happen. > > *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush > Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives > us one week of deep testing (of server, docs, demos) before the final > release. > > Next: *celebrate*!!!!!!!! [image: :tada:] > > After the 1.0.0.Final of UPS, I?d suggest a two week-based release series > of small fixes and improvements, as well as taking up new Keycloak releases > > - > > 1.0.1 > : > 01/Sep/14 > > *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few items > from the JIRA. > > - > > 1.0.2 > : > 15/Sep/14 > > *Keycloak:* main reason is pick-up of their 1.0.0.Final > > - > > 1.0.3 > > :29/Sep/14 > > Might not be needed - but added it to JIRA, just in case? > > Let me know your thoughts and I will update the roadmap! > > -Matthias > > [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/6ad38e5f/attachment-0001.html From cvasilak at gmail.com Fri Aug 1 02:26:42 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 1 Aug 2014 09:26:42 +0300 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: Message-ID: <330A5F95-71A1-4335-BD02-2A10FCF4A552@gmail.com> +1 Matthias sounds good. - Christos On Aug 1, 2014, at 7:35 AM, Matthias Wessendorf wrote: > Hi team, > > based on [1] I thought about our release timelines until 1.0.0.Final, and shortly after. > > 1.0.0.Beta2: 07/Aug/14 > > This needs to include Keycloak-beta4, and might slip by one day, but not much more of a delay. > > Please note: There is already works going on to have our parent and UPS working w/ beta4 - it?s just a matter of merging the branch, once the release is out. > > Number of open JIRAs for this release is looking good! > > 1.0.0: 18/Aug/14 > > Keycloak: This will use keycloak?s beta4 as well, unless we find BLOCKERS in their beta4... (As said before KC is mostly hidden inside the server, and we can not wait for their 1.0.0.Final in September) > > This release will be mostly around docs and perhaps some more UX review of the quickstart demos. It is possible that the UX review does not happen. > > CODE FREEZE: I?d suggest we do a code freeze for the UnifiedPush Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives us one week of deep testing (of server, docs, demos) before the final release. > > Next: celebrate!!!!!!!! > > After the 1.0.0.Final of UPS, I?d suggest a two week-based release series of small fixes and improvements, as well as taking up new Keycloak releases > > 1.0.1: 01/Sep/14 > > Keycloak: main reason is pick-up of their 1.0-RC-1 and those few items from the JIRA. > > 1.0.2: 15/Sep/14 > > Keycloak: main reason is pick-up of their 1.0.0.Final > > 1.0.3:29/Sep/14 > > Might not be needed - but added it to JIRA, just in case? > > Let me know your thoughts and I will update the roadmap! > > -Matthias > > [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/82ab0c05/attachment.html From lukas.fryc at gmail.com Fri Aug 1 02:31:24 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 1 Aug 2014 08:31:24 +0200 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: Message-ID: +1 On Admin UI front, there are some issues with tooling around NPM that I don't consider blocking 1.0.x releases (AGPUSH-863 , AGPUSH-864 ). I.e. if we stay with current versions we are okay. On Fri, Aug 1, 2014 at 8:16 AM, Daniel Bevenius wrote: > Sounds good to me! > > > On 1 August 2014 06:35, Matthias Wessendorf wrote: > >> Hi team, >> >> based on [1] I thought about our release timelines until 1.0.0.Final, and >> shortly after. >> >> - >> >> 1.0.0.Beta2 >> : >> 07/Aug/14 >> >> This needs to include Keycloak-beta4, and might slip by one day, but not >> much more of a delay. >> >> *Please note:* There is already works going on to have our parent and >> UPS working w/ beta4 - it?s just a matter of merging the branch, once the >> release is out. >> >> Number of open JIRAs for this release is looking good! >> >> - >> >> 1.0.0 >> : >> 18/Aug/14 >> >> *Keycloak:* This will use keycloak?s beta4 as well, unless we find >> BLOCKERS in their beta4... (As said before KC is mostly hidden inside the >> server, and we can not wait for their 1.0.0.Final in September) >> >> This release will be mostly around docs and perhaps some more UX review >> of the quickstart demos. It is possible that the UX review does not happen. >> >> *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush >> Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives >> us one week of deep testing (of server, docs, demos) before the final >> release. >> >> Next: *celebrate*!!!!!!!! [image: :tada:] >> >> After the 1.0.0.Final of UPS, I?d suggest a two week-based release series >> of small fixes and improvements, as well as taking up new Keycloak releases >> >> - >> >> 1.0.1 >> : >> 01/Sep/14 >> >> *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few items >> from the JIRA. >> >> - >> >> 1.0.2 >> : >> 15/Sep/14 >> >> *Keycloak:* main reason is pick-up of their 1.0.0.Final >> >> - >> >> 1.0.3 >> >> :29/Sep/14 >> >> Might not be needed - but added it to JIRA, just in case? >> >> Let me know your thoughts and I will update the roadmap! >> >> -Matthias >> >> [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/e1af25e4/attachment.html From matzew at apache.org Fri Aug 1 02:34:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 08:34:24 +0200 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 8:31 AM, Luk?? Fry? wrote: > +1 > > On Admin UI front, there are some issues with tooling around NPM that I > don't consider blocking 1.0.x releases (AGPUSH-863 > , AGPUSH-864 > ). > I.e. if we stay with current versions we are okay. > #agreed > > > On Fri, Aug 1, 2014 at 8:16 AM, Daniel Bevenius > wrote: > >> Sounds good to me! >> >> >> On 1 August 2014 06:35, Matthias Wessendorf wrote: >> >>> Hi team, >>> >>> based on [1] I thought about our release timelines until 1.0.0.Final, >>> and shortly after. >>> >>> - >>> >>> 1.0.0.Beta2 >>> : >>> 07/Aug/14 >>> >>> This needs to include Keycloak-beta4, and might slip by one day, but not >>> much more of a delay. >>> >>> *Please note:* There is already works going on to have our parent and >>> UPS working w/ beta4 - it?s just a matter of merging the branch, once the >>> release is out. >>> >>> Number of open JIRAs for this release is looking good! >>> >>> - >>> >>> 1.0.0 >>> : >>> 18/Aug/14 >>> >>> *Keycloak:* This will use keycloak?s beta4 as well, unless we find >>> BLOCKERS in their beta4... (As said before KC is mostly hidden inside the >>> server, and we can not wait for their 1.0.0.Final in September) >>> >>> This release will be mostly around docs and perhaps some more UX review >>> of the quickstart demos. It is possible that the UX review does not happen. >>> >>> *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush >>> Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives >>> us one week of deep testing (of server, docs, demos) before the final >>> release. >>> >>> Next: *celebrate*!!!!!!!! [image: :tada:] >>> >>> After the 1.0.0.Final of UPS, I?d suggest a two week-based release >>> series of small fixes and improvements, as well as taking up new Keycloak >>> releases >>> >>> - >>> >>> 1.0.1 >>> : >>> 01/Sep/14 >>> >>> *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few >>> items from the JIRA. >>> >>> - >>> >>> 1.0.2 >>> : >>> 15/Sep/14 >>> >>> *Keycloak:* main reason is pick-up of their 1.0.0.Final >>> >>> - >>> >>> 1.0.3 >>> >>> :29/Sep/14 >>> >>> Might not be needed - but added it to JIRA, just in case? >>> >>> Let me know your thoughts and I will update the roadmap! >>> >>> -Matthias >>> >>> [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/f9c812d3/attachment-0001.html From matzew at apache.org Fri Aug 1 03:25:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 09:25:57 +0200 Subject: [aerogear-dev] Improving SimplePush experience ? Message-ID: Hi, I recently found this: https://github.com/coolaj86/fxos-push-notification-demo looks pretty nice! I wonder if we should be using / leveraging that demo w/ our SP quickstart: * Polyfill: add our JS * FFOS native: I think there is a property to override the SP server URL in FFOS That could help, but if we do it, let's do it after we got the UPS 1.0.0.Final out! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/fe100eab/attachment.html From matzew at apache.org Fri Aug 1 03:36:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 09:36:59 +0200 Subject: [aerogear-dev] Releasing new parent (0.2.5) Message-ID: mainly to pick up new java-apns version (1.0.0.Beta4), which contains fixes around 'content-available' and Karel's remove of spring dependencies. The staging repo is here: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3653/ Let me know about the release! -M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/c38a8c9e/attachment.html From matzew at apache.org Fri Aug 1 04:07:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 10:07:45 +0200 Subject: [aerogear-dev] [UPS] Misc: Node.js sender Message-ID: Hi there, a few questions: * based on https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 should we do a new release of the node.js sender ? * going over the docs, do we have 'guide' or so that we can link here: http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/c7dcdb8a/attachment.html From scm.blanc at gmail.com Fri Aug 1 04:56:21 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 1 Aug 2014 10:56:21 +0200 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf wrote: > Hi there, > > a few questions: > > * based on > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 > > should we do a new release of the node.js sender ? > yes > > * going over the docs, do we have 'guide' or so that we can link here: > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials > not that I'm aware of but we could link (for now) to the README of the github which contains instructions. > > > Thanks! > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/a7b1dec4/attachment.html From avibelli at redhat.com Fri Aug 1 05:41:00 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Fri, 1 Aug 2014 02:41:00 -0700 (PDT) Subject: [aerogear-dev] Releasing new parent (0.2.5) In-Reply-To: References: Message-ID: <1406886060026-8683.post@n5.nabble.com> Hi Matt, the changes are good, nice to get rid of those deps! Go for the release! :-) Thanks Andrea Matthias Wessendorf wrote > mainly to pick up new java-apns version (1.0.0.Beta4), which contains > fixes > around 'content-available' and Karel's remove of spring dependencies. > > The staging repo is here: > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3653/ > > Let me know about the release! > > -M > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at .jboss > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Releasing-new-parent-0-2-5-tp8680p8683.html Sent from the aerogear-dev mailing list archive at Nabble.com. From cvasilak at gmail.com Fri Aug 1 06:47:16 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 1 Aug 2014 13:47:16 +0300 Subject: [aerogear-dev] Swift running on iOS 7 / Observations Message-ID: Hi all, a heads up on my observations during porting our quickstart app [1] (Swift port) and making it compatible to also run on iOS 7 too [2]. Indeed, Swift apps can run on iOS 7 due to the swift-runtime embedded in the application (and can be observed on the generated app archive [3] ). A major obstacle faced is that although you can utilise at runtime a form of dynamic version check (e.g. respondsToSelector[] ) to decide to call either iOS 7 or iOS 8 API, the runtime is strict on class loading and fails even when the code-path that instantiates the class is not executed. Let me give you a concrete example. Here is snippet of code that uses either the new push registration API available in iOS 8 or fails back to the old one if not: -- if application.respondsToSelector(Selector("registerUserNotificationSettings:")) { let settings = UIUserNotificationSettings(forTypes: .Alert | .Badge | .Sound, categories: nil) UIApplication.sharedApplication().registerUserNotificationSettings(settings) UIApplication.sharedApplication().registerForRemoteNotifications() } else { UIApplication.sharedApplication().registerForRemoteNotificationTypes( .Badge | .Sound | .Alert) } If your Target build SDK is set to ?Latest (8.0)? (to avoid compilation error of missing classes) but your deployment target is set to 7.x (to support older versions) and you have some form of dynamic selection on runtime (e.g .respondsToSelector[] ), this fails when running on iOS 7 with a missing symbol: (note that the code path that instantiates UIUserNotificationSettings is not reached but yet fails at runtime) -- dyld: Symbol not found: _OBJC_CLASS_$_UIUserNotificationSettings Referenced from: /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts Expected in: /System/Library/Frameworks/UIKit.framework/UIKit in /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts -- In contrast, the obj-c version of the same code runs fine on iOS 7. Apparently this has been observed [4] and some workarounds exist (basically use an objective-c bridge to workaround it, but that is just a ?hack'). This is to the fact that the obj-c compiler does some form of weak-linking the symbols that are only available on later versions than the deployment target. I imagine having the same form of issues when trying to utilise a any new iOS 8 class that doesn?t exist on iOS 7. For that matter (at least for the current state of the Swift runtime) i am leading towards not using any hacks to workaround issues on Swift running on iOS 7. I am sure Apple with the current pace of dev will come up with techniques, but let?s not pollute the code for the time being. Let me know your thoughts. - Christos [1] https://github.com/aerogear/aerogear-push-quickstarts/tree/swift [2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/swift-ios7 [3] http://tinyurl.com/swift-runtime [4] http://stackoverflow.com/questions/24256583/swift-write-code-for-ios-7-and-8 From abstractj at redhat.com Fri Aug 1 06:54:47 2014 From: abstractj at redhat.com (Bruno Oliveira) Date: Fri, 1 Aug 2014 07:54:47 -0300 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: Message-ID: <20140801105446.GB42958@redhat.com> +1 When? On 2014-08-01, Sebastien Blanc wrote: > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf > wrote: > > > Hi there, > > > > a few questions: > > > > * based on > > > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 > > > > should we do a new release of the node.js sender ? > > > yes > > > > > * going over the docs, do we have 'guide' or so that we can link here: > > > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials > > > not that I'm aware of but we could link (for now) to the README of the > github which contains instructions. > > > > > > > Thanks! > > Matthias > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Aug 1 06:55:13 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 1 Aug 2014 07:55:13 -0300 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: Message-ID: <20140801105513.GC42958@abstractj.org> +1 When? On 2014-08-01, Sebastien Blanc wrote: > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf > wrote: > > > Hi there, > > > > a few questions: > > > > * based on > > > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 > > > > should we do a new release of the node.js sender ? > > > yes > > > > > * going over the docs, do we have 'guide' or so that we can link here: > > > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials > > > not that I'm aware of but we could link (for now) to the README of the > github which contains instructions. > > > > > > > Thanks! > > Matthias > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Aug 1 07:08:05 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 1 Aug 2014 08:08:05 -0300 Subject: [aerogear-dev] Improving SimplePush experience ? In-Reply-To: References: Message-ID: <20140801110805.GD42958@abstractj.org> I don't know, but if we're going to start a demo. Maybe we should consider a FFOS cookbook before? On 2014-08-01, Matthias Wessendorf wrote: > Hi, > > I recently found this: > https://github.com/coolaj86/fxos-push-notification-demo > > looks pretty nice! > > I wonder if we should be using / leveraging that demo w/ our SP quickstart: > > * Polyfill: add our JS > * FFOS native: I think there is a property to override the SP server URL in > FFOS > > That could help, but if we do it, let's do it after we got the UPS > 1.0.0.Final out! > > -Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Aug 1 07:12:07 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 1 Aug 2014 08:12:07 -0300 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: <330A5F95-71A1-4335-BD02-2A10FCF4A552@gmail.com> References: <330A5F95-71A1-4335-BD02-2A10FCF4A552@gmail.com> Message-ID: <20140801111207.GE42958@abstractj.org> +1 Looks good On 2014-08-01, Christos Vasilakis wrote: > +1 Matthias sounds good. > > > - > Christos > > > On Aug 1, 2014, at 7:35 AM, Matthias Wessendorf wrote: > > > Hi team, > > > > based on [1] I thought about our release timelines until 1.0.0.Final, and shortly after. > > > > 1.0.0.Beta2: 07/Aug/14 > > > > This needs to include Keycloak-beta4, and might slip by one day, but not much more of a delay. > > > > Please note: There is already works going on to have our parent and UPS working w/ beta4 - it?s just a matter of merging the branch, once the release is out. > > > > Number of open JIRAs for this release is looking good! > > > > 1.0.0: 18/Aug/14 > > > > Keycloak: This will use keycloak?s beta4 as well, unless we find BLOCKERS in their beta4... (As said before KC is mostly hidden inside the server, and we can not wait for their 1.0.0.Final in September) > > > > This release will be mostly around docs and perhaps some more UX review of the quickstart demos. It is possible that the UX review does not happen. > > > > CODE FREEZE: I?d suggest we do a code freeze for the UnifiedPush Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives us one week of deep testing (of server, docs, demos) before the final release. > > > > Next: celebrate!!!!!!!! > > > > After the 1.0.0.Final of UPS, I?d suggest a two week-based release series of small fixes and improvements, as well as taking up new Keycloak releases > > > > 1.0.1: 01/Sep/14 > > > > Keycloak: main reason is pick-up of their 1.0-RC-1 and those few items from the JIRA. > > > > 1.0.2: 15/Sep/14 > > > > Keycloak: main reason is pick-up of their 1.0.0.Final > > > > 1.0.3:29/Sep/14 > > > > Might not be needed - but added it to JIRA, just in case? > > > > Let me know your thoughts and I will update the roadmap! > > > > -Matthias > > > > [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Fri Aug 1 07:17:29 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 1 Aug 2014 13:17:29 +0200 Subject: [aerogear-dev] Swift running on iOS 7 / Observations In-Reply-To: References: Message-ID: +1 I think not polluting the code it good. On 1 August 2014 12:47, Christos Vasilakis wrote: > Hi all, > > a heads up on my observations during porting our quickstart app [1] > (Swift port) and making it compatible to also run on iOS 7 too [2]. > Indeed, Swift apps can run on iOS 7 due to the swift-runtime embedded in > the application (and can be observed on the generated app archive [3] ). > > A major obstacle faced is that although you can utilise at runtime a form > of dynamic version check (e.g. respondsToSelector[] ) to decide to call > either iOS 7 or iOS 8 API, the runtime is strict on class loading and fails > even when the code-path that instantiates the class is not executed. > > Let me give you a concrete example. Here is snippet of code that uses > either the new push registration API available in iOS 8 or fails back to > the old one if not: > > -- > if > application.respondsToSelector(Selector("registerUserNotificationSettings:")) > { > let settings = UIUserNotificationSettings(forTypes: .Alert | .Badge | > .Sound, categories: nil) > > UIApplication.sharedApplication().registerUserNotificationSettings(settings) > UIApplication.sharedApplication().registerForRemoteNotifications() > } else { > UIApplication.sharedApplication().registerForRemoteNotificationTypes( > .Badge | .Sound | .Alert) > } > > If your Target build SDK is set to ?Latest (8.0)? (to avoid compilation > error of missing classes) but your deployment target is set to 7.x (to > support older versions) and you have some form of dynamic selection on > runtime (e.g .respondsToSelector[] ), this fails when running on iOS 7 with > a missing symbol: (note that the code path that instantiates > UIUserNotificationSettings is not reached but yet fails at runtime) > > -- > dyld: Symbol not found: _OBJC_CLASS_$_UIUserNotificationSettings > Referenced from: > /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts > Expected in: /System/Library/Frameworks/UIKit.framework/UIKit > in > /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts > -- > > In contrast, the obj-c version of the same code runs fine on iOS 7. > > Apparently this has been observed [4] and some workarounds exist > (basically use an objective-c bridge to workaround it, but that is just a > ?hack'). This is to the fact that the obj-c compiler does some form of > weak-linking the symbols that are only available on later versions than the > deployment target. > > I imagine having the same form of issues when trying to utilise a any new > iOS 8 class that doesn?t exist on iOS 7. For that matter (at least for the > current state of the Swift runtime) i am leading towards not using any > hacks to workaround issues on Swift running on iOS 7. I am sure Apple with > the current pace of dev will come up with techniques, but let?s not pollute > the code for the time being. > > Let me know your thoughts. > > - > Christos > > [1] https://github.com/aerogear/aerogear-push-quickstarts/tree/swift > [2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/swift-ios7 > [3] http://tinyurl.com/swift-runtime > [4] > http://stackoverflow.com/questions/24256583/swift-write-code-for-ios-7-and-8 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/afadd978/attachment.html From matzew at apache.org Fri Aug 1 07:22:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 13:22:25 +0200 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: <20140801105513.GC42958@abstractj.org> References: <20140801105513.GC42958@abstractj.org> Message-ID: Whenever Luke is ready ? :) On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira wrote: > +1 > > When? > > On 2014-08-01, Sebastien Blanc wrote: > > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf > > wrote: > > > > > Hi there, > > > > > > a few questions: > > > > > > * based on > > > > > > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 > > > > > > should we do a new release of the node.js sender ? > > > > > yes > > > > > > > > * going over the docs, do we have 'guide' or so that we can link here: > > > > > > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials > > > > > not that I'm aware of but we could link (for now) to the README of the > > github which contains instructions. > > > > > > > > > > > Thanks! > > > Matthias > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/40237b37/attachment.html From matzew at apache.org Fri Aug 1 07:25:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 13:25:24 +0200 Subject: [aerogear-dev] Swift running on iOS 7 / Observations In-Reply-To: References: Message-ID: sounds reasonable to me as well. Christos, let's close the PR? To avoid confusion ? On Fri, Aug 1, 2014 at 1:17 PM, Daniel Bevenius wrote: > +1 I think not polluting the code it good. > > > On 1 August 2014 12:47, Christos Vasilakis wrote: > >> Hi all, >> >> a heads up on my observations during porting our quickstart app [1] >> (Swift port) and making it compatible to also run on iOS 7 too [2]. >> Indeed, Swift apps can run on iOS 7 due to the swift-runtime embedded in >> the application (and can be observed on the generated app archive [3] ). >> >> A major obstacle faced is that although you can utilise at runtime a form >> of dynamic version check (e.g. respondsToSelector[] ) to decide to call >> either iOS 7 or iOS 8 API, the runtime is strict on class loading and fails >> even when the code-path that instantiates the class is not executed. >> >> Let me give you a concrete example. Here is snippet of code that uses >> either the new push registration API available in iOS 8 or fails back to >> the old one if not: >> >> -- >> if >> application.respondsToSelector(Selector("registerUserNotificationSettings:")) >> { >> let settings = UIUserNotificationSettings(forTypes: .Alert | .Badge | >> .Sound, categories: nil) >> >> UIApplication.sharedApplication().registerUserNotificationSettings(settings) >> UIApplication.sharedApplication().registerForRemoteNotifications() >> } else { >> UIApplication.sharedApplication().registerForRemoteNotificationTypes( >> .Badge | .Sound | .Alert) >> } >> >> If your Target build SDK is set to ?Latest (8.0)? (to avoid compilation >> error of missing classes) but your deployment target is set to 7.x (to >> support older versions) and you have some form of dynamic selection on >> runtime (e.g .respondsToSelector[] ), this fails when running on iOS 7 with >> a missing symbol: (note that the code path that instantiates >> UIUserNotificationSettings is not reached but yet fails at runtime) >> >> -- >> dyld: Symbol not found: _OBJC_CLASS_$_UIUserNotificationSettings >> Referenced from: >> /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts >> Expected in: /System/Library/Frameworks/UIKit.framework/UIKit >> in >> /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts >> -- >> >> In contrast, the obj-c version of the same code runs fine on iOS 7. >> >> Apparently this has been observed [4] and some workarounds exist >> (basically use an objective-c bridge to workaround it, but that is just a >> ?hack'). This is to the fact that the obj-c compiler does some form of >> weak-linking the symbols that are only available on later versions than the >> deployment target. >> >> I imagine having the same form of issues when trying to utilise a any new >> iOS 8 class that doesn?t exist on iOS 7. For that matter (at least for the >> current state of the Swift runtime) i am leading towards not using any >> hacks to workaround issues on Swift running on iOS 7. I am sure Apple with >> the current pace of dev will come up with techniques, but let?s not pollute >> the code for the time being. >> >> Let me know your thoughts. >> >> - >> Christos >> >> [1] https://github.com/aerogear/aerogear-push-quickstarts/tree/swift >> [2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/swift-ios7 >> [3] http://tinyurl.com/swift-runtime >> [4] >> http://stackoverflow.com/questions/24256583/swift-write-code-for-ios-7-and-8 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/b41809e7/attachment-0001.html From corinnekrych at gmail.com Fri Aug 1 07:31:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 1 Aug 2014 13:31:05 +0200 Subject: [aerogear-dev] Swift running on iOS 7 / Observations In-Reply-To: References: Message-ID: <702CB1C9-26E2-41B4-BC2F-DD443B4E76DB@gmail.com> Yep being able to target ios7 and ios8 is a mix of macro and runtime check as we did on HelloWorld [1] HelloWorl is simple enough to demo it but let?s not confuse users with a more complete ex like Contacts. We can stick to iOS8 for that Swift demo. +1 on closing PR ++ Corinne [1] https://github.com/aerogear/aerogear-push-helloworld/blob/master/ios/HelloWorld/AGAppDelegate.m#L27 On 01 Aug 2014, at 13:25, Matthias Wessendorf wrote: > sounds reasonable to me as well. > > Christos, let's close the PR? To avoid confusion ? > > > On Fri, Aug 1, 2014 at 1:17 PM, Daniel Bevenius wrote: > +1 I think not polluting the code it good. > > > On 1 August 2014 12:47, Christos Vasilakis wrote: > Hi all, > > a heads up on my observations during porting our quickstart app [1] (Swift port) and making it compatible to also run on iOS 7 too [2]. Indeed, Swift apps can run on iOS 7 due to the swift-runtime embedded in the application (and can be observed on the generated app archive [3] ). > > A major obstacle faced is that although you can utilise at runtime a form of dynamic version check (e.g. respondsToSelector[] ) to decide to call either iOS 7 or iOS 8 API, the runtime is strict on class loading and fails even when the code-path that instantiates the class is not executed. > > Let me give you a concrete example. Here is snippet of code that uses either the new push registration API available in iOS 8 or fails back to the old one if not: > > -- > if application.respondsToSelector(Selector("registerUserNotificationSettings:")) { > let settings = UIUserNotificationSettings(forTypes: .Alert | .Badge | .Sound, categories: nil) > UIApplication.sharedApplication().registerUserNotificationSettings(settings) > UIApplication.sharedApplication().registerForRemoteNotifications() > } else { > UIApplication.sharedApplication().registerForRemoteNotificationTypes( .Badge | .Sound | .Alert) > } > > If your Target build SDK is set to ?Latest (8.0)? (to avoid compilation error of missing classes) but your deployment target is set to 7.x (to support older versions) and you have some form of dynamic selection on runtime (e.g .respondsToSelector[] ), this fails when running on iOS 7 with a missing symbol: (note that the code path that instantiates UIUserNotificationSettings is not reached but yet fails at runtime) > > -- > dyld: Symbol not found: _OBJC_CLASS_$_UIUserNotificationSettings > Referenced from: /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts > Expected in: /System/Library/Frameworks/UIKit.framework/UIKit > in /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts > -- > > In contrast, the obj-c version of the same code runs fine on iOS 7. > > Apparently this has been observed [4] and some workarounds exist (basically use an objective-c bridge to workaround it, but that is just a ?hack'). This is to the fact that the obj-c compiler does some form of weak-linking the symbols that are only available on later versions than the deployment target. > > I imagine having the same form of issues when trying to utilise a any new iOS 8 class that doesn?t exist on iOS 7. For that matter (at least for the current state of the Swift runtime) i am leading towards not using any hacks to workaround issues on Swift running on iOS 7. I am sure Apple with the current pace of dev will come up with techniques, but let?s not pollute the code for the time being. > > Let me know your thoughts. > > - > Christos > > [1] https://github.com/aerogear/aerogear-push-quickstarts/tree/swift > [2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/swift-ios7 > [3] http://tinyurl.com/swift-runtime > [4] http://stackoverflow.com/questions/24256583/swift-write-code-for-ios-7-and-8 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Aug 1 07:52:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 13:52:09 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: So the questions are, I think: 1) what does 'active' mean? * total activity * or recent activity Having [1] in mind, I *think* the three most recent active variants makes sense 2) what number do we provide for that variant: a) number of receivers/active tokens that received the last Push message b) total number of all receivers, in history c) number of total push messages, per variant Here, I *think* that b) does not make sense, having [1] in mind. I think presenting a) or c) as the number on that "three recent active" variants is a nice info. -Matthias [1] https://issues.jboss.org/browse/AGPUSH-673 On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc wrote: > Hi, > I decided to start a new thread after some discussions we had on a > previous thread[1] > > Basically, we are talking about this part of the dashboard : > > [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien Blanc] > > It appeared that is not really clear what we want to show there, as a side > note, the current query behind this is not correct and should change > whatever we decide. > > So, what can we show here : > > 1. Show the most (three) recent active variants (and their # of > receivers) > Active means here, the 3 latest variants that sent a Push Message. > The term "receivers" can also be confusing , do we want to show : > > 1.a : The number of receivers/active tokens that received the last Push > message (i.e : Push Message A sent to 10 people and Push Message B to 5 > people, we show 5) ? > 1.b : The total number of receivers/actives tokens of this variant (i.e : > Push Message A sent to 10 people and Push Message B to 5 people, we show > 15) ? > 1.c : The total number of Push Messages sent (i.e : Push Message A sent > to 10 people and Push Message B to 5 people, we show 2). ? > > 2. Show the most active variants (and their # of receivers) > Almost same than 1. but here we look at all the variants even those > without an recent activity. > Here again 1.a/1.b or 1.c applies. > > The core question, IMO, is what would be an useful information for the > user ? > > Sebi > > > [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/47d41a41/attachment.html From scm.blanc at gmail.com Fri Aug 1 08:01:49 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 1 Aug 2014 14:01:49 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf wrote: > So the questions are, I think: > > 1) what does 'active' mean? > * total activity > * or recent activity > > Having [1] in mind, I *think* the three most recent active variants makes > sense > > 2) what number do we provide for that variant: > a) number of receivers/active tokens that received the last Push message > b) total number of all receivers, in history > c) number of total push messages, per variant > > > Here, I *think* that b) does not make sense, having [1] in mind. I think > presenting a) or c) as the number on that "three recent active" variants is > a nice info. > Ok , but imagine this we have 4 variants, A,B,C,D. They all sent the same messages within the same hour , starting with : A sends 5000 messages B sends 100 messages C sends 15 messages D sends 50 messages The top 3 recent active are B,C and D , it's a bit a pita A do not show up, since it was really the more active. Shall we define active within a period (24 hours ? ) ? Sebi > -Matthias > > > > > > [1] https://issues.jboss.org/browse/AGPUSH-673 > > > On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc > wrote: > >> Hi, >> I decided to start a new thread after some discussions we had on a >> previous thread[1] >> >> Basically, we are talking about this part of the dashboard : >> >> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien Blanc] >> >> It appeared that is not really clear what we want to show there, as a >> side note, the current query behind this is not correct and should change >> whatever we decide. >> >> So, what can we show here : >> >> 1. Show the most (three) recent active variants (and their # of >> receivers) >> Active means here, the 3 latest variants that sent a Push Message. >> The term "receivers" can also be confusing , do we want to show : >> >> 1.a : The number of receivers/active tokens that received the last Push >> message (i.e : Push Message A sent to 10 people and Push Message B to 5 >> people, we show 5) ? >> 1.b : The total number of receivers/actives tokens of this variant (i.e >> : Push Message A sent to 10 people and Push Message B to 5 people, we show >> 15) ? >> 1.c : The total number of Push Messages sent (i.e : Push Message A sent >> to 10 people and Push Message B to 5 people, we show 2). ? >> >> 2. Show the most active variants (and their # of receivers) >> Almost same than 1. but here we look at all the variants even those >> without an recent activity. >> Here again 1.a/1.b or 1.c applies. >> >> The core question, IMO, is what would be an useful information for the >> user ? >> >> Sebi >> >> >> [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/89b7edad/attachment-0001.html From matzew at apache.org Fri Aug 1 08:34:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 14:34:51 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc wrote: > > > > On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf > wrote: > >> So the questions are, I think: >> >> 1) what does 'active' mean? >> * total activity >> * or recent activity >> >> Having [1] in mind, I *think* the three most recent active variants makes >> sense >> >> 2) what number do we provide for that variant: >> a) number of receivers/active tokens that received the last Push message >> b) total number of all receivers, in history >> c) number of total push messages, per variant >> >> >> Here, I *think* that b) does not make sense, having [1] in mind. I think >> presenting a) or c) as the number on that "three recent active" variants is >> a nice info. >> > > Ok , but imagine this we have 4 variants, A,B,C,D. > They all sent the same messages within the same hour , starting with : > A sends 5000 messages > B sends 100 messages > C sends 15 messages > D sends 50 messages > I think messages == receivers ? (I doubt that one variant will send 5k of push messages - I'd try to sue the company for that amount of spam on my phone) > > The top 3 recent active are B,C and D , it's a bit a pita A do not show > up, > that's life! :) > since it was really the more active. > Shall we define active within a period (24 hours ? ) ? > doesn't make that even more complex ? > > Sebi > > >> -Matthias >> >> >> >> >> >> [1] https://issues.jboss.org/browse/AGPUSH-673 >> >> >> On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc >> wrote: >> >>> Hi, >>> I decided to start a new thread after some discussions we had on a >>> previous thread[1] >>> >>> Basically, we are talking about this part of the dashboard : >>> >>> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien Blanc] >>> >>> It appeared that is not really clear what we want to show there, as a >>> side note, the current query behind this is not correct and should change >>> whatever we decide. >>> >>> So, what can we show here : >>> >>> 1. Show the most (three) recent active variants (and their # of >>> receivers) >>> Active means here, the 3 latest variants that sent a Push Message. >>> The term "receivers" can also be confusing , do we want to show : >>> >>> 1.a : The number of receivers/active tokens that received the last Push >>> message (i.e : Push Message A sent to 10 people and Push Message B to 5 >>> people, we show 5) ? >>> 1.b : The total number of receivers/actives tokens of this variant (i.e >>> : Push Message A sent to 10 people and Push Message B to 5 people, we show >>> 15) ? >>> 1.c : The total number of Push Messages sent (i.e : Push Message A sent >>> to 10 people and Push Message B to 5 people, we show 2). ? >>> >>> 2. Show the most active variants (and their # of receivers) >>> Almost same than 1. but here we look at all the variants even those >>> without an recent activity. >>> Here again 1.a/1.b or 1.c applies. >>> >>> The core question, IMO, is what would be an useful information for the >>> user ? >>> >>> Sebi >>> >>> >>> [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/185a22c3/attachment.html From scm.blanc at gmail.com Fri Aug 1 08:39:16 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 1 Aug 2014 14:39:16 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 2:34 PM, Matthias Wessendorf wrote: > > > > On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc > wrote: > >> >> >> >> On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf >> wrote: >> >>> So the questions are, I think: >>> >>> 1) what does 'active' mean? >>> * total activity >>> * or recent activity >>> >>> Having [1] in mind, I *think* the three most recent active variants >>> makes sense >>> >>> 2) what number do we provide for that variant: >>> a) number of receivers/active tokens that received the last Push message >>> b) total number of all receivers, in history >>> c) number of total push messages, per variant >>> >>> >>> Here, I *think* that b) does not make sense, having [1] in mind. I think >>> presenting a) or c) as the number on that "three recent active" variants is >>> a nice info. >>> >> >> Ok , but imagine this we have 4 variants, A,B,C,D. >> They all sent the same messages within the same hour , starting with : >> A sends 5000 messages >> B sends 100 messages >> C sends 15 messages >> D sends 50 messages >> > > > I think messages == receivers ? (I doubt that one variant will send 5k of > push messages - I'd try to sue the company for that amount of spam on my > phone) > yeah receivers :) > > >> >> The top 3 recent active are B,C and D , it's a bit a pita A do not show >> up, >> > > > that's life! :) > > >> since it was really the more active. >> Shall we define active within a period (24 hours ? ) ? >> > > doesn't make that even more complex ? > Well, not that much I think since we are already going to introduce a new query based on dates. I will take a look. > > > > >> >> Sebi >> >> >>> -Matthias >>> >>> >>> >>> >>> >>> [1] https://issues.jboss.org/browse/AGPUSH-673 >>> >>> >>> On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc >>> wrote: >>> >>>> Hi, >>>> I decided to start a new thread after some discussions we had on a >>>> previous thread[1] >>>> >>>> Basically, we are talking about this part of the dashboard : >>>> >>>> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien Blanc] >>>> >>>> It appeared that is not really clear what we want to show there, as a >>>> side note, the current query behind this is not correct and should change >>>> whatever we decide. >>>> >>>> So, what can we show here : >>>> >>>> 1. Show the most (three) recent active variants (and their # of >>>> receivers) >>>> Active means here, the 3 latest variants that sent a Push Message. >>>> The term "receivers" can also be confusing , do we want to show : >>>> >>>> 1.a : The number of receivers/active tokens that received the last Push >>>> message (i.e : Push Message A sent to 10 people and Push Message B to >>>> 5 people, we show 5) ? >>>> 1.b : The total number of receivers/actives tokens of this variant >>>> (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we >>>> show 15) ? >>>> 1.c : The total number of Push Messages sent (i.e : Push Message A >>>> sent to 10 people and Push Message B to 5 people, we show 2). ? >>>> >>>> 2. Show the most active variants (and their # of receivers) >>>> Almost same than 1. but here we look at all the variants even those >>>> without an recent activity. >>>> Here again 1.a/1.b or 1.c applies. >>>> >>>> The core question, IMO, is what would be an useful information for the >>>> user ? >>>> >>>> Sebi >>>> >>>> >>>> [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/b6650b3e/attachment-0001.html From lholmqui at redhat.com Fri Aug 1 08:47:19 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 1 Aug 2014 08:47:19 -0400 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: Message-ID: <71D8CDD4-373B-4BD2-89AA-4432641C4E2E@redhat.com> ++ sounds/looks good On Aug 1, 2014, at 12:35 AM, Matthias Wessendorf wrote: > Hi team, > > based on [1] I thought about our release timelines until 1.0.0.Final, and shortly after. > > 1.0.0.Beta2: 07/Aug/14 > > This needs to include Keycloak-beta4, and might slip by one day, but not much more of a delay. > > Please note: There is already works going on to have our parent and UPS working w/ beta4 - it?s just a matter of merging the branch, once the release is out. > > Number of open JIRAs for this release is looking good! > > 1.0.0: 18/Aug/14 > > Keycloak: This will use keycloak?s beta4 as well, unless we find BLOCKERS in their beta4... (As said before KC is mostly hidden inside the server, and we can not wait for their 1.0.0.Final in September) > > This release will be mostly around docs and perhaps some more UX review of the quickstart demos. It is possible that the UX review does not happen. > > CODE FREEZE: I?d suggest we do a code freeze for the UnifiedPush Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives us one week of deep testing (of server, docs, demos) before the final release. > > Next: celebrate!!!!!!!! > > After the 1.0.0.Final of UPS, I?d suggest a two week-based release series of small fixes and improvements, as well as taking up new Keycloak releases > > 1.0.1: 01/Sep/14 > > Keycloak: main reason is pick-up of their 1.0-RC-1 and those few items from the JIRA. > > 1.0.2: 15/Sep/14 > > Keycloak: main reason is pick-up of their 1.0.0.Final > > 1.0.3:29/Sep/14 > > Might not be needed - but added it to JIRA, just in case? > > Let me know your thoughts and I will update the roadmap! > > -Matthias > > [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/6a7c92ed/attachment.html From lholmqui at redhat.com Fri Aug 1 08:48:36 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 1 Aug 2014 08:48:36 -0400 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: <20140801105513.GC42958@abstractj.org> Message-ID: <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> :), do we a JIRA, i can whip something up for a guide On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf wrote: > Whenever Luke is ready ? :) > > > > On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira wrote: > +1 > > When? > > On 2014-08-01, Sebastien Blanc wrote: > > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf > > wrote: > > > > > Hi there, > > > > > > a few questions: > > > > > > * based on > > > > > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 > > > > > > should we do a new release of the node.js sender ? > > > > > yes > > > > > > > > * going over the docs, do we have 'guide' or so that we can link here: > > > > > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials > > > > > not that I'm aware of but we could link (for now) to the README of the > > github which contains instructions. > > > > > > > > > > > Thanks! > > > Matthias > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/0802246e/attachment.html From scm.blanc at gmail.com Fri Aug 1 09:05:51 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 1 Aug 2014 15:05:51 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: Hum, after thinking and looking a bit I think it's easier and more clear to show the "real" 3 most recent active variants like you mentioned, along with the numbers of receivers for the last push messages (but the label should be made more obvious to explain this number, working on that s well) On Fri, Aug 1, 2014 at 2:39 PM, Sebastien Blanc wrote: > > > > On Fri, Aug 1, 2014 at 2:34 PM, Matthias Wessendorf > wrote: > >> >> >> >> On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc >> wrote: >> >>> >>> >>> >>> On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf >>> wrote: >>> >>>> So the questions are, I think: >>>> >>>> 1) what does 'active' mean? >>>> * total activity >>>> * or recent activity >>>> >>>> Having [1] in mind, I *think* the three most recent active variants >>>> makes sense >>>> >>>> 2) what number do we provide for that variant: >>>> a) number of receivers/active tokens that received the last Push >>>> message >>>> b) total number of all receivers, in history >>>> c) number of total push messages, per variant >>>> >>>> >>>> Here, I *think* that b) does not make sense, having [1] in mind. I >>>> think presenting a) or c) as the number on that "three recent active" >>>> variants is a nice info. >>>> >>> >>> Ok , but imagine this we have 4 variants, A,B,C,D. >>> They all sent the same messages within the same hour , starting with : >>> A sends 5000 messages >>> B sends 100 messages >>> C sends 15 messages >>> D sends 50 messages >>> >> >> >> I think messages == receivers ? (I doubt that one variant will send 5k of >> push messages - I'd try to sue the company for that amount of spam on my >> phone) >> > yeah receivers :) > >> >> >>> >>> The top 3 recent active are B,C and D , it's a bit a pita A do not show >>> up, >>> >> >> >> that's life! :) >> >> >>> since it was really the more active. >>> Shall we define active within a period (24 hours ? ) ? >>> >> >> doesn't make that even more complex ? >> > Well, not that much I think since we are already going to introduce a new > query based on dates. I will take a look. > > >> >> >> >> >>> >>> Sebi >>> >>> >>>> -Matthias >>>> >>>> >>>> >>>> >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-673 >>>> >>>> >>>> On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc >>>> wrote: >>>> >>>>> Hi, >>>>> I decided to start a new thread after some discussions we had on a >>>>> previous thread[1] >>>>> >>>>> Basically, we are talking about this part of the dashboard : >>>>> >>>>> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien Blanc] >>>>> >>>>> It appeared that is not really clear what we want to show there, as a >>>>> side note, the current query behind this is not correct and should change >>>>> whatever we decide. >>>>> >>>>> So, what can we show here : >>>>> >>>>> 1. Show the most (three) recent active variants (and their # of >>>>> receivers) >>>>> Active means here, the 3 latest variants that sent a Push Message. >>>>> The term "receivers" can also be confusing , do we want to show : >>>>> >>>>> 1.a : The number of receivers/active tokens that received the last >>>>> Push message (i.e : Push Message A sent to 10 people and Push Message >>>>> B to 5 people, we show 5) ? >>>>> 1.b : The total number of receivers/actives tokens of this variant >>>>> (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we >>>>> show 15) ? >>>>> 1.c : The total number of Push Messages sent (i.e : Push Message A >>>>> sent to 10 people and Push Message B to 5 people, we show 2). ? >>>>> >>>>> 2. Show the most active variants (and their # of receivers) >>>>> Almost same than 1. but here we look at all the variants even those >>>>> without an recent activity. >>>>> Here again 1.a/1.b or 1.c applies. >>>>> >>>>> The core question, IMO, is what would be an useful information for the >>>>> user ? >>>>> >>>>> Sebi >>>>> >>>>> >>>>> [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/b81fa496/attachment-0001.html From matzew at apache.org Fri Aug 1 09:08:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 15:08:22 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 3:05 PM, Sebastien Blanc wrote: > Hum, after thinking and looking a bit I think it's easier and more clear > to show the "real" 3 most recent active variants like you mentioned, along > with the numbers of receivers for the last push messages (but the label > should be made more obvious to explain this number, working on that s well) > sounds good w/ me -M > > > > On Fri, Aug 1, 2014 at 2:39 PM, Sebastien Blanc > wrote: > >> >> >> >> On Fri, Aug 1, 2014 at 2:34 PM, Matthias Wessendorf >> wrote: >> >>> >>> >>> >>> On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc >>> wrote: >>> >>>> >>>> >>>> >>>> On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf >>>> wrote: >>>> >>>>> So the questions are, I think: >>>>> >>>>> 1) what does 'active' mean? >>>>> * total activity >>>>> * or recent activity >>>>> >>>>> Having [1] in mind, I *think* the three most recent active variants >>>>> makes sense >>>>> >>>>> 2) what number do we provide for that variant: >>>>> a) number of receivers/active tokens that received the last Push >>>>> message >>>>> b) total number of all receivers, in history >>>>> c) number of total push messages, per variant >>>>> >>>>> >>>>> Here, I *think* that b) does not make sense, having [1] in mind. I >>>>> think presenting a) or c) as the number on that "three recent active" >>>>> variants is a nice info. >>>>> >>>> >>>> Ok , but imagine this we have 4 variants, A,B,C,D. >>>> They all sent the same messages within the same hour , starting with : >>>> A sends 5000 messages >>>> B sends 100 messages >>>> C sends 15 messages >>>> D sends 50 messages >>>> >>> >>> >>> I think messages == receivers ? (I doubt that one variant will send 5k >>> of push messages - I'd try to sue the company for that amount of spam on my >>> phone) >>> >> yeah receivers :) >> >>> >>> >>>> >>>> The top 3 recent active are B,C and D , it's a bit a pita A do not show >>>> up, >>>> >>> >>> >>> that's life! :) >>> >>> >>>> since it was really the more active. >>>> Shall we define active within a period (24 hours ? ) ? >>>> >>> >>> doesn't make that even more complex ? >>> >> Well, not that much I think since we are already going to introduce a new >> query based on dates. I will take a look. >> >> >>> >>> >>> >>> >>>> >>>> Sebi >>>> >>>> >>>>> -Matthias >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [1] https://issues.jboss.org/browse/AGPUSH-673 >>>>> >>>>> >>>>> On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> I decided to start a new thread after some discussions we had on a >>>>>> previous thread[1] >>>>>> >>>>>> Basically, we are talking about this part of the dashboard : >>>>>> >>>>>> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien Blanc] >>>>>> >>>>>> It appeared that is not really clear what we want to show there, as a >>>>>> side note, the current query behind this is not correct and should change >>>>>> whatever we decide. >>>>>> >>>>>> So, what can we show here : >>>>>> >>>>>> 1. Show the most (three) recent active variants (and their # of >>>>>> receivers) >>>>>> Active means here, the 3 latest variants that sent a Push Message. >>>>>> The term "receivers" can also be confusing , do we want to show : >>>>>> >>>>>> 1.a : The number of receivers/active tokens that received the last >>>>>> Push message (i.e : Push Message A sent to 10 people and Push >>>>>> Message B to 5 people, we show 5) ? >>>>>> 1.b : The total number of receivers/actives tokens of this variant >>>>>> (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we >>>>>> show 15) ? >>>>>> 1.c : The total number of Push Messages sent (i.e : Push Message A >>>>>> sent to 10 people and Push Message B to 5 people, we show 2). ? >>>>>> >>>>>> 2. Show the most active variants (and their # of receivers) >>>>>> Almost same than 1. but here we look at all the variants even those >>>>>> without an recent activity. >>>>>> Here again 1.a/1.b or 1.c applies. >>>>>> >>>>>> The core question, IMO, is what would be an useful information for >>>>>> the user ? >>>>>> >>>>>> Sebi >>>>>> >>>>>> >>>>>> [1] >>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/38c11712/attachment.html From matzew at apache.org Fri Aug 1 09:19:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 15:19:59 +0200 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: <71D8CDD4-373B-4BD2-89AA-4432641C4E2E@redhat.com> References: <71D8CDD4-373B-4BD2-89AA-4432641C4E2E@redhat.com> Message-ID: here we go: https://github.com/aerogear/aerogear.org/pull/343 On Fri, Aug 1, 2014 at 2:47 PM, Lucas Holmquist wrote: > ++ sounds/looks good > On Aug 1, 2014, at 12:35 AM, Matthias Wessendorf > wrote: > > Hi team, > > based on [1] I thought about our release timelines until 1.0.0.Final, and > shortly after. > > - > > 1.0.0.Beta2 > : > 07/Aug/14 > > This needs to include Keycloak-beta4, and might slip by one day, but not > much more of a delay. > > *Please note:* There is already works going on to have our parent and UPS > working w/ beta4 - it?s just a matter of merging the branch, once the > release is out. > > Number of open JIRAs for this release is looking good! > > - > > 1.0.0 > : > 18/Aug/14 > > *Keycloak:* This will use keycloak?s beta4 as well, unless we find > BLOCKERS in their beta4... (As said before KC is mostly hidden inside the > server, and we can not wait for their 1.0.0.Final in September) > > This release will be mostly around docs and perhaps some more UX review of > the quickstart demos. It is possible that the UX review does not happen. > > *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush > Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives > us one week of deep testing (of server, docs, demos) before the final > release. > > Next: *celebrate*!!!!!!!! [image: :tada:] > > After the 1.0.0.Final of UPS, I?d suggest a two week-based release series > of small fixes and improvements, as well as taking up new Keycloak releases > > - > > 1.0.1 > : > 01/Sep/14 > > *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few items > from the JIRA. > > - > > 1.0.2 > : > 15/Sep/14 > > *Keycloak:* main reason is pick-up of their 1.0.0.Final > > - > > 1.0.3 > > :29/Sep/14 > > Might not be needed - but added it to JIRA, just in case? > > Let me know your thoughts and I will update the roadmap! > > -Matthias > > [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/cf5401df/attachment-0001.html From scm.blanc at gmail.com Fri Aug 1 09:45:18 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 1 Aug 2014 15:45:18 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 3:08 PM, Matthias Wessendorf wrote: > > > > On Fri, Aug 1, 2014 at 3:05 PM, Sebastien Blanc > wrote: > >> Hum, after thinking and looking a bit I think it's easier and more clear >> to show the "real" 3 most recent active variants like you mentioned, along >> with the numbers of receivers for the last push messages (but the label >> should be made more obvious to explain this number, working on that s well) >> > > sounds good w/ me > Ok, here a last proposition, because our current model do really fit what we want to do : What about showing the 3 last activity (regardless of the variant) , basically a select on the PushMessageInformation sorted on submitDate and we pick the 3 first one ? > > -M > > >> >> >> >> On Fri, Aug 1, 2014 at 2:39 PM, Sebastien Blanc >> wrote: >> >>> >>> >>> >>> On Fri, Aug 1, 2014 at 2:34 PM, Matthias Wessendorf >>> wrote: >>> >>>> >>>> >>>> >>>> On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf >>>> > wrote: >>>>> >>>>>> So the questions are, I think: >>>>>> >>>>>> 1) what does 'active' mean? >>>>>> * total activity >>>>>> * or recent activity >>>>>> >>>>>> Having [1] in mind, I *think* the three most recent active variants >>>>>> makes sense >>>>>> >>>>>> 2) what number do we provide for that variant: >>>>>> a) number of receivers/active tokens that received the last Push >>>>>> message >>>>>> b) total number of all receivers, in history >>>>>> c) number of total push messages, per variant >>>>>> >>>>>> >>>>>> Here, I *think* that b) does not make sense, having [1] in mind. I >>>>>> think presenting a) or c) as the number on that "three recent active" >>>>>> variants is a nice info. >>>>>> >>>>> >>>>> Ok , but imagine this we have 4 variants, A,B,C,D. >>>>> They all sent the same messages within the same hour , starting with : >>>>> A sends 5000 messages >>>>> B sends 100 messages >>>>> C sends 15 messages >>>>> D sends 50 messages >>>>> >>>> >>>> >>>> I think messages == receivers ? (I doubt that one variant will send 5k >>>> of push messages - I'd try to sue the company for that amount of spam on my >>>> phone) >>>> >>> yeah receivers :) >>> >>>> >>>> >>>>> >>>>> The top 3 recent active are B,C and D , it's a bit a pita A do not >>>>> show up, >>>>> >>>> >>>> >>>> that's life! :) >>>> >>>> >>>>> since it was really the more active. >>>>> Shall we define active within a period (24 hours ? ) ? >>>>> >>>> >>>> doesn't make that even more complex ? >>>> >>> Well, not that much I think since we are already going to introduce a >>> new query based on dates. I will take a look. >>> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> Sebi >>>>> >>>>> >>>>>> -Matthias >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [1] https://issues.jboss.org/browse/AGPUSH-673 >>>>>> >>>>>> >>>>>> On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc >>>>> > wrote: >>>>>> >>>>>>> Hi, >>>>>>> I decided to start a new thread after some discussions we had on a >>>>>>> previous thread[1] >>>>>>> >>>>>>> Basically, we are talking about this part of the dashboard : >>>>>>> >>>>>>> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien >>>>>>> Blanc] >>>>>>> >>>>>>> It appeared that is not really clear what we want to show there, as >>>>>>> a side note, the current query behind this is not correct and should change >>>>>>> whatever we decide. >>>>>>> >>>>>>> So, what can we show here : >>>>>>> >>>>>>> 1. Show the most (three) recent active variants (and their # of >>>>>>> receivers) >>>>>>> Active means here, the 3 latest variants that sent a Push Message. >>>>>>> The term "receivers" can also be confusing , do we want to show : >>>>>>> >>>>>>> 1.a : The number of receivers/active tokens that received the last >>>>>>> Push message (i.e : Push Message A sent to 10 people and Push >>>>>>> Message B to 5 people, we show 5) ? >>>>>>> 1.b : The total number of receivers/actives tokens of this variant >>>>>>> (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we >>>>>>> show 15) ? >>>>>>> 1.c : The total number of Push Messages sent (i.e : Push Message A >>>>>>> sent to 10 people and Push Message B to 5 people, we show 2). ? >>>>>>> >>>>>>> 2. Show the most active variants (and their # of receivers) >>>>>>> Almost same than 1. but here we look at all the variants even those >>>>>>> without an recent activity. >>>>>>> Here again 1.a/1.b or 1.c applies. >>>>>>> >>>>>>> The core question, IMO, is what would be an useful information for >>>>>>> the user ? >>>>>>> >>>>>>> Sebi >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/45fff39c/attachment.html From lholmqui at redhat.com Fri Aug 1 09:47:59 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 1 Aug 2014 09:47:59 -0400 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> Message-ID: <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> Do we want to also rename it. the java sender is called( in maven ), ?unifiedpush-java-sender? while the node one(in npm) is ?aerogear-sender-client? i was thinking the name should probably be ?unifiedpush-sender? or ?unifiedpush-sender? what do others think? On Aug 1, 2014, at 8:48 AM, Lucas Holmquist wrote: > :), do we a JIRA, i can whip something up for a guide > On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf wrote: > >> Whenever Luke is ready ? :) >> >> >> >> On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira wrote: >> +1 >> >> When? >> >> On 2014-08-01, Sebastien Blanc wrote: >> > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf >> > wrote: >> > >> > > Hi there, >> > > >> > > a few questions: >> > > >> > > * based on >> > > >> > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 >> > > >> > > should we do a new release of the node.js sender ? >> > > >> > yes >> > >> > > >> > > * going over the docs, do we have 'guide' or so that we can link here: >> > > >> > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials >> > > >> > not that I'm aware of but we could link (for now) to the README of the >> > github which contains instructions. >> > >> > > >> > > >> > > Thanks! >> > > Matthias >> > > >> > > -- >> > > Matthias Wessendorf >> > > >> > > blog: http://matthiaswessendorf.wordpress.com/ >> > > sessions: http://www.slideshare.net/mwessendorf >> > > twitter: http://twitter.com/mwessendorf >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/0ff14be6/attachment-0001.html From matzew at apache.org Fri Aug 1 09:49:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 1 Aug 2014 15:49:31 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 3:45 PM, Sebastien Blanc wrote: > > > > On Fri, Aug 1, 2014 at 3:08 PM, Matthias Wessendorf > wrote: > >> >> >> >> On Fri, Aug 1, 2014 at 3:05 PM, Sebastien Blanc >> wrote: >> >>> Hum, after thinking and looking a bit I think it's easier and more clear >>> to show the "real" 3 most recent active variants like you mentioned, along >>> with the numbers of receivers for the last push messages (but the label >>> should be made more obvious to explain this number, working on that s well) >>> >> >> sounds good w/ me >> > Ok, here a last proposition, because our current model do really fit what > we want to do : What about showing the 3 last activity (regardless of the > variant) , basically a select on the PushMessageInformation sorted on > submitDate and we pick the 3 first one ? > ah, so it could be, for some reason list like this: * Variant A (50 message) * Variant C (5 message) * Variant A (15 message) ? I am totally fine with that as well. What ever makes sense and give some sort of "activity feeling" > > >> >> -M >> >> >>> >>> >>> >>> On Fri, Aug 1, 2014 at 2:39 PM, Sebastien Blanc >>> wrote: >>> >>>> >>>> >>>> >>>> On Fri, Aug 1, 2014 at 2:34 PM, Matthias Wessendorf >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> So the questions are, I think: >>>>>>> >>>>>>> 1) what does 'active' mean? >>>>>>> * total activity >>>>>>> * or recent activity >>>>>>> >>>>>>> Having [1] in mind, I *think* the three most recent active variants >>>>>>> makes sense >>>>>>> >>>>>>> 2) what number do we provide for that variant: >>>>>>> a) number of receivers/active tokens that received the last Push >>>>>>> message >>>>>>> b) total number of all receivers, in history >>>>>>> c) number of total push messages, per variant >>>>>>> >>>>>>> >>>>>>> Here, I *think* that b) does not make sense, having [1] in mind. I >>>>>>> think presenting a) or c) as the number on that "three recent active" >>>>>>> variants is a nice info. >>>>>>> >>>>>> >>>>>> Ok , but imagine this we have 4 variants, A,B,C,D. >>>>>> They all sent the same messages within the same hour , starting with : >>>>>> A sends 5000 messages >>>>>> B sends 100 messages >>>>>> C sends 15 messages >>>>>> D sends 50 messages >>>>>> >>>>> >>>>> >>>>> I think messages == receivers ? (I doubt that one variant will send 5k >>>>> of push messages - I'd try to sue the company for that amount of spam on my >>>>> phone) >>>>> >>>> yeah receivers :) >>>> >>>>> >>>>> >>>>>> >>>>>> The top 3 recent active are B,C and D , it's a bit a pita A do not >>>>>> show up, >>>>>> >>>>> >>>>> >>>>> that's life! :) >>>>> >>>>> >>>>>> since it was really the more active. >>>>>> Shall we define active within a period (24 hours ? ) ? >>>>>> >>>>> >>>>> doesn't make that even more complex ? >>>>> >>>> Well, not that much I think since we are already going to introduce a >>>> new query based on dates. I will take a look. >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> Sebi >>>>>> >>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1] https://issues.jboss.org/browse/AGPUSH-673 >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc < >>>>>>> scm.blanc at gmail.com> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> I decided to start a new thread after some discussions we had on a >>>>>>>> previous thread[1] >>>>>>>> >>>>>>>> Basically, we are talking about this part of the dashboard : >>>>>>>> >>>>>>>> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien >>>>>>>> Blanc] >>>>>>>> >>>>>>>> It appeared that is not really clear what we want to show there, as >>>>>>>> a side note, the current query behind this is not correct and should change >>>>>>>> whatever we decide. >>>>>>>> >>>>>>>> So, what can we show here : >>>>>>>> >>>>>>>> 1. Show the most (three) recent active variants (and their # of >>>>>>>> receivers) >>>>>>>> Active means here, the 3 latest variants that sent a Push Message. >>>>>>>> The term "receivers" can also be confusing , do we want to show : >>>>>>>> >>>>>>>> 1.a : The number of receivers/active tokens that received the last >>>>>>>> Push message (i.e : Push Message A sent to 10 people and Push >>>>>>>> Message B to 5 people, we show 5) ? >>>>>>>> 1.b : The total number of receivers/actives tokens of this variant >>>>>>>> (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we >>>>>>>> show 15) ? >>>>>>>> 1.c : The total number of Push Messages sent (i.e : Push Message A >>>>>>>> sent to 10 people and Push Message B to 5 people, we show 2). ? >>>>>>>> >>>>>>>> 2. Show the most active variants (and their # of receivers) >>>>>>>> Almost same than 1. but here we look at all the variants even those >>>>>>>> without an recent activity. >>>>>>>> Here again 1.a/1.b or 1.c applies. >>>>>>>> >>>>>>>> The core question, IMO, is what would be an useful information for >>>>>>>> the user ? >>>>>>>> >>>>>>>> Sebi >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/bc660eff/attachment.html From scm.blanc at gmail.com Fri Aug 1 10:19:49 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 1 Aug 2014 16:19:49 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 3:49 PM, Matthias Wessendorf wrote: > > > > On Fri, Aug 1, 2014 at 3:45 PM, Sebastien Blanc > wrote: > >> >> >> >> On Fri, Aug 1, 2014 at 3:08 PM, Matthias Wessendorf >> wrote: >> >>> >>> >>> >>> On Fri, Aug 1, 2014 at 3:05 PM, Sebastien Blanc >>> wrote: >>> >>>> Hum, after thinking and looking a bit I think it's easier and more >>>> clear to show the "real" 3 most recent active variants like you mentioned, >>>> along with the numbers of receivers for the last push messages (but the >>>> label should be made more obvious to explain this number, working on that s >>>> well) >>>> >>> >>> sounds good w/ me >>> >> Ok, here a last proposition, because our current model do really fit what >> we want to do : What about showing the 3 last activity (regardless of the >> variant) , basically a select on the PushMessageInformation sorted on >> submitDate and we pick the 3 first one ? >> > > ah, so it could be, for some reason list like this: > > * Variant A (50 message) > * Variant C (5 message) > * Variant A (15 message) > Well will be more * App A (total receivers from VariantMetrics list) * App C (total receivers from VariantMetrics list) * App A (total receivers from VariantMetrics list) The trick with having variant metrics is that the submit date is on the PusMessageInformation and the VariantsMetricList has no refernce back to the PushMessageInformation, which made the query a bit complex. > ? I am totally fine with that as well. What ever makes sense and give > some sort of "activity feeling" > > > >> >> >>> >>> -M >>> >>> >>>> >>>> >>>> >>>> On Fri, Aug 1, 2014 at 2:39 PM, Sebastien Blanc >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 1, 2014 at 2:34 PM, Matthias Wessendorf >>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> So the questions are, I think: >>>>>>>> >>>>>>>> 1) what does 'active' mean? >>>>>>>> * total activity >>>>>>>> * or recent activity >>>>>>>> >>>>>>>> Having [1] in mind, I *think* the three most recent active variants >>>>>>>> makes sense >>>>>>>> >>>>>>>> 2) what number do we provide for that variant: >>>>>>>> a) number of receivers/active tokens that received the last Push >>>>>>>> message >>>>>>>> b) total number of all receivers, in history >>>>>>>> c) number of total push messages, per variant >>>>>>>> >>>>>>>> >>>>>>>> Here, I *think* that b) does not make sense, having [1] in mind. I >>>>>>>> think presenting a) or c) as the number on that "three recent active" >>>>>>>> variants is a nice info. >>>>>>>> >>>>>>> >>>>>>> Ok , but imagine this we have 4 variants, A,B,C,D. >>>>>>> They all sent the same messages within the same hour , starting with >>>>>>> : >>>>>>> A sends 5000 messages >>>>>>> B sends 100 messages >>>>>>> C sends 15 messages >>>>>>> D sends 50 messages >>>>>>> >>>>>> >>>>>> >>>>>> I think messages == receivers ? (I doubt that one variant will send >>>>>> 5k of push messages - I'd try to sue the company for that amount of spam on >>>>>> my phone) >>>>>> >>>>> yeah receivers :) >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> The top 3 recent active are B,C and D , it's a bit a pita A do not >>>>>>> show up, >>>>>>> >>>>>> >>>>>> >>>>>> that's life! :) >>>>>> >>>>>> >>>>>>> since it was really the more active. >>>>>>> Shall we define active within a period (24 hours ? ) ? >>>>>>> >>>>>> >>>>>> doesn't make that even more complex ? >>>>>> >>>>> Well, not that much I think since we are already going to introduce a >>>>> new query based on dates. I will take a look. >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Sebi >>>>>>> >>>>>>> >>>>>>>> -Matthias >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1] https://issues.jboss.org/browse/AGPUSH-673 >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc < >>>>>>>> scm.blanc at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> I decided to start a new thread after some discussions we had on a >>>>>>>>> previous thread[1] >>>>>>>>> >>>>>>>>> Basically, we are talking about this part of the dashboard : >>>>>>>>> >>>>>>>>> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien >>>>>>>>> Blanc] >>>>>>>>> >>>>>>>>> It appeared that is not really clear what we want to show there, >>>>>>>>> as a side note, the current query behind this is not correct and should >>>>>>>>> change whatever we decide. >>>>>>>>> >>>>>>>>> So, what can we show here : >>>>>>>>> >>>>>>>>> 1. Show the most (three) recent active variants (and their # of >>>>>>>>> receivers) >>>>>>>>> Active means here, the 3 latest variants that sent a Push Message. >>>>>>>>> The term "receivers" can also be confusing , do we want to show : >>>>>>>>> >>>>>>>>> 1.a : The number of receivers/active tokens that received the last >>>>>>>>> Push message (i.e : Push Message A sent to 10 people and Push >>>>>>>>> Message B to 5 people, we show 5) ? >>>>>>>>> 1.b : The total number of receivers/actives tokens of this >>>>>>>>> variant (i.e : Push Message A sent to 10 people and Push Message B to 5 >>>>>>>>> people, we show 15) ? >>>>>>>>> 1.c : The total number of Push Messages sent (i.e : Push Message >>>>>>>>> A sent to 10 people and Push Message B to 5 people, we show 2). ? >>>>>>>>> >>>>>>>>> 2. Show the most active variants (and their # of receivers) >>>>>>>>> Almost same than 1. but here we look at all the variants even >>>>>>>>> those without an recent activity. >>>>>>>>> Here again 1.a/1.b or 1.c applies. >>>>>>>>> >>>>>>>>> The core question, IMO, is what would be an useful information for >>>>>>>>> the user ? >>>>>>>>> >>>>>>>>> Sebi >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matthias Wessendorf >>>>>>>> >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/c2bae655/attachment-0001.html From rhauch at redhat.com Fri Aug 1 15:02:59 2014 From: rhauch at redhat.com (Randall Hauch) Date: Fri, 1 Aug 2014 14:02:59 -0500 Subject: [aerogear-dev] Use of Differential Synchronization for data sync Message-ID: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> I?ve really enjoyed learning about what AeroGear has been doing with data sync. This is a tough problem, but finding a solution is really important. Both data sync POCs appear to use Differential Synchronization, or DS [1]. I was not familiar with the paper until today, but after reading it I do have a few questions/comments. Bear with me; this is a long post. DS is clearly targeted for use within a collaborative document editor, where there are multiple clients concurrently editing the same document, and at any one time there are a relatively small number of documents being edited; you can get a feel for this by looking at figures 5 and 7 in the paper [1] ? look at the amount of server memory and CPU required to perform DS on just one document being edited by a half-dozen clients. Also, in a collaborative document editor, clients are often continually making changes even as they attempt to synchronize with the server. (It?s interesting that Google Docs, and Google Wave before it, appear to use Operational Transformation [2] rather than DS. OT might also make it easier to implement undo/redo, which works really well in Google Docs.) An MBaaS or any other database-like service is very different. It has to host multiple applications (i.e., databases), each with multiple collections containing potentially millions of entities (e.g., JSON documents). The entities themselves are more fine-grained and smaller than collaborative documents (though probably a bit coarser-grained and larger than a single record in a RDBMS). Many clients might be reading and updating lots of documents at once, and the data service has to coordinate those changes. A single batch update from one client might request changes to dozens of entities. And the clients can/will always wait for confirmation that the server made the requested changes before continuing (unless the client is offline); or at a minimum can enqueue the requested changes. Given these characteristics, using DS within the data service might be extremely expensive in terms of CPU and memory, and difficult for a DS-based service to implement all of the features necessary. First, the data service doesn?t really know which entities are being?edited?; instead, connected clients read entities, make changes locally, then request the service make those changes. Secondly, every time a change comes in, to compute the diff the service would have to read the persisted entity; this not only is inefficient, but this also makes it more difficult to scale and handle the concurrency, consistency, atomicity, and serializability guarantees. Thirdly, what would the data service need to do when a client connects and asks for the changes since it was last connected? The data service might be able to quickly find out which entities were modified since then, but computing the diffs (relative to the time the client last connected) for all of those changed entities would be very complicated. It may be easier and better for the data service to record the individual changes (edits) made by each transaction, and then to use that information to compute the effective diffs from some period of time. In fact, these recorded edits might also be useful to implement other features within the data service; see CQRS [3] and [4]. What is really required by the client when trying to synchronize its data after being disconnected? Assuming the client can say which subset of entities it?s interested in when it reconnects (via some criteria in a subscription), does the client want: the new versions of those entities that changed; the deltas in the entities; and/or all of the events describing the individual changes made to all of those entities? It may not matter for clients that don?t allow local offline changes, but what might the preferred approach be for clients that do allow offline changes? Option 1 is clearly the easiest from the perspective of the data service, but options #2 and #3 can certainly be handled. With option #1, can the client do something like DS and maintain copies of each original (unmodified) entity so that it can compute the differences? Does this (perhaps with a journal of edits made while offline) provide enough info for the client to properly merge the local changes, or does the client really need the individual events in #3 so that it can, for example, know that some local changes were made to now-out-date data? Will the same option work for online notifications? After all, it?d be great if the same mechanism was used for data-sync, offline (push) notifications, and online notifications (events). Finally, the data sync APIs of the data service should support the use of local client storage, but it should not require it. Best regards, Randall [1] http://research.google.com/pubs/pub35605.html [2] http://en.wikipedia.org/wiki/Operational_transformation [3] http://www.infoq.com/presentations/Events-Are-Not-Just-for-Notifications [4] http://martinfowler.com/bliki/CQRS.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/6ed841d9/attachment.html From jbalunas at redhat.com Fri Aug 1 15:04:47 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Fri, 1 Aug 2014 15:04:47 -0400 Subject: [aerogear-dev] Data-sync discussions with LiveOak team Message-ID: <763DCC13-29E9-42C9-833B-31E75229D215@redhat.com> Hi All, Today we had a meeting to discuss data sync with members of AeroGear, LiveOak, and the ModShape projects. This was more of a kick off meeting, than any real deep technical discussion. I wanted to provide some high level notes and action items. Please feel free to update and/or correct as needed :-) LiveOak (Bolek, Ken, Matt) AeroGear (Summers, Dan, Luke, qmx) ModShape (Randall) After some introductions we discussed what the various teams are focused on related to sync. * LiveOak has been focused on business logic hooks and sever-side JS integration. They have been holding off on data-sync while AG are focused on it. * Randall talked about some of the cloud based concerns and future features that may be part of data services, as well as existing tech. * AeroGear team discussed the current POC's and efforts that we've been doing. ** This is captured in a etherpad here: http://oksoclap.com/p/ag_sync We discussed that it is likely important that we limit the scope of our initial efforts into data sync, and sense LiveOak is focused on data delivery, it would be a nature integration point for the AeroGear sync efforts. We discussed current status and next actions of the efforts: * The team is currently focused on googles diff sync spec and approach ** We need to discuss if there are other approaches we should ? ** What are the pro/cons of these? * How does this work with offline/security efforts from AbstractJ and Passos? ** http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Offline-IRC-meeting-Agenda-tc8044.html#a8054 ** This includes offline authentication and encryption * Dan, and Lukes diff-sync POC updates ** Work with Summers to get android integrated as a POC ** Work with iOS team to get that integrated as a POC * Work with Matt and the LiveOak team on possible integration options ** Could initial POC's be based on Matt business logic interceptors? *** Longer term we all agreed we would want something more integrated into the modules ** Develop a demo for the POC where users can configure apps and/or data to "sync" *** As long as the clients are using the right API and the server is set to sync the data stays updated *** Needs to work offline with reconnect as well, although behave not at first * DataServices integration considerations ** Where/how would this work with data services? * API Review ** We also need to solidify on an API approach as we work through POCs ** Matt has a nice set of APIs on LiveOak side, is that something to build from? ** Are there other API approaches that might be better or adjusted to work? * We need to get a clear sense of the requirements here, as well as go over the planned developer experience. ** This include integration points with LiveOak ** As well as, client platform specific APIs and behaviors Priorities are always tricky though. We're so close to having Push 1.0 released, and we have docs, testings, perf, and openshift work to complete for that. So I think for the time being this is a secondary priority that can become more important as we move beyond Push 1.0. As far as future meetings, conversations, etc... we are planning on cross posting between AeroGear, and LiveOak dev lists, IRC as needed, and if future meetings are needed, we'll figure it out then :-) Again, please feel free to add details, comment, etc.... Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140801/3d412309/attachment.html From daniel.bevenius at gmail.com Sat Aug 2 03:39:51 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Sat, 2 Aug 2014 09:39:51 +0200 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> Message-ID: Hi Randall, regarding the choice of looking closer a DS, the reason for this was that Operational Transformation (OT) has been implemented previously at Red Hat by the Errai team. Instead of doing something with OT again we decided to try DS and compare the two. Erik Jan de Wit in the AeroGear team used to work in Errai team and hopefully he can help us with comparing these two with each other. DS is just one suggestion and I don't know enough about OT to compare them. I'd like to take a closer look at OT if time permits though. I think you have raised interesting concerns/issues, some that I've not thought about before so let me think and while I don't have answers I might be able to reply on some of them next week. Thanks, /Dan On 1 August 2014 21:02, Randall Hauch wrote: > I?ve really enjoyed learning about what AeroGear has been doing with data > sync. This is a tough problem, but finding a solution is really important. > Both data sync POCs appear to use Differential Synchronization, or DS [1]. > I was not familiar with the paper until today, but after reading it I do > have a few questions/comments. Bear with me; this is a long post. > > DS is clearly targeted for use within a collaborative document editor, > where there are multiple clients concurrently editing the same document, > and at any one time there are a relatively small number of documents being > edited; you can get a feel for this by looking at figures 5 and 7 in the > paper [1] ? look at the amount of server memory and CPU required to perform > DS on just one document being edited by a half-dozen clients. Also, in a > collaborative document editor, clients are often continually making changes > even as they attempt to synchronize with the server. > > (It?s interesting that Google Docs, and Google Wave before it, appear to > use Operational Transformation [2] rather than DS. OT might also make it > easier to implement undo/redo, which works really well in Google Docs.) > > An MBaaS or any other database-like service is very different. It has to > host multiple applications (i.e., databases), each with multiple > collections containing potentially millions of entities (e.g., JSON > documents). The entities themselves are more fine-grained and smaller than > collaborative documents (though probably a bit coarser-grained and larger > than a single record in a RDBMS). Many clients might be reading and > updating lots of documents at once, and the data service has to coordinate > those changes. A single batch update from one client might request changes > to dozens of entities. And the clients can/will always wait for > confirmation that the server made the requested changes before continuing > (unless the client is offline); or at a minimum can enqueue the requested > changes. > > Given these characteristics, using DS within the data service might be > extremely expensive in terms of CPU and memory, and difficult for a > DS-based service to implement all of the features necessary. First, the > data service doesn?t really know which entities are being?edited?; instead, > connected clients read entities, make changes locally, then request the > service make those changes. Secondly, every time a change comes in, to > compute the diff the service would have to read the persisted entity; this > not only is inefficient, but this also makes it more difficult to scale and > handle the concurrency, consistency, atomicity, and serializability > guarantees. Thirdly, what would the data service need to do when a client > connects and asks for the changes since it was last connected? The data > service might be able to quickly find out which entities were modified > since then, but computing the diffs (relative to the time the client last > connected) for all of those changed entities would be very complicated. It > may be easier and better for the data service to record the individual > changes (edits) made by each transaction, and then to use that information > to compute the effective diffs from some period of time. In fact, these > recorded edits might also be useful to implement other features within the > data service; see CQRS [3] and [4]. > > What is really required by the client when trying to synchronize its data > after being disconnected? Assuming the client can say which subset of > entities it?s interested in when it reconnects (via some criteria in a > subscription), does the client want: > > 1. the new versions of those entities that changed; > 2. the deltas in the entities; and/or > 3. all of the events describing the individual changes made to all of > those entities? > > > It may not matter for clients that don?t allow local offline changes, but > what might the preferred approach be for clients that do allow offline > changes? Option 1 is clearly the easiest from the perspective of the data > service, but options #2 and #3 can certainly be handled. With option #1, > can the client do something like DS and maintain copies of each original > (unmodified) entity so that it can compute the differences? Does this > (perhaps with a journal of edits made while offline) provide enough info > for the client to properly merge the local changes, or does the client > really need the individual events in #3 so that it can, for example, know > that some local changes were made to now-out-date data? > > Will the same option work for online notifications? After all, it?d be > great if the same mechanism was used for data-sync, offline (push) > notifications, and online notifications (events). > > Finally, the data sync APIs of the data service should support the use of > local client storage, but it should not require it. > > Best regards, > > Randall > > > [1] http://research.google.com/pubs/pub35605.html > [2] http://en.wikipedia.org/wiki/Operational_transformation > [3] > http://www.infoq.com/presentations/Events-Are-Not-Just-for-Notifications > [4] http://martinfowler.com/bliki/CQRS.html > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140802/8c183ab3/attachment-0001.html From daniel.bevenius at gmail.com Mon Aug 4 00:19:31 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 4 Aug 2014 06:19:31 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140804 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/e0e5d407/attachment.html From edewit at redhat.com Mon Aug 4 02:58:14 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 4 Aug 2014 08:58:14 +0200 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> Message-ID: Hi, Like Daniel mentioned I was part of the Errai team when we started working on OT, the big problem with OT is it only works good when there is a constant connection. Because you are only sending the transformations you made to the document like: ?insert 'b' at position 200? if your you connection is gone your changes can no longer be put in reliably. What we could do later is to add a strategy when the connection is steady use OT and when the connection is not switch to DS. The OT that is part of Errai is coupled to the Errai message bus, but could be reused with some effort. On 1 Aug,2014, at 21:02 , Randall Hauch wrote: > I?ve really enjoyed learning about what AeroGear has been doing with data sync. This is a tough problem, but finding a solution is really important. Both data sync POCs appear to use Differential Synchronization, or DS [1]. I was not familiar with the paper until today, but after reading it I do have a few questions/comments. Bear with me; this is a long post. > > DS is clearly targeted for use within a collaborative document editor, where there are multiple clients concurrently editing the same document, and at any one time there are a relatively small number of documents being edited; you can get a feel for this by looking at figures 5 and 7 in the paper [1] ? look at the amount of server memory and CPU required to perform DS on just one document being edited by a half-dozen clients. Also, in a collaborative document editor, clients are often continually making changes even as they attempt to synchronize with the server. > > (It?s interesting that Google Docs, and Google Wave before it, appear to use Operational Transformation [2] rather than DS. OT might also make it easier to implement undo/redo, which works really well in Google Docs.) > > An MBaaS or any other database-like service is very different. It has to host multiple applications (i.e., databases), each with multiple collections containing potentially millions of entities (e.g., JSON documents). The entities themselves are more fine-grained and smaller than collaborative documents (though probably a bit coarser-grained and larger than a single record in a RDBMS). Many clients might be reading and updating lots of documents at once, and the data service has to coordinate those changes. A single batch update from one client might request changes to dozens of entities. And the clients can/will always wait for confirmation that the server made the requested changes before continuing (unless the client is offline); or at a minimum can enqueue the requested changes. > > Given these characteristics, using DS within the data service might be extremely expensive in terms of CPU and memory, and difficult for a DS-based service to implement all of the features necessary. First, the data service doesn?t really know which entities are being?edited?; instead, connected clients read entities, make changes locally, then request the service make those changes. Secondly, every time a change comes in, to compute the diff the service would have to read the persisted entity; this not only is inefficient, but this also makes it more difficult to scale and handle the concurrency, consistency, atomicity, and serializability guarantees. Thirdly, what would the data service need to do when a client connects and asks for the changes since it was last connected? The data service might be able to quickly find out which entities were modified since then, but computing the diffs (relative to the time the client last connected) for all of those changed entities would be very complicated. It may be easier and better for the data service to record the individual changes (edits) made by each transaction, and then to use that information to compute the effective diffs from some period of time. In fact, these recorded edits might also be useful to implement other features within the data service; see CQRS [3] and [4]. > > What is really required by the client when trying to synchronize its data after being disconnected? Assuming the client can say which subset of entities it?s interested in when it reconnects (via some criteria in a subscription), does the client want: > the new versions of those entities that changed; > the deltas in the entities; and/or > all of the events describing the individual changes made to all of those entities? > > It may not matter for clients that don?t allow local offline changes, but what might the preferred approach be for clients that do allow offline changes? Option 1 is clearly the easiest from the perspective of the data service, but options #2 and #3 can certainly be handled. With option #1, can the client do something like DS and maintain copies of each original (unmodified) entity so that it can compute the differences? Does this (perhaps with a journal of edits made while offline) provide enough info for the client to properly merge the local changes, or does the client really need the individual events in #3 so that it can, for example, know that some local changes were made to now-out-date data? > > Will the same option work for online notifications? After all, it?d be great if the same mechanism was used for data-sync, offline (push) notifications, and online notifications (events). > > Finally, the data sync APIs of the data service should support the use of local client storage, but it should not require it. > > Best regards, > > Randall > > > [1] http://research.google.com/pubs/pub35605.html > [2] http://en.wikipedia.org/wiki/Operational_transformation > [3] http://www.infoq.com/presentations/Events-Are-Not-Just-for-Notifications > [4] http://martinfowler.com/bliki/CQRS.html > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/f841bd3a/attachment.html From matzew at apache.org Mon Aug 4 03:08:00 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 4 Aug 2014 09:08:00 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: On Fri, Aug 1, 2014 at 4:19 PM, Sebastien Blanc wrote: > > > > On Fri, Aug 1, 2014 at 3:49 PM, Matthias Wessendorf > wrote: > >> >> >> >> On Fri, Aug 1, 2014 at 3:45 PM, Sebastien Blanc >> wrote: >> >>> >>> >>> >>> On Fri, Aug 1, 2014 at 3:08 PM, Matthias Wessendorf >>> wrote: >>> >>>> >>>> >>>> >>>> On Fri, Aug 1, 2014 at 3:05 PM, Sebastien Blanc >>>> wrote: >>>> >>>>> Hum, after thinking and looking a bit I think it's easier and more >>>>> clear to show the "real" 3 most recent active variants like you mentioned, >>>>> along with the numbers of receivers for the last push messages (but the >>>>> label should be made more obvious to explain this number, working on that s >>>>> well) >>>>> >>>> >>>> sounds good w/ me >>>> >>> Ok, here a last proposition, because our current model do really fit >>> what we want to do : What about showing the 3 last activity (regardless of >>> the variant) , basically a select on the PushMessageInformation sorted on >>> submitDate and we pick the 3 first one ? >>> >> >> ah, so it could be, for some reason list like this: >> >> * Variant A (50 message) >> * Variant C (5 message) >> * Variant A (15 message) >> > Well will be more > * App A (total receivers from VariantMetrics list) > * App C (total receivers from VariantMetrics list) > * App A (total receivers from VariantMetrics list) > > sounds good > The trick with having variant metrics is that the submit date is on the > PusMessageInformation and the VariantsMetricList has no refernce back to > the PushMessageInformation, which made the query a bit complex. > oh, if needed, we could change the model. > > >> ? I am totally fine with that as well. What ever makes sense and give >> some sort of "activity feeling" >> >> >> >>> >>> >>>> >>>> -M >>>> >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 1, 2014 at 2:39 PM, Sebastien Blanc >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 1, 2014 at 2:34 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc >>>>>> > wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> So the questions are, I think: >>>>>>>>> >>>>>>>>> 1) what does 'active' mean? >>>>>>>>> * total activity >>>>>>>>> * or recent activity >>>>>>>>> >>>>>>>>> Having [1] in mind, I *think* the three most recent active >>>>>>>>> variants makes sense >>>>>>>>> >>>>>>>>> 2) what number do we provide for that variant: >>>>>>>>> a) number of receivers/active tokens that received the last Push >>>>>>>>> message >>>>>>>>> b) total number of all receivers, in history >>>>>>>>> c) number of total push messages, per variant >>>>>>>>> >>>>>>>>> >>>>>>>>> Here, I *think* that b) does not make sense, having [1] in mind. I >>>>>>>>> think presenting a) or c) as the number on that "three recent active" >>>>>>>>> variants is a nice info. >>>>>>>>> >>>>>>>> >>>>>>>> Ok , but imagine this we have 4 variants, A,B,C,D. >>>>>>>> They all sent the same messages within the same hour , starting >>>>>>>> with : >>>>>>>> A sends 5000 messages >>>>>>>> B sends 100 messages >>>>>>>> C sends 15 messages >>>>>>>> D sends 50 messages >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I think messages == receivers ? (I doubt that one variant will send >>>>>>> 5k of push messages - I'd try to sue the company for that amount of spam on >>>>>>> my phone) >>>>>>> >>>>>> yeah receivers :) >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> The top 3 recent active are B,C and D , it's a bit a pita A do not >>>>>>>> show up, >>>>>>>> >>>>>>> >>>>>>> >>>>>>> that's life! :) >>>>>>> >>>>>>> >>>>>>>> since it was really the more active. >>>>>>>> Shall we define active within a period (24 hours ? ) ? >>>>>>>> >>>>>>> >>>>>>> doesn't make that even more complex ? >>>>>>> >>>>>> Well, not that much I think since we are already going to introduce a >>>>>> new query based on dates. I will take a look. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Sebi >>>>>>>> >>>>>>>> >>>>>>>>> -Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] https://issues.jboss.org/browse/AGPUSH-673 >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc < >>>>>>>>> scm.blanc at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> I decided to start a new thread after some discussions we had on >>>>>>>>>> a previous thread[1] >>>>>>>>>> >>>>>>>>>> Basically, we are talking about this part of the dashboard : >>>>>>>>>> >>>>>>>>>> [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien >>>>>>>>>> Blanc] >>>>>>>>>> >>>>>>>>>> It appeared that is not really clear what we want to show there, >>>>>>>>>> as a side note, the current query behind this is not correct and should >>>>>>>>>> change whatever we decide. >>>>>>>>>> >>>>>>>>>> So, what can we show here : >>>>>>>>>> >>>>>>>>>> 1. Show the most (three) recent active variants (and their # of >>>>>>>>>> receivers) >>>>>>>>>> Active means here, the 3 latest variants that sent a Push Message. >>>>>>>>>> The term "receivers" can also be confusing , do we want to show : >>>>>>>>>> >>>>>>>>>> 1.a : The number of receivers/active tokens that received the >>>>>>>>>> last Push message (i.e : Push Message A sent to 10 people and >>>>>>>>>> Push Message B to 5 people, we show 5) ? >>>>>>>>>> 1.b : The total number of receivers/actives tokens of this >>>>>>>>>> variant (i.e : Push Message A sent to 10 people and Push Message B to 5 >>>>>>>>>> people, we show 15) ? >>>>>>>>>> 1.c : The total number of Push Messages sent (i.e : Push Message >>>>>>>>>> A sent to 10 people and Push Message B to 5 people, we show 2). ? >>>>>>>>>> >>>>>>>>>> 2. Show the most active variants (and their # of receivers) >>>>>>>>>> Almost same than 1. but here we look at all the variants even >>>>>>>>>> those without an recent activity. >>>>>>>>>> Here again 1.a/1.b or 1.c applies. >>>>>>>>>> >>>>>>>>>> The core question, IMO, is what would be an useful information >>>>>>>>>> for the user ? >>>>>>>>>> >>>>>>>>>> Sebi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matthias Wessendorf >>>>>>>>> >>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/8b83daf6/attachment-0001.html From matzew at apache.org Mon Aug 4 07:35:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 4 Aug 2014 13:35:31 +0200 Subject: [aerogear-dev] Releasing new parent (0.2.5) In-Reply-To: <1406886060026-8683.post@n5.nabble.com> References: <1406886060026-8683.post@n5.nabble.com> Message-ID: alright, thanks Andrea the pom will be pushed to maven central On Fri, Aug 1, 2014 at 11:41 AM, Andrea Vibelli wrote: > Hi Matt, the changes are good, nice to get rid of those deps! > Go for the release! :-) > Thanks > Andrea > > > Matthias Wessendorf wrote > > mainly to pick up new java-apns version (1.0.0.Beta4), which contains > > fixes > > around 'content-available' and Karel's remove of spring dependencies. > > > > The staging repo is here: > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3653/ > > > > Let me know about the release! > > > > -M > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > > aerogear-dev at .jboss > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Releasing-new-parent-0-2-5-tp8680p8683.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/2fb3b5b1/attachment.html From supittma at redhat.com Mon Aug 4 10:34:30 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 04 Aug 2014 10:34:30 -0400 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> Message-ID: <53DF99F6.1090604@redhat.com> I am speaking from the perspective of the algorithm and less from my opinions of the way the system should work as a whole. On 08/01/2014 03:02 PM, Randall Hauch wrote: > I've really enjoyed learning about what AeroGear has been doing with > data sync. This is a tough problem, but finding a solution is really > important. Both data sync POCs appear to use Differential > Synchronization, or DS [1]. I was not familiar with the paper until > today, but after reading it I do have a few questions/comments. Bear > with me; this is a long post. > > DS is clearly targeted for use within a collaborative document editor, > where there are multiple clients concurrently editing the same > document, and at any one time there are a relatively small number of > documents being edited; you can get a feel for this by looking at > figures 5 and 7 in the paper [1] --- look at the amount of server > memory and CPU required to perform DS on just one document being > edited by a half-dozen clients. Also, in a collaborative document > editor, clients are often continually making changes even as they > attempt to synchronize with the server. It doesn't actually make any claims about CPU or memory usage. A shadow document is needed for each connection. For documents which are infrequently edited, the shadow doc can easily be frozen to disk until an edit comes in. > > (It's interesting that Google Docs, and Google Wave before it, appear > to use Operational Transformation [2] rather than DS. OT might also > make it easier to implement undo/redo, which works really well in > Google Docs.) That is probably because OT, Docs, and Apache Wave are all older then Diff-sync. OT is also a much more complicated algorithm in my experience (and from browsing around on wikipedia) > > An MBaaS or any other database-like service is very different. It has > to host multiple applications (i.e., databases), each with multiple > collections containing potentially millions of entities (e.g., JSON > documents). The entities themselves are more fine-grained and smaller > than collaborative documents (though probably a bit coarser-grained > and larger than a single record in a RDBMS). Many clients might be > reading and updating lots of documents at once, and the data service > has to coordinate those changes. A single batch update from one client > might request changes to dozens of entities. And the clients can/will > always wait for confirmation that the server made the requested > changes before continuing (unless the client is offline); or at a > minimum can enqueue the requested changes. Two quick things. A document is just a collection of entities and can be structured to reduce this problem (especially is we are faking it on a RDBMS with particularly sadistic abuses to an ORM). Clients don't have to wait for the edits to be merged on the server and the nature of diff-sync gives us batching for free. > > Given these characteristics, using DS within the data service might be > extremely expensive in terms of CPU and memory or it might not be. We need data, use cases, etc to test and see what happens. > , and difficult for a DS-based service to implement all of the > features necessary. Which features? Features of the algorithm of features of the application? The algorithm is really REALLY simple for what we get out of it. > First, the data service doesn't really know which entities are > being"edited"; instead, connected clients read entities, make changes > locally, then request the service make those changes. I disagree. The service knows documents which the client has a connection to/active session for. It most certainly knows which entities are being edited. > Secondly, every time a change comes in, to compute the diff the > service would have to read the persisted entity; this not only is > inefficient, but this also makes it more difficult to scale and handle > the concurrency, consistency, atomicity, and serializability guarantees. See earlier comment about sadistic abuses of an ORM. Yes we have to be aware of the RDB underneath the sync server, but I don't think this is a problem with the algorithm. > Thirdly, what would the data service need to do when a client connects > and asks for the changes since it was last connected? Send it the diff of the clients serverside shadow and the server's current document. This diff will get sent to the client, merged with the clients shadow, and the diff of that will get sent back to the server. Repeat until the client is in sync. > The data service might be able to quickly find out which entities were > modified since then, but computing the diffs (relative to the time the > client last connected) for all of those changed entities would be very > complicated. It isn't. > It may be easier and better for the data service to record the > individual changes (edits) made by each transaction, and then to use > that information to compute the effective diffs from some period of > time. In fact, these recorded edits might also be useful to implement > other features within the data service; see CQRS [3] and [4]. > > What is really required by the client when trying to synchronize its > data after being disconnected? Assuming the client can say which > subset of entities it's interested in when it reconnects (via some > criteria in a subscription), does the client want: > > 1. the new versions of those entities that changed; > No > > 1. the deltas in the entities; and/or > Yes > > 1. all of the events describing the individual changes made to all of > those entities? > No. > > It may not matter for clients that don't allow local offline changes, > but what might the preferred approach be for clients that do allow > offline changes? Option 1 is clearly the easiest from the perspective > of the data service, but options #2 and #3 can certainly be handled. > With option #1, can the client do something like DS and maintain > copies of each original (unmodified) entity so that it can compute the > differences? Does this (perhaps with a journal of edits made while > offline) provide enough info for the client to properly merge the > local changes, or does the client really need the individual events in > #3 so that it can, for example, know that some local changes were made > to now-out-date data? Except in the case of a merge error, the algorithm handles long offline periods with edits just fine. If there is a merge error the user/application will have to manually merge the documents somehow. One of the things to keep in mind is on mobile devices the radio is the most expensive thing you can control as an application. Any decision we make should err toward only sending as little data as possible as few times as possible. > > Will the same option work for online notifications? After all, it'd be > great if the same mechanism was used for data-sync, offline (push) > notifications, and online notifications (events). I don't understand your question. > > Finally, the data sync APIs of the data service should support the use > of local client storage, but it should not require it. > > Best regards, > > Randall > > > [1] http://research.google.com/pubs/pub35605.html > [2] http://en.wikipedia.org/wiki/Operational_transformation > [3] > http://www.infoq.com/presentations/Events-Are-Not-Just-for-Notifications > [4] http://martinfowler.com/bliki/CQRS.html > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/efbb57d4/attachment.html From cvasilak at gmail.com Mon Aug 4 10:37:06 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 4 Aug 2014 17:37:06 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Mon Aug 4 14:35:45 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-04-14.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-04-14.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-04-14.00.log.html On Aug 4, 2014, at 7:19 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140804 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/f4ab45c1/attachment-0001.html From bsutter at redhat.com Mon Aug 4 10:44:16 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 4 Aug 2014 10:44:16 -0400 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? In-Reply-To: References: Message-ID: <44D5F302-1B01-47BD-BC8E-05DE2A2E26E5@redhat.com> I am not sure that I followed the thread completely so please read the following with that in mind. One item that I feel is critical, the determining metric (e.g. number of sent messages, number of registered devices, etc) should be displayed in the dashboard, therefore, it is obvious why the line-item is listed on the dashboard. I also like the concept of "recent activity" as that allows me the developer and/or administrator to know which "channels" are being used...right now (in the last N hours). On Aug 4, 2014, at 3:08 AM, Matthias Wessendorf wrote: > > > > On Fri, Aug 1, 2014 at 4:19 PM, Sebastien Blanc wrote: > > > > On Fri, Aug 1, 2014 at 3:49 PM, Matthias Wessendorf wrote: > > > > On Fri, Aug 1, 2014 at 3:45 PM, Sebastien Blanc wrote: > > > > On Fri, Aug 1, 2014 at 3:08 PM, Matthias Wessendorf wrote: > > > > On Fri, Aug 1, 2014 at 3:05 PM, Sebastien Blanc wrote: > Hum, after thinking and looking a bit I think it's easier and more clear to show the "real" 3 most recent active variants like you mentioned, along with the numbers of receivers for the last push messages (but the label should be made more obvious to explain this number, working on that s well) > > sounds good w/ me > Ok, here a last proposition, because our current model do really fit what we want to do : What about showing the 3 last activity (regardless of the variant) , basically a select on the PushMessageInformation sorted on submitDate and we pick the 3 first one ? > > ah, so it could be, for some reason list like this: > > * Variant A (50 message) > * Variant C (5 message) > * Variant A (15 message) > Well will be more > * App A (total receivers from VariantMetrics list) > * App C (total receivers from VariantMetrics list) > * App A (total receivers from VariantMetrics list) > > > sounds good > > The trick with having variant metrics is that the submit date is on the PusMessageInformation and the VariantsMetricList has no refernce back to the PushMessageInformation, which made the query a bit complex. > > oh, if needed, we could change the model. > > > > ? I am totally fine with that as well. What ever makes sense and give some sort of "activity feeling" > > > > > -M > > > > > On Fri, Aug 1, 2014 at 2:39 PM, Sebastien Blanc wrote: > > > > On Fri, Aug 1, 2014 at 2:34 PM, Matthias Wessendorf wrote: > > > > On Fri, Aug 1, 2014 at 2:01 PM, Sebastien Blanc wrote: > > > > On Fri, Aug 1, 2014 at 1:52 PM, Matthias Wessendorf wrote: > So the questions are, I think: > > 1) what does 'active' mean? > * total activity > * or recent activity > > Having [1] in mind, I *think* the three most recent active variants makes sense > > 2) what number do we provide for that variant: > a) number of receivers/active tokens that received the last Push message > b) total number of all receivers, in history > c) number of total push messages, per variant > > > Here, I *think* that b) does not make sense, having [1] in mind. I think presenting a) or c) as the number on that "three recent active" variants is a nice info. > > Ok , but imagine this we have 4 variants, A,B,C,D. > They all sent the same messages within the same hour , starting with : > A sends 5000 messages > B sends 100 messages > C sends 15 messages > D sends 50 messages > > > I think messages == receivers ? (I doubt that one variant will send 5k of push messages - I'd try to sue the company for that amount of spam on my phone) > yeah receivers :) > > > The top 3 recent active are B,C and D , it's a bit a pita A do not show up, > > > that's life! :) > > since it was really the more active. > Shall we define active within a period (24 hours ? ) ? > > doesn't make that even more complex ? > Well, not that much I think since we are already going to introduce a new query based on dates. I will take a look. > > > > > > Sebi > > > -Matthias > > > > > > [1] https://issues.jboss.org/browse/AGPUSH-673 > > > On Thu, Jul 31, 2014 at 6:37 PM, Sebastien Blanc wrote: > Hi, > I decided to start a new thread after some discussions we had on a previous thread[1] > > Basically, we are talking about this part of the dashboard : > > > > It appeared that is not really clear what we want to show there, as a side note, the current query behind this is not correct and should change whatever we decide. > > So, what can we show here : > > 1. Show the most (three) recent active variants (and their # of receivers) > Active means here, the 3 latest variants that sent a Push Message. > The term "receivers" can also be confusing , do we want to show : > > 1.a : The number of receivers/active tokens that received the last Push message (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we show 5) ? > 1.b : The total number of receivers/actives tokens of this variant (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we show 15) ? > 1.c : The total number of Push Messages sent (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we show 2). ? > > 2. Show the most active variants (and their # of receivers) > Almost same than 1. but here we look at all the variants even those without an recent activity. > Here again 1.a/1.b or 1.c applies. > > The core question, IMO, is what would be an useful information for the user ? > > Sebi > > > [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/8b90cb94/attachment-0001.html From rhauch at redhat.com Mon Aug 4 13:19:17 2014 From: rhauch at redhat.com (Randall Hauch) Date: Mon, 4 Aug 2014 12:19:17 -0500 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: <53DF99F6.1090604@redhat.com> References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> <53DF99F6.1090604@redhat.com> Message-ID: Perhaps we?re looking at this from different perspectives. It?s great that you guys are trying to better understand DS so that you can compare it to other techniques, including OT. That certainly needs to be done. I guess I was looking at DS from the perspective of how a data service might need to implement it, knowing that the choice of how data sync is ultimately done will be influenced in part by how the data service would implement each approach and the impact on scalability and performance. Perhaps it?s too early to provide my thoughts along those lines. On Aug 4, 2014, at 9:34 AM, Summers Pittman wrote: > I am speaking from the perspective of the algorithm and less from my opinions of the way the system should work as a whole. > > On 08/01/2014 03:02 PM, Randall Hauch wrote: >> I?ve really enjoyed learning about what AeroGear has been doing with data sync. This is a tough problem, but finding a solution is really important. Both data sync POCs appear to use Differential Synchronization, or DS [1]. I was not familiar with the paper until today, but after reading it I do have a few questions/comments. Bear with me; this is a long post. >> >> DS is clearly targeted for use within a collaborative document editor, where there are multiple clients concurrently editing the same document, and at any one time there are a relatively small number of documents being edited; you can get a feel for this by looking at figures 5 and 7 in the paper [1] ? look at the amount of server memory and CPU required to perform DS on just one document being edited by a half-dozen clients. Also, in a collaborative document editor, clients are often continually making changes even as they attempt to synchronize with the server. > It doesn't actually make any claims about CPU or memory usage. A shadow document is needed for each connection. For documents which are infrequently edited, the shadow doc can easily be frozen to disk until an edit comes in. Sure, you don?t have to keep it in memory. But it does have to be in memory to do anything with it in an efficient way. And, yes, you certainly can build a data service that uses this technique. My point was that having multiple copies of a document being edited will reduce the scalability of the data service compared to other techniques. >> >> (It?s interesting that Google Docs, and Google Wave before it, appear to use Operational Transformation [2] rather than DS. OT might also make it easier to implement undo/redo, which works really well in Google Docs.) > That is probably because OT, Docs, and Apache Wave are all older then Diff-sync. OT is also a much more complicated algorithm in my experience (and from browsing around on wikipedia) >> >> An MBaaS or any other database-like service is very different. It has to host multiple applications (i.e., databases), each with multiple collections containing potentially millions of entities (e.g., JSON documents). The entities themselves are more fine-grained and smaller than collaborative documents (though probably a bit coarser-grained and larger than a single record in a RDBMS). Many clients might be reading and updating lots of documents at once, and the data service has to coordinate those changes. A single batch update from one client might request changes to dozens of entities. And the clients can/will always wait for confirmation that the server made the requested changes before continuing (unless the client is offline); or at a minimum can enqueue the requested changes. > Two quick things. A document is just a collection of entities and can be structured to reduce this problem (especially is we are faking it on a RDBMS with particularly sadistic abuses to an ORM). Yes, a document might be a JSON document that is an aggregate of multiple objects, and not just a flat map of key-value pairs. The use of aggregate data structures and denormalization are some of the ways that eventually-consistent data stores work. The goal is to reduce the scope of a set of operations to a single aggregate. Other data stores (like graph and hierarchical databases) require strong consistency and transactions because operations necessarily span multiple objects. But limiting operations to a single aggregate is also quite constraining w/r/t app development, since you can?t always denormalize all data to separate aggregates. So even if a collection (in the MongoDB sense) contains documents that are aggregates of multiple ?entities? (in the Hibernate sense of the word), my point still stands that generally any given JSON document will still be smaller than a document used in a collaborative document editor. Also, I would not be surprised if the sheer number of documents in a MongoDB collection is orders of magnitude larger than the number of documents stored by a collaborative editor app. > Clients don't have to wait for the edits to be merged on the server and the nature of diff-sync gives us batching for free. Hmm? even if you could do it this way, do you not want to be able to give feedback to the user that the changes might not have been accepted/persisted? Do you have some scenarios that describe the kinds of applications you?re considering? I?m wondering if I?m envisioning a different kind of app. >> >> Given these characteristics, using DS within the data service might be extremely expensive in terms of CPU and memory > or it might not be. We need data, use cases, etc to test and see what happens. >> , and difficult for a DS-based service to implement all of the features necessary. > Which features? Features of the algorithm of features of the application? The algorithm is really REALLY simple for what we get out of it. I was referring to features of the data service, and especially how the data service?s implementation can satisfy the difficult non-functional requirements like scalability and performance. While the algorithm might be really simple, that doesn?t mean implementing it on the server is efficient. What I?ve read so far makes me think that it?s could very well be less efficient and scalable than other techniques used in data services. >> First, the data service doesn?t really know which entities are being?edited?; instead, connected clients read entities, make changes locally, then request the service make those changes. > I disagree. The service knows documents which the client has a connection to/active session for. It most certainly knows which entities are being edited. I guess I was hoping that the client can manipulate documents locally without having to coordinate that with the server. Again, I?m concerned about server scalability. >> Secondly, every time a change comes in, to compute the diff the service would have to read the persisted entity; this not only is inefficient, but this also makes it more difficult to scale and handle the concurrency, consistency, atomicity, and serializability guarantees. > See earlier comment about sadistic abuses of an ORM. Yes we have to be aware of the RDB underneath the sync server, but I don't think this is a problem with the algorithm. I agree, it?s not a problem with the algorithm. It?s a problem insofar as it would mandate what the server has to support. >> Thirdly, what would the data service need to do when a client connects and asks for the changes since it was last connected? > Send it the diff of the clients serverside shadow and the server's current document. This diff will get sent to the client, merged with the clients shadow, and the diff of that will get sent back to the server. Repeat until the client is in sync. >> The data service might be able to quickly find out which entities were modified since then, but computing the diffs (relative to the time the client last connected) for all of those changed entities would be very complicated. > It isn?t. Perhaps I should have said ?expensive? rather than ?complicated?. >> It may be easier and better for the data service to record the individual changes (edits) made by each transaction, and then to use that information to compute the effective diffs from some period of time. In fact, these recorded edits might also be useful to implement other features within the data service; see CQRS [3] and [4]. >> >> What is really required by the client when trying to synchronize its data after being disconnected? Assuming the client can say which subset of entities it?s interested in when it reconnects (via some criteria in a subscription), does the client want: >> the new versions of those entities that changed; > No This is actually what a number of MBaaS offerings do, although it?s often hidden by the client SDKs. It may not be ideal because it places more work onto the client SDK, but the benefit is that a good portion of the work is done on the client, and the load on the server is reduced (and scalability increased). It?s also trivially easy for the data service to implement. >> the deltas in the entities; and/or > Yes >> all of the events describing the individual changes made to all of those entities? > No. >> >> It may not matter for clients that don?t allow local offline changes, but what might the preferred approach be for clients that do allow offline changes? Option 1 is clearly the easiest from the perspective of the data service, but options #2 and #3 can certainly be handled. With option #1, can the client do something like DS and maintain copies of each original (unmodified) entity so that it can compute the differences? Does this (perhaps with a journal of edits made while offline) provide enough info for the client to properly merge the local changes, or does the client really need the individual events in #3 so that it can, for example, know that some local changes were made to now-out-date data? > Except in the case of a merge error, the algorithm handles long offline periods with edits just fine. If there is a merge error the user/application will have to manually merge the documents somehow. > > One of the things to keep in mind is on mobile devices the radio is the most expensive thing you can control as an application. Any decision we make should err toward only sending as little data as possible as few times as possible. I completely agree. >> >> Will the same option work for online notifications? After all, it?d be great if the same mechanism was used for data-sync, offline (push) notifications, and online notifications (events). > I don't understand your question. Only that it seems beneficial that the same mechanism be used for ?events" (while connected) and both online and offline data-sync. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/50b6af52/attachment-0001.html From daniel at passos.me Mon Aug 4 18:02:04 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 4 Aug 2014 19:02:04 -0300 Subject: [aerogear-dev] Swift running on iOS 7 / Observations In-Reply-To: References: Message-ID: Awesome explanation. Thanks for that. +1 for not polluting the code -- Passos On Fri, Aug 1, 2014 at 7:47 AM, Christos Vasilakis wrote: > Hi all, > > a heads up on my observations during porting our quickstart app [1] > (Swift port) and making it compatible to also run on iOS 7 too [2]. > Indeed, Swift apps can run on iOS 7 due to the swift-runtime embedded in > the application (and can be observed on the generated app archive [3] ). > > A major obstacle faced is that although you can utilise at runtime a form > of dynamic version check (e.g. respondsToSelector[] ) to decide to call > either iOS 7 or iOS 8 API, the runtime is strict on class loading and fails > even when the code-path that instantiates the class is not executed. > > Let me give you a concrete example. Here is snippet of code that uses > either the new push registration API available in iOS 8 or fails back to > the old one if not: > > -- > if > application.respondsToSelector(Selector("registerUserNotificationSettings:")) > { > let settings = UIUserNotificationSettings(forTypes: .Alert | .Badge | > .Sound, categories: nil) > > UIApplication.sharedApplication().registerUserNotificationSettings(settings) > UIApplication.sharedApplication().registerForRemoteNotifications() > } else { > UIApplication.sharedApplication().registerForRemoteNotificationTypes( > .Badge | .Sound | .Alert) > } > > If your Target build SDK is set to ?Latest (8.0)? (to avoid compilation > error of missing classes) but your deployment target is set to 7.x (to > support older versions) and you have some form of dynamic selection on > runtime (e.g .respondsToSelector[] ), this fails when running on iOS 7 with > a missing symbol: (note that the code path that instantiates > UIUserNotificationSettings is not reached but yet fails at runtime) > > -- > dyld: Symbol not found: _OBJC_CLASS_$_UIUserNotificationSettings > Referenced from: > /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts > Expected in: /System/Library/Frameworks/UIKit.framework/UIKit > in > /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts > -- > > In contrast, the obj-c version of the same code runs fine on iOS 7. > > Apparently this has been observed [4] and some workarounds exist > (basically use an objective-c bridge to workaround it, but that is just a > ?hack'). This is to the fact that the obj-c compiler does some form of > weak-linking the symbols that are only available on later versions than the > deployment target. > > I imagine having the same form of issues when trying to utilise a any new > iOS 8 class that doesn?t exist on iOS 7. For that matter (at least for the > current state of the Swift runtime) i am leading towards not using any > hacks to workaround issues on Swift running on iOS 7. I am sure Apple with > the current pace of dev will come up with techniques, but let?s not pollute > the code for the time being. > > Let me know your thoughts. > > - > Christos > > [1] https://github.com/aerogear/aerogear-push-quickstarts/tree/swift > [2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/swift-ios7 > [3] http://tinyurl.com/swift-runtime > [4] > http://stackoverflow.com/questions/24256583/swift-write-code-for-ios-7-and-8 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/2328e250/attachment.html From daniel at passos.me Mon Aug 4 18:07:45 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 4 Aug 2014 19:07:45 -0300 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> Message-ID: On Fri, Aug 1, 2014 at 10:47 AM, Lucas Holmquist wrote: > Do we want to also rename it. > > the java sender is called( in maven ), ?unifiedpush-java-sender? > > while the node one(in npm) is ?aerogear-sender-client? > > i was thinking the name should probably be ?unifiedpush-sender? or > ?unifiedpush-sender? > I like that +1 for ?unifiedpush-sender? or ?unifiedpush-sender? Or unifiedpush-node-sender > what do others think? > > > On Aug 1, 2014, at 8:48 AM, Lucas Holmquist wrote: > > :), do we a JIRA, i can whip something up for a guide > On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf wrote: > > Whenever Luke is ready ? :) > > > > On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira > wrote: > >> +1 >> >> When? >> >> On 2014-08-01, Sebastien Blanc wrote: >> > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf > > >> > wrote: >> > >> > > Hi there, >> > > >> > > a few questions: >> > > >> > > * based on >> > > >> > > >> https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 >> > > >> > > should we do a new release of the node.js sender ? >> > > >> > yes >> > >> > > >> > > * going over the docs, do we have 'guide' or so that we can link here: >> > > >> > > >> http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials >> > > >> > not that I'm aware of but we could link (for now) to the README of the >> > github which contains instructions. >> > >> > > >> > > >> > > Thanks! >> > > Matthias >> > > >> > > -- >> > > Matthias Wessendorf >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/e32a4337/attachment.html From daniel at passos.me Mon Aug 4 18:18:11 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 4 Aug 2014 19:18:11 -0300 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: <71D8CDD4-373B-4BD2-89AA-4432641C4E2E@redhat.com> Message-ID: +1 On Fri, Aug 1, 2014 at 10:19 AM, Matthias Wessendorf wrote: > here we go: > > https://github.com/aerogear/aerogear.org/pull/343 > > > On Fri, Aug 1, 2014 at 2:47 PM, Lucas Holmquist > wrote: > >> ++ sounds/looks good >> On Aug 1, 2014, at 12:35 AM, Matthias Wessendorf >> wrote: >> >> Hi team, >> >> based on [1] I thought about our release timelines until 1.0.0.Final, and >> shortly after. >> >> - >> >> 1.0.0.Beta2 >> : >> 07/Aug/14 >> >> This needs to include Keycloak-beta4, and might slip by one day, but not >> much more of a delay. >> >> *Please note:* There is already works going on to have our parent and >> UPS working w/ beta4 - it?s just a matter of merging the branch, once the >> release is out. >> >> Number of open JIRAs for this release is looking good! >> >> - >> >> 1.0.0 >> : >> 18/Aug/14 >> >> *Keycloak:* This will use keycloak?s beta4 as well, unless we find >> BLOCKERS in their beta4... (As said before KC is mostly hidden inside the >> server, and we can not wait for their 1.0.0.Final in September) >> >> This release will be mostly around docs and perhaps some more UX review >> of the quickstart demos. It is possible that the UX review does not happen. >> >> *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush >> Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives >> us one week of deep testing (of server, docs, demos) before the final >> release. >> >> Next: *celebrate*!!!!!!!! [image: :tada:] >> >> After the 1.0.0.Final of UPS, I?d suggest a two week-based release series >> of small fixes and improvements, as well as taking up new Keycloak releases >> >> - >> >> 1.0.1 >> : >> 01/Sep/14 >> >> *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few items >> from the JIRA. >> >> - >> >> 1.0.2 >> : >> 15/Sep/14 >> >> *Keycloak:* main reason is pick-up of their 1.0.0.Final >> >> - >> >> 1.0.3 >> >> :29/Sep/14 >> >> Might not be needed - but added it to JIRA, just in case? >> >> Let me know your thoughts and I will update the roadmap! >> >> -Matthias >> >> [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/17aca1eb/attachment-0001.html From daniel at passos.me Mon Aug 4 19:18:31 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 4 Aug 2014 20:18:31 -0300 Subject: [aerogear-dev] Swift - Frameworks/Static libs and Cocoapods In-Reply-To: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> References: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> Message-ID: Another awesome explanation. Thanks for the heads-up and teach me a little more about the about the new swift world -- Passos On Tue, Jul 22, 2014 at 5:09 AM, Christos Vasilakis wrote: > Hi all, > > want to give a heads up on the current status of Swift frameworks/static > libs generation and cocoapods support. This is based on the current state > of affairs, as in Xcode beta 4 (released yesterday). > > Note: "Since rapid developments are taking place, will update this thread > as more information becomes available and with any breaking changes" > > First, let me start by making three observations: > > a) quoting Apple release notes[1], "Xcode does not support building static > libraries that include Swift code?. You can notice that in Xcode 6 when > choosing ?Cocoa Touch Static Library? there is no option to select ?Swift? > as the preferred language. > > b) new in Xcode 6 is the generation of ?dynamic? frameworks for library > targets. The reason for ?dynamic? linking, as explained by apple in [2], is > to enable the new functionality in iOS 8 called ?extensions?. Per apple > quote "Frameworks work perfectly with extensions, sharing logic that can be > used by both the main application, and the bundled extensions? > > c) Dynamic framework for a swift library (the only option offered by > Xcode) , in the current state requires the source code of the library to be > build together with the app that uses it. This is due to the binary > interface, which has not being finalised yet. Quoting apple blog [3] > ("Binary Compatibility and Frameworks? section): > > ? > "While your app?s runtime compatibility is ensured, the Swift language > itself will continue to evolve, and the binary interface will also change. > To be safe, all components of your app should be built with the same > version of Xcode and the Swift compiler to ensure that they work together. > > This means that frameworks need to be managed carefully. For instance, if > your project uses frameworks to share code with an embedded extension, you > will want to build the frameworks, app, and extensions together. It would > be dangerous to rely upon binary frameworks that use Swift ? especially > from third parties. As Swift changes, those frameworks will be incompatible > with the rest of your app. When the binary interface stabilizes in a year > or two, the Swift runtime will become part of the host OS and this > limitation will no longer exist.? > ? > > What does all that gives us? > In plain form, "Distribution of the push-sdk (swift port) should be done > in source form with polished documentation on how the user can add it to > their own project.? > > Already, looking at the various swift-libs currently in existence[4], that > is the current approach, a well-written README.md on how the user can add > the library dependency into their own projects. For example, something like > the section ?How to Install Library? found here [5] > > As for cocoapods, currently no support is provided for swift projects. > There is an on-going discussion on the issues list found here [6] on how to > effectively support ?dynamic framework? for swift projects, and still keep > backwards compatibility, but things are not yet finalised. > > Let me know your thoughts / comments. > > Thanks, > Christos > > [1] > http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf > [2] > https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14 > [3] https://developer.apple.com/swift/blog/?id=2 > [4] http://www.swifttoolbox.io > [5] https://github.com/Quick/Quick > [6] https://github.com/CocoaPods/CocoaPods/issues/2272 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/5b404ddd/attachment.html From supittma at redhat.com Mon Aug 4 21:05:11 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 04 Aug 2014 21:05:11 -0400 Subject: [aerogear-dev] Swift running on iOS 7 / Observations In-Reply-To: References: Message-ID: <53E02DC7.3020709@redhat.com> On 08/01/2014 06:47 AM, Christos Vasilakis wrote: > Hi all, > > a heads up on my observations during porting our quickstart app [1] (Swift port) and making it compatible to also run on iOS 7 too [2]. Indeed, Swift apps can run on iOS 7 due to the swift-runtime embedded in the application (and can be observed on the generated app archive [3] ). > > A major obstacle faced is that although you can utilise at runtime a form of dynamic version check (e.g. respondsToSelector[] ) to decide to call either iOS 7 or iOS 8 API, the runtime is strict on class loading and fails even when the code-path that instantiates the class is not executed. > > Let me give you a concrete example. Here is snippet of code that uses either the new push registration API available in iOS 8 or fails back to the old one if not: > > -- > if application.respondsToSelector(Selector("registerUserNotificationSettings:")) { > let settings = UIUserNotificationSettings(forTypes: .Alert | .Badge | .Sound, categories: nil) > UIApplication.sharedApplication().registerUserNotificationSettings(settings) > UIApplication.sharedApplication().registerForRemoteNotifications() > } else { > UIApplication.sharedApplication().registerForRemoteNotificationTypes( .Badge | .Sound | .Alert) > } > > If your Target build SDK is set to ?Latest (8.0)? (to avoid compilation error of missing classes) but your deployment target is set to 7.x (to support older versions) and you have some form of dynamic selection on runtime (e.g .respondsToSelector[] ), this fails when running on iOS 7 with a missing symbol: (note that the code path that instantiates UIUserNotificationSettings is not reached but yet fails at runtime) > > -- > dyld: Symbol not found: _OBJC_CLASS_$_UIUserNotificationSettings > Referenced from: /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts > Expected in: /System/Library/Frameworks/UIKit.framework/UIKit > in /var/mobile/Applications/E8C53BD1-285E-4DDD-B71C-C99D61195671/Contacts.app/Contacts > -- > > In contrast, the obj-c version of the same code runs fine on iOS 7. > > Apparently this has been observed [4] and some workarounds exist (basically use an objective-c bridge to workaround it, but that is just a ?hack'). This is to the fact that the obj-c compiler does some form of weak-linking the symbols that are only available on later versions than the deployment target. > > I imagine having the same form of issues when trying to utilise a any new iOS 8 class that doesn?t exist on iOS 7. For that matter (at least for the current state of the Swift runtime) i am leading towards not using any hacks to workaround issues on Swift running on iOS 7. I am sure Apple with the current pace of dev will come up with techniques, but let?s not pollute the code for the time being. > > Let me know your thoughts.\ +1 don't pollute the code. Wait for Apple to show the way or for a better "hack" to emerge. > > - > Christos > > [1] https://github.com/aerogear/aerogear-push-quickstarts/tree/swift > [2] https://github.com/cvasilak/aerogear-push-quickstarts/tree/swift-ios7 > [3] http://tinyurl.com/swift-runtime > [4] http://stackoverflow.com/questions/24256583/swift-write-code-for-ios-7-and-8 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From supittma at redhat.com Mon Aug 4 21:17:01 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 04 Aug 2014 21:17:01 -0400 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> <53DF99F6.1090604@redhat.com> Message-ID: <53E0308D.2050103@redhat.com> On Mon 04 Aug 2014 01:19:17 PM EDT, Randall Hauch wrote: > Perhaps we?re looking at this from different perspectives. It?s great > that you guys are trying to better understand DS so that you can > compare it to other techniques, including OT. That certainly needs to > be done. I guess I was looking at DS from the perspective of how a > data service might need to implement it, knowing that the choice of > how data sync is ultimately done will be influenced in part by how the > data service would implement each approach and the impact on > scalability and performance. Perhaps it?s too early to provide my > thoughts along those lines. > > On Aug 4, 2014, at 9:34 AM, Summers Pittman > wrote: > >> I am speaking from the perspective of the algorithm and less from my >> opinions of the way the system should work as a whole. >> >> On 08/01/2014 03:02 PM, Randall Hauch wrote: >>> I?ve really enjoyed learning about what AeroGear has been doing with >>> data sync. This is a tough problem, but finding a solution is really >>> important. Both data sync POCs appear to use Differential >>> Synchronization, or DS [1]. I was not familiar with the paper until >>> today, but after reading it I do have a few questions/comments. Bear >>> with me; this is a long post. >>> >>> DS is clearly targeted for use within a collaborative document >>> editor, where there are multiple clients concurrently editing the >>> same document, and at any one time there are a relatively small >>> number of documents being edited; you can get a feel for this by >>> looking at figures 5 and 7 in the paper [1] ? look at the amount of >>> server memory and CPU required to perform DS on just one document >>> being edited by a half-dozen clients. Also, in a collaborative >>> document editor, clients are often continually making changes even >>> as they attempt to synchronize with the server. >> It doesn't actually make any claims about CPU or memory usage. A >> shadow document is needed for each connection. For documents which >> are infrequently edited, the shadow doc can easily be frozen to disk >> until an edit comes in. > > Sure, you don?t have to keep it in memory. But it does have to be in > memory to do anything with it in an efficient way. And, yes, you > certainly can build a data service that uses this technique. My point > was that having multiple copies of a document being edited will reduce > the scalability of the data service compared to other techniques. > >>> >>> (It?s interesting that Google Docs, and Google Wave before it, >>> appear to use Operational Transformation [2] rather than DS. OT >>> might also make it easier to implement undo/redo, which works really >>> well in Google Docs.) >> That is probably because OT, Docs, and Apache Wave are all older then >> Diff-sync. OT is also a much more complicated algorithm in my >> experience (and from browsing around on wikipedia) >>> >>> An MBaaS or any other database-like service is very different. It >>> has to host multiple applications (i.e., databases), each with >>> multiple collections containing potentially millions of entities >>> (e.g., JSON documents). The entities themselves are more >>> fine-grained and smaller than collaborative documents (though >>> probably a bit coarser-grained and larger than a single record in a >>> RDBMS). Many clients might be reading and updating lots of documents >>> at once, and the data service has to coordinate those changes. A >>> single batch update from one client might request changes to dozens >>> of entities. And the clients can/will always wait for confirmation >>> that the server made the requested changes before continuing (unless >>> the client is offline); or at a minimum can enqueue the requested >>> changes. >> Two quick things. A document is just a collection of entities and >> can be structured to reduce this problem (especially is we are faking >> it on a RDBMS with particularly sadistic abuses to an ORM). > > Yes, a document might be a JSON document that is an aggregate of > multiple objects, and not just a flat map of key-value pairs. The use > of aggregate data structures and denormalization are some of the ways > that eventually-consistent data stores work. The goal is to reduce the > scope of a set of operations to a single aggregate. Other data stores > (like graph and hierarchical databases) require strong consistency and > transactions because operations necessarily span multiple objects. But > limiting operations to a single aggregate is also quite constraining > w/r/t app development, since you can?t always denormalize all data to > separate aggregates. > > So even if a collection (in the MongoDB sense) contains documents that > are aggregates of multiple ?entities? (in the Hibernate sense of the > word), my point still stands that generally any given JSON document > will still be smaller than a document used in a collaborative document > editor. Also, I would not be surprised if the sheer number of > documents in a MongoDB collection is orders of magnitude larger than > the number of documents stored by a collaborative editor app. > >> Clients don't have to wait for the edits to be merged on the server >> and the nature of diff-sync gives us batching for free. > > Hmm? even if you could do it this way, do you not want to be able to > give feedback to the user that the changes might not have been > accepted/persisted? > > Do you have some scenarios that describe the kinds of applications > you?re considering? I?m wondering if I?m envisioning a different kind > of app. > >>> >>> Given these characteristics, using DS within the data service might >>> be extremely expensive in terms of CPU and memory >> or it might not be. We need data, use cases, etc to test and see >> what happens. >>> , and difficult for a DS-based service to implement all of the >>> features necessary. >> Which features? Features of the algorithm of features of the >> application? The algorithm is really REALLY simple for what we get >> out of it. > > I was referring to features of the data service, and especially how > the data service?s implementation can satisfy the difficult > non-functional requirements like scalability and performance. While > the algorithm might be really simple, that doesn?t mean implementing > it on the server is efficient. What I?ve read so far makes me think > that it?s could very well be less efficient and scalable than other > techniques used in data services. > >>> First, the data service doesn?t really know which entities are >>> being?edited?; instead, connected clients read entities, make >>> changes locally, then request the service make those changes. >> I disagree. The service knows documents which the client has a >> connection to/active session for. It most certainly knows which >> entities are being edited. > > I guess I was hoping that the client can manipulate documents locally > without having to coordinate that with the server. Again, I?m > concerned about server scalability. > >>> Secondly, every time a change comes in, to compute the diff the >>> service would have to read the persisted entity; this not only is >>> inefficient, but this also makes it more difficult to scale and >>> handle the concurrency, consistency, atomicity, and serializability >>> guarantees. >> See earlier comment about sadistic abuses of an ORM. Yes we have to >> be aware of the RDB underneath the sync server, but I don't think >> this is a problem with the algorithm. > > I agree, it?s not a problem with the algorithm. It?s a problem insofar > as it would mandate what the server has to support. > >>> Thirdly, what would the data service need to do when a client >>> connects and asks for the changes since it was last connected? >> Send it the diff of the clients serverside shadow and the server's >> current document. This diff will get sent to the client, merged with >> the clients shadow, and the diff of that will get sent back to the >> server. Repeat until the client is in sync. >>> The data service might be able to quickly find out which entities >>> were modified since then, but computing the diffs (relative to the >>> time the client last connected) for all of those changed entities >>> would be very complicated. >> It isn?t. > > Perhaps I should have said ?expensive? rather than ?complicated?. > >>> It may be easier and better for the data service to record the >>> individual changes (edits) made by each transaction, and then to use >>> that information to compute the effective diffs from some period of >>> time. In fact, these recorded edits might also be useful to >>> implement other features within the data service; see CQRS [3] and [4]. >>> >>> What is really required by the client when trying to synchronize its >>> data after being disconnected? Assuming the client can say which >>> subset of entities it?s interested in when it reconnects (via some >>> criteria in a subscription), does the client want: >>> >>> 1. the new versions of those entities that changed; >> No > > This is actually what a number of MBaaS offerings do, although it?s > often hidden by the client SDKs. It may not be ideal because it places > more work onto the client SDK, but the benefit is that a good portion > of the work is done on the client, and the load on the server is > reduced (and scalability increased). It?s also trivially easy for the > data service to implement. > >>> 1. the deltas in the entities; and/or >> Yes >>> >>> 1. all of the events describing the individual changes made to all >>> of those entities? >> No. >>> >>> It may not matter for clients that don?t allow local offline >>> changes, but what might the preferred approach be for clients that >>> do allow offline changes? Option 1 is clearly the easiest from the >>> perspective of the data service, but options #2 and #3 can certainly >>> be handled. With option #1, can the client do something like DS and >>> maintain copies of each original (unmodified) entity so that it can >>> compute the differences? Does this (perhaps with a journal of edits >>> made while offline) provide enough info for the client to properly >>> merge the local changes, or does the client really need the >>> individual events in #3 so that it can, for example, know that some >>> local changes were made to now-out-date data? >> Except in the case of a merge error, the algorithm handles long >> offline periods with edits just fine. If there is a merge error the >> user/application will have to manually merge the documents somehow. >> >> One of the things to keep in mind is on mobile devices the radio is >> the most expensive thing you can control as an application. Any >> decision we make should err toward only sending as little data as >> possible as few times as possible. > > I completely agree. > >>> >>> Will the same option work for online notifications? After all, it?d >>> be great if the same mechanism was used for data-sync, offline >>> (push) notifications, and online notifications (events). >> I don't understand your question. > > Only that it seems beneficial that the same mechanism be used for > ?events" (while connected) and both online and offline data-sync. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev I don't think it is too early for service minded people to point out the big honking problems we will face. At the very least it helps us figure out the use cases we will support for the initial releases as to POC morphs into an actual project. From a mobile client developer perspective, this algorithm feels very easy to understand and it handles a lot of annoying corner cases very well (e.g. offline, operation batching, conflict handling, document synchronization, collaboration etc.) . Additionally, in my experiments, plugging in different diff-merge-synch operations allows for the general framework to be adapted to other use cases and data types. (i.e. if the server is just batching a list of changed Object IDs instead of the actual changes for binary files). One of the things we need to do is determine which problems we are going to solve/support (single user multi device sync, multi user collaboration, binary files etc), which we are going to short circuit (limiting numbers of collaborators, limiting file size, etc), and which we are just going to document as best practices to use or to avoid. Maybe I'm just stuck seeing my hammer (DS) and everything is nails and if someone can give a demo of something else (OT, etc) then I will be really interested to compare. -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From daniel.bevenius at gmail.com Mon Aug 4 23:37:24 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 5 Aug 2014 05:37:24 +0200 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> Message-ID: +1 for 'unifiedpush-node-sender' tisdag 5 augusti 2014 skrev Daniel Passos : > On Fri, Aug 1, 2014 at 10:47 AM, Lucas Holmquist > wrote: > >> Do we want to also rename it. >> >> the java sender is called( in maven ), ?unifiedpush-java-sender? >> >> while the node one(in npm) is ?aerogear-sender-client? >> >> i was thinking the name should probably be ?unifiedpush-sender? or >> ?unifiedpush-sender? >> > > I like that > > +1 for ?unifiedpush-sender? or ?unifiedpush-sender? > > Or unifiedpush-node-sender > > >> what do others think? >> >> >> On Aug 1, 2014, at 8:48 AM, Lucas Holmquist > > wrote: >> >> :), do we a JIRA, i can whip something up for a guide >> On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf > > wrote: >> >> Whenever Luke is ready ? :) >> >> >> >> On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira > > wrote: >> >>> +1 >>> >>> When? >>> >>> On 2014-08-01, Sebastien Blanc wrote: >>> > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf < >>> matzew at apache.org > >>> > wrote: >>> > >>> > > Hi there, >>> > > >>> > > a few questions: >>> > > >>> > > * based on >>> > > >>> > > >>> https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 >>> > > >>> > > should we do a new release of the node.js sender ? >>> > > >>> > yes >>> > >>> > > >>> > > * going over the docs, do we have 'guide' or so that we can link >>> here: >>> > > >>> > > >>> http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials >>> > > >>> > not that I'm aware of but we could link (for now) to the README of the >>> > github which contains instructions. >>> > >>> > > >>> > > >>> > > Thanks! >>> > > Matthias >>> > > >>> > > -- >>> > > Matthias Wessendorf >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/8f913c55/attachment.html From cvasilak at gmail.com Tue Aug 5 00:56:13 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 5 Aug 2014 07:56:13 +0300 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> Message-ID: <81D7DE6C-92EA-4642-84B2-F0FAEEC89135@gmail.com> On Aug 5, 2014, at 6:37 AM, Daniel Bevenius wrote: > +1 for 'unifiedpush-node-sender? +1 for 'unifiedpush-node-sender? too > > tisdag 5 augusti 2014 skrev Daniel Passos : > On Fri, Aug 1, 2014 at 10:47 AM, Lucas Holmquist wrote: > Do we want to also rename it. > > the java sender is called( in maven ), ?unifiedpush-java-sender? > > while the node one(in npm) is ?aerogear-sender-client? > > i was thinking the name should probably be ?unifiedpush-sender? or ?unifiedpush-sender? > > I like that > > +1 for ?unifiedpush-sender? or ?unifiedpush-sender? > > Or unifiedpush-node-sender > > what do others think? > > > On Aug 1, 2014, at 8:48 AM, Lucas Holmquist wrote: > >> :), do we a JIRA, i can whip something up for a guide >> On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf wrote: >> >>> Whenever Luke is ready ? :) >>> >>> >>> >>> On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira wrote: >>> +1 >>> >>> When? >>> >>> On 2014-08-01, Sebastien Blanc wrote: >>> > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf >>> > wrote: >>> > >>> > > Hi there, >>> > > >>> > > a few questions: >>> > > >>> > > * based on >>> > > >>> > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 >>> > > >>> > > should we do a new release of the node.js sender ? >>> > > >>> > yes >>> > >>> > > >>> > > * going over the docs, do we have 'guide' or so that we can link here: >>> > > >>> > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials >>> > > >>> > not that I'm aware of but we could link (for now) to the README of the >>> > github which contains instructions. >>> > >>> > > >>> > > >>> > > Thanks! >>> > > Matthias >>> > > >>> > > -- >>> > > Matthias Wessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/b5a81ac0/attachment.html From matzew at apache.org Tue Aug 5 02:45:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 5 Aug 2014 08:45:06 +0200 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released Message-ID: FYI https://twitter.com/apachecordova/status/496418463666028545 Wondering, should we update the plugin ? -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/e37662e3/attachment.html From kpiwko at redhat.com Tue Aug 5 04:04:14 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 05 Aug 2014 08:06:14 +0002 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: References: Message-ID: <1407225854.2790.1@smtp.corp.redhat.com> +1 for updating. On Tue, Aug 5, 2014 at 8:45 AM, Matthias Wessendorf wrote: > FYI > > https://twitter.com/apachecordova/status/496418463666028545 > > Wondering, should we update the plugin ? > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf From edewit at redhat.com Tue Aug 5 04:26:53 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 5 Aug 2014 10:26:53 +0200 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: <1407225854.2790.1@smtp.corp.redhat.com> References: <1407225854.2790.1@smtp.corp.redhat.com> Message-ID: <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> We had this discussion before and I still feel that this course of action is wrong. It?s like let?s update the java library that we created when there is a security error in java. All people have to do is to use the newer version of the android platform (if they are currently using 3.5.0) cordova platform add android at 3.5.1 On 5 Aug,2014, at 10:04 , Karel Piwko wrote: > +1 for updating. > > On Tue, Aug 5, 2014 at 8:45 AM, Matthias Wessendorf > wrote: >> FYI >> >> https://twitter.com/apachecordova/status/496418463666028545 >> >> Wondering, should we update the plugin ? >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/553fe13a/attachment-0001.html From matzew at apache.org Tue Aug 5 04:30:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 5 Aug 2014 10:30:08 +0200 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> References: <1407225854.2790.1@smtp.corp.redhat.com> <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> Message-ID: how about adding some notes on the README ? On Tue, Aug 5, 2014 at 10:26 AM, Erik Jan de Wit wrote: > We had this discussion before and I still feel that this course of action > is wrong. It?s like let?s update the java library that we created when > there is a security error in java. > > All people have to do is to use the newer version of the android platform > (if they are currently using 3.5.0) > > cordova platform add android at 3.5.1 > > > > On 5 Aug,2014, at 10:04 , Karel Piwko wrote: > > +1 for updating. > > On Tue, Aug 5, 2014 at 8:45 AM, Matthias Wessendorf > wrote: > > FYI > > https://twitter.com/apachecordova/status/496418463666028545 > > Wondering, should we update the plugin ? > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/9c113fbd/attachment.html From kpiwko at redhat.com Tue Aug 5 04:42:33 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 05 Aug 2014 08:44:33 +0002 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> References: <1407225854.2790.1@smtp.corp.redhat.com> <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> Message-ID: <1407228153.2790.2@smtp.corp.redhat.com> In such case, would it make sense to lock Cordova related versions in our tutorials/quickstarts/documentation and update versions there after security bug instead? On Tue, Aug 5, 2014 at 10:26 AM, Erik Jan de Wit wrote: > We had this discussion before and I still feel that this course of > action is wrong. It?s like let?s update the java library that we > created when there is a security error in java. > > All people have to do is to use the newer version of the android > platform (if they are currently using 3.5.0) > > cordova platform add android at 3.5.1 > > > On 5 Aug,2014, at 10:04 , Karel Piwko wrote: > >> +1 for updating. >> >> On Tue, Aug 5, 2014 at 8:45 AM, Matthias Wessendorf >> >> wrote: >>> FYI >>> >>> https://twitter.com/apachecordova/status/496418463666028545 >>> >>> Wondering, should we update the plugin ? >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > From keith at kdmooreconsulting.com Tue Aug 5 04:48:21 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Tue, 5 Aug 2014 01:48:21 -0700 (PDT) Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> Message-ID: <1407228501135-8730.post@n5.nabble.com> Not to split hairs but the Java Sender library names are as follows: GitHub: aerogear-unifiedpush-java-client Maven: unifiedpush-java-client Jira: UnifiedPush-java-sender -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UPS-Misc-Node-js-sender-tp8681p8730.html Sent from the aerogear-dev mailing list archive at Nabble.com. From edewit at redhat.com Tue Aug 5 04:48:46 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 5 Aug 2014 10:48:46 +0200 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: <1407228153.2790.2@smtp.corp.redhat.com> References: <1407225854.2790.1@smtp.corp.redhat.com> <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> <1407228153.2790.2@smtp.corp.redhat.com> Message-ID: <49715152-A001-4C4F-9915-DEF10DA37289@redhat.com> On 5 Aug,2014, at 10:42 , Karel Piwko wrote: > In such case, would it make sense to lock Cordova related versions in > our tutorials/quickstarts/documentation and update versions there after > security bug instead? > When you tryout / install our demo now you?ll get the latest version of the android platform (3.5.1) this security update is ?only? important if you have a project currently on your drive then you?ll have to update the android platform From matzew at apache.org Tue Aug 5 05:51:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 5 Aug 2014 11:51:43 +0200 Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> Message-ID: Hello, based on your feedback, we did some overhaul on our RESTful APIs: http://aerogear.org/docs/specs/aerogear-unifiedpush-rest/overview-index.html On Thu, Jul 24, 2014 at 10:01 PM, bradrickcarter wrote: > BTW - you asked why I put brackets around the credentials, its in your > docs. it may be common knowledge not to do that but I was having such a > hard time making it work I thought I would follow the docs to a T. > > http://aerogear.org/docs/specs/aerogear-push-messages/ > > curl -3 -u "{PushApplicationID}:{MasterSecret}" -v -H "Accept: > application/json" -H "Content-type: application/json" -X POST -d '{ > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", > "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], "alias" : ["user at account.com", > "someone at aerogear.org", ....], "categories" : ["someCategory", > "otherCategory"], "deviceType" : ["iPad", "AndroidTablet"], "ttl" : 3600, > "message": { "alert":"HELLO!", "sound":"default", "badge":7, > "content-available" : true, "someKey":"some value", > "anotherCustomKey":"some other value" }, "simple-push": "version=123" }' href="https://SERVER:PORT/CONTEXT/rest/sender">https://SERVER:PORT > /CONTEXT/rest/sender > > On Jul 24, 2014, at 1:40 PM, Matthias Wessendorf [via aerogear-dev] <[hidden > email] > wrote: > > You should have received a message :-) > > > here is my curl: > > curl -3 -u > "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" > -v -H "Accept: application/json" -H "Content-type: application/json" -X > POST -d '{"message": {"alert":"This is a test push from > cURL","sound":"default","badge":7,"content-available" : true}}' > https://push-1127studios.rhcloud.com/ag-push/rest/sender > > > I removed the {} from the applicationID and from the masterSecret as well. > > I wonder, why did you enter these {} around the credentials ? > > > > > > > On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter < href="x-msg://9/user/SendEmail.jtp?type=node&node=8521&i=0" > target="_top" rel="nofollow" link="external">[hidden email]> wrote: > >> Hi Matthias, >> >> Yes, the "Send Push" dialog works on the server. >> >> I had a typo in my url but I am now getting a 401 Unauthorized. curl >> request below; >> >> curl -3 -u >> "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" >> -v -H "Accept: application/json" -H "Content-type: application/json" -X >> POST -d '{"message": {"alert":"This is a test push from >> cURL","sound":"default","badge":7,"content-available" : true}}' >> https://push-1127studios.rhcloud.com/ag-push/rest/sender >> >> >> Thank you! >> >> >> On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden >> email] > wrote: >> >> >> >> >> On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=0" >> target="_top" rel="nofollow" link="external">[hidden email]> wrote: >> >>> First I'd like to say I spent about 3 days trying to get the push plugin >>> to >>> work in my cordova project (pulled out all of my hair!). I finally got it >>> working and I am able to push to iOS and Android. The issue is I can only >>> push messages from the Aerogear Push server on OpenSift. I have tried all >>> day to send a message using the rest end-points with cURL and Ajax. I >>> have >>> no more hair to pull out. >>> >>> I have used the following urls to send and none work; >>> >>> https://push-1127studios.rhcloud.com/ag-push/rest/sender >>> returns - HTTP/1.1 400 Bad Request >>> >> >> Can share the CURL that cause the 400 ? >> I bet there is some tiny error on the actual CURL/JSON >> >> PS: Does the "Send Push" dialog work? The Server has a little page to >> actually send messags >> >> -M >> >> >>> >>> https://push-1127studios.rhcloud.com/rest/sender >>> returns - HTTP/1.1 404 Not Found >>> >>> I have double checked my applicationID and master secret but nothing is >>> working. >>> >>> Help! >>> please... >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >>> Sent from the aerogear-dev mailing list archive at Nabble.com >>> . >>> _______________________________________________ >>> aerogear-dev mailing list >>> x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=1" >>> target="_top" rel="nofollow" link="external">[hidden email] >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=2" >> target="_top" rel="nofollow" link="external">[hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html >> To unsubscribe from push sender rest not working for me, click here. >> NAML >> >> >> >> >> ------------------------------ >> View this message in context: Re: [aerogear-dev] push sender rest not >> working for me >> >> >> Sent from the aerogear-dev mailing list archive >> at Nabble.com. >> >> _______________________________________________ >> aerogear-dev mailing list >> > target="_top" rel="nofollow" link="external">[hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > target="_top" rel="nofollow" link="external">[hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8521.html > To unsubscribe from push sender rest not working for me, click here. > NAML > > > > > ------------------------------ > View this message in context: Re: [aerogear-dev] push sender rest not > working for me > > Sent from the aerogear-dev mailing list archive > at Nabble.com. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/095ee59f/attachment-0001.html From bruno at abstractj.org Tue Aug 5 07:22:37 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 5 Aug 2014 08:22:37 -0300 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: References: Message-ID: <20140805112237.GA39880@abstractj.org> Please! On 2014-08-05, Matthias Wessendorf wrote: > FYI > > https://twitter.com/apachecordova/status/496418463666028545 > > Wondering, should we update the plugin ? > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Aug 5 07:25:35 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 5 Aug 2014 08:25:35 -0300 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> References: <1407225854.2790.1@smtp.corp.redhat.com> <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> Message-ID: <20140805112535.GB39880@abstractj.org> On 2014-08-05, Erik Jan de Wit wrote: > We had this discussion before and I still feel that this course of action is wrong. It?s like let?s update the java library that we created when there is a security error in java. That **must** be the correct approach, most part of the time the cause of people exploiting security vulnerabilities is because the software is outdated. Do you want to engage our developers to ignore it? > > All people have to do is to use the newer version of the android platform (if they are currently using 3.5.0) > > cordova platform add android at 3.5.1 I still disagree on that, we must lead by example and encourage them to update their versions. > > > On 5 Aug,2014, at 10:04 , Karel Piwko wrote: > > > +1 for updating. > > > > On Tue, Aug 5, 2014 at 8:45 AM, Matthias Wessendorf > > wrote: > >> FYI > >> > >> https://twitter.com/apachecordova/status/496418463666028545 > >> > >> Wondering, should we update the plugin ? > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From edewit at redhat.com Tue Aug 5 07:34:50 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 5 Aug 2014 13:34:50 +0200 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: <20140805112535.GB39880@abstractj.org> References: <1407225854.2790.1@smtp.corp.redhat.com> <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> <20140805112535.GB39880@abstractj.org> Message-ID: <652C0D77-2C66-4F8F-A138-AAE4CF4A730C@redhat.com> On 5 Aug,2014, at 13:25 , Bruno Oliveira wrote: > On 2014-08-05, Erik Jan de Wit wrote: >> We had this discussion before and I still feel that this course of action is wrong. It?s like let?s update the java library that we created when there is a security error in java. > > That **must** be the correct approach, most part of the time the cause > of people exploiting security vulnerabilities is because the software is > outdated. Do you want to engage our developers to ignore it? It?s not cordova itself that is vulnerable it?s one particular version of a platform ( 3.5.0 android ). I?m not saying that people should ignore security, just that we use a runtime and we cannot be held responsible or control what version of that runtime people are using -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/3ed9fc97/attachment.html From tolisemm at gmail.com Tue Aug 5 07:57:56 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Tue, 5 Aug 2014 14:57:56 +0300 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: <652C0D77-2C66-4F8F-A138-AAE4CF4A730C@redhat.com> References: <1407225854.2790.1@smtp.corp.redhat.com> <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> <20140805112535.GB39880@abstractj.org> <652C0D77-2C66-4F8F-A138-AAE4CF4A730C@redhat.com> Message-ID: 2014-08-05 14:34 GMT+03:00 Erik Jan de Wit : > > It?s not cordova itself that is vulnerable it?s one particular version of > a platform ( 3.5.0 android ). I?m not saying that people should ignore > security, just that we use a runtime and we cannot be held responsible or > control what version of that runtime people are using > > +1 I think it's users responsiblity to upgrade or not. Also, it looks like Apache is not enforcing the latest cordova version in their plugins e.g https://github.com/apache/cordova-plugin-statusbar/blob/master/plugin.xml#L32 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/cd6ed3d6/attachment.html From matzew at apache.org Tue Aug 5 08:00:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 5 Aug 2014 14:00:55 +0200 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: <71D8CDD4-373B-4BD2-89AA-4432641C4E2E@redhat.com> Message-ID: There might be a little delay, when we can release our own 1.0.0.Final, since I found a KC bug that occurs only w/ MySQL and EAP 6.3.Beta: http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002388.html In case this fix makes it into Keycloak's RC-1 (instead of beta-4 - which seems reasonable to me), we should be waiting a few more days to pick up their RC-1 in our final. That means we could release the same week (e.g. 22nd), or exactly one week later - on 25th of August. Things are being discussed atm, this is just a heads-up ... -Matthias On Fri, Aug 1, 2014 at 3:19 PM, Matthias Wessendorf wrote: > here we go: > > https://github.com/aerogear/aerogear.org/pull/343 > > > On Fri, Aug 1, 2014 at 2:47 PM, Lucas Holmquist > wrote: > >> ++ sounds/looks good >> On Aug 1, 2014, at 12:35 AM, Matthias Wessendorf >> wrote: >> >> Hi team, >> >> based on [1] I thought about our release timelines until 1.0.0.Final, and >> shortly after. >> >> - >> >> 1.0.0.Beta2 >> : >> 07/Aug/14 >> >> This needs to include Keycloak-beta4, and might slip by one day, but not >> much more of a delay. >> >> *Please note:* There is already works going on to have our parent and >> UPS working w/ beta4 - it?s just a matter of merging the branch, once the >> release is out. >> >> Number of open JIRAs for this release is looking good! >> >> - >> >> 1.0.0 >> : >> 18/Aug/14 >> >> *Keycloak:* This will use keycloak?s beta4 as well, unless we find >> BLOCKERS in their beta4... (As said before KC is mostly hidden inside the >> server, and we can not wait for their 1.0.0.Final in September) >> >> This release will be mostly around docs and perhaps some more UX review >> of the quickstart demos. It is possible that the UX review does not happen. >> >> *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush >> Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives >> us one week of deep testing (of server, docs, demos) before the final >> release. >> >> Next: *celebrate*!!!!!!!! [image: :tada:] >> >> After the 1.0.0.Final of UPS, I?d suggest a two week-based release series >> of small fixes and improvements, as well as taking up new Keycloak releases >> >> - >> >> 1.0.1 >> : >> 01/Sep/14 >> >> *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few items >> from the JIRA. >> >> - >> >> 1.0.2 >> : >> 15/Sep/14 >> >> *Keycloak:* main reason is pick-up of their 1.0.0.Final >> >> - >> >> 1.0.3 >> >> :29/Sep/14 >> >> Might not be needed - but added it to JIRA, just in case? >> >> Let me know your thoughts and I will update the roadmap! >> >> -Matthias >> >> [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/5f7610a8/attachment-0001.html From matzew at apache.org Tue Aug 5 08:10:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 5 Aug 2014 14:10:23 +0200 Subject: [aerogear-dev] [Cordova] Important security fixes for Cordova-Android just released In-Reply-To: References: <1407225854.2790.1@smtp.corp.redhat.com> <8E954D1A-295D-4166-9F26-4C8458D64348@redhat.com> <20140805112535.GB39880@abstractj.org> <652C0D77-2C66-4F8F-A138-AAE4CF4A730C@redhat.com> Message-ID: On Tue, Aug 5, 2014 at 1:57 PM, tolis emmanouilidis wrote: > 2014-08-05 14:34 GMT+03:00 Erik Jan de Wit : > > >> It?s not cordova itself that is vulnerable it?s one particular version of >> a platform ( 3.5.0 android ). I?m not saying that people should ignore >> security, just that we use a runtime and we cannot be held responsible or >> control what version of that runtime people are using >> >> > +1 I think it's users responsiblity to upgrade or not. Also, it looks like > Apache is not enforcing the latest cordova version in their plugins e.g > https://github.com/apache/cordova-plugin-statusbar/blob/master/plugin.xml#L32 > ha! That's good info! -M > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/324fad0e/attachment.html From lholmqui at redhat.com Tue Aug 5 08:25:02 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 5 Aug 2014 08:25:02 -0400 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: <81D7DE6C-92EA-4642-84B2-F0FAEEC89135@gmail.com> References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> <81D7DE6C-92EA-4642-84B2-F0FAEEC89135@gmail.com> Message-ID: On Aug 5, 2014, at 12:56 AM, Christos Vasilakis wrote: > > On Aug 5, 2014, at 6:37 AM, Daniel Bevenius wrote: > >> +1 for 'unifiedpush-node-sender? > > > +1 for 'unifiedpush-node-sender? too while i like ?unifiedpush-node-sender? i sort of didn?t want to put the word node in it. if you are searching on npm/using npm to install something. it?s node although, if this also has a CLI component to it, that might make sense then, ?$ unifiedpush-node-sender ?.. ? i?m so torn :) ok, lets go with ?unifiedpush-node-sender' i wouldn?t rename the github repo thought. > > >> >> tisdag 5 augusti 2014 skrev Daniel Passos : >> On Fri, Aug 1, 2014 at 10:47 AM, Lucas Holmquist wrote: >> Do we want to also rename it. >> >> the java sender is called( in maven ), ?unifiedpush-java-sender? >> >> while the node one(in npm) is ?aerogear-sender-client? >> >> i was thinking the name should probably be ?unifiedpush-sender? or ?unifiedpush-sender? >> >> I like that >> >> +1 for ?unifiedpush-sender? or ?unifiedpush-sender? >> >> Or unifiedpush-node-sender >> >> what do others think? >> >> >> On Aug 1, 2014, at 8:48 AM, Lucas Holmquist wrote: >> >>> :), do we a JIRA, i can whip something up for a guide >>> On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf wrote: >>> >>>> Whenever Luke is ready ? :) >>>> >>>> >>>> >>>> On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira wrote: >>>> +1 >>>> >>>> When? >>>> >>>> On 2014-08-01, Sebastien Blanc wrote: >>>> > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf >>>> > wrote: >>>> > >>>> > > Hi there, >>>> > > >>>> > > a few questions: >>>> > > >>>> > > * based on >>>> > > >>>> > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 >>>> > > >>>> > > should we do a new release of the node.js sender ? >>>> > > >>>> > yes >>>> > >>>> > > >>>> > > * going over the docs, do we have 'guide' or so that we can link here: >>>> > > >>>> > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials >>>> > > >>>> > not that I'm aware of but we could link (for now) to the README of the >>>> > github which contains instructions. >>>> > >>>> > > >>>> > > >>>> > > Thanks! >>>> > > Matthias >>>> > > >>>> > > -- >>>> > > Matthias Wessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/4cf44c71/attachment.html From matzew at apache.org Tue Aug 5 08:28:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 5 Aug 2014 14:28:59 +0200 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> <81D7DE6C-92EA-4642-84B2-F0FAEEC89135@gmail.com> Message-ID: On Tue, Aug 5, 2014 at 2:25 PM, Lucas Holmquist wrote: > > On Aug 5, 2014, at 12:56 AM, Christos Vasilakis > wrote: > > > On Aug 5, 2014, at 6:37 AM, Daniel Bevenius > wrote: > > +1 for 'unifiedpush-node-sender? > > > > +1 for 'unifiedpush-node-sender? too > > > while i like ?unifiedpush-node-sender? i sort of didn?t want to put the > word node in it. if you are searching on npm/using npm to install > something. it?s node > > although, if this also has a CLI component to it, that might make sense > then, ?$ unifiedpush-node-sender ?.. ? > > > i?m so torn :) > he! ja, it's valid concerns! > > ok, lets go with ?unifiedpush-node-sender' > soundz good to me > > i wouldn?t rename the github repo thought. > +1 > > > > > > tisdag 5 augusti 2014 skrev Daniel Passos : > >> On Fri, Aug 1, 2014 at 10:47 AM, Lucas Holmquist >> wrote: >> >>> Do we want to also rename it. >>> >>> the java sender is called( in maven ), ?unifiedpush-java-sender? >>> >>> while the node one(in npm) is ?aerogear-sender-client? >>> >>> i was thinking the name should probably be ?unifiedpush-sender? or >>> ?unifiedpush-sender? >>> >> >> I like that >> >> +1 for ?unifiedpush-sender? or ?unifiedpush-sender? >> >> Or unifiedpush-node-sender >> >> >>> what do others think? >>> >>> >>> On Aug 1, 2014, at 8:48 AM, Lucas Holmquist wrote: >>> >>> :), do we a JIRA, i can whip something up for a guide >>> On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf >>> wrote: >>> >>> Whenever Luke is ready ? :) >>> >>> >>> >>> On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira >>> wrote: >>> >>>> +1 >>>> >>>> When? >>>> >>>> On 2014-08-01, Sebastien Blanc wrote: >>>> > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf < >>>> matzew at apache.org> >>>> > wrote: >>>> > >>>> > > Hi there, >>>> > > >>>> > > a few questions: >>>> > > >>>> > > * based on >>>> > > >>>> > > >>>> https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 >>>> > > >>>> > > should we do a new release of the node.js sender ? >>>> > > >>>> > yes >>>> > >>>> > > >>>> > > * going over the docs, do we have 'guide' or so that we can link >>>> here: >>>> > > >>>> > > >>>> http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials >>>> > > >>>> > not that I'm aware of but we could link (for now) to the README of the >>>> > github which contains instructions. >>>> > >>>> > > >>>> > > >>>> > > Thanks! >>>> > > Matthias >>>> > > >>>> > > -- >>>> > > Matthias Wessendorf >>>> >>> _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/4d592476/attachment-0001.html From lholmqui at redhat.com Tue Aug 5 08:55:00 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 5 Aug 2014 08:55:00 -0400 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> <81D7DE6C-92EA-4642-84B2-F0FAEEC89135@gmail.com> Message-ID: On Aug 5, 2014, at 8:28 AM, Matthias Wessendorf wrote: > > > > On Tue, Aug 5, 2014 at 2:25 PM, Lucas Holmquist wrote: > > On Aug 5, 2014, at 12:56 AM, Christos Vasilakis wrote: > >> >> On Aug 5, 2014, at 6:37 AM, Daniel Bevenius wrote: >> >>> +1 for 'unifiedpush-node-sender? >> >> >> +1 for 'unifiedpush-node-sender? too > > while i like ?unifiedpush-node-sender? i sort of didn?t want to put the word node in it. if you are searching on npm/using npm to install something. it?s node > > although, if this also has a CLI component to it, that might make sense then, ?$ unifiedpush-node-sender ?.. ? > > > i?m so torn :) > > he! ja, it's valid concerns! > > > ok, lets go with ?unifiedpush-node-sender' > > soundz good to me ok, i?ll go with it, @matzew, could you update the component in the AGPUSH JIRA to be UnifiedPush-node-sender > > > i wouldn?t rename the github repo thought. > > +1 > > > >> >> >>> >>> tisdag 5 augusti 2014 skrev Daniel Passos : >>> On Fri, Aug 1, 2014 at 10:47 AM, Lucas Holmquist wrote: >>> Do we want to also rename it. >>> >>> the java sender is called( in maven ), ?unifiedpush-java-sender? >>> >>> while the node one(in npm) is ?aerogear-sender-client? >>> >>> i was thinking the name should probably be ?unifiedpush-sender? or ?unifiedpush-sender? >>> >>> I like that >>> >>> +1 for ?unifiedpush-sender? or ?unifiedpush-sender? >>> >>> Or unifiedpush-node-sender >>> >>> what do others think? >>> >>> >>> On Aug 1, 2014, at 8:48 AM, Lucas Holmquist wrote: >>> >>>> :), do we a JIRA, i can whip something up for a guide >>>> On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf wrote: >>>> >>>>> Whenever Luke is ready ? :) >>>>> >>>>> >>>>> >>>>> On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira wrote: >>>>> +1 >>>>> >>>>> When? >>>>> >>>>> On 2014-08-01, Sebastien Blanc wrote: >>>>> > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf >>>>> > wrote: >>>>> > >>>>> > > Hi there, >>>>> > > >>>>> > > a few questions: >>>>> > > >>>>> > > * based on >>>>> > > >>>>> > > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 >>>>> > > >>>>> > > should we do a new release of the node.js sender ? >>>>> > > >>>>> > yes >>>>> > >>>>> > > >>>>> > > * going over the docs, do we have 'guide' or so that we can link here: >>>>> > > >>>>> > > http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials >>>>> > > >>>>> > not that I'm aware of but we could link (for now) to the README of the >>>>> > github which contains instructions. >>>>> > >>>>> > > >>>>> > > >>>>> > > Thanks! >>>>> > > Matthias >>>>> > > >>>>> > > -- >>>>> > > Matthias Wessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/078a94aa/attachment.html From matzew at apache.org Tue Aug 5 08:58:33 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 5 Aug 2014 14:58:33 +0200 Subject: [aerogear-dev] [UPS] Misc: Node.js sender In-Reply-To: References: <20140801105513.GC42958@abstractj.org> <56D6FE58-9631-451F-85FA-7DA04617461C@redhat.com> <6C2BF0C7-FCA3-439E-955B-68229765E5AC@redhat.com> <81D7DE6C-92EA-4642-84B2-F0FAEEC89135@gmail.com> Message-ID: done! On Tue, Aug 5, 2014 at 2:55 PM, Lucas Holmquist wrote: > > On Aug 5, 2014, at 8:28 AM, Matthias Wessendorf wrote: > > > > > On Tue, Aug 5, 2014 at 2:25 PM, Lucas Holmquist > wrote: > >> >> On Aug 5, 2014, at 12:56 AM, Christos Vasilakis >> wrote: >> >> >> On Aug 5, 2014, at 6:37 AM, Daniel Bevenius >> wrote: >> >> +1 for 'unifiedpush-node-sender? >> >> >> >> +1 for 'unifiedpush-node-sender? too >> >> >> while i like ?unifiedpush-node-sender? i sort of didn?t want to put the >> word node in it. if you are searching on npm/using npm to install >> something. it?s node >> >> although, if this also has a CLI component to it, that might make sense >> then, ?$ unifiedpush-node-sender ?.. ? >> >> >> i?m so torn :) >> > > he! ja, it's valid concerns! > > >> >> ok, lets go with ?unifiedpush-node-sender' >> > > soundz good to me > > > ok, i?ll go with it, > > @matzew, could you update the component in the AGPUSH JIRA to be > UnifiedPush- > node-sender > > > >> >> i wouldn?t rename the github repo thought. >> > > +1 > > >> >> >> >> >> >> tisdag 5 augusti 2014 skrev Daniel Passos : >> >>> On Fri, Aug 1, 2014 at 10:47 AM, Lucas Holmquist >>> wrote: >>> >>>> Do we want to also rename it. >>>> >>>> the java sender is called( in maven ), ?unifiedpush-java-sender? >>>> >>>> while the node one(in npm) is ?aerogear-sender-client? >>>> >>>> i was thinking the name should probably be ?unifiedpush-sender? or >>>> ?unifiedpush-sender? >>>> >>> >>> I like that >>> >>> +1 for ?unifiedpush-sender? or ?unifiedpush-sender? >>> >>> Or unifiedpush-node-sender >>> >>> >>>> what do others think? >>>> >>>> >>>> On Aug 1, 2014, at 8:48 AM, Lucas Holmquist >>>> wrote: >>>> >>>> :), do we a JIRA, i can whip something up for a guide >>>> On Aug 1, 2014, at 7:22 AM, Matthias Wessendorf >>>> wrote: >>>> >>>> Whenever Luke is ready ? :) >>>> >>>> >>>> >>>> On Fri, Aug 1, 2014 at 12:55 PM, Bruno Oliveira >>>> wrote: >>>> >>>>> +1 >>>>> >>>>> When? >>>>> >>>>> On 2014-08-01, Sebastien Blanc wrote: >>>>> > On Fri, Aug 1, 2014 at 10:07 AM, Matthias Wessendorf < >>>>> matzew at apache.org> >>>>> > wrote: >>>>> > >>>>> > > Hi there, >>>>> > > >>>>> > > a few questions: >>>>> > > >>>>> > > * based on >>>>> > > >>>>> > > >>>>> https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/commit/a5a50e9a87161dfb39f8d3e73f7b1f1d77111e93 >>>>> > > >>>>> > > should we do a new release of the node.js sender ? >>>>> > > >>>>> > yes >>>>> > >>>>> > > >>>>> > > * going over the docs, do we have 'guide' or so that we can link >>>>> here: >>>>> > > >>>>> > > >>>>> http://aerogear.org/docs/unifiedpush/ups_userguide/next/#_server_integration_tutorials >>>>> > > >>>>> > not that I'm aware of but we could link (for now) to the README of >>>>> the >>>>> > github which contains instructions. >>>>> > >>>>> > > >>>>> > > >>>>> > > Thanks! >>>>> > > Matthias >>>>> > > >>>>> > > -- >>>>> > > Matthias Wessendorf >>>>> >>>> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/8514ae74/attachment-0001.html From bruno at abstractj.org Tue Aug 5 09:05:30 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 5 Aug 2014 10:05:30 -0300 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: <71D8CDD4-373B-4BD2-89AA-4432641C4E2E@redhat.com> Message-ID: <20140805130530.GB43044@abstractj.org> +1 on delaying it, fair enough On 2014-08-05, Matthias Wessendorf wrote: > There might be a little delay, when we can release our own 1.0.0.Final, > since I found a KC bug that occurs only w/ MySQL and EAP 6.3.Beta: > http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002388.html > > In case this fix makes it into Keycloak's RC-1 (instead of beta-4 - which > seems reasonable to me), we should be waiting a few more days to pick up > their RC-1 in our final. That means we could release the same week (e.g. > 22nd), or exactly one week later - on 25th of August. > > Things are being discussed atm, this is just a heads-up ... > > > -Matthias > > > > > On Fri, Aug 1, 2014 at 3:19 PM, Matthias Wessendorf > wrote: > > > here we go: > > > > https://github.com/aerogear/aerogear.org/pull/343 > > > > > > On Fri, Aug 1, 2014 at 2:47 PM, Lucas Holmquist > > wrote: > > > >> ++ sounds/looks good > >> On Aug 1, 2014, at 12:35 AM, Matthias Wessendorf > >> wrote: > >> > >> Hi team, > >> > >> based on [1] I thought about our release timelines until 1.0.0.Final, and > >> shortly after. > >> > >> - > >> > >> 1.0.0.Beta2 > >> : > >> 07/Aug/14 > >> > >> This needs to include Keycloak-beta4, and might slip by one day, but not > >> much more of a delay. > >> > >> *Please note:* There is already works going on to have our parent and > >> UPS working w/ beta4 - it?s just a matter of merging the branch, once the > >> release is out. > >> > >> Number of open JIRAs for this release is looking good! > >> > >> - > >> > >> 1.0.0 > >> : > >> 18/Aug/14 > >> > >> *Keycloak:* This will use keycloak?s beta4 as well, unless we find > >> BLOCKERS in their beta4... (As said before KC is mostly hidden inside the > >> server, and we can not wait for their 1.0.0.Final in September) > >> > >> This release will be mostly around docs and perhaps some more UX review > >> of the quickstart demos. It is possible that the UX review does not happen. > >> > >> *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush > >> Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives > >> us one week of deep testing (of server, docs, demos) before the final > >> release. > >> > >> Next: *celebrate*!!!!!!!! [image: :tada:] > >> > >> After the 1.0.0.Final of UPS, I?d suggest a two week-based release series > >> of small fixes and improvements, as well as taking up new Keycloak releases > >> > >> - > >> > >> 1.0.1 > >> : > >> 01/Sep/14 > >> > >> *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few items > >> from the JIRA. > >> > >> - > >> > >> 1.0.2 > >> : > >> 15/Sep/14 > >> > >> *Keycloak:* main reason is pick-up of their 1.0.0.Final > >> > >> - > >> > >> 1.0.3 > >> > >> :29/Sep/14 > >> > >> Might not be needed - but added it to JIRA, just in case? > >> > >> Let me know your thoughts and I will update the roadmap! > >> > >> -Matthias > >> > >> [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Aug 5 15:56:07 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 5 Aug 2014 16:56:07 -0300 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback Message-ID: <20140805195607.GA56126@abstractj.org> Good morning peeps, I would like to open this thread to discuss some ideas about how to improve the current build on Push server. Lukas have been doing a stellar job improving it and I think we can help. Yesterday I spent some time trying to build a developer environment for UPS ? was a good exercise to realize how people feel trying to contribute. The goal was to build the environment from scratch. Here comes some feedback (keep in mind that I'm not that good on Node.js) - Build our dependencies takes a considerable time. For fair reasons, we are running mvn install, npm install and bower install for the first time. Maybe we can reduce one step? - Java developers don't have their environment ready for Node ? it can be a blocker. For example, was necessary to install gcc, libpng and libpng-devel. I already saw team members struggling with it, like me. - Maybe we should run -Pdev by default and run the complete build only for CI. - Maybe we can minify some JS dependencies and don't build everything altogether? I built an image[1][2], because developers willing to just use UPS with the latest bits might struggle to configure their environment and maybe it can be helpful. The image is not perfect and soon will be moved to jboss/dockerfiles. Thoughts? [1] - https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ -- abstractj PGP: 0x84DC9914 From jbalunas at redhat.com Tue Aug 5 18:34:58 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Tue, 5 Aug 2014 18:34:58 -0400 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: <53E0308D.2050103@redhat.com> References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> <53DF99F6.1090604@redhat.com> <53E0308D.2050103@redhat.com> Message-ID: <99B4D3FB-AEBF-453B-B611-52182C9613B5@redhat.com> On Aug 4, 2014, at 9:17 PM, Summers Pittman wrote: > On Mon 04 Aug 2014 01:19:17 PM EDT, Randall Hauch wrote: >> Perhaps we?re looking at this from different perspectives. It?s great >> that you guys are trying to better understand DS so that you can >> compare it to other techniques, including OT. That certainly needs to >> be done. I guess I was looking at DS from the perspective of how a >> data service might need to implement it, knowing that the choice of >> how data sync is ultimately done will be influenced in part by how the >> data service would implement each approach and the impact on >> scalability and performance. Perhaps it?s too early to provide my >> thoughts along those lines. >> >> On Aug 4, 2014, at 9:34 AM, Summers Pittman > > wrote: >> >>> I am speaking from the perspective of the algorithm and less from my >>> opinions of the way the system should work as a whole. >>> >>> On 08/01/2014 03:02 PM, Randall Hauch wrote: >>>> I?ve really enjoyed learning about what AeroGear has been doing with >>>> data sync. This is a tough problem, but finding a solution is really >>>> important. Both data sync POCs appear to use Differential >>>> Synchronization, or DS [1]. I was not familiar with the paper until >>>> today, but after reading it I do have a few questions/comments. Bear >>>> with me; this is a long post. >>>> >>>> DS is clearly targeted for use within a collaborative document >>>> editor, where there are multiple clients concurrently editing the >>>> same document, and at any one time there are a relatively small >>>> number of documents being edited; you can get a feel for this by >>>> looking at figures 5 and 7 in the paper [1] ? look at the amount of >>>> server memory and CPU required to perform DS on just one document >>>> being edited by a half-dozen clients. Also, in a collaborative >>>> document editor, clients are often continually making changes even >>>> as they attempt to synchronize with the server. >>> It doesn't actually make any claims about CPU or memory usage. A >>> shadow document is needed for each connection. For documents which >>> are infrequently edited, the shadow doc can easily be frozen to disk >>> until an edit comes in. >> >> Sure, you don?t have to keep it in memory. But it does have to be in >> memory to do anything with it in an efficient way. And, yes, you >> certainly can build a data service that uses this technique. My point >> was that having multiple copies of a document being edited will reduce >> the scalability of the data service compared to other techniques. >> >>>> >>>> (It?s interesting that Google Docs, and Google Wave before it, >>>> appear to use Operational Transformation [2] rather than DS. OT >>>> might also make it easier to implement undo/redo, which works really >>>> well in Google Docs.) >>> That is probably because OT, Docs, and Apache Wave are all older then >>> Diff-sync. OT is also a much more complicated algorithm in my >>> experience (and from browsing around on wikipedia) >>>> >>>> An MBaaS or any other database-like service is very different. It >>>> has to host multiple applications (i.e., databases), each with >>>> multiple collections containing potentially millions of entities >>>> (e.g., JSON documents). The entities themselves are more >>>> fine-grained and smaller than collaborative documents (though >>>> probably a bit coarser-grained and larger than a single record in a >>>> RDBMS). Many clients might be reading and updating lots of documents >>>> at once, and the data service has to coordinate those changes. A >>>> single batch update from one client might request changes to dozens >>>> of entities. And the clients can/will always wait for confirmation >>>> that the server made the requested changes before continuing (unless >>>> the client is offline); or at a minimum can enqueue the requested >>>> changes. >>> Two quick things. A document is just a collection of entities and >>> can be structured to reduce this problem (especially is we are faking >>> it on a RDBMS with particularly sadistic abuses to an ORM). >> >> Yes, a document might be a JSON document that is an aggregate of >> multiple objects, and not just a flat map of key-value pairs. The use >> of aggregate data structures and denormalization are some of the ways >> that eventually-consistent data stores work. The goal is to reduce the >> scope of a set of operations to a single aggregate. Other data stores >> (like graph and hierarchical databases) require strong consistency and >> transactions because operations necessarily span multiple objects. But >> limiting operations to a single aggregate is also quite constraining >> w/r/t app development, since you can?t always denormalize all data to >> separate aggregates. >> >> So even if a collection (in the MongoDB sense) contains documents that >> are aggregates of multiple ?entities? (in the Hibernate sense of the >> word), my point still stands that generally any given JSON document >> will still be smaller than a document used in a collaborative document >> editor. Also, I would not be surprised if the sheer number of >> documents in a MongoDB collection is orders of magnitude larger than >> the number of documents stored by a collaborative editor app. >> >>> Clients don't have to wait for the edits to be merged on the server >>> and the nature of diff-sync gives us batching for free. >> >> Hmm? even if you could do it this way, do you not want to be able to >> give feedback to the user that the changes might not have been >> accepted/persisted? >> >> Do you have some scenarios that describe the kinds of applications >> you?re considering? I?m wondering if I?m envisioning a different kind >> of app. >> >>>> >>>> Given these characteristics, using DS within the data service might >>>> be extremely expensive in terms of CPU and memory >>> or it might not be. We need data, use cases, etc to test and see >>> what happens. >>>> , and difficult for a DS-based service to implement all of the >>>> features necessary. >>> Which features? Features of the algorithm of features of the >>> application? The algorithm is really REALLY simple for what we get >>> out of it. >> >> I was referring to features of the data service, and especially how >> the data service?s implementation can satisfy the difficult >> non-functional requirements like scalability and performance. While >> the algorithm might be really simple, that doesn?t mean implementing >> it on the server is efficient. What I?ve read so far makes me think >> that it?s could very well be less efficient and scalable than other >> techniques used in data services. >> >>>> First, the data service doesn?t really know which entities are >>>> being?edited?; instead, connected clients read entities, make >>>> changes locally, then request the service make those changes. >>> I disagree. The service knows documents which the client has a >>> connection to/active session for. It most certainly knows which >>> entities are being edited. >> >> I guess I was hoping that the client can manipulate documents locally >> without having to coordinate that with the server. Again, I?m >> concerned about server scalability. >> >>>> Secondly, every time a change comes in, to compute the diff the >>>> service would have to read the persisted entity; this not only is >>>> inefficient, but this also makes it more difficult to scale and >>>> handle the concurrency, consistency, atomicity, and serializability >>>> guarantees. >>> See earlier comment about sadistic abuses of an ORM. Yes we have to >>> be aware of the RDB underneath the sync server, but I don't think >>> this is a problem with the algorithm. >> >> I agree, it?s not a problem with the algorithm. It?s a problem insofar >> as it would mandate what the server has to support. >> >>>> Thirdly, what would the data service need to do when a client >>>> connects and asks for the changes since it was last connected? >>> Send it the diff of the clients serverside shadow and the server's >>> current document. This diff will get sent to the client, merged with >>> the clients shadow, and the diff of that will get sent back to the >>> server. Repeat until the client is in sync. >>>> The data service might be able to quickly find out which entities >>>> were modified since then, but computing the diffs (relative to the >>>> time the client last connected) for all of those changed entities >>>> would be very complicated. >>> It isn?t. >> >> Perhaps I should have said ?expensive? rather than ?complicated?. >> >>>> It may be easier and better for the data service to record the >>>> individual changes (edits) made by each transaction, and then to use >>>> that information to compute the effective diffs from some period of >>>> time. In fact, these recorded edits might also be useful to >>>> implement other features within the data service; see CQRS [3] and [4]. >>>> >>>> What is really required by the client when trying to synchronize its >>>> data after being disconnected? Assuming the client can say which >>>> subset of entities it?s interested in when it reconnects (via some >>>> criteria in a subscription), does the client want: >>>> >>>> 1. the new versions of those entities that changed; >>> No >> >> This is actually what a number of MBaaS offerings do, although it?s >> often hidden by the client SDKs. It may not be ideal because it places >> more work onto the client SDK, but the benefit is that a good portion >> of the work is done on the client, and the load on the server is >> reduced (and scalability increased). It?s also trivially easy for the >> data service to implement. >> >>>> 1. the deltas in the entities; and/or >>> Yes >>>> >>>> 1. all of the events describing the individual changes made to all >>>> of those entities? >>> No. >>>> >>>> It may not matter for clients that don?t allow local offline >>>> changes, but what might the preferred approach be for clients that >>>> do allow offline changes? Option 1 is clearly the easiest from the >>>> perspective of the data service, but options #2 and #3 can certainly >>>> be handled. With option #1, can the client do something like DS and >>>> maintain copies of each original (unmodified) entity so that it can >>>> compute the differences? Does this (perhaps with a journal of edits >>>> made while offline) provide enough info for the client to properly >>>> merge the local changes, or does the client really need the >>>> individual events in #3 so that it can, for example, know that some >>>> local changes were made to now-out-date data? >>> Except in the case of a merge error, the algorithm handles long >>> offline periods with edits just fine. If there is a merge error the >>> user/application will have to manually merge the documents somehow. >>> >>> One of the things to keep in mind is on mobile devices the radio is >>> the most expensive thing you can control as an application. Any >>> decision we make should err toward only sending as little data as >>> possible as few times as possible. >> >> I completely agree. >> >>>> >>>> Will the same option work for online notifications? After all, it?d >>>> be great if the same mechanism was used for data-sync, offline >>>> (push) notifications, and online notifications (events). >>> I don't understand your question. >> >> Only that it seems beneficial that the same mechanism be used for >> ?events" (while connected) and both online and offline data-sync. >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > I don't think it is too early for service minded people to point out > the big honking problems we will face. At the very least it helps us > figure out the use cases we will support for the initial releases as to > POC morphs into an actual project. I actually this this a very good point (as have other points on both sides). We will rely on people like you Randall to assist us in understanding the impact and advocate for the deeper server-side needs. While at the same time the client side APIs and developer experience will also need to be reviewed and taken into consideration. I think it is important to remember that all of these are POC's and I think with a problem domain as complex as this, before we get to actual cross-project implementation we need to develop and flush out specs, including all of these various points, risks, etc... This would be across data services, liveoak and aerogear and possibly others. > > From a mobile client developer perspective, this algorithm feels very > easy to understand and it handles a lot of annoying corner cases very > well (e.g. offline, operation batching, conflict handling, document > synchronization, collaboration etc.) . Additionally, in my > experiments, plugging in different diff-merge-synch operations allows > for the general framework to be adapted to other use cases and data > types. (i.e. if the server is just batching a list of changed Object > IDs instead of the actual changes for binary files). > > One of the things we need to do is determine which problems we are > going to solve/support (single user multi device sync, multi user > collaboration, binary files etc), which we are going to short circuit > (limiting numbers of collaborators, limiting file size, etc), and which > we are just going to document as best practices to use or to avoid. > > Maybe I'm just stuck seeing my hammer (DS) and everything is nails and > if someone can give a demo of something else (OT, etc) then I will be > really interested to compare. > > > -- > Summers Pittman >>> Phone:404 941 4698 >>> Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140805/4e77cdfe/attachment-0001.html From daniel.bevenius at gmail.com Wed Aug 6 02:27:06 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 6 Aug 2014 08:27:06 +0200 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: <99B4D3FB-AEBF-453B-B611-52182C9613B5@redhat.com> References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> <53DF99F6.1090604@redhat.com> <53E0308D.2050103@redhat.com> <99B4D3FB-AEBF-453B-B611-52182C9613B5@redhat.com> Message-ID: >I think it is important to remember that all of these are POC's and I think with a problem domain as complex as this, before we get to actual cross->project implementation we need to develop and flush out specs, including all of these various points, risks, etc... I agree with this. I think limiting the scope of this for now and enabling the underlying choice of storage/data service to be flexible will allow us to cater for the complex enterprise as well as a the simpler use cases which are important too if we want people to start using this and trying it out. On 6 August 2014 00:34, Jay Balunas wrote: > > On Aug 4, 2014, at 9:17 PM, Summers Pittman wrote: > > On Mon 04 Aug 2014 01:19:17 PM EDT, Randall Hauch wrote: > > Perhaps we?re looking at this from different perspectives. It?s great > that you guys are trying to better understand DS so that you can > compare it to other techniques, including OT. That certainly needs to > be done. I guess I was looking at DS from the perspective of how a > data service might need to implement it, knowing that the choice of > how data sync is ultimately done will be influenced in part by how the > data service would implement each approach and the impact on > scalability and performance. Perhaps it?s too early to provide my > thoughts along those lines. > > On Aug 4, 2014, at 9:34 AM, Summers Pittman >> wrote: > > I am speaking from the perspective of the algorithm and less from my > opinions of the way the system should work as a whole. > > On 08/01/2014 03:02 PM, Randall Hauch wrote: > > I?ve really enjoyed learning about what AeroGear has been doing with > data sync. This is a tough problem, but finding a solution is really > important. Both data sync POCs appear to use Differential > Synchronization, or DS [1]. I was not familiar with the paper until > today, but after reading it I do have a few questions/comments. Bear > with me; this is a long post. > > DS is clearly targeted for use within a collaborative document > editor, where there are multiple clients concurrently editing the > same document, and at any one time there are a relatively small > number of documents being edited; you can get a feel for this by > looking at figures 5 and 7 in the paper [1] ? look at the amount of > server memory and CPU required to perform DS on just one document > being edited by a half-dozen clients. Also, in a collaborative > document editor, clients are often continually making changes even > as they attempt to synchronize with the server. > > It doesn't actually make any claims about CPU or memory usage. A > shadow document is needed for each connection. For documents which > are infrequently edited, the shadow doc can easily be frozen to disk > until an edit comes in. > > > Sure, you don?t have to keep it in memory. But it does have to be in > memory to do anything with it in an efficient way. And, yes, you > certainly can build a data service that uses this technique. My point > was that having multiple copies of a document being edited will reduce > the scalability of the data service compared to other techniques. > > > (It?s interesting that Google Docs, and Google Wave before it, > appear to use Operational Transformation [2] rather than DS. OT > might also make it easier to implement undo/redo, which works really > well in Google Docs.) > > That is probably because OT, Docs, and Apache Wave are all older then > Diff-sync. OT is also a much more complicated algorithm in my > experience (and from browsing around on wikipedia) > > > An MBaaS or any other database-like service is very different. It > has to host multiple applications (i.e., databases), each with > multiple collections containing potentially millions of entities > (e.g., JSON documents). The entities themselves are more > fine-grained and smaller than collaborative documents (though > probably a bit coarser-grained and larger than a single record in a > RDBMS). Many clients might be reading and updating lots of documents > at once, and the data service has to coordinate those changes. A > single batch update from one client might request changes to dozens > of entities. And the clients can/will always wait for confirmation > that the server made the requested changes before continuing (unless > the client is offline); or at a minimum can enqueue the requested > changes. > > Two quick things. A document is just a collection of entities and > can be structured to reduce this problem (especially is we are faking > it on a RDBMS with particularly sadistic abuses to an ORM). > > > Yes, a document might be a JSON document that is an aggregate of > multiple objects, and not just a flat map of key-value pairs. The use > of aggregate data structures and denormalization are some of the ways > that eventually-consistent data stores work. The goal is to reduce the > scope of a set of operations to a single aggregate. Other data stores > (like graph and hierarchical databases) require strong consistency and > transactions because operations necessarily span multiple objects. But > limiting operations to a single aggregate is also quite constraining > w/r/t app development, since you can?t always denormalize all data to > separate aggregates. > > So even if a collection (in the MongoDB sense) contains documents that > are aggregates of multiple ?entities? (in the Hibernate sense of the > word), my point still stands that generally any given JSON document > will still be smaller than a document used in a collaborative document > editor. Also, I would not be surprised if the sheer number of > documents in a MongoDB collection is orders of magnitude larger than > the number of documents stored by a collaborative editor app. > > Clients don't have to wait for the edits to be merged on the server > and the nature of diff-sync gives us batching for free. > > > Hmm? even if you could do it this way, do you not want to be able to > give feedback to the user that the changes might not have been > accepted/persisted? > > Do you have some scenarios that describe the kinds of applications > you?re considering? I?m wondering if I?m envisioning a different kind > of app. > > > Given these characteristics, using DS within the data service might > be extremely expensive in terms of CPU and memory > > or it might not be. We need data, use cases, etc to test and see > what happens. > > , and difficult for a DS-based service to implement all of the > features necessary. > > Which features? Features of the algorithm of features of the > application? The algorithm is really REALLY simple for what we get > out of it. > > > I was referring to features of the data service, and especially how > the data service?s implementation can satisfy the difficult > non-functional requirements like scalability and performance. While > the algorithm might be really simple, that doesn?t mean implementing > it on the server is efficient. What I?ve read so far makes me think > that it?s could very well be less efficient and scalable than other > techniques used in data services. > > First, the data service doesn?t really know which entities are > being?edited?; instead, connected clients read entities, make > changes locally, then request the service make those changes. > > I disagree. The service knows documents which the client has a > connection to/active session for. It most certainly knows which > entities are being edited. > > > I guess I was hoping that the client can manipulate documents locally > without having to coordinate that with the server. Again, I?m > concerned about server scalability. > > Secondly, every time a change comes in, to compute the diff the > service would have to read the persisted entity; this not only is > inefficient, but this also makes it more difficult to scale and > handle the concurrency, consistency, atomicity, and serializability > guarantees. > > See earlier comment about sadistic abuses of an ORM. Yes we have to > be aware of the RDB underneath the sync server, but I don't think > this is a problem with the algorithm. > > > I agree, it?s not a problem with the algorithm. It?s a problem insofar > as it would mandate what the server has to support. > > Thirdly, what would the data service need to do when a client > connects and asks for the changes since it was last connected? > > Send it the diff of the clients serverside shadow and the server's > current document. This diff will get sent to the client, merged with > the clients shadow, and the diff of that will get sent back to the > server. Repeat until the client is in sync. > > The data service might be able to quickly find out which entities > were modified since then, but computing the diffs (relative to the > time the client last connected) for all of those changed entities > would be very complicated. > > It isn?t. > > > Perhaps I should have said ?expensive? rather than ?complicated?. > > It may be easier and better for the data service to record the > individual changes (edits) made by each transaction, and then to use > that information to compute the effective diffs from some period of > time. In fact, these recorded edits might also be useful to > implement other features within the data service; see CQRS [3] and [4]. > > What is really required by the client when trying to synchronize its > data after being disconnected? Assuming the client can say which > subset of entities it?s interested in when it reconnects (via some > criteria in a subscription), does the client want: > > 1. the new versions of those entities that changed; > > No > > > This is actually what a number of MBaaS offerings do, although it?s > often hidden by the client SDKs. It may not be ideal because it places > more work onto the client SDK, but the benefit is that a good portion > of the work is done on the client, and the load on the server is > reduced (and scalability increased). It?s also trivially easy for the > data service to implement. > > 1. the deltas in the entities; and/or > > Yes > > > 1. all of the events describing the individual changes made to all > of those entities? > > No. > > > It may not matter for clients that don?t allow local offline > changes, but what might the preferred approach be for clients that > do allow offline changes? Option 1 is clearly the easiest from the > perspective of the data service, but options #2 and #3 can certainly > be handled. With option #1, can the client do something like DS and > maintain copies of each original (unmodified) entity so that it can > compute the differences? Does this (perhaps with a journal of edits > made while offline) provide enough info for the client to properly > merge the local changes, or does the client really need the > individual events in #3 so that it can, for example, know that some > local changes were made to now-out-date data? > > Except in the case of a merge error, the algorithm handles long > offline periods with edits just fine. If there is a merge error the > user/application will have to manually merge the documents somehow. > > One of the things to keep in mind is on mobile devices the radio is > the most expensive thing you can control as an application. Any > decision we make should err toward only sending as little data as > possible as few times as possible. > > > I completely agree. > > > Will the same option work for online notifications? After all, it?d > be great if the same mechanism was used for data-sync, offline > (push) notifications, and online notifications (events). > > I don't understand your question. > > > Only that it seems beneficial that the same mechanism be used for > ?events" (while connected) and both online and offline data-sync. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > I don't think it is too early for service minded people to point out > the big honking problems we will face. At the very least it helps us > figure out the use cases we will support for the initial releases as to > POC morphs into an actual project. > > > I actually this this a very good point (as have other points on both > sides). We will rely on people like you Randall to assist us in > understanding the impact and advocate for the deeper server-side needs. > While at the same time the client side APIs and developer experience will > also need to be reviewed and taken into consideration. > > I think it is important to remember that all of these are POC's and I > think with a problem domain as complex as this, before we get to actual > cross-project implementation we need to develop and flush out specs, > including all of these various points, risks, etc... This would be across > data services, liveoak and aerogear and possibly others. > > > From a mobile client developer perspective, this algorithm feels very > easy to understand and it handles a lot of annoying corner cases very > well (e.g. offline, operation batching, conflict handling, document > synchronization, collaboration etc.) . Additionally, in my > experiments, plugging in different diff-merge-synch operations allows > for the general framework to be adapted to other use cases and data > types. (i.e. if the server is just batching a list of changed Object > IDs instead of the actual changes for binary files). > > One of the things we need to do is determine which problems we are > going to solve/support (single user multi device sync, multi user > collaboration, binary files etc), which we are going to short circuit > (limiting numbers of collaborators, limiting file size, etc), and which > we are just going to document as best practices to use or to avoid. > > Maybe I'm just stuck seeing my hammer (DS) and everything is nails and > if someone can give a demo of something else (OT, etc) then I will be > really interested to compare. > > > -- > Summers Pittman > > Phone:404 941 4698 > Java is my crack. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/c4973776/attachment-0001.html From cvasilak at gmail.com Wed Aug 6 03:07:41 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 6 Aug 2014 10:07:41 +0300 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: <20140805195607.GA56126@abstractj.org> References: <20140805195607.GA56126@abstractj.org> Message-ID: <5CCE0C86-E9ED-43AD-8574-8D32431A9BC8@gmail.com> nice work Bruno! tested the docker image and have to admit it?s slick, nice! - Christos On Aug 5, 2014, at 10:56 PM, Bruno Oliveira wrote: > Good morning peeps, > > I would like to open this thread to discuss some ideas about how to > improve the current build on Push server. Lukas have been doing a > stellar job improving it and I think we can help. > > Yesterday I spent some time trying to build a developer environment for > UPS ? was a good exercise to realize how people feel trying to contribute. > The goal was to build the environment from scratch. > > Here comes some feedback (keep in mind that I'm not that good on Node.js) > > - Build our dependencies takes a considerable time. For fair > reasons, we are running mvn install, npm install and bower install > for the first time. Maybe we can reduce one step? > > - Java developers don't have their environment ready for Node ? it can > be a blocker. For example, was necessary to install gcc, libpng and > libpng-devel. I already saw team members struggling with it, like me. > > - Maybe we should run -Pdev by default and run the complete build only > for CI. > > - Maybe we can minify some JS dependencies and don't build > everything altogether? > > I built an image[1][2], because developers willing to just use UPS with the > latest bits might struggle to configure their environment and maybe it > can be helpful. > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > Thoughts? > > [1] - https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Wed Aug 6 03:47:30 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 09:47:30 +0200 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: <20140805195607.GA56126@abstractj.org> References: <20140805195607.GA56126@abstractj.org> Message-ID: On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira wrote: > Good morning peeps, > > I would like to open this thread to discuss some ideas about how to > improve the current build on Push server. Lukas have been doing a > stellar job improving it and I think we can help. > > Yesterday I spent some time trying to build a developer environment for > UPS ? was a good exercise to realize how people feel trying to contribute. > The goal was to build the environment from scratch. > > Here comes some feedback (keep in mind that I'm not that good on Node.js) > > - Build our dependencies takes a considerable time. For fair > reasons, we are running mvn install, npm install and bower install > for the first time. Maybe we can reduce one step? > > - Java developers don't have their environment ready for Node ? it can > be a blocker. For example, was necessary to install gcc, libpng and > libpng-devel. I already saw team members struggling with it, like me. > gcc, libpng etc -> LOL. yeah, that should NOT Be required > > - Maybe we should run -Pdev by default and run the complete build only > for CI. > yeah, auto activating the -Pdev makes only the very first build take forever. I think this will improve things already slightly. > > - Maybe we can minify some JS dependencies and don't build > everything altogether? > > I built an image[1][2], because developers willing to just use UPS with the > latest bits might struggle to configure their environment and maybe it > can be helpful. > That's awesome! This made me install docker :) > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > Thoughts? > > [1] - > https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/a8ae6641/attachment.html From daniel.bevenius at gmail.com Wed Aug 6 04:29:45 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 6 Aug 2014 10:29:45 +0200 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: References: <20140805195607.GA56126@abstractj.org> Message-ID: Nice, I like the docker image! On 6 August 2014 09:47, Matthias Wessendorf wrote: > > > > On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira > wrote: > >> Good morning peeps, >> >> I would like to open this thread to discuss some ideas about how to >> improve the current build on Push server. Lukas have been doing a >> stellar job improving it and I think we can help. >> >> Yesterday I spent some time trying to build a developer environment for >> UPS ? was a good exercise to realize how people feel trying to contribute. >> The goal was to build the environment from scratch. >> >> Here comes some feedback (keep in mind that I'm not that good on Node.js) >> >> - Build our dependencies takes a considerable time. For fair >> reasons, we are running mvn install, npm install and bower install >> for the first time. Maybe we can reduce one step? >> >> - Java developers don't have their environment ready for Node ? it can >> be a blocker. For example, was necessary to install gcc, libpng and >> libpng-devel. I already saw team members struggling with it, like me. >> > > gcc, libpng etc -> LOL. > yeah, that should NOT Be required > > >> >> - Maybe we should run -Pdev by default and run the complete build only >> for CI. >> > > yeah, auto activating the -Pdev makes only the very first build take > forever. > I think this will improve things already slightly. > > > >> >> - Maybe we can minify some JS dependencies and don't build >> everything altogether? >> >> I built an image[1][2], because developers willing to just use UPS with >> the >> latest bits might struggle to configure their environment and maybe it >> can be helpful. >> > > That's awesome! This made me install docker :) > > >> >> The image is not perfect and soon will be moved to jboss/dockerfiles. >> >> Thoughts? >> >> [1] - >> https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev >> [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/aff1ef1b/attachment.html From bruno at abstractj.org Wed Aug 6 05:06:58 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 6 Aug 2014 06:06:58 -0300 Subject: [aerogear-dev] Docker images for AeroGear Message-ID: <20140806090658.GA65629@abstractj.org> Good morning my friends, only because I don't want to hijack the building thread, I'm opening this one. For the further docker images I was wondering about the following structure: . ??? as7 - Images for JBoss AS7 ??? ??? README.md ??? ??? aerogear-simplepush - binaries with the latest stable release from SimplePush ??? ??? ??? README.md ??? ??? aerogear-simplepush-dev - compile and run SimplePush from scratch (the work done by Daniel Bevenius with some changes) ??? ??? ??? README.md ??? ??? aerogear-unifiedpush - binaries with the latest stable release from UnifiedPush ??? ??? ??? README.md ??? ??? aerogear-unifiedpush-dev - compile and run UnifiedPush server from scratch (the first image released here) ??? ??? Dockerfile ??? ??? README.md ??? wildfly - Images for Wildfly (with the same goals above) ??? README.md ??? aerogear-simplepush ??? ??? README.md ??? aerogear-simplepush-dev ??? ??? README.md ??? aerogear-unifiedpush ??? ??? README.md ??? aerogear-unifiedpush-dev ??? README.md What do you think? Is anything missing? -- abstractj PGP: 0x84DC9914 From matzew at apache.org Wed Aug 6 05:10:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 11:10:54 +0200 Subject: [aerogear-dev] Docker images for AeroGear In-Reply-To: <20140806090658.GA65629@abstractj.org> References: <20140806090658.GA65629@abstractj.org> Message-ID: looking really good! On Wed, Aug 6, 2014 at 11:06 AM, Bruno Oliveira wrote: > Good morning my friends, only because I don't want to hijack the > building thread, I'm opening this one. > > For the further docker images I was wondering about the following > structure: > > . > ??? as7 - Images for JBoss AS7 > ? ??? README.md > ? ??? aerogear-simplepush - binaries with the latest stable release > from SimplePush > ? ? ??? README.md > ? ??? aerogear-simplepush-dev - compile and run SimplePush from > scratch (the work done by Daniel Bevenius with some changes) > ? ? ??? README.md > ? ??? aerogear-unifiedpush - binaries with the latest stable release > from UnifiedPush > ? ? ??? README.md > ? ??? aerogear-unifiedpush-dev - compile and run UnifiedPush server > from scratch (the first image released here) > ? ??? Dockerfile > ? ??? README.md > ??? wildfly - Images for Wildfly (with the same goals above) > ??? README.md > ??? aerogear-simplepush > ? ??? README.md > ??? aerogear-simplepush-dev > ? ??? README.md > ??? aerogear-unifiedpush > ? ??? README.md > ??? aerogear-unifiedpush-dev > ??? README.md > > What do you think? Is anything missing? > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/009d1a56/attachment-0001.html From lukas.fryc at gmail.com Wed Aug 6 07:22:01 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 6 Aug 2014 13:22:01 +0200 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: <20140805195607.GA56126@abstractj.org> References: <20140805195607.GA56126@abstractj.org> Message-ID: Hey Bruno, awesome job with the docker image! Could we mention that in the README? I've created this issue to track improvements in the build itself: https://issues.jboss.org/browse/AGPUSH-881 Responds inline: On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira wrote: > Good morning peeps, > > I would like to open this thread to discuss some ideas about how to > improve the current build on Push server. Lukas have been doing a > stellar job improving it and I think we can help. > > Yesterday I spent some time trying to build a developer environment for > UPS ? was a good exercise to realize how people feel trying to contribute. > The goal was to build the environment from scratch. > > Here comes some feedback (keep in mind that I'm not that good on Node.js) > > - Build our dependencies takes a considerable time. For fair > reasons, we are running mvn install, npm install and bo > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/wer > install > for the first time. Maybe we can reduce one step? > We cannot avoid Maven and if we want really fresh compiled-from-sources approach (as opposed to store-compiled-to-git what we had before), we need go with both, Bower and NPM. Storing NPM deps in /node_modules is platform-dependent . We could store there Bower dependencies though. We can use exportsOverride section to extract just those files from our dependencies that we actually require in the project. Once updated, we can save them. But once you have NPM installed correctly, it's just a small step to running Bower. > > - Java developers don't have their environment ready for Node ? it can > be a blocker. For example, was necessary to install gcc, libpng and > libpng-devel. I already saw team members struggling with it, like me. > This is a blocker, I wasn't even aware of it - we may want to choose other plugins that don't require those dependencies or maybe inspect what grunt plugins we are even using. Do we even need some of those Grunt plugins like PNG minification (imagemin)? > > - Maybe we should run -Pdev by default and run the complete build only > for CI. > Yes, we have to come with sensible defaults. We store our NPM/Bower caches inside the project structure and we clean them with each clean. This is anti-pattern - in Java analogy - it's cleaning .m2/repository for each build - we should clean them just when we explicitly want to. -Pdev would stay here, but it would just remove /node_modules and /bower_components a) should add one more profile to clean even caches, e.g. -Pforce-clean b) or do not clean it at all and document that if one needs completely fresh sources, he should clean manually by "git clean -f -x -d" and "npm cache clean" > > - Maybe we can minify some JS dependencies and don't build > everything altogether? > > I built an image[1][2], because developers willing to just use UPS with the > latest bits might struggle to configure their environment and maybe it > can be helpful. > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > Thoughts? > > [1] - > https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev Also, someone suggested to use wro4j - as long as it is vital alternative for the build time, wro4j is really not handy for development, you won't get as quick turnaround as with Grunt. Some plugins we use doesn't even have to be available in wro4j, e.g. ngtemplates, ngmin. Making the build straight-forward is an ongoing, continuous process and we have still lot to investigate here. It can't definitely be finished in 1.0 time. Bear in mind that Node/NPM is very young technology and it will take some time to get it to the state where Maven is (if ever). In the meantime, I encourage you to use this awesome docker image Bruno created! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/66e745be/attachment.html From bruno at abstractj.org Wed Aug 6 07:23:36 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 6 Aug 2014 08:23:36 -0300 Subject: [aerogear-dev] UPS with Keycloak beta4 Message-ID: <20140806112336.GA88078@abstractj.org> Good morning, UPS with Keycloak beta4 is available for testing and feedback. Please test it https://github.com/aerogear/aerogear-unifiedpush-server/pull/341. Bonus points if you find bugs. Thanks in advance. -- abstractj PGP: 0x84DC9914 From matzew at apache.org Wed Aug 6 07:53:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 13:53:56 +0200 Subject: [aerogear-dev] UPS with Keycloak beta4 In-Reply-To: <20140806112336.GA88078@abstractj.org> References: <20140806112336.GA88078@abstractj.org> Message-ID: awesome work! I am now testing this. I'd prefer we merge this one, before we merege the other outstanding PRs ... -Matthias On Wed, Aug 6, 2014 at 1:23 PM, Bruno Oliveira wrote: > Good morning, UPS with Keycloak beta4 is available for testing and > feedback. > > Please test it > https://github.com/aerogear/aerogear-unifiedpush-server/pull/341. Bonus > points if you find bugs. > > Thanks in advance. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/95ef1831/attachment.html From lholmqui at redhat.com Wed Aug 6 08:18:11 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 6 Aug 2014 08:18:11 -0400 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: References: <20140805195607.GA56126@abstractj.org> Message-ID: On Aug 6, 2014, at 7:22 AM, Luk?? Fry? wrote: > Hey Bruno, > > awesome job with the docker image! > Could we mention that in the README? > > > I've created this issue to track improvements in the build itself: > https://issues.jboss.org/browse/AGPUSH-881 > > > > > > Responds inline: > > On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira wrote: > Good morning peeps, > > I would like to open this thread to discuss some ideas about how to > improve the current build on Push server. Lukas have been doing a > stellar job improving it and I think we can help. > > Yesterday I spent some time trying to build a developer environment for > UPS ? was a good exercise to realize how people feel trying to contribute. > The goal was to build the environment from scratch. > > Here comes some feedback (keep in mind that I'm not that good on Node.js) > > - Build our dependencies takes a considerable time. For fair > reasons, we are running mvn install, npm install and bohttp://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/wer install > for the first time. Maybe we can reduce one step? > > We cannot avoid Maven and if we want really fresh compiled-from-sources approach (as opposed to store-compiled-to-git what we had before), we need go with both, Bower and NPM. > > Storing NPM deps in /node_modules is platform-dependent. > > We could store there Bower dependencies though. We can use exportsOverride section to extract just those files from our dependencies that we actually require in the project. Once updated, we can save them. > > But once you have NPM installed correctly, it's just a small step to running Bower. > > > - Java developers don't have their environment ready for Node ? it can > be a blocker. For example, was necessary to install gcc, libpng and > libpng-devel. I already saw team members struggling with it, like me. > > This is a blocker, I wasn't even aware of it - we may want to choose other plugins that don't require those dependencies or maybe inspect what grunt plugins we are even using. Do we even need some of those Grunt plugins like PNG minification (imagemin)? +1, i?m guessing some of those are defaults from a base yeoman build? > > > - Maybe we should run -Pdev by default and run the complete build only > for CI. > > Yes, we have to come with sensible defaults. We store our NPM/Bower caches inside the project structure and we clean them with each clean. This is anti-pattern - in Java analogy - it's cleaning .m2/repository for each build - we should clean them just when we explicitly want to. -Pdev would stay here, but it would just remove /node_modules and /bower_components > > a) should add one more profile to clean even caches, e.g. -Pforce-clean > b) or do not clean it at all and document that if one needs completely fresh sources, he should clean manually by "git clean -f -x -d" and "npm cache clean" > > > - Maybe we can minify some JS dependencies and don't build > everything altogether? > > I built an image[1][2], because developers willing to just use UPS with the > latest bits might struggle to configure their environment and maybe it > can be helpful. > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > Thoughts? > > [1] - https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > Also, someone suggested to use wro4j - as long as it is vital alternative for the build time, wro4j is really not handy for development, you won't get as quick turnaround as with Grunt. > > Some plugins we use doesn't even have to be available in wro4j, e.g. ngtemplates, ngmin. > > > > Making the build straight-forward is an ongoing, continuous process and we have still lot to investigate here. It can't definitely be finished in 1.0 time. > > Bear in mind that Node/NPM is very young technology and it will take some time to get it to the state where Maven is (if ever). > > In the meantime, I encourage you to use this awesome docker image Bruno created! > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/7e06b9c2/attachment-0001.html From lholmqui at redhat.com Wed Aug 6 08:53:51 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 6 Aug 2014 08:53:51 -0400 Subject: [aerogear-dev] Update Node Sender for UnifiedPush Server Message-ID: <1AAB6FD7-E9D5-4114-A3AC-94B14E988FFC@redhat.com> For those of you who don?t read my blog, tsk tsk, the UnifiedPush node sender was updated Hello. A new version of the node sender client for the AeroGear UnifiedPush server is now up on npm https://www.npmjs.org/package/unifiedpush-node-sender You will notice that the name has of the module has changed This was done to fall in line with the other sender clients, such as the unifiedpush-java-sender If you want to get the latest source, has a look see herehttps://github.com/aerogear/aerogear-unifiedpush-nodejs-client/releases/latest Have a Good One. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/ab64e5e5/attachment.html From bruno at abstractj.org Wed Aug 6 08:54:13 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 6 Aug 2014 09:54:13 -0300 Subject: [aerogear-dev] UPS with Keycloak beta4 In-Reply-To: References: <20140806112336.GA88078@abstractj.org> Message-ID: <20140806125413.GB88078@abstractj.org> +1 Already tested UPS in non SSL environments, Keycloak forbid the access like expected On 2014-08-06, Matthias Wessendorf wrote: > awesome work! > > I am now testing this. > > I'd prefer we merge this one, before we merege the other outstanding PRs ... > > -Matthias > > > On Wed, Aug 6, 2014 at 1:23 PM, Bruno Oliveira wrote: > > > Good morning, UPS with Keycloak beta4 is available for testing and > > feedback. > > > > Please test it > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/341. Bonus > > points if you find bugs. > > > > Thanks in advance. > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From lukas.fryc at gmail.com Wed Aug 6 08:56:19 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 6 Aug 2014 14:56:19 +0200 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: References: <20140805195607.GA56126@abstractj.org> Message-ID: You guess completely right :-) On Wed, Aug 6, 2014 at 2:18 PM, Lucas Holmquist wrote: > > On Aug 6, 2014, at 7:22 AM, Luk?? Fry? wrote: > > Hey Bruno, > > awesome job with the docker image! > Could we mention that in the README? > > > I've created this issue to track improvements in the build itself: > https://issues.jboss.org/browse/AGPUSH-881 > > > > > > Responds inline: > > On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira > wrote: > >> Good morning peeps, >> >> I would like to open this thread to discuss some ideas about how to >> improve the current build on Push server. Lukas have been doing a >> stellar job improving it and I think we can help. >> >> Yesterday I spent some time trying to build a developer environment for >> UPS ? was a good exercise to realize how people feel trying to contribute. >> The goal was to build the environment from scratch. >> >> Here comes some feedback (keep in mind that I'm not that good on Node.js) >> >> - Build our dependencies takes a considerable time. For fair >> reasons, we are running mvn install, npm install and bo >> http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/wer >> install >> for the first time. Maybe we can reduce one step? >> > > We cannot avoid Maven and if we want really fresh compiled-from-sources > approach (as opposed to store-compiled-to-git what we had before), we need > go with both, Bower and NPM. > > Storing NPM deps in /node_modules is platform-dependent > > . > > We could store there Bower dependencies though. We can use exportsOverride > > section to extract just those files from our dependencies that we > actually require in the project. Once updated, we can save them. > > But once you have NPM installed correctly, it's just a small step to > running Bower. > > >> >> - Java developers don't have their environment ready for Node ? it can >> be a blocker. For example, was necessary to install gcc, libpng and >> libpng-devel. I already saw team members struggling with it, like me. >> > > This is a blocker, I wasn't even aware of it - we may want to choose other > plugins that don't require those dependencies or maybe inspect what grunt > plugins we are even using. Do we even need some of those Grunt plugins like > PNG minification (imagemin)? > > > +1, i?m guessing some of those are defaults from a base yeoman build? > > > >> >> - Maybe we should run -Pdev by default and run the complete build only >> for CI. >> > > Yes, we have to come with sensible defaults. We store our NPM/Bower caches > inside the project structure and we clean them with each clean. This is > anti-pattern - in Java analogy - it's cleaning .m2/repository for each > build - we should clean them just when we explicitly want to. -Pdev would > stay here, but it would just remove /node_modules and /bower_components > > a) should add one more profile to clean even caches, e.g. -Pforce-clean > b) or do not clean it at all and document that if one needs completely > fresh sources, he should clean manually by "git clean -f -x -d" and "npm > cache clean" > > >> >> - Maybe we can minify some JS dependencies and don't build >> everything altogether? >> >> I built an image[1][2], because developers willing to just use UPS with >> the >> latest bits might struggle to configure their environment and maybe it >> can be helpful. >> >> The image is not perfect and soon will be moved to jboss/dockerfiles. >> >> Thoughts? >> >> [1] - >> https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev >> [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > Also, someone suggested to use wro4j - as long as it is vital alternative > for the build time, wro4j is really not handy for development, you won't > get as quick turnaround as with Grunt. > > Some plugins we use doesn't even have to be available in wro4j, e.g. > ngtemplates, ngmin. > > > > Making the build straight-forward is an ongoing, continuous process and we > have still lot to investigate here. It can't definitely be finished in 1.0 > time. > > Bear in mind that Node/NPM is very young technology and it will take some > time to get it to the state where Maven is (if ever). > > In the meantime, I encourage you to use this awesome docker image Bruno > created! > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/15771904/attachment.html From lholmqui at redhat.com Wed Aug 6 08:58:08 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 6 Aug 2014 08:58:08 -0400 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: References: <20140805195607.GA56126@abstractj.org> Message-ID: On Aug 6, 2014, at 8:56 AM, Luk?? Fry? wrote: > You guess completely right :-) Yay!!, what did i win :) > > > On Wed, Aug 6, 2014 at 2:18 PM, Lucas Holmquist wrote: > > On Aug 6, 2014, at 7:22 AM, Luk?? Fry? wrote: > >> Hey Bruno, >> >> awesome job with the docker image! >> Could we mention that in the README? >> >> >> I've created this issue to track improvements in the build itself: >> https://issues.jboss.org/browse/AGPUSH-881 >> >> >> >> >> >> Responds inline: >> >> On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira wrote: >> Good morning peeps, >> >> I would like to open this thread to discuss some ideas about how to >> improve the current build on Push server. Lukas have been doing a >> stellar job improving it and I think we can help. >> >> Yesterday I spent some time trying to build a developer environment for >> UPS ? was a good exercise to realize how people feel trying to contribute. >> The goal was to build the environment from scratch. >> >> Here comes some feedback (keep in mind that I'm not that good on Node.js) >> >> - Build our dependencies takes a considerable time. For fair >> reasons, we are running mvn install, npm install and bohttp://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/wer install >> for the first time. Maybe we can reduce one step? >> >> We cannot avoid Maven and if we want really fresh compiled-from-sources approach (as opposed to store-compiled-to-git what we had before), we need go with both, Bower and NPM. >> >> Storing NPM deps in /node_modules is platform-dependent. >> >> We could store there Bower dependencies though. We can use exportsOverride section to extract just those files from our dependencies that we actually require in the project. Once updated, we can save them. >> >> But once you have NPM installed correctly, it's just a small step to running Bower. >> >> >> - Java developers don't have their environment ready for Node ? it can >> be a blocker. For example, was necessary to install gcc, libpng and >> libpng-devel. I already saw team members struggling with it, like me. >> >> This is a blocker, I wasn't even aware of it - we may want to choose other plugins that don't require those dependencies or maybe inspect what grunt plugins we are even using. Do we even need some of those Grunt plugins like PNG minification (imagemin)? > > +1, i?m guessing some of those are defaults from a base yeoman build? > >> >> >> - Maybe we should run -Pdev by default and run the complete build only >> for CI. >> >> Yes, we have to come with sensible defaults. We store our NPM/Bower caches inside the project structure and we clean them with each clean. This is anti-pattern - in Java analogy - it's cleaning .m2/repository for each build - we should clean them just when we explicitly want to. -Pdev would stay here, but it would just remove /node_modules and /bower_components >> >> a) should add one more profile to clean even caches, e.g. -Pforce-clean >> b) or do not clean it at all and document that if one needs completely fresh sources, he should clean manually by "git clean -f -x -d" and "npm cache clean" >> >> >> - Maybe we can minify some JS dependencies and don't build >> everything altogether? >> >> I built an image[1][2], because developers willing to just use UPS with the >> latest bits might struggle to configure their environment and maybe it >> can be helpful. >> >> The image is not perfect and soon will be moved to jboss/dockerfiles. >> >> Thoughts? >> >> [1] - https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev >> [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> Also, someone suggested to use wro4j - as long as it is vital alternative for the build time, wro4j is really not handy for development, you won't get as quick turnaround as with Grunt. >> >> Some plugins we use doesn't even have to be available in wro4j, e.g. ngtemplates, ngmin. >> >> >> >> Making the build straight-forward is an ongoing, continuous process and we have still lot to investigate here. It can't definitely be finished in 1.0 time. >> >> Bear in mind that Node/NPM is very young technology and it will take some time to get it to the state where Maven is (if ever). >> >> In the meantime, I encourage you to use this awesome docker image Bruno created! >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/fa01acfb/attachment-0001.html From matzew at apache.org Wed Aug 6 08:58:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 14:58:49 +0200 Subject: [aerogear-dev] UPS with Keycloak beta4 In-Reply-To: <20140806125413.GB88078@abstractj.org> References: <20140806112336.GA88078@abstractj.org> <20140806125413.GB88078@abstractj.org> Message-ID: as said in the PR - works great on Openshift. If one wants to try. It's simple: rhc app create --no-git https://cartreflect-claytondev.rhcloud.com/reflect?github=matzew/openshift-origin-cartridge-aerogear-push&commit=1a23d7fd5f05be6a8cd9f3616643d61612205c64 On Wed, Aug 6, 2014 at 2:54 PM, Bruno Oliveira wrote: > +1 Already tested UPS in non SSL environments, Keycloak forbid the access > like expected > > On 2014-08-06, Matthias Wessendorf wrote: > > awesome work! > > > > I am now testing this. > > > > I'd prefer we merge this one, before we merege the other outstanding PRs > ... > > > > -Matthias > > > > > > On Wed, Aug 6, 2014 at 1:23 PM, Bruno Oliveira > wrote: > > > > > Good morning, UPS with Keycloak beta4 is available for testing and > > > feedback. > > > > > > Please test it > > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/341. > Bonus > > > points if you find bugs. > > > > > > Thanks in advance. > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/c11d8e5d/attachment.html From bruno at abstractj.org Wed Aug 6 09:10:37 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 6 Aug 2014 10:10:37 -0300 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: References: <20140805195607.GA56126@abstractj.org> Message-ID: <20140806131037.GC88078@abstractj.org> Ahoy, answers inline. On 2014-08-06, Luk?? Fry? wrote: > Hey Bruno, > > awesome job with the docker image! > Could we mention that in the README? Sure thing, glad you enjoyed. > > > I've created this issue to track improvements in the build itself: > https://issues.jboss.org/browse/AGPUSH-881 Thanks a lot. > > Responds inline: > > On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira wrote: > > > Good morning peeps, > > > > I would like to open this thread to discuss some ideas about how to > > improve the current build on Push server. Lukas have been doing a > > stellar job improving it and I think we can help. > > > > Yesterday I spent some time trying to build a developer environment for > > UPS ? was a good exercise to realize how people feel trying to contribute. > > The goal was to build the environment from scratch. > > > > Here comes some feedback (keep in mind that I'm not that good on Node.js) > > > > - Build our dependencies takes a considerable time. For fair > > reasons, we are running mvn install, npm install and bo > > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/wer > > install > > for the first time. Maybe we can reduce one step? > > > > We cannot avoid Maven and if we want really fresh compiled-from-sources > approach (as opposed to store-compiled-to-git what we had before), we need > go with both, Bower and NPM. > > Storing NPM deps in /node_modules is platform-dependent > Bummer, got it. That makes sense. > . > > We could store there Bower dependencies though. We can use exportsOverride > > section to extract just those files from our dependencies that we actually > require in the project. Once updated, we can save them. > > But once you have NPM installed correctly, it's just a small step to > running Bower. If is just a small step let's leave it as is. > > > > > > - Java developers don't have their environment ready for Node ? it can > > be a blocker. For example, was necessary to install gcc, libpng and > > libpng-devel. I already saw team members struggling with it, like me. > > > > This is a blocker, I wasn't even aware of it - we may want to choose other > plugins that don't require those dependencies or maybe inspect what grunt > plugins we are even using. Do we even need some of those Grunt plugins like > PNG minification (imagemin)? Maybe we can improve here! Remove imagemin would be a win, once it requires libpng and libpng-devel. (not sure about the impact of removing it) > > > > > > - Maybe we should run -Pdev by default and run the complete build only > > for CI. > > > > Yes, we have to come with sensible defaults. We store our NPM/Bower caches > inside the project structure and we clean them with each clean. This is > anti-pattern - in Java analogy - it's cleaning .m2/repository for each > build - we should clean them just when we explicitly want to. -Pdev would > stay here, but it would just remove /node_modules and /bower_components > > a) should add one more profile to clean even caches, e.g. -Pforce-clean > b) or do not clean it at all and document that if one needs completely > fresh sources, he should clean manually by "git clean -f -x -d" and "npm > cache clean" To me the idea of having a profile to clean everything if they want to, is a good idea. And what would be the default? -Pdev? > > > > > > - Maybe we can minify some JS dependencies and don't build > > everything altogether? > > > > I built an image[1][2], because developers willing to just use UPS with the > > latest bits might struggle to configure their environment and maybe it > > can be helpful. > > > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > > > Thoughts? > > > > [1] - > > https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > > -- > > > > Also, someone suggested to use wro4j - as long as it is vital alternative > for the build time, wro4j is really not handy for development, you won't > get as quick turnaround as with Grunt. +1 on keep Grunt > > Some plugins we use doesn't even have to be available in wro4j, e.g. > ngtemplates, ngmin. > > > > Making the build straight-forward is an ongoing, continuous process and we > have still lot to investigate here. It can't definitely be finished in 1.0 > time. +1 my friend, deal with the build and multiple technologies is not that easy. We can alwasy improve, thanks for looking at it. > > Bear in mind that Node/NPM is very young technology and it will take some > time to get it to the state where Maven is (if ever). > > In the meantime, I encourage you to use this awesome docker image Bruno > created! > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From supittma at redhat.com Wed Aug 6 09:43:28 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 06 Aug 2014 09:43:28 -0400 Subject: [aerogear-dev] Swift - Frameworks/Static libs and Cocoapods In-Reply-To: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> References: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> Message-ID: <53E23100.9090106@redhat.com> On 07/22/2014 04:09 AM, Christos Vasilakis wrote: > Hi all, > > want to give a heads up on the current status of Swift frameworks/static libs generation and cocoapods support. This is based on the current state of affairs, as in Xcode beta 4 (released yesterday). > > Note: "Since rapid developments are taking place, will update this thread as more information becomes available and with any breaking changes" > > First, let me start by making three observations: > > a) quoting Apple release notes[1], "Xcode does not support building static libraries that include Swift code?. You can notice that in Xcode 6 when choosing ?Cocoa Touch Static Library? there is no option to select ?Swift? as the preferred language. > > b) new in Xcode 6 is the generation of ?dynamic? frameworks for library targets. The reason for ?dynamic? linking, as explained by apple in [2], is to enable the new functionality in iOS 8 called ?extensions?. Per apple quote "Frameworks work perfectly with extensions, sharing logic that can be used by both the main application, and the bundled extensions? > > c) Dynamic framework for a swift library (the only option offered by Xcode) , in the current state requires the source code of the library to be build together with the app that uses it. This is due to the binary interface, which has not being finalised yet. Quoting apple blog [3] ("Binary Compatibility and Frameworks? section): > > ? > "While your app?s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together. > > This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift ? especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.? > ? > > What does all that gives us? > In plain form, "Distribution of the push-sdk (swift port) should be done in source form with polished documentation on how the user can add it to their own project.? > > Already, looking at the various swift-libs currently in existence[4], that is the current approach, a well-written README.md on how the user can add the library dependency into their own projects. For example, something like the section ?How to Install Library? found here [5] > > As for cocoapods, currently no support is provided for swift projects. There is an on-going discussion on the issues list found here [6] on how to effectively support ?dynamic framework? for swift projects, and still keep backwards compatibility, but things are not yet finalised. > > Let me know your thoughts / comments. > > Thanks, > Christos > > [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf > [2] https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14 > [3] https://developer.apple.com/swift/blog/?id=2 > [4] http://www.swifttoolbox.io > [5] https://github.com/Quick/Quick > [6] https://github.com/CocoaPods/CocoaPods/issues/2272 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev Thanks for keeping us up to date. I'm having flashbacks of Eclipse and ADT... -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From lukas.fryc at gmail.com Wed Aug 6 09:55:33 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 6 Aug 2014 15:55:33 +0200 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: <20140806131037.GC88078@abstractj.org> References: <20140805195607.GA56126@abstractj.org> <20140806131037.GC88078@abstractj.org> Message-ID: On Wed, Aug 6, 2014 at 3:10 PM, Bruno Oliveira wrote: > Ahoy, answers inline. > > On 2014-08-06, Luk?? Fry? wrote: > > Hey Bruno, > > > > awesome job with the docker image! > > Could we mention that in the README? > > Sure thing, glad you enjoyed. > > > > > > > I've created this issue to track improvements in the build itself: > > https://issues.jboss.org/browse/AGPUSH-881 > > Thanks a lot. > > > > > Responds inline: > > > > On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira > wrote: > > > > > Good morning peeps, > > > > > > I would like to open this thread to discuss some ideas about how to > > > improve the current build on Push server. Lukas have been doing a > > > stellar job improving it and I think we can help. > > > > > > Yesterday I spent some time trying to build a developer environment for > > > UPS ? was a good exercise to realize how people feel trying to > contribute. > > > The goal was to build the environment from scratch. > > > > > > Here comes some feedback (keep in mind that I'm not that good on > Node.js) > > > > > > - Build our dependencies takes a considerable time. For fair > > > reasons, we are running mvn install, npm install and bo > > > > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/wer > > > install > > > for the first time. Maybe we can reduce one step? > > > > > > > We cannot avoid Maven and if we want really fresh compiled-from-sources > > approach (as opposed to store-compiled-to-git what we had before), we > need > > go with both, Bower and NPM. > > > > Storing NPM deps in /node_modules is platform-dependent > > < > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/ > > > > Bummer, got it. That makes sense. > > . > > > > We could store there Bower dependencies though. We can use > exportsOverride > > < > https://github.com/liveoak-io/liveoak/blob/master/console/src/main/resources/bower.json#L28 > > > > section to extract just those files from our dependencies that we > actually > > require in the project. Once updated, we can save them. > > > > But once you have NPM installed correctly, it's just a small step to > > running Bower. > > If is just a small step let's leave it as is. > > > > > > > > > > - Java developers don't have their environment ready for Node ? it can > > > be a blocker. For example, was necessary to install gcc, libpng and > > > libpng-devel. I already saw team members struggling with it, like me. > > > > > > > This is a blocker, I wasn't even aware of it - we may want to choose > other > > plugins that don't require those dependencies or maybe inspect what grunt > > plugins we are even using. Do we even need some of those Grunt plugins > like > > PNG minification (imagemin)? > > Maybe we can improve here! Remove imagemin would be a win, once it > requires libpng and libpng-devel. (not sure about the impact of removing > it) > > > > > > > > > > > - Maybe we should run -Pdev by default and run the complete build only > > > for CI. > > > > > > > Yes, we have to come with sensible defaults. We store our NPM/Bower > caches > > inside the project structure and we clean them with each clean. This is > > anti-pattern - in Java analogy - it's cleaning .m2/repository for each > > build - we should clean them just when we explicitly want to. -Pdev would > > stay here, but it would just remove /node_modules and /bower_components > > > > a) should add one more profile to clean even caches, e.g. -Pforce-clean > > b) or do not clean it at all and document that if one needs completely > > fresh sources, he should clean manually by "git clean -f -x -d" and "npm > > cache clean" > > To me the idea of having a profile to clean everything if they want to, > is a good idea. And what would be the default? -Pdev? > [admin-ui/] $ mvn clean install # clean .tmp/ dist/ [admin-ui/] $ mvn clean install -Dforce-clean # clean .tmp/ dist/ node_modules/ bower_components/ and caches (.build-tmp/) # this is recommended for continuous integration Good news is that our toolchain (NPM, Bower and frontend-maven-plugin) fully reacts on changes in versions (package.json, bower.json and pom.xml). So if you change dependency versions in those configuration files you should get new versions installed pro-actively even with $ mvn clean install, no need for cleaning anything. At the end we should get this: $ mvn clean install -------------------------- BUILD SUCCESS -------------------------- Total time: 14.376s -------------------------- > > > > > > > > > > - Maybe we can minify some JS dependencies and don't build > > > everything altogether? > > > > > > I built an image[1][2], because developers willing to just use UPS > with the > > > latest bits might struggle to configure their environment and maybe it > > > can be helpful. > > > > > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > > > > > Thoughts? > > > > > > [1] - > > > > https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > > > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > > > -- > > > > > > > Also, someone suggested to use wro4j - as long as it is vital alternative > > for the build time, wro4j is really not handy for development, you won't > > get as quick turnaround as with Grunt. > > +1 on keep Grunt > > > > > Some plugins we use doesn't even have to be available in wro4j, e.g. > > ngtemplates, ngmin. > > > > > > > > Making the build straight-forward is an ongoing, continuous process and > we > > have still lot to investigate here. It can't definitely be finished in > 1.0 > > time. > > +1 my friend, deal with the build and multiple technologies is not that > easy. We can alwasy improve, thanks for looking at it. > > > > > Bear in mind that Node/NPM is very young technology and it will take some > > time to get it to the state where Maven is (if ever). > > > > In the meantime, I encourage you to use this awesome docker image Bruno > > created! > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/a34b9be5/attachment-0001.html From lukas.fryc at gmail.com Wed Aug 6 09:57:54 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 6 Aug 2014 15:57:54 +0200 Subject: [aerogear-dev] Update Node Sender for UnifiedPush Server In-Reply-To: <1AAB6FD7-E9D5-4114-A3AC-94B14E988FFC@redhat.com> References: <1AAB6FD7-E9D5-4114-A3AC-94B14E988FFC@redhat.com> Message-ID: Nice! On Wed, Aug 6, 2014 at 2:53 PM, Lucas Holmquist wrote: > For those of you who don?t read my blog, tsk tsk, the UnifiedPush node > sender was updated > > Hello. > > A new version of the node sender client for the AeroGear UnifiedPush > server is now up on npm > > https://www.npmjs.org/package/unifiedpush-node-sender > > You will notice that the name has of the *module has changed* > > This was done to fall in line with the other sender clients, such as the > unifiedpush-java-sender > > If you want to get the latest source, has a look see here > https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/releases/latest > > Have a Good One. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/fc1e6e87/attachment.html From matzew at apache.org Wed Aug 6 09:59:11 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 15:59:11 +0200 Subject: [aerogear-dev] Update Node Sender for UnifiedPush Server In-Reply-To: References: <1AAB6FD7-E9D5-4114-A3AC-94B14E988FFC@redhat.com> Message-ID: yay On Wed, Aug 6, 2014 at 3:57 PM, Luk?? Fry? wrote: > Nice! > > > On Wed, Aug 6, 2014 at 2:53 PM, Lucas Holmquist > wrote: > >> For those of you who don?t read my blog, tsk tsk, the UnifiedPush node >> sender was updated >> >> Hello. >> >> A new version of the node sender client for the AeroGear UnifiedPush >> server is now up on npm >> >> https://www.npmjs.org/package/unifiedpush-node-sender >> >> You will notice that the name has of the *module has changed* >> >> This was done to fall in line with the other sender clients, such as the >> unifiedpush-java-sender >> >> If you want to get the latest source, has a look see here >> https://github.com/aerogear/aerogear-unifiedpush-nodejs-client/releases/latest >> >> Have a Good One. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/42cec3c9/attachment.html From matzew at apache.org Wed Aug 6 10:03:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 16:03:37 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: References: Message-ID: Due to silence for quite a while, I have the impression there is no new release of our "Cordova Push Plugin" needed :-) That's fine, but please keep in mind that for the UPS 1.0.0, the versions of the different client SDKs need to go to 1.0.0 as well On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf wrote: > Hi, > > looked at the change log of the Cordova Plugin and there were some fixes > since the last 0.6.0 release. > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > Any thoughts? > > Thanks, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/b2c7744c/attachment.html From matzew at apache.org Wed Aug 6 10:30:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 16:30:53 +0200 Subject: [aerogear-dev] new parent release Message-ID: mainly to get the underlying KC-beta4 dependencies sorted: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3663/ -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/e9c68684/attachment.html From bruno at abstractj.org Wed Aug 6 10:31:25 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 6 Aug 2014 11:31:25 -0300 Subject: [aerogear-dev] Update Node Sender for UnifiedPush Server In-Reply-To: <1AAB6FD7-E9D5-4114-A3AC-94B14E988FFC@redhat.com> References: <1AAB6FD7-E9D5-4114-A3AC-94B14E988FFC@redhat.com> Message-ID: <20140806143125.GA95252@abstractj.org> I'm reading your blog, what did I win? On 2014-08-06, Lucas Holmquist wrote: > For those of you who don?t read my blog, tsk tsk, the UnifiedPush node sender was updated > > Hello. > > A new version of the node sender client for the AeroGear UnifiedPush server is now up on npm > > https://www.npmjs.org/package/unifiedpush-node-sender > > You will notice that the name has of the module has changed > > This was done to fall in line with the other sender clients, such as the unifiedpush-java-sender > > If you want to get the latest source, has a look see herehttps://github.com/aerogear/aerogear-unifiedpush-nodejs-client/releases/latest > > Have a Good One. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Wed Aug 6 10:32:43 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 6 Aug 2014 16:32:43 +0200 Subject: [aerogear-dev] Update Node Sender for UnifiedPush Server In-Reply-To: <20140806143125.GA95252@abstractj.org> References: <1AAB6FD7-E9D5-4114-A3AC-94B14E988FFC@redhat.com> <20140806143125.GA95252@abstractj.org> Message-ID: nice! On 6 August 2014 16:31, Bruno Oliveira wrote: > I'm reading your blog, what did I win? > > On 2014-08-06, Lucas Holmquist wrote: > > For those of you who don?t read my blog, tsk tsk, the UnifiedPush node > sender was updated > > > > Hello. > > > > A new version of the node sender client for the AeroGear UnifiedPush > server is now up on npm > > > > https://www.npmjs.org/package/unifiedpush-node-sender > > > > You will notice that the name has of the module has changed > > > > This was done to fall in line with the other sender clients, such as the > unifiedpush-java-sender > > > > If you want to get the latest source, has a look see herehttps:// > github.com/aerogear/aerogear-unifiedpush-nodejs-client/releases/latest > > > > Have a Good One. > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/4083e437/attachment-0001.html From rhauch at redhat.com Wed Aug 6 10:47:28 2014 From: rhauch at redhat.com (Randall Hauch) Date: Wed, 6 Aug 2014 09:47:28 -0500 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> <53DF99F6.1090604@redhat.com> <53E0308D.2050103@redhat.com> <99B4D3FB-AEBF-453B-B611-52182C9613B5@redhat.com> Message-ID: <2383104F-5FF1-4617-850D-19BE26985E71@redhat.com> On Aug 6, 2014, at 1:27 AM, Daniel Bevenius wrote: > On 6 August 2014 00:34, Jay Balunas wrote: > > I actually this this a very good point (as have other points on both sides). We will rely on people like you Randall to assist us in understanding the impact and advocate for the deeper server-side needs. While at the same time the client side APIs and developer experience will also need to be reviewed and taken into consideration. > > I think it is important to remember that all of these are POC's and I think with a problem domain as complex as this, before we get to actual cross-project implementation we need to develop and flush out specs, including all of these various points, risks, etc... This would be across data services, liveoak and aerogear and possibly others. > > I think limiting the scope of this for now and enabling the underlying choice of storage/data service to be flexible will allow us to cater for the complex enterprise as well as a the simpler use cases which are important too if we want people to start using this and trying it out. Agree that the POCs should be focused and limited. Has someone already looked at techniques that involve the client asking for which documents (satisfying some criteria defined by the subscription) have changed since the time the client last connected, and then as needed having the client ask for the latest version of some/all of those documents (or parts of those documents)? I know that?s not ideal from the client perspective, but this is extremely simple for the service to do. In fact, doing more than this in the service gets very expensive and very complicated very quickly. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/94aa8f9c/attachment.html From matzew at apache.org Wed Aug 6 11:07:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 17:07:28 +0200 Subject: [aerogear-dev] Preparation: UnifiedPush Server 1.0.0.Beta2 (was: Re: [UnifiedPush Server] release timelines) Message-ID: Hi team, now that keycloak-beta4 was released, we have an updated PR from abstractj to use that version ([1]), combined w/ an upcoming release of our parent (to leverage the kc-beta4 JARs), see [2]. At the moment we have a few open PRs: https://github.com/aerogear/aerogear-unifiedpush-server/pulls Please review, but DO NOT merge them! Why? The KC PR goes in first, afterwards I will merge the other items, based on review feedback. By tomorrow that all should be done (read: merged) and there will be a staged repo for tests (and openshift updates), watch out for the email! As mentioned on IRC, the nominees for the testing, are: * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj Besides testing the UPS staging repo, please test our quickstarts (including their client SDKs) as well: * https://github.com/aerogear/aerogear-push-helloworld * https://github.com/aerogear/aerogear-push-quickstarts (use the master branch - there will be a .Beta2 TAG, if all goes well there) Last but not least, please 'test' the documentation as well. For instance the new UPS guide: http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ or other items of the new 'UPS doc center' :-) http://staging.aerogear.org/docs/unifiedpush Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after that we can go to CODE_FREEZE for the 1.0.0.Final Any thoughts ? -Matthias PS: others, besides the nominated folks, are welcome to test the things as well :) -Matthias [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008658.html [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008672.html On Fri, Aug 1, 2014 at 6:35 AM, Matthias Wessendorf wrote: > Hi team, > > based on [1] I thought about our release timelines until 1.0.0.Final, and > shortly after. > > - > > 1.0.0.Beta2 > : > 07/Aug/14 > > This needs to include Keycloak-beta4, and might slip by one day, but not > much more of a delay. > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/ca4a7bad/attachment.html From bruno at abstractj.org Wed Aug 6 12:43:47 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 6 Aug 2014 13:43:47 -0300 Subject: [aerogear-dev] Docker image to try UPS with Keycloak beta4 Message-ID: <20140806164347.GA12898@abstractj.org> Good morning, my name is Bruno and I'm Docker addicted. I just pushed a new image to Docker hub with the binaries based on https://github.com/aerogear/aerogear-unifiedpush-server/pull/341. If you want to test please follow the instructions here: https://registry.hub.docker.com/u/abstractj/unifiedpush/. Please notice the tag for KC-beta4. -- abstractj PGP: 0x84DC9914 From cvasilak at gmail.com Wed Aug 6 13:44:21 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 6 Aug 2014 20:44:21 +0300 Subject: [aerogear-dev] new parent release In-Reply-To: References: Message-ID: Hi, tested using the following configuration and have build and run successfully both on jboss and wildfly. +1 Below is a log: (Note: started clean with rm -rf .m2/repository) $ java -version java version "1.7.0_67" Java(TM) SE Runtime Environment (build 1.7.0_67-b01) Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) $ mvn -version Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 18:22:22+0300) Maven home: /Applications/apache-maven-3.1.1 Java version: 1.7.0_67, vendor: Oracle Corporation Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac" $/aerogear-parent (KeycloakBeta4)$ mvn clean install ... $/keycloak-1.0-beta-4$ mvn clean install ... $/aerogear-unifiedpush-server (KeycloakBeta4_no_bootstrap)$ mvn clean install ... ----all steps succeeded??--- running mvn clean jboss-as:deploy on jboss-as-7.1.1.Final succeeded +1 running mvn -Pwildfly clean wildfly:deploy on wildfly-8.1.0.Final succeeded +1 Only got some warns from maven when building for some missing 'version' but not sure if its my configuration. If is feel free to ignore Apart from it, +1 worked smoothly! - Christos On Aug 6, 2014, at 5:30 PM, Matthias Wessendorf wrote: > mainly to get the underlying KC-beta4 dependencies sorted: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3663/ > > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/306bd67b/attachment-0001.html From scm.blanc at gmail.com Wed Aug 6 14:40:57 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 6 Aug 2014 20:40:57 +0200 Subject: [aerogear-dev] new parent release In-Reply-To: References: Message-ID: Did the same tests as Christos, used the staged parent to build and deploy UPS( KC.Beta4 branch). All good ! +1 On Wed, Aug 6, 2014 at 7:44 PM, Christos Vasilakis wrote: > Hi, > > tested using the following configuration and have build and run > successfully both on jboss and wildfly. +1 > > Below is a log: > > (Note: started clean with rm -rf .m2/repository) > > > $ java -version > java version "1.7.0_67" > Java(TM) SE Runtime Environment (build 1.7.0_67-b01) > Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) > > $ mvn -version > Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 18:22:22+0300) > Maven home: /Applications/apache-maven-3.1.1 > Java version: 1.7.0_67, vendor: Oracle Corporation > Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac" > > $/aerogear-parent (KeycloakBeta4)$ mvn clean install > ... > $/keycloak-1.0-beta-4$ mvn clean install > ... > $/aerogear-unifiedpush-server (KeycloakBeta4_no_bootstrap)$ mvn clean install > ... > > > ----all steps succeeded??--- > > running mvn clean jboss-as:deploy on jboss-as-7.1.1.Final succeeded +1 > > running mvn -Pwildfly clean wildfly:deploy on wildfly-8.1.0.Final succeeded > +1 > > Only got some warns > from maven when > building for some missing 'version' but not sure if its my configuration. > If is feel free to ignore > > Apart from it, +1 worked smoothly! > - > Christos > > > On Aug 6, 2014, at 5:30 PM, Matthias Wessendorf wrote: > > mainly to get the underlying KC-beta4 dependencies sorted: > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3663/ > > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/f37124db/attachment.html From matzew at apache.org Wed Aug 6 15:38:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 21:38:24 +0200 Subject: [aerogear-dev] new parent release In-Reply-To: References: Message-ID: Thanks for testing. I will push the 'release button' in a bit. That enables us to have both, kc-beta4 and 0.2.6 parent on Maven-Central by tomorrow, for merging abstractj's KC-beta4 PR against UPS! -M On Wed, Aug 6, 2014 at 8:40 PM, Sebastien Blanc wrote: > Did the same tests as Christos, used the staged parent to build and deploy > UPS( KC.Beta4 branch). > All good ! > +1 > > > > On Wed, Aug 6, 2014 at 7:44 PM, Christos Vasilakis > wrote: > >> Hi, >> >> tested using the following configuration and have build and run >> successfully both on jboss and wildfly. +1 >> >> Below is a log: >> >> (Note: started clean with rm -rf .m2/repository) >> >> >> $ java -version >> java version "1.7.0_67" >> Java(TM) SE Runtime Environment (build 1.7.0_67-b01) >> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) >> >> $ mvn -version >> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 18:22:22+0300) >> Maven home: /Applications/apache-maven-3.1.1 >> Java version: 1.7.0_67, vendor: Oracle Corporation >> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre >> Default locale: en_US, platform encoding: UTF-8 >> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac" >> >> $/aerogear-parent (KeycloakBeta4)$ mvn clean install >> ... >> $/keycloak-1.0-beta-4$ mvn clean install >> ... >> $/aerogear-unifiedpush-server (KeycloakBeta4_no_bootstrap)$ mvn clean install >> ... >> >> >> ----all steps succeeded??--- >> >> running mvn clean jboss-as:deploy on jboss-as-7.1.1.Final succeeded +1 >> >> running mvn -Pwildfly clean wildfly:deploy on wildfly-8.1.0.Final succeeded >> +1 >> >> Only got some warns >> from maven when >> building for some missing 'version' but not sure if its my configuration. >> If is feel free to ignore >> >> Apart from it, +1 worked smoothly! >> - >> Christos >> >> >> On Aug 6, 2014, at 5:30 PM, Matthias Wessendorf >> wrote: >> >> mainly to get the underlying KC-beta4 dependencies sorted: >> >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3663/ >> >> >> -Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/d4d772cf/attachment.html From matzew at apache.org Wed Aug 6 16:40:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 6 Aug 2014 22:40:57 +0200 Subject: [aerogear-dev] new parent release In-Reply-To: References: Message-ID: The pom files are on their way to maven central On Wed, Aug 6, 2014 at 9:38 PM, Matthias Wessendorf wrote: > Thanks for testing. > > I will push the 'release button' in a bit. That enables us to have both, > kc-beta4 and 0.2.6 parent on Maven-Central by tomorrow, for merging > abstractj's KC-beta4 PR against UPS! > > > -M > > > On Wed, Aug 6, 2014 at 8:40 PM, Sebastien Blanc > wrote: > >> Did the same tests as Christos, used the staged parent to build and >> deploy UPS( KC.Beta4 branch). >> All good ! >> +1 >> >> >> >> On Wed, Aug 6, 2014 at 7:44 PM, Christos Vasilakis >> wrote: >> >>> Hi, >>> >>> tested using the following configuration and have build and run >>> successfully both on jboss and wildfly. +1 >>> >>> Below is a log: >>> >>> (Note: started clean with rm -rf .m2/repository) >>> >>> >>> $ java -version >>> java version "1.7.0_67" >>> Java(TM) SE Runtime Environment (build 1.7.0_67-b01) >>> Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) >>> >>> $ mvn -version >>> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 18:22:22+0300) >>> Maven home: /Applications/apache-maven-3.1.1 >>> Java version: 1.7.0_67, vendor: Oracle Corporation >>> Java home: /Library/Java/JavaVirtualMachines/jdk1.7.0_67.jdk/Contents/Home/jre >>> Default locale: en_US, platform encoding: UTF-8 >>> OS name: "mac os x", version: "10.9.4", arch: "x86_64", family: "mac" >>> >>> $/aerogear-parent (KeycloakBeta4)$ mvn clean install >>> ... >>> $/keycloak-1.0-beta-4$ mvn clean install >>> ... >>> $/aerogear-unifiedpush-server (KeycloakBeta4_no_bootstrap)$ mvn clean install >>> ... >>> >>> >>> ----all steps succeeded??--- >>> >>> running mvn clean jboss-as:deploy on jboss-as-7.1.1.Final succeeded +1 >>> >>> running mvn -Pwildfly clean wildfly:deploy on wildfly-8.1.0.Final succeeded >>> +1 >>> >>> Only got some warns >>> from maven when >>> building for some missing 'version' but not sure if its my configuration. >>> If is feel free to ignore >>> >>> Apart from it, +1 worked smoothly! >>> - >>> Christos >>> >>> >>> On Aug 6, 2014, at 5:30 PM, Matthias Wessendorf >>> wrote: >>> >>> mainly to get the underlying KC-beta4 dependencies sorted: >>> >>> >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3663/ >>> >>> >>> -Matthias >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140806/0faef19f/attachment-0001.html From bruno at abstractj.org Thu Aug 7 03:21:54 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Aug 2014 04:21:54 -0300 Subject: [aerogear-dev] SSL configuration all over the place Message-ID: <20140807072154.GA68549@abstractj.org> Good morning my friends, SSL setup can be painful. So I made it for you: https://registry.hub.docker.com/u/abstractj/unifiedpush/ If you already suffered with it, feedback with what's missing is welcome. -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Thu Aug 7 06:40:46 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 7 Aug 2014 12:40:46 +0200 Subject: [aerogear-dev] Use of Differential Synchronization for data sync In-Reply-To: <2383104F-5FF1-4617-850D-19BE26985E71@redhat.com> References: <36AD5F9D-31D4-406C-B8CD-25E639187C0C@redhat.com> <53DF99F6.1090604@redhat.com> <53E0308D.2050103@redhat.com> <99B4D3FB-AEBF-453B-B611-52182C9613B5@redhat.com> <2383104F-5FF1-4617-850D-19BE26985E71@redhat.com> Message-ID: >Has someone already looked at techniques that involve the client asking for which documents (satisfying some criteria defined by the subscription) >have changed since the time the client last connected, and then as needed having the client ask for the latest version of some/all of those documents >(or parts of those documents)? Not that I'm aware of, at least I have not. The need for a client to ask for which document have changed did not really come up with the current demo using DS. The way this demo works is that there are multiple clients that edit a document identified with an documentId. The first client that connects adds the document, the following new clients will get the latest version that is on the server. For client that are reconnecting after being offline they will get patched with the edits to bring it up to date. Regarding how efficient this is that is probably is not :) The goals is mainly to try things out and see if would work out in real life. On 6 August 2014 16:47, Randall Hauch wrote: > > On Aug 6, 2014, at 1:27 AM, Daniel Bevenius > wrote: > > On 6 August 2014 00:34, Jay Balunas wrote: > >> >> I actually this this a very good point (as have other points on both >> sides). We will rely on people like you Randall to assist us in >> understanding the impact and advocate for the deeper server-side needs. >> While at the same time the client side APIs and developer experience will >> also need to be reviewed and taken into consideration. >> >> I think it is important to remember that all of these are POC's and I >> think with a problem domain as complex as this, before we get to actual >> cross-project implementation we need to develop and flush out specs, >> including all of these various points, risks, etc... This would be across >> data services, liveoak and aerogear and possibly others. >> > > I think limiting the scope of this for now and enabling the underlying > choice of storage/data service to be flexible will allow us to cater for > the complex enterprise as well as a the simpler use cases which are > important too if we want people to start using this and trying it out. > > > Agree that the POCs should be focused and limited. > > Has someone already looked at techniques that involve the client asking > for which documents (satisfying some criteria defined by the subscription) > have changed since the time the client last connected, and then as needed > having the client ask for the latest version of some/all of those documents > (or parts of those documents)? I know that?s not ideal from the client > perspective, but this is extremely simple for the service to do. In fact, > doing more than this in the service gets very expensive and very > complicated very quickly. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140807/85ae2d81/attachment.html From marcpiresrj at gmail.com Thu Aug 7 07:58:56 2014 From: marcpiresrj at gmail.com (Marc Pires) Date: Thu, 7 Aug 2014 08:58:56 -0300 Subject: [aerogear-dev] text/html Requests instead of application/json Message-ID: Hi guys, i'm having a little trouble with an app i'm developing. Doing a post request against an API, I receive from the server that my request is going as text/html instead application/json, text/javascript or text/json that the API expects. As I never had this problem before, i research the docs but did not found the reference yet, so how can i define my request to go as application/json instead text/html -- Desenvolvedor IOS, Rails, RIA http://www.linkedin.com/in/marcpires http://about.me/marcelo_pires -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140807/d03c433c/attachment.html From cvasilak at gmail.com Thu Aug 7 08:05:40 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 7 Aug 2014 15:05:40 +0300 Subject: [aerogear-dev] text/html Requests instead of application/json In-Reply-To: References: Message-ID: <6C0F0006-4DDD-4135-9CE0-FC9F3591E731@gmail.com> Hi Marc, thanks for your email. Mind to be a little specific on the details e.g. what kind of platform are you using, and what API are u going against too. It will be easier for us to identify the issue and offer some help. - Christos On Aug 7, 2014, at 2:58 PM, Marc Pires wrote: > Hi guys, i'm having a little trouble with an app i'm developing. Doing a post request against an API, I receive from the server that my request is going as text/html instead application/json, text/javascript or text/json that the API expects. > > As I never had this problem before, i research the docs but did not found the reference yet, so how can i define my request to go as application/json instead text/html > > -- > Desenvolvedor IOS, Rails, RIA > > http://www.linkedin.com/in/marcpires > http://about.me/marcelo_pires > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140807/7479c2d7/attachment.html From antoine.matyja at worldline.com Thu Aug 7 08:06:55 2014 From: antoine.matyja at worldline.com (A577127) Date: Thu, 7 Aug 2014 05:06:55 -0700 (PDT) Subject: [aerogear-dev] text/html Requests instead of application/json In-Reply-To: References: Message-ID: <1407413215281-8781.post@n5.nabble.com> In your POST request, you must set the "Content-Type" header to "application/json". -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-text-html-Requests-instead-of-application-json-tp8779p8781.html Sent from the aerogear-dev mailing list archive at Nabble.com. From daniel.bevenius at gmail.com Thu Aug 7 09:06:27 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 7 Aug 2014 15:06:27 +0200 Subject: [aerogear-dev] Docker image to try UPS with Keycloak beta4 In-Reply-To: <20140806164347.GA12898@abstractj.org> References: <20140806164347.GA12898@abstractj.org> Message-ID: Nice work Bruno! So I'm testing the aerogear-push-quickstart [1]. And there are a few different combinations here which need to be tested with regards to the server. The clients quickstart need to have the contacts-mobile-picketlink-secured deployed and contacts-mobile-webapp to run against. If we could provide an image for that I think that might save time testing. Also having an image for the proxy quickstart which requires three servers, contacts-mobile-picketlink-secured, contacts-mobile-webapp, and contacts-mobile-proxy deployed and running on different ports. I think this would save some time for us when doing manual tests. [1] https://github.com/aerogear/aerogear-push-quickstarts On 6 August 2014 18:43, Bruno Oliveira wrote: > Good morning, my name is Bruno and I'm Docker addicted. I just pushed a > new image to Docker hub with the binaries based on > https://github.com/aerogear/aerogear-unifiedpush-server/pull/341. > > If you want to test please follow the instructions here: > https://registry.hub.docker.com/u/abstractj/unifiedpush/. > > Please notice the tag for KC-beta4. > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140807/b987c190/attachment.html From daniel at passos.me Thu Aug 7 09:43:37 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 7 Aug 2014 10:43:37 -0300 Subject: [aerogear-dev] Docker image to try UPS with Keycloak beta4 In-Reply-To: References: <20140806164347.GA12898@abstractj.org> Message-ID: On Thu, Aug 7, 2014 at 10:06 AM, Daniel Bevenius wrote: > Nice work Bruno! > > So I'm testing the aerogear-push-quickstart [1]. And there are a few > different combinations here which need to be tested with regards to the > server. The clients quickstart need to have the > contacts-mobile-picketlink-secured deployed and contacts-mobile-webapp to > run against. If we could provide an image for that I think that might save > time testing. > > Also having an image for the proxy quickstart which requires three > servers, contacts-mobile-picketlink-secured, contacts-mobile-webapp, and > contacts-mobile-proxy deployed and running on different ports. I think this > would save some time for us when doing manual tests. > +9001 > [1] https://github.com/aerogear/aerogear-push-quickstarts > > > On 6 August 2014 18:43, Bruno Oliveira wrote: > >> Good morning, my name is Bruno and I'm Docker addicted. I just pushed a >> new image to Docker hub with the binaries based on >> https://github.com/aerogear/aerogear-unifiedpush-server/pull/341. >> >> If you want to test please follow the instructions here: >> https://registry.hub.docker.com/u/abstractj/unifiedpush/. >> >> Please notice the tag for KC-beta4. >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140807/b0b6b846/attachment-0001.html From matzew at apache.org Thu Aug 7 10:10:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 7 Aug 2014 16:10:55 +0200 Subject: [aerogear-dev] [UnifiedPush Server] release timelines In-Reply-To: References: <71D8CDD4-373B-4BD2-89AA-4432641C4E2E@redhat.com> Message-ID: On Tue, Aug 5, 2014 at 2:00 PM, Matthias Wessendorf wrote: > There might be a little delay, when we can release our own 1.0.0.Final, > since I found a KC bug that occurs only w/ MySQL and EAP 6.3.Beta: > http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002388.html > > was not a bug on KC - was JBoss AS7.x (EAP) that was no longer happy w/ the CLI. This has been fixedm and there is no reason to delay the 1.0.0.Final for a week to pick up KC's RC-1 release. The integration of RC-1 will happen in 1.0.1 release http://staging.aerogear.org/docs/planning/roadmaps/UnifiedPush/#_1_0_1_early_september_2014 -Matthias > In case this fix makes it into Keycloak's RC-1 (instead of beta-4 - which > seems reasonable to me), we should be waiting a few more days to pick up > their RC-1 in our final. That means we could release the same week (e.g. > 22nd), or exactly one week later - on 25th of August. > > Things are being discussed atm, this is just a heads-up ... > > > -Matthias > > > > > On Fri, Aug 1, 2014 at 3:19 PM, Matthias Wessendorf > wrote: > >> here we go: >> >> https://github.com/aerogear/aerogear.org/pull/343 >> >> >> On Fri, Aug 1, 2014 at 2:47 PM, Lucas Holmquist >> wrote: >> >>> ++ sounds/looks good >>> On Aug 1, 2014, at 12:35 AM, Matthias Wessendorf >>> wrote: >>> >>> Hi team, >>> >>> based on [1] I thought about our release timelines until 1.0.0.Final, >>> and shortly after. >>> >>> - >>> >>> 1.0.0.Beta2 >>> : >>> 07/Aug/14 >>> >>> This needs to include Keycloak-beta4, and might slip by one day, but not >>> much more of a delay. >>> >>> *Please note:* There is already works going on to have our parent and >>> UPS working w/ beta4 - it?s just a matter of merging the branch, once the >>> release is out. >>> >>> Number of open JIRAs for this release is looking good! >>> >>> - >>> >>> 1.0.0 >>> : >>> 18/Aug/14 >>> >>> *Keycloak:* This will use keycloak?s beta4 as well, unless we find >>> BLOCKERS in their beta4... (As said before KC is mostly hidden inside the >>> server, and we can not wait for their 1.0.0.Final in September) >>> >>> This release will be mostly around docs and perhaps some more UX review >>> of the quickstart demos. It is possible that the UX review does not happen. >>> >>> *CODE FREEZE:* I?d suggest we do a *code freeze* for the UnifiedPush >>> Server on 11/Aug/14. This is pretty much shortly after the beta2 and gives >>> us one week of deep testing (of server, docs, demos) before the final >>> release. >>> >>> Next: *celebrate*!!!!!!!! [image: :tada:] >>> >>> After the 1.0.0.Final of UPS, I?d suggest a two week-based release >>> series of small fixes and improvements, as well as taking up new Keycloak >>> releases >>> >>> - >>> >>> 1.0.1 >>> : >>> 01/Sep/14 >>> >>> *Keycloak:* main reason is pick-up of their 1.0-RC-1 and those few >>> items from the JIRA. >>> >>> - >>> >>> 1.0.2 >>> : >>> 15/Sep/14 >>> >>> *Keycloak:* main reason is pick-up of their 1.0.0.Final >>> >>> - >>> >>> 1.0.3 >>> >>> :29/Sep/14 >>> >>> Might not be needed - but added it to JIRA, just in case? >>> >>> Let me know your thoughts and I will update the roadmap! >>> >>> -Matthias >>> >>> [1] http://lists.jboss.org/pipermail/keycloak-dev/2014-July/002360.html >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140807/290dafac/attachment.html From bsutter at redhat.com Thu Aug 7 10:11:37 2014 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 7 Aug 2014 10:11:37 -0400 Subject: [aerogear-dev] text/html Requests instead of application/json In-Reply-To: <1407413215281-8781.post@n5.nabble.com> References: <1407413215281-8781.post@n5.nabble.com> Message-ID: <7C187B3C-A87D-4D15-B83F-9BE0B82CA70F@redhat.com> The request can also include Accept: application/json That may instruct the server to respond with JSON instead of its default of HTML. Depends on the remote server/service. On Aug 7, 2014, at 8:06 AM, A577127 wrote: > In your POST request, you must set the "Content-Type" header to > "application/json". > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-text-html-Requests-instead-of-application-json-tp8779p8781.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140807/69d23764/attachment.html From bruno at abstractj.org Thu Aug 7 10:51:07 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Aug 2014 11:51:07 -0300 Subject: [aerogear-dev] text/html Requests instead of application/json In-Reply-To: References: Message-ID: <20140807145106.GA69609@abstractj.org> Good morning Marc, if possible would you mind to gist a code snippet with what are you trying to do? On 2014-08-07, Marc Pires wrote: > Hi guys, i'm having a little trouble with an app i'm developing. Doing a > post request against an API, I receive from the server that my request is > going as text/html instead application/json, text/javascript or text/json > that the API expects. > > As I never had this problem before, i research the docs but did not found > the reference yet, so how can i define my request to go as application/json > instead text/html > > -- > Desenvolvedor IOS, Rails, RIA > > http://www.linkedin.com/in/marcpires > http://about.me/marcelo_pires > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Thu Aug 7 11:35:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 7 Aug 2014 17:35:36 +0200 Subject: [aerogear-dev] Preparation: UnifiedPush Server 1.0.0.Beta2 (was: Re: [UnifiedPush Server] release timelines) In-Reply-To: References: Message-ID: Hi team, a little update On Wed, Aug 6, 2014 at 5:07 PM, Matthias Wessendorf wrote: > Hi team, > > > now that keycloak-beta4 was released, we have an updated PR from abstractj > to use that version ([1]), combined w/ an upcoming release of our parent > (to leverage the kc-beta4 JARs), see [2]. > > At the moment we have a few open PRs: > https://github.com/aerogear/aerogear-unifiedpush-server/pulls > > Please review, but DO NOT merge them! Why? The KC PR goes in first, > afterwards I will merge the other items, based on review feedback. > > By tomorrow that all should be done (read: merged) and there will be a > staged repo for tests (and openshift updates), watch out for the email! > The staging will happen early Friday morning (German time), mainly to allow us a smooth finish of the on-going testing and review of the last two PRs. We are really close! YAY! team++ > As mentioned on IRC, the nominees for the testing, are: > * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > sblanc is out the next two weeks - we will find someone else :-) -Matthias > > Besides testing the UPS staging repo, please test our quickstarts > (including their client SDKs) as well: > * https://github.com/aerogear/aerogear-push-helloworld > * https://github.com/aerogear/aerogear-push-quickstarts > > (use the master branch - there will be a .Beta2 TAG, if all goes well > there) > > Last but not least, please 'test' the documentation as well. For instance > the new UPS guide: > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > or other items of the new 'UPS doc center' :-) > http://staging.aerogear.org/docs/unifiedpush > > > Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after > that we can go to CODE_FREEZE for the 1.0.0.Final > > Any thoughts ? > > -Matthias > > PS: others, besides the nominated folks, are welcome to test the things as > well :) > > > -Matthias > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008658.html > [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008672.html > > > On Fri, Aug 1, 2014 at 6:35 AM, Matthias Wessendorf > wrote: > >> Hi team, >> >> based on [1] I thought about our release timelines until 1.0.0.Final, and >> shortly after. >> >> - >> >> 1.0.0.Beta2 >> : >> 07/Aug/14 >> >> This needs to include Keycloak-beta4, and might slip by one day, but not >> much more of a delay. >> > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140807/d1876f21/attachment.html From bruno at abstractj.org Thu Aug 7 15:14:14 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Aug 2014 16:14:14 -0300 Subject: [aerogear-dev] Preparation: UnifiedPush Server 1.0.0.Beta2 (was: Re: [UnifiedPush Server] release timelines) In-Reply-To: References: Message-ID: <20140807191414.GA87049@abstractj.org> +1 stage the Kraken! On 2014-08-06, Matthias Wessendorf wrote: > Hi team, > > > now that keycloak-beta4 was released, we have an updated PR from abstractj > to use that version ([1]), combined w/ an upcoming release of our parent > (to leverage the kc-beta4 JARs), see [2]. > > At the moment we have a few open PRs: > https://github.com/aerogear/aerogear-unifiedpush-server/pulls > > Please review, but DO NOT merge them! Why? The KC PR goes in first, > afterwards I will merge the other items, based on review feedback. > > By tomorrow that all should be done (read: merged) and there will be a > staged repo for tests (and openshift updates), watch out for the email! > > As mentioned on IRC, the nominees for the testing, are: > * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > > Besides testing the UPS staging repo, please test our quickstarts > (including their client SDKs) as well: > * https://github.com/aerogear/aerogear-push-helloworld > * https://github.com/aerogear/aerogear-push-quickstarts > > (use the master branch - there will be a .Beta2 TAG, if all goes well there) > > Last but not least, please 'test' the documentation as well. For instance > the new UPS guide: > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > or other items of the new 'UPS doc center' :-) > http://staging.aerogear.org/docs/unifiedpush > > > Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after > that we can go to CODE_FREEZE for the 1.0.0.Final > > Any thoughts ? > > -Matthias > > PS: others, besides the nominated folks, are welcome to test the things as > well :) > > > -Matthias > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008658.html > [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008672.html > > > On Fri, Aug 1, 2014 at 6:35 AM, Matthias Wessendorf > wrote: > > > Hi team, > > > > based on [1] I thought about our release timelines until 1.0.0.Final, and > > shortly after. > > > > - > > > > 1.0.0.Beta2 > > : > > 07/Aug/14 > > > > This needs to include Keycloak-beta4, and might slip by one day, but not > > much more of a delay. > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 7 15:17:59 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Aug 2014 16:17:59 -0300 Subject: [aerogear-dev] Preparation: UnifiedPush Server 1.0.0.Beta2 (was: Re: [UnifiedPush Server] release timelines) In-Reply-To: References: Message-ID: <20140807191759.GB87049@abstractj.org> Hi Matthias, to make it easy to our scripts and being selfish, Docker. Do you think that's possible to have our artifacts named with the suffix "-latest.tar.gz" at bintray for example? Something like: auth-server-latest.tar.gz ups-server-latest.tar.gz On 2014-08-07, Matthias Wessendorf wrote: > Hi team, > > a little update > > > On Wed, Aug 6, 2014 at 5:07 PM, Matthias Wessendorf > wrote: > > > Hi team, > > > > > > now that keycloak-beta4 was released, we have an updated PR from abstractj > > to use that version ([1]), combined w/ an upcoming release of our parent > > (to leverage the kc-beta4 JARs), see [2]. > > > > At the moment we have a few open PRs: > > https://github.com/aerogear/aerogear-unifiedpush-server/pulls > > > > Please review, but DO NOT merge them! Why? The KC PR goes in first, > > afterwards I will merge the other items, based on review feedback. > > > > By tomorrow that all should be done (read: merged) and there will be a > > staged repo for tests (and openshift updates), watch out for the email! > > > > The staging will happen early Friday morning (German time), mainly to allow > us a smooth finish of the on-going testing and review of the last two PRs. > We are really close! YAY! team++ > > > > > As mentioned on IRC, the nominees for the testing, are: > > * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > > > > sblanc is out the next two weeks - we will find someone else :-) > > -Matthias > > > > > > Besides testing the UPS staging repo, please test our quickstarts > > (including their client SDKs) as well: > > * https://github.com/aerogear/aerogear-push-helloworld > > * https://github.com/aerogear/aerogear-push-quickstarts > > > > (use the master branch - there will be a .Beta2 TAG, if all goes well > > there) > > > > Last but not least, please 'test' the documentation as well. For instance > > the new UPS guide: > > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > > > or other items of the new 'UPS doc center' :-) > > http://staging.aerogear.org/docs/unifiedpush > > > > > > Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after > > that we can go to CODE_FREEZE for the 1.0.0.Final > > > > Any thoughts ? > > > > -Matthias > > > > PS: others, besides the nominated folks, are welcome to test the things as > > well :) > > > > > > -Matthias > > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008658.html > > [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008672.html > > > > > > On Fri, Aug 1, 2014 at 6:35 AM, Matthias Wessendorf > > wrote: > > > >> Hi team, > >> > >> based on [1] I thought about our release timelines until 1.0.0.Final, and > >> shortly after. > >> > >> - > >> > >> 1.0.0.Beta2 > >> : > >> 07/Aug/14 > >> > >> This needs to include Keycloak-beta4, and might slip by one day, but not > >> much more of a delay. > >> > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 7 15:26:26 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Aug 2014 16:26:26 -0300 Subject: [aerogear-dev] Docker image to try UPS with Keycloak beta4 In-Reply-To: References: <20140806164347.GA12898@abstractj.org> Message-ID: <20140807192626.GC87049@abstractj.org> Included your considerations here: https://issues.jboss.org/browse/AEROGEAR-1480. Not sure about the timing, but will do that for sure. On 2014-08-07, Daniel Bevenius wrote: > Nice work Bruno! > > So I'm testing the aerogear-push-quickstart [1]. And there are a few > different combinations here which need to be tested with regards to the > server. The clients quickstart need to have the > contacts-mobile-picketlink-secured deployed and contacts-mobile-webapp to > run against. If we could provide an image for that I think that might save > time testing. > > Also having an image for the proxy quickstart which requires three servers, > contacts-mobile-picketlink-secured, contacts-mobile-webapp, and > contacts-mobile-proxy deployed and running on different ports. I think this > would save some time for us when doing manual tests. > > > [1] https://github.com/aerogear/aerogear-push-quickstarts > > > On 6 August 2014 18:43, Bruno Oliveira wrote: > > > Good morning, my name is Bruno and I'm Docker addicted. I just pushed a > > new image to Docker hub with the binaries based on > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/341. > > > > If you want to test please follow the instructions here: > > https://registry.hub.docker.com/u/abstractj/unifiedpush/. > > > > Please notice the tag for KC-beta4. > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 7 15:52:00 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Aug 2014 16:52:00 -0300 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: References: Message-ID: <20140807195159.GA87785@abstractj.org> I also think that our roadmap should reflect the reality: http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ Erik any thoughts? Otherwise I will consider to do a full review of Cordova and take over it. On 2014-08-06, Matthias Wessendorf wrote: > Due to silence for quite a while, I have the impression there is no new > release of our "Cordova Push Plugin" needed :-) > > > That's fine, but please keep in mind that for the UPS 1.0.0, the versions > of the different client SDKs need to go to 1.0.0 as well > > > > On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf > wrote: > > > Hi, > > > > looked at the change log of the Cordova Plugin and there were some fixes > > since the last 0.6.0 release. > > > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on > > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > > > Any thoughts? > > > > Thanks, > > Matthias > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 7 15:54:06 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Aug 2014 16:54:06 -0300 Subject: [aerogear-dev] AeroGear UnifiedPush server build feedback In-Reply-To: References: <20140805195607.GA56126@abstractj.org> <20140806131037.GC88078@abstractj.org> Message-ID: <20140807195406.GB87785@abstractj.org> Nice Lukas, thank you for the effort. Let's stick with your suggestions. On 2014-08-06, Luk?? Fry? wrote: > On Wed, Aug 6, 2014 at 3:10 PM, Bruno Oliveira wrote: > > > Ahoy, answers inline. > > > > On 2014-08-06, Luk?? Fry? wrote: > > > Hey Bruno, > > > > > > awesome job with the docker image! > > > Could we mention that in the README? > > > > Sure thing, glad you enjoyed. > > > > > > > > > > > I've created this issue to track improvements in the build itself: > > > https://issues.jboss.org/browse/AGPUSH-881 > > > > Thanks a lot. > > > > > > > > Responds inline: > > > > > > On Tue, Aug 5, 2014 at 9:56 PM, Bruno Oliveira > > wrote: > > > > > > > Good morning peeps, > > > > > > > > I would like to open this thread to discuss some ideas about how to > > > > improve the current build on Push server. Lukas have been doing a > > > > stellar job improving it and I think we can help. > > > > > > > > Yesterday I spent some time trying to build a developer environment for > > > > UPS ? was a good exercise to realize how people feel trying to > > contribute. > > > > The goal was to build the environment from scratch. > > > > > > > > Here comes some feedback (keep in mind that I'm not that good on > > Node.js) > > > > > > > > - Build our dependencies takes a considerable time. For fair > > > > reasons, we are running mvn install, npm install and bo > > > > > > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/wer > > > > install > > > > for the first time. Maybe we can reduce one step? > > > > > > > > > > We cannot avoid Maven and if we want really fresh compiled-from-sources > > > approach (as opposed to store-compiled-to-git what we had before), we > > need > > > go with both, Bower and NPM. > > > > > > Storing NPM deps in /node_modules is platform-dependent > > > < > > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/ > > > > > > > Bummer, got it. That makes sense. > > > . > > > > > > We could store there Bower dependencies though. We can use > > exportsOverride > > > < > > https://github.com/liveoak-io/liveoak/blob/master/console/src/main/resources/bower.json#L28 > > > > > > section to extract just those files from our dependencies that we > > actually > > > require in the project. Once updated, we can save them. > > > > > > But once you have NPM installed correctly, it's just a small step to > > > running Bower. > > > > If is just a small step let's leave it as is. > > > > > > > > > > > > > > - Java developers don't have their environment ready for Node ? it can > > > > be a blocker. For example, was necessary to install gcc, libpng and > > > > libpng-devel. I already saw team members struggling with it, like me. > > > > > > > > > > This is a blocker, I wasn't even aware of it - we may want to choose > > other > > > plugins that don't require those dependencies or maybe inspect what grunt > > > plugins we are even using. Do we even need some of those Grunt plugins > > like > > > PNG minification (imagemin)? > > > > Maybe we can improve here! Remove imagemin would be a win, once it > > requires libpng and libpng-devel. (not sure about the impact of removing > > it) > > > > > > > > > > > > > > > > - Maybe we should run -Pdev by default and run the complete build only > > > > for CI. > > > > > > > > > > Yes, we have to come with sensible defaults. We store our NPM/Bower > > caches > > > inside the project structure and we clean them with each clean. This is > > > anti-pattern - in Java analogy - it's cleaning .m2/repository for each > > > build - we should clean them just when we explicitly want to. -Pdev would > > > stay here, but it would just remove /node_modules and /bower_components > > > > > > a) should add one more profile to clean even caches, e.g. -Pforce-clean > > > b) or do not clean it at all and document that if one needs completely > > > fresh sources, he should clean manually by "git clean -f -x -d" and "npm > > > cache clean" > > > > To me the idea of having a profile to clean everything if they want to, > > is a good idea. And what would be the default? -Pdev? > > > > [admin-ui/] $ mvn clean install > # clean .tmp/ dist/ > > [admin-ui/] $ mvn clean install -Dforce-clean > # clean .tmp/ dist/ node_modules/ bower_components/ and caches > (.build-tmp/) > # this is recommended for continuous integration > > Good news is that our toolchain (NPM, Bower and frontend-maven-plugin) > fully reacts on changes in versions (package.json, bower.json and pom.xml). > > So if you change dependency versions in those configuration files you > should get new versions installed pro-actively even with $ mvn clean > install, no need for cleaning anything. > > At the end we should get this: > > $ mvn clean install > -------------------------- > BUILD SUCCESS > -------------------------- > Total time: 14.376s > -------------------------- > > > > > > > > > > > > > > > > - Maybe we can minify some JS dependencies and don't build > > > > everything altogether? > > > > > > > > I built an image[1][2], because developers willing to just use UPS > > with the > > > > latest bits might struggle to configure their environment and maybe it > > > > can be helpful. > > > > > > > > The image is not perfect and soon will be moved to jboss/dockerfiles. > > > > > > > > Thoughts? > > > > > > > > [1] - > > > > > > https://github.com/abstractj/docker/tree/master/aerogear-unifiedpush-dev > > > > [2] - https://registry.hub.docker.com/u/abstractj/unifiedpush-dev/ > > > > -- > > > > > > > > > > Also, someone suggested to use wro4j - as long as it is vital alternative > > > for the build time, wro4j is really not handy for development, you won't > > > get as quick turnaround as with Grunt. > > > > +1 on keep Grunt > > > > > > > > Some plugins we use doesn't even have to be available in wro4j, e.g. > > > ngtemplates, ngmin. > > > > > > > > > > > > Making the build straight-forward is an ongoing, continuous process and > > we > > > have still lot to investigate here. It can't definitely be finished in > > 1.0 > > > time. > > > > +1 my friend, deal with the build and multiple technologies is not that > > easy. We can alwasy improve, thanks for looking at it. > > > > > > > > Bear in mind that Node/NPM is very young technology and it will take some > > > time to get it to the state where Maven is (if ever). > > > > > > In the meantime, I encourage you to use this awesome docker image Bruno > > > created! > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 7 16:22:29 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 7 Aug 2014 17:22:29 -0300 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: <20140807195159.GA87785@abstractj.org> References: <20140807195159.GA87785@abstractj.org> Message-ID: <20140807202229.GA89272@abstractj.org> Erik is on PTO, my bad. Anyone would like to join me reviewing Jiras and helping with a proposal to the roadmap? On 2014-08-07, Bruno Oliveira wrote: > I also think that our roadmap should reflect the reality: > http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ > > Erik any thoughts? Otherwise I will consider to do a full review of Cordova and > take over it. > > On 2014-08-06, Matthias Wessendorf wrote: > > Due to silence for quite a while, I have the impression there is no new > > release of our "Cordova Push Plugin" needed :-) > > > > > > That's fine, but please keep in mind that for the UPS 1.0.0, the versions > > of the different client SDKs need to go to 1.0.0 as well > > > > > > > > On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf > > wrote: > > > > > Hi, > > > > > > looked at the change log of the Cordova Plugin and there were some fixes > > > since the last 0.6.0 release. > > > > > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on > > > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > > > > > Any thoughts? > > > > > > Thanks, > > > Matthias > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 -- abstractj PGP: 0x84DC9914 From scm.blanc at gmail.com Thu Aug 7 17:11:02 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Thu, 7 Aug 2014 23:11:02 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: <20140807202229.GA89272@abstractj.org> References: <20140807195159.GA87785@abstractj.org> <20140807202229.GA89272@abstractj.org> Message-ID: <0CF49279-7F24-4A1F-8364-7B48882FA83D@gmail.com> I will try tomorrow to find some time to draft a first roadmap that takes into account the other roadmaps (UPS, iOS , Android and Sec). Than we will need to check if they are matching jiras / create jiras Envoy? de mon iPhone > Le 7 ao?t 2014 ? 22:22, Bruno Oliveira a ?crit : > > Erik is on PTO, my bad. Anyone would like to join me reviewing Jiras and helping > with a proposal to the roadmap? > >> On 2014-08-07, Bruno Oliveira wrote: >> I also think that our roadmap should reflect the reality: >> http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ >> >> Erik any thoughts? Otherwise I will consider to do a full review of Cordova and >> take over it. >> >>> On 2014-08-06, Matthias Wessendorf wrote: >>> Due to silence for quite a while, I have the impression there is no new >>> release of our "Cordova Push Plugin" needed :-) >>> >>> >>> That's fine, but please keep in mind that for the UPS 1.0.0, the versions >>> of the different client SDKs need to go to 1.0.0 as well >>> >>> >>> >>> On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf >>> wrote: >>> >>>> Hi, >>>> >>>> looked at the change log of the Cordova Plugin and there were some fixes >>>> since the last 0.6.0 release. >>>> >>>> Before we run the Beta2 of UPS (around 6th of August, depends a bit on >>>> Keycloak's beta4) I'd like to get a 0.7.0 release out. >>>> >>>> Any thoughts? >>>> >>>> Thanks, >>>> Matthias >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Aug 8 00:54:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 8 Aug 2014 06:54:50 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: <20140807195159.GA87785@abstractj.org> References: <20140807195159.GA87785@abstractj.org> Message-ID: On Thu, Aug 7, 2014 at 9:52 PM, Bruno Oliveira wrote: > I also think that our roadmap should reflect the reality: > http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ Not sure about the other plugins, but for push the reality is that it is stable and releases are only needed on demand. After 0.6.0 we had some bug-fixes, but no new features. That still qualifies the original request for a 0.7.0 release, but I think it is hard to 'plan' bug-fix releases. -Matthias > > > Erik any thoughts? Otherwise I will consider to do a full review of > Cordova and > take over it. > > On 2014-08-06, Matthias Wessendorf wrote: > > Due to silence for quite a while, I have the impression there is no new > > release of our "Cordova Push Plugin" needed :-) > > > > > > That's fine, but please keep in mind that for the UPS 1.0.0, the versions > > of the different client SDKs need to go to 1.0.0 as well > > > > > > > > On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf > > > wrote: > > > > > Hi, > > > > > > looked at the change log of the Cordova Plugin and there were some > fixes > > > since the last 0.6.0 release. > > > > > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on > > > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > > > > > Any thoughts? > > > > > > Thanks, > > > Matthias > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/c283b65b/attachment.html From scm.blanc at gmail.com Fri Aug 8 01:57:09 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 8 Aug 2014 07:57:09 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: References: <20140807195159.GA87785@abstractj.org> Message-ID: On Fri, Aug 8, 2014 at 6:54 AM, Matthias Wessendorf wrote: > > > > On Thu, Aug 7, 2014 at 9:52 PM, Bruno Oliveira > wrote: > >> I also think that our roadmap should reflect the reality: >> http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ > > > > Not sure about the other plugins, but for push the reality is that it is > stable and releases are only needed on demand. > After 0.6.0 we had some bug-fixes, but no new features. That still > qualifies the original request for a 0.7.0 release, but I think it is hard > to 'plan' bug-fix releases. > But we could try to stick to the UPS roadmap. So, for instance, instead of doing a 0.7.0 release, we could give it version 1.0 and (if needed), release along with UPS : End of August : 1.0 (Between UPS 1.0.0 and 1.1) 1.0.X releases when needed (native SDK push lib update / bug fixe on cordova parts) 1.1 : Support for other platform (ffos / Windows / Amazon ?) wdyt ? > -Matthias > > >> >> >> Erik any thoughts? Otherwise I will consider to do a full review of >> Cordova and >> take over it. >> >> On 2014-08-06, Matthias Wessendorf wrote: >> > Due to silence for quite a while, I have the impression there is no new >> > release of our "Cordova Push Plugin" needed :-) >> > >> > >> > That's fine, but please keep in mind that for the UPS 1.0.0, the >> versions >> > of the different client SDKs need to go to 1.0.0 as well >> > >> > >> > >> > On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf < >> matzew at apache.org> >> > wrote: >> > >> > > Hi, >> > > >> > > looked at the change log of the Cordova Plugin and there were some >> fixes >> > > since the last 0.6.0 release. >> > > >> > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on >> > > Keycloak's beta4) I'd like to get a 0.7.0 release out. >> > > >> > > Any thoughts? >> > > >> > > Thanks, >> > > Matthias >> > > >> > > -- >> > > Matthias Wessendorf >> > > >> > > blog: http://matthiaswessendorf.wordpress.com/ >> > > sessions: http://www.slideshare.net/mwessendorf >> > > twitter: http://twitter.com/mwessendorf >> > > >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/33c175cd/attachment-0001.html From scm.blanc at gmail.com Fri Aug 8 02:14:25 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 8 Aug 2014 08:14:25 +0200 Subject: [aerogear-dev] Preparation: UnifiedPush Server 1.0.0.Beta2 (was: Re: [UnifiedPush Server] release timelines) In-Reply-To: References: Message-ID: On Wed, Aug 6, 2014 at 5:07 PM, Matthias Wessendorf wrote: > Hi team, > > > now that keycloak-beta4 was released, we have an updated PR from abstractj > to use that version ([1]), combined w/ an upcoming release of our parent > (to leverage the kc-beta4 JARs), see [2]. > > At the moment we have a few open PRs: > https://github.com/aerogear/aerogear-unifiedpush-server/pulls > > Please review, but DO NOT merge them! Why? The KC PR goes in first, > afterwards I will merge the other items, based on review feedback. > > By tomorrow that all should be done (read: merged) and there will be a > staged repo for tests (and openshift updates), watch out for the email! > > As mentioned on IRC, the nominees for the testing, are: > * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > > Besides testing the UPS staging repo, please test our quickstarts > (including their client SDKs) as well: > * https://github.com/aerogear/aerogear-push-helloworld > * https://github.com/aerogear/aerogear-push-quickstarts > Keep in mind this is quite a big part : we have a lot of combination for these clients, we have 10 flavors : - helloworld-ios / helloworld-android / helloworld-cordova-android / helloworld-cordova-ios - quickstart-ios / quickstart-android / quickstart-cordova-jqm-android / quickstart-cordova-jqm-ios / quickstart-cordova-ionic-ios / quickstart-cordova-ionic-android > > > (use the master branch - there will be a .Beta2 TAG, if all goes well > there) > > Last but not least, please 'test' the documentation as well. For instance > the new UPS guide: > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > or other items of the new 'UPS doc center' :-) > http://staging.aerogear.org/docs/unifiedpush > > > Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after > that we can go to CODE_FREEZE for the 1.0.0.Final > > Any thoughts ? > > -Matthias > > PS: others, besides the nominated folks, are welcome to test the things as > well :) > > > -Matthias > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008658.html > [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008672.html > > > On Fri, Aug 1, 2014 at 6:35 AM, Matthias Wessendorf > wrote: > >> Hi team, >> >> based on [1] I thought about our release timelines until 1.0.0.Final, and >> shortly after. >> >> - >> >> 1.0.0.Beta2 >> : >> 07/Aug/14 >> >> This needs to include Keycloak-beta4, and might slip by one day, but not >> much more of a delay. >> > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/2da23b9e/attachment.html From matzew at apache.org Fri Aug 8 02:53:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 8 Aug 2014 08:53:05 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: References: <20140807195159.GA87785@abstractj.org> Message-ID: On Fri, Aug 8, 2014 at 7:57 AM, Sebastien Blanc wrote: > > > > On Fri, Aug 8, 2014 at 6:54 AM, Matthias Wessendorf > wrote: > >> >> >> >> On Thu, Aug 7, 2014 at 9:52 PM, Bruno Oliveira >> wrote: >> >>> I also think that our roadmap should reflect the reality: >>> http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ >> >> >> >> Not sure about the other plugins, but for push the reality is that it is >> stable and releases are only needed on demand. >> After 0.6.0 we had some bug-fixes, but no new features. That still >> qualifies the original request for a 0.7.0 release, but I think it is hard >> to 'plan' bug-fix releases. >> > > But we could try to stick to the UPS roadmap. > sure - exception: bug / security fixes :) > So, for instance, instead of doing a 0.7.0 release, we could give it > version 1.0 and (if needed), release along with UPS : > > End of August : 1.0 > +1 but have in mind that the native SDKs, bundle w/ the plugin, need to go 1.0.0 first ;-) > > (Between UPS 1.0.0 and 1.1) 1.0.X releases when needed (native SDK push > lib update / bug fixe on cordova parts) > > 1.1 : Support for other platform (ffos / Windows / Amazon ?) > +1 on that > > wdyt ? > > >> -Matthias >> >> >>> >>> >>> Erik any thoughts? Otherwise I will consider to do a full review of >>> Cordova and >>> take over it. >>> >>> On 2014-08-06, Matthias Wessendorf wrote: >>> > Due to silence for quite a while, I have the impression there is no new >>> > release of our "Cordova Push Plugin" needed :-) >>> > >>> > >>> > That's fine, but please keep in mind that for the UPS 1.0.0, the >>> versions >>> > of the different client SDKs need to go to 1.0.0 as well >>> > >>> > >>> > >>> > On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf < >>> matzew at apache.org> >>> > wrote: >>> > >>> > > Hi, >>> > > >>> > > looked at the change log of the Cordova Plugin and there were some >>> fixes >>> > > since the last 0.6.0 release. >>> > > >>> > > Before we run the Beta2 of UPS (around 6th of August, depends a bit >>> on >>> > > Keycloak's beta4) I'd like to get a 0.7.0 release out. >>> > > >>> > > Any thoughts? >>> > > >>> > > Thanks, >>> > > Matthias >>> > > >>> > > -- >>> > > Matthias Wessendorf >>> > > >>> > > blog: http://matthiaswessendorf.wordpress.com/ >>> > > sessions: http://www.slideshare.net/mwessendorf >>> > > twitter: http://twitter.com/mwessendorf >>> > > >>> > >>> > >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/99553dd7/attachment.html From bruno at abstractj.org Fri Aug 8 05:03:14 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 8 Aug 2014 06:03:14 -0300 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: References: <20140807195159.GA87785@abstractj.org> Message-ID: <20140808090314.GA19027@abstractj.org> On 2014-08-08, Matthias Wessendorf wrote: > On Thu, Aug 7, 2014 at 9:52 PM, Bruno Oliveira wrote: > > > I also think that our roadmap should reflect the reality: > > http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ > > > > Not sure about the other plugins, but for push the reality is that it is > stable and releases are only needed on demand. > After 0.6.0 we had some bug-fixes, but no new features. That still > qualifies the original request for a 0.7.0 release, but I think it is hard > to 'plan' bug-fix releases. Releases on demand? IMO this is wrong, even for bug fixes we should plan when it will be fixed. > > -Matthias > > > > > > > > Erik any thoughts? Otherwise I will consider to do a full review of > > Cordova and > > take over it. > > > > On 2014-08-06, Matthias Wessendorf wrote: > > > Due to silence for quite a while, I have the impression there is no new > > > release of our "Cordova Push Plugin" needed :-) > > > > > > > > > That's fine, but please keep in mind that for the UPS 1.0.0, the versions > > > of the different client SDKs need to go to 1.0.0 as well > > > > > > > > > > > > On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf > > > > > wrote: > > > > > > > Hi, > > > > > > > > looked at the change log of the Cordova Plugin and there were some > > fixes > > > > since the last 0.6.0 release. > > > > > > > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on > > > > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > > > > > > > Any thoughts? > > > > > > > > Thanks, > > > > Matthias > > > > > > > > -- > > > > Matthias Wessendorf > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Fri Aug 8 05:14:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 8 Aug 2014 11:14:19 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: <20140808090314.GA19027@abstractj.org> References: <20140807195159.GA87785@abstractj.org> <20140808090314.GA19027@abstractj.org> Message-ID: On Fri, Aug 8, 2014 at 11:03 AM, Bruno Oliveira wrote: > On 2014-08-08, Matthias Wessendorf wrote: > > On Thu, Aug 7, 2014 at 9:52 PM, Bruno Oliveira > wrote: > > > > > I also think that our roadmap should reflect the reality: > > > http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ > > > > > > > > Not sure about the other plugins, but for push the reality is that it is > > stable and releases are only needed on demand. > > After 0.6.0 we had some bug-fixes, but no new features. That still > > qualifies the original request for a 0.7.0 release, but I think it is > hard > > to 'plan' bug-fix releases. > > Releases on demand? IMO this is wrong, even for bug fixes we should plan > when it will be fixed. > Regarding, releasing (not fixing) on demand, I think common sense rules here. Example: We have 1.0.0 out in August and next is planed late October. But in early September a lot of critical items came up, why ever. They got fixed. IMO it would be a demand to do a release before the original planed late October release. In that case the roadmap needs to be updated and reflect that, I fully agree. I think we are on the same page here. -Matthias > > > > > -Matthias > > > > > > > > > > > > > Erik any thoughts? Otherwise I will consider to do a full review of > > > Cordova and > > > take over it. > > > > > > On 2014-08-06, Matthias Wessendorf wrote: > > > > Due to silence for quite a while, I have the impression there is no > new > > > > release of our "Cordova Push Plugin" needed :-) > > > > > > > > > > > > That's fine, but please keep in mind that for the UPS 1.0.0, the > versions > > > > of the different client SDKs need to go to 1.0.0 as well > > > > > > > > > > > > > > > > On Tue, Jul 29, 2014 at 11:55 PM, Matthias Wessendorf < > matzew at apache.org > > > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > looked at the change log of the Cordova Plugin and there were some > > > fixes > > > > > since the last 0.6.0 release. > > > > > > > > > > Before we run the Beta2 of UPS (around 6th of August, depends a > bit on > > > > > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > > > > > > > > > Any thoughts? > > > > > > > > > > Thanks, > > > > > Matthias > > > > > > > > > > -- > > > > > Matthias Wessendorf > > > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > > sessions: http://www.slideshare.net/mwessendorf > > > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > twitter: http://twitter.com/mwessendorf > > > > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/3920d114/attachment.html From matzew at apache.org Fri Aug 8 07:51:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 8 Aug 2014 13:51:13 +0200 Subject: [aerogear-dev] UPS: Java Sender release (0.9.0) Message-ID: Hi, I'd like to release the 0.9.0 version of the java-sender. The staging repo is here: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3672/ Changes since last release: * usage of latest parent * Improvements on doc Please test and let me know! Thanks! -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/ec06a389/attachment.html From bruno at abstractj.org Fri Aug 8 07:52:39 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 08 Aug 2014 04:52:39 -0700 (PDT) Subject: [aerogear-dev] UPS: Java Sender release (0.9.0) In-Reply-To: References: Message-ID: <1407498759447.0a8ad5a7@Nodemailer> When?? abstractj PGP: 0x84DC9914 On Fri, Aug 8, 2014 at 8:51 AM, Matthias Wessendorf wrote: > Hi, > I'd like to release the 0.9.0 version of the java-sender. The staging repo > is here: > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3672/ > Changes since last release: > * usage of latest parent > * Improvements on doc > Please test and let me know! > Thanks! > -- > Matthias Wessendorf > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/cf59eacc/attachment.html From kpiwko at redhat.com Fri Aug 8 08:03:54 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Fri, 08 Aug 2014 12:05:54 +0002 Subject: [aerogear-dev] SSL configuration all over the place In-Reply-To: <20140807072154.GA68549@abstractj.org> References: <20140807072154.GA68549@abstractj.org> Message-ID: <1407499434.6077.1@smtp.corp.redhat.com> Good morning abstractj, this is great stuff, I was able to run AS7 one smoothly! Just the links are broken - missing ':' character. Karel On Thu, Aug 7, 2014 at 9:21 AM, Bruno Oliveira wrote: > Good morning my friends, SSL setup can be painful. So I made it for > you: > https://registry.hub.docker.com/u/abstractj/unifiedpush/ > > If you already suffered with it, feedback with what's missing is > welcome. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Aug 8 08:16:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 8 Aug 2014 14:16:39 +0200 Subject: [aerogear-dev] UPS: Java Sender release (0.9.0) In-Reply-To: References: Message-ID: I plan to push to Maven Central on late Tuesday, as discussed in Monday's meeting. Looks like I forgot to copy the "REPLACE DATE HERE" line from my template On Fri, Aug 8, 2014 at 1:51 PM, Matthias Wessendorf wrote: > Hi, > > I'd like to release the 0.9.0 version of the java-sender. The staging repo > is here: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3672/ > > > Changes since last release: > * usage of latest parent > * Improvements on doc > > Please test and let me know! > > Thanks! > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/a6eb85dd/attachment-0001.html From matzew at apache.org Fri Aug 8 08:52:00 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 8 Aug 2014 14:52:00 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta2 Message-ID: Hello folks! we are getting closer and closer to our 1.0.0 release! Thank you very much, guys! However, before we are moving towards the 1.0.0.Final community release, I'd love to get the current work out as 1.0.0.Beta2 Note this release contains a ton of work and new features. To name a few highlights: * Keycloak beta-4 usage * Wildfly support * new documentation guide on UPS * various improvements on the server and its UI! The did an outstanding job to get the Beta2 done. Details on all the JIRAs can be found here: https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092 The staging repository is located here: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3670/ NOTE: Once this release has been approved the matching tag will be used to get the OpenShift online bits updated! Let me know the results of your testing! If I hear nothing bad by Tuesday evening, the release to maven central will happen on Wednesday morning; Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/b0b58972/attachment.html From matzew at apache.org Fri Aug 8 09:11:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 8 Aug 2014 15:11:37 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle Message-ID: Hi team, now that we have votes for the UPS and the java-sender (see [1] and [2]), I'd like to start testing the release bundle. As mentioned on IRC, the nominees for the testing, are: * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj Besides testing the UPS and sender staging repos, please test our quickstarts as well: 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 tag) 2) https://github.com/aerogear/aerogear-push-quickstarts Regarding 2), please use the master branch, for now. There will be a .Beta2 tag as well, once the open PRs are merged (and reviewed) Last but not least, please 'test' (review) the documentation as well, like our guide on the UnifiedPush Server: http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ BTW. there is more doc on the new 'UPS doc center' :-) http://staging.aerogear.org/docs/unifiedpush Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after that we can go to CODE_FREEZE for the 1.0.0.Final Any thoughts ? -Matthias PS: besides the nominated folks, others are welcome to test the things as well :) -Matthias [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/de7c1c85/attachment.html From daniel.bevenius at gmail.com Fri Aug 8 09:38:49 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 8 Aug 2014 15:38:49 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: Sounds good. I'll take a look at the aerogear-push-helloworlds as I've been testing the quickstarts. On 8 August 2014 15:11, Matthias Wessendorf wrote: > Hi team, > > now that we have votes for the UPS and the java-sender (see [1] and [2]), > I'd like to start testing the release bundle. > > As mentioned on IRC, the nominees for the testing, are: > * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > > Besides testing the UPS and sender staging repos, please test our > quickstarts as well: > 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest > (1.0.0.Beta2 tag) > 2) https://github.com/aerogear/aerogear-push-quickstarts > > Regarding 2), please use the master branch, for now. There will be a > .Beta2 tag as well, once the open PRs are merged (and reviewed) > > Last but not least, please 'test' (review) the documentation as well, like > our guide on the UnifiedPush Server: > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > BTW. there is more doc on the new 'UPS doc center' :-) > http://staging.aerogear.org/docs/unifiedpush > > > Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after > that we can go to CODE_FREEZE for the 1.0.0.Final > > Any thoughts ? > > -Matthias > > PS: besides the nominated folks, others are welcome to test the things as > well :) > > > -Matthias > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html > [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/9d4e9c13/attachment.html From scm.blanc at gmail.com Fri Aug 8 10:26:57 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 8 Aug 2014 16:26:57 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: I'm on PTO in about 15 minutes ;) I've reviewed the UPS user guide, and I'm +1 (I know WF section will be add soon) As replacement, the reviewRoulette as designed .......... Summers ! Sebi On Fri, Aug 8, 2014 at 3:38 PM, Daniel Bevenius wrote: > Sounds good. I'll take a look at the aerogear-push-helloworlds as I've > been testing the quickstarts. > > > On 8 August 2014 15:11, Matthias Wessendorf wrote: > >> Hi team, >> >> now that we have votes for the UPS and the java-sender (see [1] and [2]), >> I'd like to start testing the release bundle. >> >> As mentioned on IRC, the nominees for the testing, are: >> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >> >> Besides testing the UPS and sender staging repos, please test our >> quickstarts as well: >> 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest >> (1.0.0.Beta2 tag) >> 2) https://github.com/aerogear/aerogear-push-quickstarts >> >> Regarding 2), please use the master branch, for now. There will be a >> .Beta2 tag as well, once the open PRs are merged (and reviewed) >> >> Last but not least, please 'test' (review) the documentation as well, >> like our guide on the UnifiedPush Server: >> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >> >> BTW. there is more doc on the new 'UPS doc center' :-) >> http://staging.aerogear.org/docs/unifiedpush >> >> >> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after >> that we can go to CODE_FREEZE for the 1.0.0.Final >> >> Any thoughts ? >> >> -Matthias >> >> PS: besides the nominated folks, others are welcome to test the things as >> well :) >> >> >> -Matthias >> >> [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >> [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140808/1e5a434e/attachment.html From bruno at abstractj.org Fri Aug 8 21:06:23 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 8 Aug 2014 22:06:23 -0300 Subject: [aerogear-dev] Updates on Docker images for AeroGear Message-ID: <20140809010623.GA53398@abstractj.org> Good morning team, I did a full organization and documentation of Docker images, now with support to Wildfly, for further details please check: https://github.com/abstractj/docker/tree/master/aerogear In addition I've already submited a pull request against the official repository: https://github.com/jboss/dockerfiles/pull/26 Have fun. -- abstractj PGP: 0x84DC9914 From matzew at apache.org Sat Aug 9 00:51:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 9 Aug 2014 06:51:37 +0200 Subject: [aerogear-dev] Updates on Docker images for AeroGear In-Reply-To: <20140809010623.GA53398@abstractj.org> References: <20140809010623.GA53398@abstractj.org> Message-ID: AWESOME !!!! On Sat, Aug 9, 2014 at 3:06 AM, Bruno Oliveira wrote: > Good morning team, I did a full organization and documentation of Docker > images, now with support to Wildfly, for further details please check: > https://github.com/abstractj/docker/tree/master/aerogear > > In addition I've already submited a pull request against the official > repository: > > https://github.com/jboss/dockerfiles/pull/26 > > Have fun. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140809/7dcd335c/attachment.html From daniel.bevenius at gmail.com Sat Aug 9 00:53:26 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Sat, 9 Aug 2014 06:53:26 +0200 Subject: [aerogear-dev] Updates on Docker images for AeroGear In-Reply-To: References: <20140809010623.GA53398@abstractj.org> Message-ID: Nice work! l?rdag 9 augusti 2014 skrev Matthias Wessendorf : > AWESOME !!!! > > > On Sat, Aug 9, 2014 at 3:06 AM, Bruno Oliveira > wrote: > >> Good morning team, I did a full organization and documentation of Docker >> images, now with support to Wildfly, for further details please check: >> https://github.com/abstractj/docker/tree/master/aerogear >> >> In addition I've already submited a pull request against the official >> repository: >> >> https://github.com/jboss/dockerfiles/pull/26 >> >> Have fun. >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140809/8e9fcc69/attachment.html From cvasilak at gmail.com Sat Aug 9 01:46:20 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Sat, 9 Aug 2014 08:46:20 +0300 Subject: [aerogear-dev] Updates on Docker images for AeroGear In-Reply-To: <20140809010623.GA53398@abstractj.org> References: <20140809010623.GA53398@abstractj.org> Message-ID: <7F258AB5-2F74-4CE4-8960-521BB26F0639@gmail.com> Nice work Bruno! - Christos > On 9 ??? 2014, at 4:06, Bruno Oliveira wrote: > > Good morning team, I did a full organization and documentation of Docker > images, now with support to Wildfly, for further details please check: > https://github.com/abstractj/docker/tree/master/aerogear > > In addition I've already submited a pull request against the official > repository: > > https://github.com/jboss/dockerfiles/pull/26 > > Have fun. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Sun Aug 10 04:01:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 10 Aug 2014 10:01:29 +0200 Subject: [aerogear-dev] Fwd: [liveoak] Unable to use with iOS push notifications (#270) In-Reply-To: References: Message-ID: I have seen that too, that some services allow no passphrase set. Some even require no passphrase. (i think it was FB/Parse and/or Push.io) If we make passphrase optional, we could help their users tool. At the end, it's users choice to do so, or not. Will create a JIRA for 1.0.0.Final to cover this... -Matthias ---------- Forwarded message ---------- From: *Pauli Jokela* Date: Saturday, August 9, 2014 Subject: [liveoak] Unable to use with iOS push notifications (#270) To: liveoak-io/liveoak As the current AeroGear implementation does not allow for empty passphrases when adding a push certificate, I'm unable to use the push notification feature at all. A lot of services out there require that a push certificate does NOT have a passphrase set, so it's not an uncommon request. ? Reply to this email directly or view it on GitHub . -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140810/74675178/attachment.html From matzew at apache.org Sun Aug 10 06:59:46 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 10 Aug 2014 12:59:46 +0200 Subject: [aerogear-dev] Keycloak Admin Console: OAuth clients ? Message-ID: Hi, on the "Keycloak Admin Console" there is the "OAuth clients" menu item. I wonder, for UPS, do we really need to add new OAuth clients? On the long run, yes, at least I think so, e.g. when "device registration" and "Send Push" is covered by OAuth. But do we need it *now* ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140810/548fdd2f/attachment.html From ken at kenfinnigan.me Sun Aug 10 07:30:41 2014 From: ken at kenfinnigan.me (Ken Finnigan) Date: Sun, 10 Aug 2014 07:30:41 -0400 Subject: [aerogear-dev] Fwd: [liveoak] Unable to use with iOS push notifications (#270) In-Reply-To: References: Message-ID: <9E8356E8-2802-48B5-8C47-629339228D56@kenfinnigan.me> Thanks Matthias! Sent from my iPhone > On Aug 10, 2014, at 4:01, Matthias Wessendorf wrote: > > I have seen that too, that some services allow no passphrase set. Some even require no passphrase. (i think it was FB/Parse and/or Push.io) > > If we make passphrase optional, we could help their users tool. At the end, it's users choice to do so, or not. > > Will create a JIRA for 1.0.0.Final to cover this... > > -Matthias > > ---------- Forwarded message ---------- > From: Pauli Jokela > Date: Saturday, August 9, 2014 > Subject: [liveoak] Unable to use with iOS push notifications (#270) > To: liveoak-io/liveoak > > > As the current AeroGear implementation does not allow for empty passphrases when adding a push certificate, I'm unable to use the push notification feature at all. > > A lot of services out there require that a push certificate does NOT have a passphrase set, so it's not an uncommon request. > > ? > Reply to this email directly or view it on GitHub. > > > > > -- > Sent from Gmail Mobile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140810/91f9592b/attachment.html From matzew at apache.org Sun Aug 10 07:34:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 10 Aug 2014 13:34:59 +0200 Subject: [aerogear-dev] Fwd: [liveoak] Unable to use with iOS push notifications (#270) In-Reply-To: <9E8356E8-2802-48B5-8C47-629339228D56@kenfinnigan.me> References: <9E8356E8-2802-48B5-8C47-629339228D56@kenfinnigan.me> Message-ID: connection on the train is better than expected :-) here is the ticket: https://issues.jboss.org/browse/AGPUSH-923 On Sun, Aug 10, 2014 at 1:30 PM, Ken Finnigan wrote: > Thanks Matthias! > > Sent from my iPhone > > On Aug 10, 2014, at 4:01, Matthias Wessendorf wrote: > > I have seen that too, that some services allow no passphrase set. Some > even require no passphrase. (i think it was FB/Parse and/or Push.io) > > If we make passphrase optional, we could help their users tool. At the > end, it's users choice to do so, or not. > > Will create a JIRA for 1.0.0.Final to cover this... > > -Matthias > > ---------- Forwarded message ---------- > From: *Pauli Jokela* > Date: Saturday, August 9, 2014 > Subject: [liveoak] Unable to use with iOS push notifications (#270) > To: liveoak-io/liveoak > > > As the current AeroGear implementation does not allow for empty > passphrases when adding a push certificate, I'm unable to use the push > notification feature at all. > > A lot of services out there require that a push certificate does NOT have > a passphrase set, so it's not an uncommon request. > > ? > Reply to this email directly or view it on GitHub > . > > > > -- > Sent from Gmail Mobile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140810/6c21ea97/attachment-0001.html From matzew at apache.org Sun Aug 10 07:48:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 10 Aug 2014 13:48:13 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf wrote: > Hi team, > > now that we have votes for the UPS and the java-sender (see [1] and [2]), > I'd like to start testing the release bundle. > > As mentioned on IRC, the nominees for the testing, are: > * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > > Besides testing the UPS and sender staging repos, please test our > quickstarts as well: > 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest > (1.0.0.Beta2 tag) > 2) https://github.com/aerogear/aerogear-push-quickstarts > > Regarding 2), please use the master branch, for now. There will be a > .Beta2 tag as well, once the open PRs are merged (and reviewed) > Most of the PRs have been merged and reviewed. Those that are open require some additional work and it's perfectly fine to get them in for 1.0.0.Final. Therefore here is the Beta2 release/tag https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 > > Last but not least, please 'test' (review) the documentation as well, like > our guide on the UnifiedPush Server: > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > BTW. there is more doc on the new 'UPS doc center' :-) > http://staging.aerogear.org/docs/unifiedpush > > > Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after > that we can go to CODE_FREEZE for the 1.0.0.Final > > Any thoughts ? > > -Matthias > > PS: besides the nominated folks, others are welcome to test the things as > well :) > > > -Matthias > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html > [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140810/6f66699c/attachment.html From bruno at abstractj.org Sun Aug 10 08:13:06 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sun, 10 Aug 2014 05:13:06 -0700 (PDT) Subject: [aerogear-dev] Fwd: [liveoak] Unable to use with iOS push notifications (#270) In-Reply-To: References: Message-ID: <1407672785703.7ddbe286@Nodemailer> Make passphrase optional defeats the purpose of security. I don't even get why those services need a certificate if they skip the bare minimum. If we are planning to make this happen, ok. But with huge blinking warnings. ? abstractj PGP: 0x84DC9914 On Sun, Aug 10, 2014 at 5:01 AM, Matthias Wessendorf wrote: > I have seen that too, that some services allow no passphrase set. Some even > require no passphrase. (i think it was FB/Parse and/or Push.io) > If we make passphrase optional, we could help their users tool. At the end, > it's users choice to do so, or not. > Will create a JIRA for 1.0.0.Final to cover this... > -Matthias > ---------- Forwarded message ---------- > From: *Pauli Jokela* > Date: Saturday, August 9, 2014 > Subject: [liveoak] Unable to use with iOS push notifications (#270) > To: liveoak-io/liveoak > As the current AeroGear implementation does not allow for empty passphrases > when adding a push certificate, I'm unable to use the push notification > feature at all. > A lot of services out there require that a push certificate does NOT have a > passphrase set, so it's not an uncommon request. > ? > Reply to this email directly or view it on GitHub > . > -- > Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140810/a396b3d9/attachment.html From matzew at apache.org Sun Aug 10 08:24:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 10 Aug 2014 14:24:07 +0200 Subject: [aerogear-dev] Fwd: [liveoak] Unable to use with iOS push notifications (#270) In-Reply-To: <1407672785703.7ddbe286@Nodemailer> References: <1407672785703.7ddbe286@Nodemailer> Message-ID: On Sun, Aug 10, 2014 at 2:13 PM, Bruno Oliveira wrote: > Make passphrase optional defeats the purpose of security. I don't even get > why those services need a certificate if they skip the bare minimum. The cert is a thing, required from Apple. Too bad, they can't skip that part :-) > > If we are planning to make this happen, ok. > I am not really sure we do that :-) > But with huge blinking warnings. > Same thought here, add that sentence to the JIRA ;-) > ? > abstractj > PGP: 0x84DC9914 > > > On Sun, Aug 10, 2014 at 5:01 AM, Matthias Wessendorf > wrote: > >> I have seen that too, that some services allow no passphrase set. Some >> even require no passphrase. (i think it was FB/Parse and/or Push.io) >> >> If we make passphrase optional, we could help their users tool. At the >> end, it's users choice to do so, or not. >> >> Will create a JIRA for 1.0.0.Final to cover this... >> >> -Matthias >> >> ---------- Forwarded message ---------- >> From: *Pauli Jokela* >> Date: Saturday, August 9, 2014 >> Subject: [liveoak] Unable to use with iOS push notifications (#270) >> To: liveoak-io/liveoak >> >> >> As the current AeroGear implementation does not allow for empty >> passphrases when adding a push certificate, I'm unable to use the push >> notification feature at all. >> >> A lot of services out there require that a push certificate does NOT have >> a passphrase set, so it's not an uncommon request. >> >> ? >> Reply to this email directly or view it on GitHub >> . >> >> >> >> -- >> Sent from Gmail Mobile >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140810/346a144b/attachment.html From daniel.bevenius at gmail.com Sun Aug 10 09:09:27 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Sun, 10 Aug 2014 15:09:27 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140811 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140810/ef8e04d5/attachment.html From daniel.bevenius at gmail.com Mon Aug 11 03:31:16 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 11 Aug 2014 09:31:16 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: Tested aerogear-push-helloworld/ios and found the following minor issues: * *https://issues.jboss.org/browse/AGPUSH-925 * "iOS helloworld example contains out dated information regarding sending push messages." * *https://github.com/aerogear/aerogear.org/pull/350 * "Minor spelling corrections/suggestions" Other than those I was able to follow the docs from scratch and run the app and successfully received push notifications. On 10 August 2014 13:48, Matthias Wessendorf wrote: > > > > On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf > wrote: > >> Hi team, >> >> now that we have votes for the UPS and the java-sender (see [1] and [2]), >> I'd like to start testing the release bundle. >> >> As mentioned on IRC, the nominees for the testing, are: >> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >> >> Besides testing the UPS and sender staging repos, please test our >> quickstarts as well: >> 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest >> (1.0.0.Beta2 tag) >> 2) https://github.com/aerogear/aerogear-push-quickstarts >> >> Regarding 2), please use the master branch, for now. There will be a >> .Beta2 tag as well, once the open PRs are merged (and reviewed) >> > > Most of the PRs have been merged and reviewed. Those that are open require > some additional work and it's perfectly fine to get them in for 1.0.0.Final. > Therefore here is the Beta2 release/tag > > > https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 > > >> >> Last but not least, please 'test' (review) the documentation as well, >> like our guide on the UnifiedPush Server: >> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >> >> BTW. there is more doc on the new 'UPS doc center' :-) >> http://staging.aerogear.org/docs/unifiedpush >> >> >> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after >> that we can go to CODE_FREEZE for the 1.0.0.Final >> >> Any thoughts ? >> >> -Matthias >> >> PS: besides the nominated folks, others are welcome to test the things as >> well :) >> >> >> -Matthias >> >> [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >> [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/80ddd54f/attachment-0001.html From daniel.bevenius at gmail.com Mon Aug 11 06:24:15 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 11 Aug 2014 12:24:15 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: Tested aerogear-push/helloworld/andorid and was able to follow the docs to setup everything and try out the application and receiving notifications by using Genymotion (thanks to Erik and Passos for helping me set that up). On 11 August 2014 09:31, Daniel Bevenius wrote: > Tested aerogear-push-helloworld/ios and found the following minor issues: > * *https://issues.jboss.org/browse/AGPUSH-925 > * "iOS helloworld example > contains out dated information regarding sending push messages." > * *https://github.com/aerogear/aerogear.org/pull/350 > * "Minor spelling > corrections/suggestions" > Other than those I was able to follow the docs from scratch and run the > app and successfully received push notifications. > > > > > On 10 August 2014 13:48, Matthias Wessendorf wrote: > >> >> >> >> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf >> wrote: >> >>> Hi team, >>> >>> now that we have votes for the UPS and the java-sender (see [1] and >>> [2]), I'd like to start testing the release bundle. >>> >>> As mentioned on IRC, the nominees for the testing, are: >>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>> >>> Besides testing the UPS and sender staging repos, please test our >>> quickstarts as well: >>> 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest >>> (1.0.0.Beta2 tag) >>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>> >>> Regarding 2), please use the master branch, for now. There will be a >>> .Beta2 tag as well, once the open PRs are merged (and reviewed) >>> >> >> Most of the PRs have been merged and reviewed. Those that are open >> require some additional work and it's perfectly fine to get them in for >> 1.0.0.Final. >> Therefore here is the Beta2 release/tag >> >> >> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >> >> >>> >>> Last but not least, please 'test' (review) the documentation as well, >>> like our guide on the UnifiedPush Server: >>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>> >>> BTW. there is more doc on the new 'UPS doc center' :-) >>> http://staging.aerogear.org/docs/unifiedpush >>> >>> >>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly >>> after that we can go to CODE_FREEZE for the 1.0.0.Final >>> >>> Any thoughts ? >>> >>> -Matthias >>> >>> PS: besides the nominated folks, others are welcome to test the things >>> as well :) >>> >>> >>> -Matthias >>> >>> [1] >>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>> [2] >>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/6e1bc755/attachment.html From daniel.bevenius at gmail.com Mon Aug 11 07:42:55 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 11 Aug 2014 13:42:55 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: Tested aerogear-push-hellworld/cordova and found this issue: * https://github.com/aerogear/aerogear-push-helloworld/pull/41 Other than that I was able to run both the Android and iOS applications and receive push notifications. I did not have ant installed which generated an error which was pretty clear, but perhaps we should add something about this requirement unless it is mentioned elsewhere. On 11 August 2014 12:24, Daniel Bevenius wrote: > Tested aerogear-push/helloworld/andorid and was able to follow the docs to > setup everything and try out the application and receiving notifications by > using Genymotion (thanks to Erik and Passos for helping me set that up). > > > > > > On 11 August 2014 09:31, Daniel Bevenius > wrote: > >> Tested aerogear-push-helloworld/ios and found the following minor issues: >> * *https://issues.jboss.org/browse/AGPUSH-925 >> * "iOS helloworld example >> contains out dated information regarding sending push messages." >> * *https://github.com/aerogear/aerogear.org/pull/350 >> * "Minor spelling >> corrections/suggestions" >> Other than those I was able to follow the docs from scratch and run the >> app and successfully received push notifications. >> >> >> >> >> On 10 August 2014 13:48, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf >>> wrote: >>> >>>> Hi team, >>>> >>>> now that we have votes for the UPS and the java-sender (see [1] and >>>> [2]), I'd like to start testing the release bundle. >>>> >>>> As mentioned on IRC, the nominees for the testing, are: >>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>> >>>> Besides testing the UPS and sender staging repos, please test our >>>> quickstarts as well: >>>> 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest >>>> (1.0.0.Beta2 tag) >>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>> >>>> Regarding 2), please use the master branch, for now. There will be a >>>> .Beta2 tag as well, once the open PRs are merged (and reviewed) >>>> >>> >>> Most of the PRs have been merged and reviewed. Those that are open >>> require some additional work and it's perfectly fine to get them in for >>> 1.0.0.Final. >>> Therefore here is the Beta2 release/tag >>> >>> >>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>> >>> >>>> >>>> Last but not least, please 'test' (review) the documentation as well, >>>> like our guide on the UnifiedPush Server: >>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>> >>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>> http://staging.aerogear.org/docs/unifiedpush >>>> >>>> >>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly >>>> after that we can go to CODE_FREEZE for the 1.0.0.Final >>>> >>>> Any thoughts ? >>>> >>>> -Matthias >>>> >>>> PS: besides the nominated folks, others are welcome to test the things >>>> as well :) >>>> >>>> >>>> -Matthias >>>> >>>> [1] >>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>> [2] >>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/e733b95c/attachment.html From matzew at apache.org Mon Aug 11 07:46:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 13:46:43 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius wrote: > Tested aerogear-push-hellworld/cordova and found this issue: > * https://github.com/aerogear/aerogear-push-helloworld/pull/41 > > Other than that I was able to run both the Android and iOS applications > and receive push notifications. > > I did not have ant installed which generated an error which was pretty > clear, but perhaps we should add something about this requirement unless it > is mentioned elsewhere. > oh, right - I think it does not hurt to have 'Ant' in the requirements section (install is also easy :-) -> brew install ant ) > > > > On 11 August 2014 12:24, Daniel Bevenius > wrote: > >> Tested aerogear-push/helloworld/andorid and was able to follow the docs >> to setup everything and try out the application and receiving notifications >> by using Genymotion (thanks to Erik and Passos for helping me set that up). >> >> >> >> >> >> On 11 August 2014 09:31, Daniel Bevenius >> wrote: >> >>> Tested aerogear-push-helloworld/ios and found the following minor issues: >>> * *https://issues.jboss.org/browse/AGPUSH-925 >>> * "iOS helloworld example >>> contains out dated information regarding sending push messages." >>> * *https://github.com/aerogear/aerogear.org/pull/350 >>> * "Minor spelling >>> corrections/suggestions" >>> Other than those I was able to follow the docs from scratch and run the >>> app and successfully received push notifications. >>> >>> >>> >>> >>> On 10 August 2014 13:48, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf >>>> wrote: >>>> >>>>> Hi team, >>>>> >>>>> now that we have votes for the UPS and the java-sender (see [1] and >>>>> [2]), I'd like to start testing the release bundle. >>>>> >>>>> As mentioned on IRC, the nominees for the testing, are: >>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>>> >>>>> Besides testing the UPS and sender staging repos, please test our >>>>> quickstarts as well: >>>>> 1) >>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest >>>>> (1.0.0.Beta2 tag) >>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>>> >>>>> Regarding 2), please use the master branch, for now. There will be a >>>>> .Beta2 tag as well, once the open PRs are merged (and reviewed) >>>>> >>>> >>>> Most of the PRs have been merged and reviewed. Those that are open >>>> require some additional work and it's perfectly fine to get them in for >>>> 1.0.0.Final. >>>> Therefore here is the Beta2 release/tag >>>> >>>> >>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>>> >>>> >>>>> >>>>> Last but not least, please 'test' (review) the documentation as well, >>>>> like our guide on the UnifiedPush Server: >>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>>> >>>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>>> http://staging.aerogear.org/docs/unifiedpush >>>>> >>>>> >>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly >>>>> after that we can go to CODE_FREEZE for the 1.0.0.Final >>>>> >>>>> Any thoughts ? >>>>> >>>>> -Matthias >>>>> >>>>> PS: besides the nominated folks, others are welcome to test the things >>>>> as well :) >>>>> >>>>> >>>>> -Matthias >>>>> >>>>> [1] >>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>>> [2] >>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/ad0cfb11/attachment-0001.html From bsutter at redhat.com Mon Aug 11 09:26:33 2014 From: bsutter at redhat.com (Burr Sutter) Date: Mon, 11 Aug 2014 09:26:33 -0400 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf wrote: > > > > On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius wrote: > Tested aerogear-push-hellworld/cordova and found this issue: > * https://github.com/aerogear/aerogear-push-helloworld/pull/41 > > Other than that I was able to run both the Android and iOS applications and receive push notifications. > > I did not have ant installed which generated an error which was pretty clear, but perhaps we should add something about this requirement unless it is mentioned elsewhere. > > oh, right - I think it does not hurt to have 'Ant' in the requirements section (install is also easy :-) -> brew install ant ) Cordova and Android will mostly be developed on Windows machines. I assue the non-command-line user will be fine just using JBDS - many Windows-based developers never see a command line (DOS prompt). And for those Windows-based devs who are comfortable with an command line - we can specify what version of Ant they should have in their PATH and they should know what the PATH is. > > > > > On 11 August 2014 12:24, Daniel Bevenius wrote: > Tested aerogear-push/helloworld/andorid and was able to follow the docs to setup everything and try out the application and receiving notifications by using Genymotion (thanks to Erik and Passos for helping me set that up). > > > > > > On 11 August 2014 09:31, Daniel Bevenius wrote: > Tested aerogear-push-helloworld/ios and found the following minor issues: > * https://issues.jboss.org/browse/AGPUSH-925 "iOS helloworld example contains out dated information regarding sending push messages." > * https://github.com/aerogear/aerogear.org/pull/350 "Minor spelling corrections/suggestions" > Other than those I was able to follow the docs from scratch and run the app and successfully received push notifications. > > > > > On 10 August 2014 13:48, Matthias Wessendorf wrote: > > > > On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf wrote: > Hi team, > > now that we have votes for the UPS and the java-sender (see [1] and [2]), I'd like to start testing the release bundle. > > As mentioned on IRC, the nominees for the testing, are: > * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > > Besides testing the UPS and sender staging repos, please test our quickstarts as well: > 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 tag) > 2) https://github.com/aerogear/aerogear-push-quickstarts > > Regarding 2), please use the master branch, for now. There will be a .Beta2 tag as well, once the open PRs are merged (and reviewed) > > Most of the PRs have been merged and reviewed. Those that are open require some additional work and it's perfectly fine to get them in for 1.0.0.Final. > Therefore here is the Beta2 release/tag > > https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 > > > Last but not least, please 'test' (review) the documentation as well, like our guide on the UnifiedPush Server: > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > BTW. there is more doc on the new 'UPS doc center' :-) > http://staging.aerogear.org/docs/unifiedpush > > > Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after that we can go to CODE_FREEZE for the 1.0.0.Final > > Any thoughts ? > > -Matthias > > PS: besides the nominated folks, others are welcome to test the things as well :) > > > -Matthias > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html > [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/2402f85f/attachment.html From matzew at apache.org Mon Aug 11 09:28:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 15:28:55 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> Message-ID: On Mon, Aug 11, 2014 at 3:26 PM, Burr Sutter wrote: > > On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf > wrote: > > > > > On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Tested aerogear-push-hellworld/cordova and found this issue: >> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >> >> Other than that I was able to run both the Android and iOS applications >> and receive push notifications. >> >> I did not have ant installed which generated an error which was pretty >> clear, but perhaps we should add something about this requirement unless it >> is mentioned elsewhere. >> > > oh, right - I think it does not hurt to have 'Ant' in the requirements > section (install is also easy :-) -> brew install ant ) > > Cordova and Android will mostly be developed on Windows machines. > well, we would only list Ant Version (I don't knwo exactly) as 'required' - not really how to install Ant. I just said, after I noticed the missing ant, it was (for me) easy enough (brew install ant) > > I assue the non-command-line user will be fine just using JBDS - many > Windows-based developers never see a command line (DOS prompt). > > And for those Windows-based devs who are comfortable with an command line > - we can specify what version of Ant they should have in their PATH and > they should know what the PATH is. > > > >> >> >> >> On 11 August 2014 12:24, Daniel Bevenius >> wrote: >> >>> Tested aerogear-push/helloworld/andorid and was able to follow the docs >>> to setup everything and try out the application and receiving notifications >>> by using Genymotion (thanks to Erik and Passos for helping me set that up). >>> >>> >>> >>> >>> >>> On 11 August 2014 09:31, Daniel Bevenius >>> wrote: >>> >>>> Tested aerogear-push-helloworld/ios and found the following minor >>>> issues: >>>> * *https://issues.jboss.org/browse/AGPUSH-925 >>>> * "iOS helloworld example >>>> contains out dated information regarding sending push messages." >>>> * *https://github.com/aerogear/aerogear.org/pull/350 >>>> * "Minor spelling >>>> corrections/suggestions" >>>> Other than those I was able to follow the docs from scratch and run the >>>> app and successfully received push notifications. >>>> >>>> >>>> >>>> >>>> On 10 August 2014 13:48, Matthias Wessendorf wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf >>>> > wrote: >>>>> >>>>>> Hi team, >>>>>> >>>>>> now that we have votes for the UPS and the java-sender (see [1] and >>>>>> [2]), I'd like to start testing the release bundle. >>>>>> >>>>>> As mentioned on IRC, the nominees for the testing, are: >>>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>>>> >>>>>> Besides testing the UPS and sender staging repos, please test our >>>>>> quickstarts as well: >>>>>> 1) >>>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 >>>>>> tag) >>>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>>>> >>>>>> Regarding 2), please use the master branch, for now. There will be a >>>>>> .Beta2 tag as well, once the open PRs are merged (and reviewed) >>>>>> >>>>> >>>>> Most of the PRs have been merged and reviewed. Those that are open >>>>> require some additional work and it's perfectly fine to get them in for >>>>> 1.0.0.Final. >>>>> Therefore here is the Beta2 release/tag >>>>> >>>>> >>>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>>>> >>>>> >>>>>> >>>>>> Last but not least, please 'test' (review) the documentation as well, >>>>>> like our guide on the UnifiedPush Server: >>>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>>>> >>>>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>>>> http://staging.aerogear.org/docs/unifiedpush >>>>>> >>>>>> >>>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly >>>>>> after that we can go to CODE_FREEZE for the 1.0.0.Final >>>>>> >>>>>> Any thoughts ? >>>>>> >>>>>> -Matthias >>>>>> >>>>>> PS: besides the nominated folks, others are welcome to test the >>>>>> things as well :) >>>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> [1] >>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>>>> [2] >>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/33196a52/attachment-0001.html From mmusaji at redhat.com Mon Aug 11 09:35:18 2014 From: mmusaji at redhat.com (Mustafa Musaji) Date: Mon, 11 Aug 2014 09:35:18 -0400 (EDT) Subject: [aerogear-dev] JavaSender questions and a few other bits Message-ID: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> Hi team I can successfully send a UPS message from the console to my device. So I'm trying to play around with the JavaSender. Following the docs here [1], I wrote my standalone client, the main bit you can see here [2], which I had to change a little as the API has changed since [1] was written I guess. Now, I use the same ApplicationID and masterSecret in the console and standalone client - however, with the standalone client I get a 401 response and the console works. Aug 11, 2014 12:45:14 PM org.jboss.aerogear.unifiedpush.SenderClient submitPayload INFO: HTTP Response code from UnifiedPush Server: 401 So why would it not be authorized? How can I find out what's happening? Finally, this is a good point for me to ask perhaps how I can get some deeper level debug logging on the UPS to try and track down what might be happening in these sort of issues. I have TRACE level logging set up but all I see is FINE level logging such as [org.jboss.aerogear.unifiedpush.message.sender.GCMPushNotificationSender]. Also, the WARN and INFO logs from resteasy and keycloak respectively are kind of a lot in the server.log. These seem to be internal to UPS so not sure if we need to raise an issue with KC/UPS to get rid of these or change them over to DEBUG level. There's a lot of them everytime to do something with the console and I'm not sure it's necessary. So, when ever you have time to take a look at the above queries I'd be grateful. Regards Mus [1] http://aerogear.org/docs/guides/GetStartedwithJavaSender/ [2] http://pastebin.com/7U667RDU -------------- Mustafa Musaji Software Maintenance Engineer Red Hat UK Ltd 200 Fowler Avenue, Farnborough Business Park, Farnborough, Hants GU14 7JP Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charles Peters (USA), Michael O'Neill(Ireland) From matzew at apache.org Mon Aug 11 09:39:18 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 15:39:18 +0200 Subject: [aerogear-dev] JavaSender questions and a few other bits In-Reply-To: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> References: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> Message-ID: Hi Mus! On Mon, Aug 11, 2014 at 3:35 PM, Mustafa Musaji wrote: > Hi team > > I can successfully send a UPS message from the console to my device. So > I'm trying to play around with the JavaSender. Following the docs here [1], > I wrote my standalone client, the main bit you can see here [2], which I > had to change a little as the API has changed since [1] was written I guess. > > Now, I use the same ApplicationID and masterSecret in the console and > standalone client - however, with the standalone client I get a 401 > response and the console works. > can you share the content of the HTTP POST, submitted by the console (e.g. extract the request, headers etc with ... Chrome Dev Tools or something like that) ? > > Aug 11, 2014 12:45:14 PM org.jboss.aerogear.unifiedpush.SenderClient > submitPayload > INFO: HTTP Response code from UnifiedPush Server: 401 > > So why would it not be authorized? How can I find out what's happening? > > Finally, this is a good point for me to ask perhaps how I can get some > deeper level debug logging on the UPS to try and track down what might be > happening in these sort of issues. I have TRACE level logging set up but > all I see is FINE level logging such as > [org.jboss.aerogear.unifiedpush.message.sender.GCMPushNotificationSender]. > Good point - setting up a document is on my list: https://issues.jboss.org/browse/AGPUSH-623 > > Also, the WARN and INFO logs from resteasy and keycloak respectively are > kind of a lot in the server.log. These seem to be internal to UPS so not > sure if we need to raise an issue with KC/UPS to get rid of these or change > them over to DEBUG level. There's a lot of them everytime to do something > with the console and I'm not sure it's necessary. > yes, fully agree. We have tracked that on UPS: https://issues.jboss.org/browse/AGPUSH-883 and there is also an KC ticket that Stian created: https://issues.jboss.org/browse/KEYCLOAK-531 -Matthias > > So, when ever you have time to take a look at the above queries I'd be > grateful. > > Regards > Mus > > [1] http://aerogear.org/docs/guides/GetStartedwithJavaSender/ > [2] http://pastebin.com/7U667RDU > -------------- > Mustafa Musaji > Software Maintenance Engineer > Red Hat UK Ltd > 200 Fowler Avenue, Farnborough Business Park, Farnborough, Hants GU14 7JP > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charles Peters > (USA), Michael O'Neill(Ireland) > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/94482a8a/attachment.html From smikloso at redhat.com Mon Aug 11 09:42:01 2014 From: smikloso at redhat.com (Stefan Miklosovic) Date: Mon, 11 Aug 2014 09:42:01 -0400 (EDT) Subject: [aerogear-dev] JavaSender questions and a few other bits In-Reply-To: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> References: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> Message-ID: <1693815161.11914041.1407764521064.JavaMail.zimbra@redhat.com> Hi, maybe it is unrelated and you already have it like that, but do you have the latest version of sender? It aerogear docs you have linked, Maven dependency is of version 0.6.0 but there is 0.8.0 in central already. Try to upgrade that version first. Sorry for noise if you have already done that. Stefan Miklosovic Red Hat Brno - JBoss Mobile Platform e-mail: smikloso at redhat.com irc: smikloso ----- Original Message ----- > Hi team > > I can successfully send a UPS message from the console to my device. So I'm > trying to play around with the JavaSender. Following the docs here [1], I > wrote my standalone client, the main bit you can see here [2], which I had > to change a little as the API has changed since [1] was written I guess. > > Now, I use the same ApplicationID and masterSecret in the console and > standalone client - however, with the standalone client I get a 401 response > and the console works. > > Aug 11, 2014 12:45:14 PM org.jboss.aerogear.unifiedpush.SenderClient > submitPayload > INFO: HTTP Response code from UnifiedPush Server: 401 > > So why would it not be authorized? How can I find out what's happening? > > Finally, this is a good point for me to ask perhaps how I can get some deeper > level debug logging on the UPS to try and track down what might be happening > in these sort of issues. I have TRACE level logging set up but all I see is > FINE level logging such as > [org.jboss.aerogear.unifiedpush.message.sender.GCMPushNotificationSender]. > > Also, the WARN and INFO logs from resteasy and keycloak respectively are kind > of a lot in the server.log. These seem to be internal to UPS so not sure if > we need to raise an issue with KC/UPS to get rid of these or change them > over to DEBUG level. There's a lot of them everytime to do something with > the console and I'm not sure it's necessary. > > So, when ever you have time to take a look at the above queries I'd be > grateful. > > Regards > Mus > > [1] http://aerogear.org/docs/guides/GetStartedwithJavaSender/ > [2] http://pastebin.com/7U667RDU > -------------- > Mustafa Musaji > Software Maintenance Engineer > Red Hat UK Ltd > 200 Fowler Avenue, Farnborough Business Park, Farnborough, Hants GU14 7JP > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charles Peters (USA), > Michael O'Neill(Ireland) > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From matzew at apache.org Mon Aug 11 09:43:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 15:43:42 +0200 Subject: [aerogear-dev] JavaSender questions and a few other bits In-Reply-To: <1693815161.11914041.1407764521064.JavaMail.zimbra@redhat.com> References: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> <1693815161.11914041.1407764521064.JavaMail.zimbra@redhat.com> Message-ID: Oh, good point, Stefan our latest guide is here: http://staging.aerogear.org/docs/unifiedpush/GetStartedwithJavaSender/ (has been relocated) -M On Mon, Aug 11, 2014 at 3:42 PM, Stefan Miklosovic wrote: > Hi, > > maybe it is unrelated and you already have it like that, but do you have > the latest version > of sender? It aerogear docs you have linked, Maven dependency is of > version 0.6.0 but there > is 0.8.0 in central already. Try to upgrade that version first. Sorry for > noise if you have > already done that. > > Stefan Miklosovic > Red Hat Brno - JBoss Mobile Platform > > e-mail: smikloso at redhat.com > irc: smikloso > > ----- Original Message ----- > > Hi team > > > > I can successfully send a UPS message from the console to my device. So > I'm > > trying to play around with the JavaSender. Following the docs here [1], I > > wrote my standalone client, the main bit you can see here [2], which I > had > > to change a little as the API has changed since [1] was written I guess. > > > > Now, I use the same ApplicationID and masterSecret in the console and > > standalone client - however, with the standalone client I get a 401 > response > > and the console works. > > > > Aug 11, 2014 12:45:14 PM org.jboss.aerogear.unifiedpush.SenderClient > > submitPayload > > INFO: HTTP Response code from UnifiedPush Server: 401 > > > > So why would it not be authorized? How can I find out what's happening? > > > > Finally, this is a good point for me to ask perhaps how I can get some > deeper > > level debug logging on the UPS to try and track down what might be > happening > > in these sort of issues. I have TRACE level logging set up but all I see > is > > FINE level logging such as > > > [org.jboss.aerogear.unifiedpush.message.sender.GCMPushNotificationSender]. > > > > Also, the WARN and INFO logs from resteasy and keycloak respectively are > kind > > of a lot in the server.log. These seem to be internal to UPS so not sure > if > > we need to raise an issue with KC/UPS to get rid of these or change them > > over to DEBUG level. There's a lot of them everytime to do something with > > the console and I'm not sure it's necessary. > > > > So, when ever you have time to take a look at the above queries I'd be > > grateful. > > > > Regards > > Mus > > > > [1] http://aerogear.org/docs/guides/GetStartedwithJavaSender/ > > [2] http://pastebin.com/7U667RDU > > -------------- > > Mustafa Musaji > > Software Maintenance Engineer > > Red Hat UK Ltd > > 200 Fowler Avenue, Farnborough Business Park, Farnborough, Hants GU14 7JP > > > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham (USA), Matt Parson (USA), Charles Peters > (USA), > > Michael O'Neill(Ireland) > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/707c9f17/attachment.html From vblanc at viaxoft.com Mon Aug 4 05:58:11 2014 From: vblanc at viaxoft.com (Vincent Blanc) Date: Mon, 4 Aug 2014 11:58:11 +0200 Subject: [aerogear-dev] Error JBAS014771 deployment of unified push server Message-ID: hello, my name is Vincent and i'm in internship. I have this problem when i try to deploy the server but i can't figure what to do. my problem: Request { "address" => [("deployment" => "unifiedpush-auth-server-0.11.0.war")], "operation" => "deploy" } Response Internal Server Error { "outcome" => "failed", "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => [ "jboss.persistenceunit.\"unifiedpush-auth-server-0.11.0.war#jpa-keycloak-audit-store\".__FIRST_PHASE__ is missing [jboss.naming.context.java.jboss.datasources.UnifiedPushDS]", "jboss.persistenceunit.\"unifiedpush-auth-server-0.11.0.war#jpa-keycloak-identity-store\".__FIRST_PHASE__ is missing [jboss.naming.context.java.jboss.datasources.UnifiedPushDS]" ]}, "rolled-back" => true } what can i do? thank you for your time and to answer to my question have a nice day. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140804/e6abff3c/attachment-0001.html From matzew at apache.org Mon Aug 11 09:52:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 15:52:27 +0200 Subject: [aerogear-dev] Error JBAS014771 deployment of unified push server In-Reply-To: References: Message-ID: Hello Vincent, sorry for the late reply, but your mail was stuck in moderation queue. Looks like you did not subscribe to this list. Anyways. regarding the logs, looks like you did not configure a database w/in the JBoss AS. Here is the related section: http://staging.aerogear.org/docs/unifiedpush/ups_userguide/server-installation/#_database_configuration The H2 database is the easiest solution and very fast to setup. BTW here is our new guide, that explains more details on UPS - including the UI and how to install and configure: http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ -Matthias On Mon, Aug 4, 2014 at 11:58 AM, Vincent Blanc wrote: > hello, > > my name is Vincent and i'm in internship. I have this problem when i try > to deploy the server but i can't figure what to do. > > my problem: > > Request > { > "address" => [("deployment" => "unifiedpush-auth-server-0.11.0.war")], > "operation" => "deploy" > } > > Response > > Internal Server Error > { > "outcome" => "failed", > "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => [ > "jboss.persistenceunit.\"unifiedpush-auth-server-0.11.0.war#jpa-keycloak-audit-store\".__FIRST_PHASE__ is missing [jboss.naming.context.java.jboss.datasources.UnifiedPushDS]", > "jboss.persistenceunit.\"unifiedpush-auth-server-0.11.0.war#jpa-keycloak-identity-store\".__FIRST_PHASE__ is missing [jboss.naming.context.java.jboss.datasources.UnifiedPushDS]" > ]}, > "rolled-back" => true > > } > > what can i do? > > > thank you for your time and to answer to my question > > > have a nice day. > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/1436d1a1/attachment.html From lholmqui at redhat.com Mon Aug 11 09:58:14 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 11 Aug 2014 09:58:14 -0400 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: <2B9EF7DF-24C3-4C4B-B277-3BAD71DF6055@redhat.com> i?ll probably be mostly testing the quick starts, as i have been recently playing with them On Aug 8, 2014, at 9:11 AM, Matthias Wessendorf wrote: > Hi team, > > now that we have votes for the UPS and the java-sender (see [1] and [2]), I'd like to start testing the release bundle. > > As mentioned on IRC, the nominees for the testing, are: > * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > > Besides testing the UPS and sender staging repos, please test our quickstarts as well: > 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 tag) > 2) https://github.com/aerogear/aerogear-push-quickstarts > > Regarding 2), please use the master branch, for now. There will be a .Beta2 tag as well, once the open PRs are merged (and reviewed) > > Last but not least, please 'test' (review) the documentation as well, like our guide on the UnifiedPush Server: > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > BTW. there is more doc on the new 'UPS doc center' :-) > http://staging.aerogear.org/docs/unifiedpush > > > Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after that we can go to CODE_FREEZE for the 1.0.0.Final > > Any thoughts ? > > -Matthias > > PS: besides the nominated folks, others are welcome to test the things as well :) > > > -Matthias > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html > [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/abebe8cb/attachment.html From cvasilak at gmail.com Mon Aug 11 10:18:12 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 11 Aug 2014 17:18:12 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: <26BA7EFD-2BD3-4B3D-B1D1-82C4F8E286EB@gmail.com> fyi, meeting minutes: Meeting ended Mon Aug 11 14:16:10 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-11-14.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-11-14.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-11-14.00.log.html On Aug 10, 2014, at 4:09 PM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140811 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/4f828498/attachment.html From lholmqui at redhat.com Mon Aug 11 10:22:52 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 11 Aug 2014 10:22:52 -0400 Subject: [aerogear-dev] Call for Arms( Cordova Quickstart ) Message-ID: <7CBBB9FD-9DE7-493B-86EA-BA0DCA0693CF@redhat.com> Hello Everybody( said in best Dr. Nick voice ), Last week there were many Cordova related quick start, Looks like most are UI related, not really cordova specific stuff, so if you are a good fit to fix it, help would be appreciated https://issues.jboss.org/issues/?jql=project%20%3D%20AGPUSH%20AND%20component%20%3D%20examples%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20lucas.holmquist%20ORDER%20BY%20priority%20DESC Thanks Dudes -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/170cf235/attachment.html From supittma at redhat.com Mon Aug 11 10:34:34 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 11 Aug 2014 10:34:34 -0400 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> Message-ID: <53E8D47A.3040006@redhat.com> On 8/11/2014 9:26 AM, Burr Sutter wrote: > > On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf > wrote: > >> >> >> >> On Mon, Aug 11, 2014 at 1:42 PM, Daniel >> Bevenius> >wrote: >> >> Tested aerogear-push-hellworld/cordova and found this issue: >> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >> >> Other than that I was able to run both the Android and iOS >> applications and receive push notifications. >> >> I did not have ant installed which generated an error which was >> pretty clear, but perhaps we should add something about this >> requirement unless it is mentioned elsewhere. >> >> >> oh, right - I think it does not hurt to have 'Ant' in the >> requirements section (install is also easy :-) -> brew install ant ) > Cordova and Android will mostly be developed on Windows machines. > > I assue the non-command-line user will be fine just using JBDS - many > Windows-based developers never see a command line (DOS prompt). > > And for those Windows-based devs who are comfortable with an command > line - we can specify what version of Ant they should have in their > PATH and they should know what the PATH is. I'll make the runs on windows and see how things go. > >> >> >> >> On 11 August 2014 12:24, Daniel >> Bevenius> >wrote: >> >> Tested aerogear-push/helloworld/andorid and was able to >> follow the docs to setup everything and try out the >> application and receiving notifications by using Genymotion >> (thanks to Erik and Passos for helping me set that up). >> >> >> >> >> >> On 11 August 2014 09:31, Daniel >> Bevenius> >wrote: >> >> Tested aerogear-push-helloworld/ios and found the >> following minor issues: >> * _https://issues.jboss.org/browse/AGPUSH-925_ "iOS >> helloworld example contains out dated information >> regarding sending push messages." >> * >> _https://github.com/aerogear/aerogear.org/pull/350_ "Minor spelling >> corrections/suggestions" >> Other than those I was able to follow the docs from >> scratch and run the app and successfully received push >> notifications. >> >> >> >> >> On 10 August 2014 13:48, Matthias >> Wessendorf> >wrote: >> >> >> >> >> On Fri, Aug 8, 2014 at 3:11 PM, Matthias >> Wessendorf> >wrote: >> >> Hi team, >> >> now that we have votes for the UPS and the >> java-sender (see [1] and [2]), I'd like to start >> testing the release bundle. >> >> As mentioned on IRC, the nominees for the >> testing, are: >> * sblanc, cvasilak, dbevenius, lholmquist, lfryc >> and abstractj >> >> Besides testing the UPS and sender staging repos, >> please test our quickstarts as well: >> 1)https://github.com/aerogear/aerogear-push-helloworld/releases/latest(1.0.0.Beta2 >> tag) >> 2)https://github.com/aerogear/aerogear-push-quickstarts >> >> >> Regarding 2), please use the master branch, for >> now. There will be a .Beta2 tag as well, once the >> open PRs are merged (and reviewed) >> >> >> Most of the PRs have been merged and reviewed. Those >> that are open require some additional work and it's >> perfectly fine to get them in for 1.0.0.Final. >> Therefore here is the Beta2 release/tag >> >> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >> >> >> Last but not least, please 'test' (review) the >> documentation as well, like our guide on the >> UnifiedPush Server: >> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >> >> BTW. there is more doc on the new 'UPS doc >> center' :-) >> http://staging.aerogear.org/docs/unifiedpush >> >> >> Hopefully, by Wednesday we have an awesome >> 1.0.0.Beta2 and shortly after that we can go to >> CODE_FREEZE for the 1.0.0.Final >> >> Any thoughts ? >> >> -Matthias >> >> PS: besides the nominated folks, others are >> welcome to test the things as well :) >> >> >> -Matthias >> >> [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >> [2]http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >> >> >> -- >> Matthias Wessendorf >> >> blog:http://matthiaswessendorf.wordpress.com/ >> sessions:http://www.slideshare.net/mwessendorf >> twitter:http://twitter.com/mwessendorf >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog:http://matthiaswessendorf.wordpress.com/ >> sessions:http://www.slideshare.net/mwessendorf >> twitter:http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog:http://matthiaswessendorf.wordpress.com/ >> sessions:http://www.slideshare.net/mwessendorf >> twitter:http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/12819291/attachment-0001.html From daniel.bevenius at gmail.com Mon Aug 11 10:35:59 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 11 Aug 2014 16:35:59 +0200 Subject: [aerogear-dev] Call for Arms( Cordova Quickstart ) In-Reply-To: <7CBBB9FD-9DE7-493B-86EA-BA0DCA0693CF@redhat.com> References: <7CBBB9FD-9DE7-493B-86EA-BA0DCA0693CF@redhat.com> Message-ID: I'm probably the worst fit but I'll take a stab at one. They are all assigned to you at the moment as far as I can tell, could you un-assign the ones that are up for grabs? On 11 August 2014 16:22, Lucas Holmquist wrote: > Hello Everybody( said in best Dr. Nick voice ), > > > Last week there were many Cordova related quick start, > > > Looks like most are UI related, not really cordova specific stuff, > > so if you are a good fit to fix it, help would be appreciated > > > > https://issues.jboss.org/issues/?jql=project%20%3D%20AGPUSH%20AND%20component%20%3D%20examples%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20lucas.holmquist%20ORDER%20BY%20priority%20DESC > > > > > Thanks Dudes > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/000025c3/attachment.html From lholmqui at redhat.com Mon Aug 11 10:37:44 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 11 Aug 2014 10:37:44 -0400 Subject: [aerogear-dev] Call for Arms( Cordova Quickstart ) In-Reply-To: References: <7CBBB9FD-9DE7-493B-86EA-BA0DCA0693CF@redhat.com> Message-ID: <71916B3B-1A07-4111-9869-E08EF9C1BA19@redhat.com> They are all up for grabs, except the one with the PR on it :) On Aug 11, 2014, at 10:35 AM, Daniel Bevenius wrote: > I'm probably the worst fit but I'll take a stab at one. They are all assigned to you at the moment as far as I can tell, could you un-assign the ones that are up for grabs? > > > > > On 11 August 2014 16:22, Lucas Holmquist wrote: > Hello Everybody( said in best Dr. Nick voice ), > > > Last week there were many Cordova related quick start, > > > Looks like most are UI related, not really cordova specific stuff, > > so if you are a good fit to fix it, help would be appreciated > > > https://issues.jboss.org/issues/?jql=project%20%3D%20AGPUSH%20AND%20component%20%3D%20examples%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20lucas.holmquist%20ORDER%20BY%20priority%20DESC > > > > Thanks Dudes > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/1bd0415f/attachment.html From mmusaji at redhat.com Mon Aug 11 10:42:54 2014 From: mmusaji at redhat.com (mmusaji) Date: Mon, 11 Aug 2014 07:42:54 -0700 (PDT) Subject: [aerogear-dev] JavaSender questions and a few other bits In-Reply-To: References: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> <1693815161.11914041.1407764521064.JavaMail.zimbra@redhat.com> Message-ID: <1407768174359-8833.post@n5.nabble.com> I'm using JavaSender 0.8.0. This is from the internal DR3 release. Here's the POST captured from the console. NOTE: this works fine, but the JavaSender fails so if you want me to capture anything from this side let me know how/what you need. Remote Address:10.33.1.143:8080 Request URL:http://10.33.1.143:8080/ag-push/rest/sender Request Method:POST Status Code:200 OK Request Headersview source Accept:application/json, text/plain, */* Accept-Encoding:gzip,deflate,sdch Accept-Language:en-US,en;q=0.8,en-GB;q=0.6 aerogear-sender:AeroGear UnifiedPush Console Authorization:Basic ZWM4MjYwYjUtNWRiMi00NDNhLTkwZGItNjRlNDlkMTQ3YzIxOjRiMDlhOGI3LTg4ZGEtNGJjNi05MjJhLWM2NWZkNDAwNDVmMw== Connection:keep-alive Content-Length:46 Content-Type:application/json;charset=UTF-8 Host:10.33.1.143:8080 Origin:http://10.33.1.143:8080 Referer:http://10.33.1.143:8080/ag-push/ User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36 Request Payloadview source {message:{sound:default, alert:Blah}} message: {sound:default, alert:Blah} Response Headersview source Content-Length:13 Content-Type:application/json Date:Mon, 11 Aug 2014 14:36:59 GMT Server:Apache-Coyote/1.1 -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaSender-questions-and-a-few-other-bits-tp8827p8833.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Mon Aug 11 11:05:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 17:05:29 +0200 Subject: [aerogear-dev] JavaSender questions and a few other bits In-Reply-To: <1407768174359-8833.post@n5.nabble.com> References: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> <1693815161.11914041.1407764521064.JavaMail.zimbra@redhat.com> <1407768174359-8833.post@n5.nabble.com> Message-ID: Hi Mus, I have decoded your credentials, submitted by the UnifiedPush Console. ec8260b5-5db2-443a-90db-64e49d147c21:4b09a8b7-88da-4bc6-922a-c65fd40045f3 however, your java code has this: 1. .pushApplicationId( "73275d2d-5e83-4a87-8342-7a6cd15068f2") 2. .masterSecret( "cd9aabfa-e163-4a52-8f18-4ca3de3b1001") That does explain the 401 -Matthias On Mon, Aug 11, 2014 at 4:42 PM, mmusaji wrote: > I'm using JavaSender 0.8.0. This is from the internal DR3 release. > > Here's the POST captured from the console. NOTE: this works fine, but the > JavaSender fails so if you want me to capture anything from this side let > me > know how/what you need. > > Remote Address:10.33.1.143:8080 > Request URL:http://10.33.1.143:8080/ag-push/rest/sender > Request Method:POST > Status Code:200 OK > Request Headersview source > Accept:application/json, text/plain, */* > Accept-Encoding:gzip,deflate,sdch > Accept-Language:en-US,en;q=0.8,en-GB;q=0.6 > aerogear-sender:AeroGear UnifiedPush Console > Authorization:Basic > > ZWM4MjYwYjUtNWRiMi00NDNhLTkwZGItNjRlNDlkMTQ3YzIxOjRiMDlhOGI3LTg4ZGEtNGJjNi05MjJhLWM2NWZkNDAwNDVmMw== > Connection:keep-alive > Content-Length:46 > Content-Type:application/json;charset=UTF-8 > Host:10.33.1.143:8080 > Origin:http://10.33.1.143:8080 > Referer:http://10.33.1.143:8080/ag-push/ > User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like > Gecko) Chrome/36.0.1985.125 Safari/537.36 > Request Payloadview source > {message:{sound:default, alert:Blah}} > message: {sound:default, alert:Blah} > Response Headersview source > Content-Length:13 > Content-Type:application/json > Date:Mon, 11 Aug 2014 14:36:59 GMT > Server:Apache-Coyote/1.1 > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaSender-questions-and-a-few-other-bits-tp8827p8833.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/2c9ebbdb/attachment.html From matzew at apache.org Mon Aug 11 11:06:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 17:06:42 +0200 Subject: [aerogear-dev] Call for Arms( Cordova Quickstart ) In-Reply-To: <71916B3B-1A07-4111-9869-E08EF9C1BA19@redhat.com> References: <7CBBB9FD-9DE7-493B-86EA-BA0DCA0693CF@redhat.com> <71916B3B-1A07-4111-9869-E08EF9C1BA19@redhat.com> Message-ID: or "Coding in progress" could be used, in JIRA, as well as an indicator On Mon, Aug 11, 2014 at 4:37 PM, Lucas Holmquist wrote: > They are all up for grabs, except the one with the PR on it :) > > > On Aug 11, 2014, at 10:35 AM, Daniel Bevenius > wrote: > > I'm probably the worst fit but I'll take a stab at one. They are all > assigned to you at the moment as far as I can tell, could you un-assign the > ones that are up for grabs? > > > > > On 11 August 2014 16:22, Lucas Holmquist wrote: > >> Hello Everybody( said in best Dr. Nick voice ), >> >> >> Last week there were many Cordova related quick start, >> >> >> Looks like most are UI related, not really cordova specific stuff, >> >> so if you are a good fit to fix it, help would be appreciated >> >> >> >> https://issues.jboss.org/issues/?jql=project%20%3D%20AGPUSH%20AND%20component%20%3D%20examples%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20lucas.holmquist%20ORDER%20BY%20priority%20DESC >> >> >> >> >> Thanks Dudes >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/27570dc7/attachment-0001.html From edewit at redhat.com Mon Aug 11 11:43:52 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 11 Aug 2014 17:43:52 +0200 Subject: [aerogear-dev] Call for Arms( Cordova Quickstart ) In-Reply-To: <7CBBB9FD-9DE7-493B-86EA-BA0DCA0693CF@redhat.com> References: <7CBBB9FD-9DE7-493B-86EA-BA0DCA0693CF@redhat.com> Message-ID: I?ll help, but who is Dr. Nick On 11 Aug,2014, at 16:22 , Lucas Holmquist wrote: > Hello Everybody( said in best Dr. Nick voice ), > > > Last week there were many Cordova related quick start, > > > Looks like most are UI related, not really cordova specific stuff, > > so if you are a good fit to fix it, help would be appreciated > > > https://issues.jboss.org/issues/?jql=project%20%3D%20AGPUSH%20AND%20component%20%3D%20examples%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20lucas.holmquist%20ORDER%20BY%20priority%20DESC > > > > Thanks Dudes > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/2e791923/attachment.html From matzew at apache.org Mon Aug 11 11:48:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 17:48:01 +0200 Subject: [aerogear-dev] JavaSender questions and a few other bits In-Reply-To: References: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> <1693815161.11914041.1407764521064.JavaMail.zimbra@redhat.com> <1407768174359-8833.post@n5.nabble.com> Message-ID: Hi Mus, I started the doc on "better debugging", I have added the logging section: https://gist.github.com/matzew/149024e54a0bdec927ee James Perkins, from WF team, did help with the content On Mon, Aug 11, 2014 at 5:05 PM, Matthias Wessendorf wrote: > Hi Mus, > > I have decoded your credentials, submitted by the UnifiedPush Console. > ec8260b5-5db2-443a-90db-64e49d147c21:4b09a8b7-88da-4bc6-922a-c65fd40045f3 > > > however, your java code has this: > > 1. .pushApplicationId( > "73275d2d-5e83-4a87-8342-7a6cd15068f2") > 2. .masterSecret( > "cd9aabfa-e163-4a52-8f18-4ca3de3b1001") > > > > That does explain the 401 > > -Matthias > > > > > > > On Mon, Aug 11, 2014 at 4:42 PM, mmusaji wrote: > >> I'm using JavaSender 0.8.0. This is from the internal DR3 release. >> >> Here's the POST captured from the console. NOTE: this works fine, but the >> JavaSender fails so if you want me to capture anything from this side let >> me >> know how/what you need. >> >> Remote Address:10.33.1.143:8080 >> Request URL:http://10.33.1.143:8080/ag-push/rest/sender >> Request Method:POST >> Status Code:200 OK >> Request Headersview source >> Accept:application/json, text/plain, */* >> Accept-Encoding:gzip,deflate,sdch >> Accept-Language:en-US,en;q=0.8,en-GB;q=0.6 >> aerogear-sender:AeroGear UnifiedPush Console >> Authorization:Basic >> >> ZWM4MjYwYjUtNWRiMi00NDNhLTkwZGItNjRlNDlkMTQ3YzIxOjRiMDlhOGI3LTg4ZGEtNGJjNi05MjJhLWM2NWZkNDAwNDVmMw== >> Connection:keep-alive >> Content-Length:46 >> Content-Type:application/json;charset=UTF-8 >> Host:10.33.1.143:8080 >> Origin:http://10.33.1.143:8080 >> Referer:http://10.33.1.143:8080/ag-push/ >> User-Agent:Mozilla/5.0 >> (X11; Linux >> x86_64) AppleWebKit/537.36 (KHTML, like >> Gecko) Chrome/36.0.1985.125 Safari/537.36 >> Request Payloadview source >> {message:{sound:default, alert:Blah}} >> message: {sound:default, alert:Blah} >> Response Headersview source >> Content-Length:13 >> Content-Type:application/json >> Date:Mon, 11 Aug 2014 14:36:59 GMT >> Server:Apache-Coyote/1.1 >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaSender-questions-and-a-few-other-bits-tp8827p8833.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/0fc206c4/attachment.html From lholmqui at redhat.com Mon Aug 11 12:03:23 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 11 Aug 2014 12:03:23 -0400 Subject: [aerogear-dev] Call for Arms( Cordova Quickstart ) In-Reply-To: References: <7CBBB9FD-9DE7-493B-86EA-BA0DCA0693CF@redhat.com> Message-ID: On Aug 11, 2014, at 11:43 AM, Erik Jan de Wit wrote: > I?ll help, but who is Dr. Nick the Simpsons!! > > On 11 Aug,2014, at 16:22 , Lucas Holmquist wrote: > >> Hello Everybody( said in best Dr. Nick voice ), >> >> >> Last week there were many Cordova related quick start, >> >> >> Looks like most are UI related, not really cordova specific stuff, >> >> so if you are a good fit to fix it, help would be appreciated >> >> >> https://issues.jboss.org/issues/?jql=project%20%3D%20AGPUSH%20AND%20component%20%3D%20examples%20AND%20resolution%20%3D%20Unresolved%20AND%20assignee%20%3D%20lucas.holmquist%20ORDER%20BY%20priority%20DESC >> >> >> >> Thanks Dudes >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/5151a41b/attachment.html From matzew at apache.org Mon Aug 11 13:27:18 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 19:27:18 +0200 Subject: [aerogear-dev] Push Quickstarts - Maven ? Message-ID: Hi, the README on the quickstarts have a "Configure Maven to Build and Deploy the Quickstarts". I am not able to build the thing, nor do I understand the "need" to do all that (especially "replace the repo" part). Doing "mvn clean -s ./contributor-settings.xml" (similar to using the "settings.xml" instead) on the root of the directory gives some maven trouble (as reported in a few PRs last week) So.... I am wondering how folks are building this... Ideally a "mvn clean install -s ./contributor-settings.xml" should work. Or if some magic profile needs to be enabled, our README should say so Thanks, Matthias [INFO] Scanning for projects... Downloading: http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-resteasy/6.2.0.GA/jboss-javaee-6.0-with-resteasy-6.2.0.GA.pom [ERROR] The build could not read 2 projects -> [Help 1] [ERROR] [ERROR] The project org.jboss.quickstarts.wfk:jboss-contacts-mobile-picketlink-secured:1.0.0.Beta2-SNAPSHOT (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-picketlink-secured/pom.xml) has 27 errors [ERROR] Non-resolvable import POM: Failure to find org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced @ org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, line 42, column 25 -> [Help 2] [ERROR] Non-resolvable import POM: Failure to find org.jboss.bom.wfk:jboss-javaee-6.0-with-deltaspike:pom:2.6.0-redhat-1 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced @ line 99, column 25 -> [Help 2] [ERROR] Non-resolvable import POM: Failure to find org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.2.GA in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced @ line 107, column 25 -> [Help 2] [ERROR] Non-resolvable import POM: Failure to find org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.2.GA in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced @ line 115, column 25 -> [Help 2] [ERROR] Non-resolvable import POM: Failure to find org.jboss.bom.eap:jboss-javaee-6.0-with-security:pom:6.2.2.GA in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced @ line 122, column 25 -> [Help 2] [ERROR] 'dependencies.dependency.version' for javax.enterprise:cdi-api:jar is missing. @ line 167, column 21 [ERROR] 'dependencies.dependency.version' for javax.inject:javax.inject:jar is missing. @ line 172, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is missing. @ line 179, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @ line 186, column 21 [ERROR] 'dependencies.dependency.version' for org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @ line 193, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line 200, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ line 207, column 21 [ERROR] 'dependencies.dependency.version' for javax.validation:validation-api:jar is missing. @ line 214, column 21 [ERROR] 'dependencies.dependency.version' for org.hibernate:hibernate-validator:jar is missing. @ line 223, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.resteasy:resteasy-jackson-provider:jar is missing. @ line 235, column 21 [ERROR] 'dependencies.dependency.version' for org.apache.deltaspike.core:deltaspike-core-api:jar is missing. @ line 283, column 21 [ERROR] 'dependencies.dependency.version' for org.apache.deltaspike.core:deltaspike-core-impl:jar is missing. @ line 291, column 21 [ERROR] 'dependencies.dependency.version' for org.apache.deltaspike.modules:deltaspike-security-module-api:jar is missing. @ line 300, column 21 [ERROR] 'dependencies.dependency.version' for org.apache.deltaspike.modules:deltaspike-security-module-impl:jar is missing. @ line 308, column 21 [ERROR] 'dependencies.dependency.version' for org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 317, column 21 [ERROR] 'dependencies.dependency.version' for junit:junit:jar is missing. @ line 324, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @ line 336, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is missing. @ line 342, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.arquillian.container:arquillian-container-test-api:jar is missing. @ line 348, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.arquillian.junit:arquillian-junit-core:jar is missing. @ line 354, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.shrinkwrap:shrinkwrap-api:jar is missing. @ line 360, column 21 [ERROR] 'dependencies.dependency.version' for org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:jar is missing. @ line 366, column 21 [ERROR] [ERROR] The project org.jboss.quickstarts.wfk:jboss-contacts-mobile-proxy:1.0.0.Beta2-SNAPSHOT (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-proxy/pom.xml) has 4 errors [ERROR] Non-resolvable import POM: Failure to find org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in http://repo.maven.apache.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced @ org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, line 42, column 25 -> [Help 2] [ERROR] Non-resolvable import POM: Could not find artifact org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.0.GA in central ( http://repo.maven.apache.org/maven2) @ line 79, column 25 -> [Help 2] [ERROR] 'dependencies.dependency.version' for org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ line 92, column 21 [ERROR] 'dependencies.dependency.version' for junit:junit:jar is missing. @ line 117, column 21 [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException [ERROR] [Help 2] http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/2881b132/attachment-0001.html From scm.blanc at gmail.com Mon Aug 11 14:14:45 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 11 Aug 2014 20:14:45 +0200 Subject: [aerogear-dev] Push Quickstarts - Maven ? In-Reply-To: References: Message-ID: Which version of Maven are you using ? I remember Fred reported a bug with Maven and resolving BOMs : https://jira.codehaus.org/browse/MNG-5663 On Mon, Aug 11, 2014 at 7:27 PM, Matthias Wessendorf wrote: > Hi, > > the README on the quickstarts have a "Configure Maven to Build and Deploy > the Quickstarts". > > I am not able to build the thing, nor do I understand the "need" to do all > that (especially "replace the repo" part). > > Doing "mvn clean -s ./contributor-settings.xml" (similar to using the > "settings.xml" instead) on the root of the directory gives some maven > trouble (as reported in a few PRs last week) > > > So.... I am wondering how folks are building this... > > Ideally a "mvn clean install -s ./contributor-settings.xml" should work. > Or if some magic profile needs to be enabled, our README should say so > > > Thanks, > Matthias > > > > > > > [INFO] Scanning for projects... > Downloading: > http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-resteasy/6.2.0.GA/jboss-javaee-6.0-with-resteasy-6.2.0.GA.pom > [ERROR] The build could not read 2 projects -> [Help 1] > [ERROR] > [ERROR] The project > org.jboss.quickstarts.wfk:jboss-contacts-mobile-picketlink-secured:1.0.0.Beta2-SNAPSHOT > (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-picketlink-secured/pom.xml) > has 27 errors > [ERROR] Non-resolvable import POM: Failure to find > org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in > http://repo.maven.apache.org/maven2 was cached in the local repository, > resolution will not be reattempted until the update interval of central has > elapsed or updates are forced @ > org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], > /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, > line 42, column 25 -> [Help 2] > [ERROR] Non-resolvable import POM: Failure to find > org.jboss.bom.wfk:jboss-javaee-6.0-with-deltaspike:pom:2.6.0-redhat-1 in > http://repo.maven.apache.org/maven2 was cached in the local repository, > resolution will not be reattempted until the update interval of central has > elapsed or updates are forced @ line 99, column 25 -> [Help 2] > [ERROR] Non-resolvable import POM: Failure to find > org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.2.GA in > http://repo.maven.apache.org/maven2 was cached in the local repository, > resolution will not be reattempted until the update interval of central has > elapsed or updates are forced @ line 107, column 25 -> [Help 2] > [ERROR] Non-resolvable import POM: Failure to find > org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.2.GA in > http://repo.maven.apache.org/maven2 was cached in the local repository, > resolution will not be reattempted until the update interval of central has > elapsed or updates are forced @ line 115, column 25 -> [Help 2] > [ERROR] Non-resolvable import POM: Failure to find > org.jboss.bom.eap:jboss-javaee-6.0-with-security:pom:6.2.2.GA in > http://repo.maven.apache.org/maven2 was cached in the local repository, > resolution will not be reattempted until the update interval of central has > elapsed or updates are forced @ line 122, column 25 -> [Help 2] > [ERROR] 'dependencies.dependency.version' for > javax.enterprise:cdi-api:jar is missing. @ line 167, column 21 > [ERROR] 'dependencies.dependency.version' for > javax.inject:javax.inject:jar is missing. @ line 172, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is > missing. @ line 179, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @ > line 186, column 21 > [ERROR] 'dependencies.dependency.version' for > org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @ > line 193, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line 200, > column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ > line 207, column 21 > [ERROR] 'dependencies.dependency.version' for > javax.validation:validation-api:jar is missing. @ line 214, column 21 > [ERROR] 'dependencies.dependency.version' for > org.hibernate:hibernate-validator:jar is missing. @ line 223, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.resteasy:resteasy-jackson-provider:jar is missing. @ line 235, > column 21 > [ERROR] 'dependencies.dependency.version' for > org.apache.deltaspike.core:deltaspike-core-api:jar is missing. @ line 283, > column 21 > [ERROR] 'dependencies.dependency.version' for > org.apache.deltaspike.core:deltaspike-core-impl:jar is missing. @ line 291, > column 21 > [ERROR] 'dependencies.dependency.version' for > org.apache.deltaspike.modules:deltaspike-security-module-api:jar is > missing. @ line 300, column 21 > [ERROR] 'dependencies.dependency.version' for > org.apache.deltaspike.modules:deltaspike-security-module-impl:jar is > missing. @ line 308, column 21 > [ERROR] 'dependencies.dependency.version' for > org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 317, column 21 > [ERROR] 'dependencies.dependency.version' for junit:junit:jar is > missing. @ line 324, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @ > line 336, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is missing. @ > line 342, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.arquillian.container:arquillian-container-test-api:jar is > missing. @ line 348, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.arquillian.junit:arquillian-junit-core:jar is missing. @ line > 354, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.shrinkwrap:shrinkwrap-api:jar is missing. @ line 360, column 21 > [ERROR] 'dependencies.dependency.version' for > org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:jar is missing. > @ line 366, column 21 > [ERROR] > [ERROR] The project > org.jboss.quickstarts.wfk:jboss-contacts-mobile-proxy:1.0.0.Beta2-SNAPSHOT > (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-proxy/pom.xml) > has 4 errors > [ERROR] Non-resolvable import POM: Failure to find > org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in > http://repo.maven.apache.org/maven2 was cached in the local repository, > resolution will not be reattempted until the update interval of central has > elapsed or updates are forced @ > org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], > /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, > line 42, column 25 -> [Help 2] > [ERROR] Non-resolvable import POM: Could not find artifact > org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.0.GA in central ( > http://repo.maven.apache.org/maven2) @ line 79, column 25 -> [Help 2] > [ERROR] 'dependencies.dependency.version' for > org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ > line 92, column 21 > [ERROR] 'dependencies.dependency.version' for junit:junit:jar is > missing. @ line 117, column 21 > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the > -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, > please read the following articles: > [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException > [ERROR] [Help 2] > http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/31a6eaee/attachment.html From matzew at apache.org Mon Aug 11 14:33:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 11 Aug 2014 20:33:09 +0200 Subject: [aerogear-dev] Push Quickstarts - Maven ? In-Reply-To: References: Message-ID: ah!!!!!!!!!!!!!!!! thanks, Sebi - I am on Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e; 2014-06-17T15:51:42+02:00) I will update the README tomorrow! thanks! On Mon, Aug 11, 2014 at 8:14 PM, Sebastien Blanc wrote: > Which version of Maven are you using ? I remember Fred reported a bug with > Maven and resolving BOMs : https://jira.codehaus.org/browse/MNG-5663 > > > On Mon, Aug 11, 2014 at 7:27 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> the README on the quickstarts have a "Configure Maven to Build and Deploy >> the Quickstarts". >> >> I am not able to build the thing, nor do I understand the "need" to do >> all that (especially "replace the repo" part). >> >> Doing "mvn clean -s ./contributor-settings.xml" (similar to using the >> "settings.xml" instead) on the root of the directory gives some maven >> trouble (as reported in a few PRs last week) >> >> >> So.... I am wondering how folks are building this... >> >> Ideally a "mvn clean install -s ./contributor-settings.xml" should work. >> Or if some magic profile needs to be enabled, our README should say so >> >> >> Thanks, >> Matthias >> >> >> >> >> >> >> [INFO] Scanning for projects... >> Downloading: >> http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-resteasy/6.2.0.GA/jboss-javaee-6.0-with-resteasy-6.2.0.GA.pom >> [ERROR] The build could not read 2 projects -> [Help 1] >> [ERROR] >> [ERROR] The project >> org.jboss.quickstarts.wfk:jboss-contacts-mobile-picketlink-secured:1.0.0.Beta2-SNAPSHOT >> (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-picketlink-secured/pom.xml) >> has 27 errors >> [ERROR] Non-resolvable import POM: Failure to find >> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in >> http://repo.maven.apache.org/maven2 was cached in the local repository, >> resolution will not be reattempted until the update interval of central has >> elapsed or updates are forced @ >> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], >> /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, >> line 42, column 25 -> [Help 2] >> [ERROR] Non-resolvable import POM: Failure to find >> org.jboss.bom.wfk:jboss-javaee-6.0-with-deltaspike:pom:2.6.0-redhat-1 in >> http://repo.maven.apache.org/maven2 was cached in the local repository, >> resolution will not be reattempted until the update interval of central has >> elapsed or updates are forced @ line 99, column 25 -> [Help 2] >> [ERROR] Non-resolvable import POM: Failure to find >> org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.2.GA in >> http://repo.maven.apache.org/maven2 was cached in the local repository, >> resolution will not be reattempted until the update interval of central has >> elapsed or updates are forced @ line 107, column 25 -> [Help 2] >> [ERROR] Non-resolvable import POM: Failure to find >> org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.2.GA in >> http://repo.maven.apache.org/maven2 was cached in the local repository, >> resolution will not be reattempted until the update interval of central has >> elapsed or updates are forced @ line 115, column 25 -> [Help 2] >> [ERROR] Non-resolvable import POM: Failure to find >> org.jboss.bom.eap:jboss-javaee-6.0-with-security:pom:6.2.2.GA in >> http://repo.maven.apache.org/maven2 was cached in the local repository, >> resolution will not be reattempted until the update interval of central has >> elapsed or updates are forced @ line 122, column 25 -> [Help 2] >> [ERROR] 'dependencies.dependency.version' for >> javax.enterprise:cdi-api:jar is missing. @ line 167, column 21 >> [ERROR] 'dependencies.dependency.version' for >> javax.inject:javax.inject:jar is missing. @ line 172, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is >> missing. @ line 179, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @ >> line 186, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @ >> line 193, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line 200, >> column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ >> line 207, column 21 >> [ERROR] 'dependencies.dependency.version' for >> javax.validation:validation-api:jar is missing. @ line 214, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.hibernate:hibernate-validator:jar is missing. @ line 223, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.resteasy:resteasy-jackson-provider:jar is missing. @ line 235, >> column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.apache.deltaspike.core:deltaspike-core-api:jar is missing. @ line 283, >> column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.apache.deltaspike.core:deltaspike-core-impl:jar is missing. @ line 291, >> column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.apache.deltaspike.modules:deltaspike-security-module-api:jar is >> missing. @ line 300, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.apache.deltaspike.modules:deltaspike-security-module-impl:jar is >> missing. @ line 308, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 317, column 21 >> [ERROR] 'dependencies.dependency.version' for junit:junit:jar is >> missing. @ line 324, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @ >> line 336, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is missing. @ >> line 342, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.arquillian.container:arquillian-container-test-api:jar is >> missing. @ line 348, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.arquillian.junit:arquillian-junit-core:jar is missing. @ line >> 354, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.shrinkwrap:shrinkwrap-api:jar is missing. @ line 360, column 21 >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:jar is missing. >> @ line 366, column 21 >> [ERROR] >> [ERROR] The project >> org.jboss.quickstarts.wfk:jboss-contacts-mobile-proxy:1.0.0.Beta2-SNAPSHOT >> (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-proxy/pom.xml) >> has 4 errors >> [ERROR] Non-resolvable import POM: Failure to find >> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in >> http://repo.maven.apache.org/maven2 was cached in the local repository, >> resolution will not be reattempted until the update interval of central has >> elapsed or updates are forced @ >> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], >> /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, >> line 42, column 25 -> [Help 2] >> [ERROR] Non-resolvable import POM: Could not find artifact >> org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.0.GA in central >> (http://repo.maven.apache.org/maven2) @ line 79, column 25 -> [Help 2] >> [ERROR] 'dependencies.dependency.version' for >> org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ >> line 92, column 21 >> [ERROR] 'dependencies.dependency.version' for junit:junit:jar is >> missing. @ line 117, column 21 >> [ERROR] >> [ERROR] To see the full stack trace of the errors, re-run Maven with the >> -e switch. >> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >> [ERROR] >> [ERROR] For more information about the errors and possible solutions, >> please read the following articles: >> [ERROR] [Help 1] >> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException >> [ERROR] [Help 2] >> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/6a8e6bf5/attachment-0001.html From lholmqui at redhat.com Mon Aug 11 14:54:09 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 11 Aug 2014 14:54:09 -0400 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <2B9EF7DF-24C3-4C4B-B277-3BAD71DF6055@redhat.com> References: <2B9EF7DF-24C3-4C4B-B277-3BAD71DF6055@redhat.com> Message-ID: <55A63DBC-9E6B-4312-8E12-CC629C54C479@redhat.com> I?ve tests the iOS, Android, and Cordova Angular Version Beta2 branch with the UPS Beta2 branch and things are working On Aug 11, 2014, at 9:58 AM, Lucas Holmquist wrote: > i?ll probably be mostly testing the quick starts, as i have been recently playing with them > > > > > On Aug 8, 2014, at 9:11 AM, Matthias Wessendorf wrote: > >> Hi team, >> >> now that we have votes for the UPS and the java-sender (see [1] and [2]), I'd like to start testing the release bundle. >> >> As mentioned on IRC, the nominees for the testing, are: >> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >> >> Besides testing the UPS and sender staging repos, please test our quickstarts as well: >> 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 tag) >> 2) https://github.com/aerogear/aerogear-push-quickstarts >> >> Regarding 2), please use the master branch, for now. There will be a .Beta2 tag as well, once the open PRs are merged (and reviewed) >> >> Last but not least, please 'test' (review) the documentation as well, like our guide on the UnifiedPush Server: >> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >> >> BTW. there is more doc on the new 'UPS doc center' :-) >> http://staging.aerogear.org/docs/unifiedpush >> >> >> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after that we can go to CODE_FREEZE for the 1.0.0.Final >> >> Any thoughts ? >> >> -Matthias >> >> PS: besides the nominated folks, others are welcome to test the things as well :) >> >> >> -Matthias >> >> [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >> [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/d7f12154/attachment.html From supittma at redhat.com Mon Aug 11 16:40:53 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 11 Aug 2014 16:40:53 -0400 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <53E8D47A.3040006@redhat.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> <53E8D47A.3040006@redhat.com> Message-ID: <53E92A55.2080102@redhat.com> Hey, since we've moved to KC for auth, do the restful login bits still work? Here's what I've got so far : https://gist.github.com/secondsun/9a2bd78fe94bf4031a8a I can rewrite the Android guide section on setting up a variant to use the UI if we aren't using the restful end points. If we are I can update them with the correct commands and such. On 8/11/2014 10:34 AM, Summers Pittman wrote: > On 8/11/2014 9:26 AM, Burr Sutter wrote: >> >> On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf > > wrote: >> >>> >>> >>> >>> On Mon, Aug 11, 2014 at 1:42 PM, Daniel >>> Bevenius>> >wrote: >>> >>> Tested aerogear-push-hellworld/cordova and found this issue: >>> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >>> >>> Other than that I was able to run both the Android and iOS >>> applications and receive push notifications. >>> >>> I did not have ant installed which generated an error which was >>> pretty clear, but perhaps we should add something about this >>> requirement unless it is mentioned elsewhere. >>> >>> >>> oh, right - I think it does not hurt to have 'Ant' in the >>> requirements section (install is also easy :-) -> brew install ant ) >> Cordova and Android will mostly be developed on Windows machines. >> >> I assue the non-command-line user will be fine just using JBDS - many >> Windows-based developers never see a command line (DOS prompt). >> >> And for those Windows-based devs who are comfortable with an command >> line - we can specify what version of Ant they should have in their >> PATH and they should know what the PATH is. > I'll make the runs on windows and see how things go. >> >>> >>> >>> >>> On 11 August 2014 12:24, Daniel >>> Bevenius>> >wrote: >>> >>> Tested aerogear-push/helloworld/andorid and was able to >>> follow the docs to setup everything and try out the >>> application and receiving notifications by using Genymotion >>> (thanks to Erik and Passos for helping me set that up). >>> >>> >>> >>> >>> >>> On 11 August 2014 09:31, Daniel >>> Bevenius>> >wrote: >>> >>> Tested aerogear-push-helloworld/ios and found the >>> following minor issues: >>> * _https://issues.jboss.org/browse/AGPUSH-925_ "iOS >>> helloworld example contains out dated information >>> regarding sending push messages." >>> * >>> _https://github.com/aerogear/aerogear.org/pull/350_ "Minor >>> spelling corrections/suggestions" >>> Other than those I was able to follow the docs from >>> scratch and run the app and successfully received push >>> notifications. >>> >>> >>> >>> >>> On 10 August 2014 13:48, Matthias >>> Wessendorf>> >wrote: >>> >>> >>> >>> >>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias >>> Wessendorf>> >wrote: >>> >>> Hi team, >>> >>> now that we have votes for the UPS and the >>> java-sender (see [1] and [2]), I'd like to start >>> testing the release bundle. >>> >>> As mentioned on IRC, the nominees for the >>> testing, are: >>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc >>> and abstractj >>> >>> Besides testing the UPS and sender staging >>> repos, please test our quickstarts as well: >>> 1)https://github.com/aerogear/aerogear-push-helloworld/releases/latest(1.0.0.Beta2 >>> tag) >>> 2)https://github.com/aerogear/aerogear-push-quickstarts >>> >>> >>> Regarding 2), please use the master branch, for >>> now. There will be a .Beta2 tag as well, once >>> the open PRs are merged (and reviewed) >>> >>> >>> Most of the PRs have been merged and reviewed. Those >>> that are open require some additional work and it's >>> perfectly fine to get them in for 1.0.0.Final. >>> Therefore here is the Beta2 release/tag >>> >>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>> >>> >>> Last but not least, please 'test' (review) the >>> documentation as well, like our guide on the >>> UnifiedPush Server: >>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>> >>> BTW. there is more doc on the new 'UPS doc >>> center' :-) >>> http://staging.aerogear.org/docs/unifiedpush >>> >>> >>> Hopefully, by Wednesday we have an awesome >>> 1.0.0.Beta2 and shortly after that we can go to >>> CODE_FREEZE for the 1.0.0.Final >>> >>> Any thoughts ? >>> >>> -Matthias >>> >>> PS: besides the nominated folks, others are >>> welcome to test the things as well :) >>> >>> >>> -Matthias >>> >>> [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>> [2]http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog:http://matthiaswessendorf.wordpress.com/ >>> sessions:http://www.slideshare.net/mwessendorf >>> twitter:http://twitter.com/mwessendorf >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog:http://matthiaswessendorf.wordpress.com/ >>> sessions:http://www.slideshare.net/mwessendorf >>> twitter:http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog:http://matthiaswessendorf.wordpress.com/ >>> sessions:http://www.slideshare.net/mwessendorf >>> twitter:http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/36df0111/attachment-0001.html From daniel at passos.me Mon Aug 11 18:46:44 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 11 Aug 2014 19:46:44 -0300 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <53E92A55.2080102@redhat.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> <53E8D47A.3040006@redhat.com> <53E92A55.2080102@redhat.com> Message-ID: Summers, All curl steps were replaced by AdminUI. We need update this doc as Dan asked here[1]. Let's use[2] to do it [1] https://issues.jboss.org/browse/AGDROID-166?focusedCommentId=12991267 [2] https://issues.jboss.org/browse/AGPUSH-851 -- Passos On Mon, Aug 11, 2014 at 5:40 PM, Summers Pittman wrote: > Hey, since we've moved to KC for auth, do the restful login bits still > work? > > Here's what I've got so far : > https://gist.github.com/secondsun/9a2bd78fe94bf4031a8a > > I can rewrite the Android guide section on setting up a variant to use the > UI if we aren't using the restful end points. If we are I can update them > with the correct commands and such. > > > On 8/11/2014 10:34 AM, Summers Pittman wrote: > > On 8/11/2014 9:26 AM, Burr Sutter wrote: > > > On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf > wrote: > > > > > On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Tested aerogear-push-hellworld/cordova and found this issue: >> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >> >> Other than that I was able to run both the Android and iOS applications >> and receive push notifications. >> >> I did not have ant installed which generated an error which was pretty >> clear, but perhaps we should add something about this requirement unless it >> is mentioned elsewhere. >> > > oh, right - I think it does not hurt to have 'Ant' in the requirements > section (install is also easy :-) -> brew install ant ) > > Cordova and Android will mostly be developed on Windows machines. > > I assue the non-command-line user will be fine just using JBDS - many > Windows-based developers never see a command line (DOS prompt). > > And for those Windows-based devs who are comfortable with an command > line - we can specify what version of Ant they should have in their PATH > and they should know what the PATH is. > > I'll make the runs on windows and see how things go. > > > > >> >> >> >> On 11 August 2014 12:24, Daniel Bevenius >> wrote: >> >>> Tested aerogear-push/helloworld/andorid and was able to follow the docs >>> to setup everything and try out the application and receiving notifications >>> by using Genymotion (thanks to Erik and Passos for helping me set that up). >>> >>> >>> >>> >>> >>> On 11 August 2014 09:31, Daniel Bevenius >>> wrote: >>> >>>> Tested aerogear-push-helloworld/ios and found the following minor >>>> issues: >>>> * *https://issues.jboss.org/browse/AGPUSH-925 >>>> * "iOS helloworld example >>>> contains out dated information regarding sending push messages." >>>> * *https://github.com/aerogear/aerogear.org/pull/350 >>>> * "Minor spelling >>>> corrections/suggestions" >>>> Other than those I was able to follow the docs from scratch and run the >>>> app and successfully received push notifications. >>>> >>>> >>>> >>>> >>>> On 10 August 2014 13:48, Matthias Wessendorf >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> Hi team, >>>>>> >>>>>> now that we have votes for the UPS and the java-sender (see [1] and >>>>>> [2]), I'd like to start testing the release bundle. >>>>>> >>>>>> As mentioned on IRC, the nominees for the testing, are: >>>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>>>> >>>>>> Besides testing the UPS and sender staging repos, please test our >>>>>> quickstarts as well: >>>>>> 1) >>>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 >>>>>> tag) >>>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>>>> >>>>>> Regarding 2), please use the master branch, for now. There will be >>>>>> a .Beta2 tag as well, once the open PRs are merged (and reviewed) >>>>>> >>>>> >>>>> Most of the PRs have been merged and reviewed. Those that are open >>>>> require some additional work and it's perfectly fine to get them in for >>>>> 1.0.0.Final. >>>>> Therefore here is the Beta2 release/tag >>>>> >>>>> >>>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>>>> >>>>> >>>>>> >>>>>> Last but not least, please 'test' (review) the documentation as >>>>>> well, like our guide on the UnifiedPush Server: >>>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>>>> >>>>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>>>> http://staging.aerogear.org/docs/unifiedpush >>>>>> >>>>>> >>>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly >>>>>> after that we can go to CODE_FREEZE for the 1.0.0.Final >>>>>> >>>>>> Any thoughts ? >>>>>> >>>>>> -Matthias >>>>>> >>>>>> PS: besides the nominated folks, others are welcome to test the >>>>>> things as well :) >>>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> [1] >>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>>>> [2] >>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140811/ca60dab2/attachment-0001.html From matzew at apache.org Tue Aug 12 02:48:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 12 Aug 2014 08:48:37 +0200 Subject: [aerogear-dev] Push Quickstarts - Maven ? In-Reply-To: References: Message-ID: Bruno already improved some of the confusing instructions. I think with https://github.com/aerogear/aerogear-push-quickstarts/pull/60 merged, we are good to go One question: Should be use --setting settings.xml? Or contributor-settings.xml ? -Matthias On Mon, Aug 11, 2014 at 8:33 PM, Matthias Wessendorf wrote: > ah!!!!!!!!!!!!!!!! > > thanks, Sebi - I am on Apache Maven 3.2.2 > (45f7c06d68e745d05611f7fd14efb6594181933e; 2014-06-17T15:51:42+02:00) > > > I will update the README tomorrow! > > thanks! > > > On Mon, Aug 11, 2014 at 8:14 PM, Sebastien Blanc > wrote: > >> Which version of Maven are you using ? I remember Fred reported a bug >> with Maven and resolving BOMs : https://jira.codehaus.org/browse/MNG-5663 >> >> >> On Mon, Aug 11, 2014 at 7:27 PM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> the README on the quickstarts have a "Configure Maven to Build and >>> Deploy the Quickstarts". >>> >>> I am not able to build the thing, nor do I understand the "need" to do >>> all that (especially "replace the repo" part). >>> >>> Doing "mvn clean -s ./contributor-settings.xml" (similar to using the >>> "settings.xml" instead) on the root of the directory gives some maven >>> trouble (as reported in a few PRs last week) >>> >>> >>> So.... I am wondering how folks are building this... >>> >>> Ideally a "mvn clean install -s ./contributor-settings.xml" should work. >>> Or if some magic profile needs to be enabled, our README should say so >>> >>> >>> Thanks, >>> Matthias >>> >>> >>> >>> >>> >>> >>> [INFO] Scanning for projects... >>> Downloading: >>> http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-resteasy/6.2.0.GA/jboss-javaee-6.0-with-resteasy-6.2.0.GA.pom >>> [ERROR] The build could not read 2 projects -> [Help 1] >>> [ERROR] >>> [ERROR] The project >>> org.jboss.quickstarts.wfk:jboss-contacts-mobile-picketlink-secured:1.0.0.Beta2-SNAPSHOT >>> (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-picketlink-secured/pom.xml) >>> has 27 errors >>> [ERROR] Non-resolvable import POM: Failure to find >>> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in >>> http://repo.maven.apache.org/maven2 was cached in the local repository, >>> resolution will not be reattempted until the update interval of central has >>> elapsed or updates are forced @ >>> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], >>> /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, >>> line 42, column 25 -> [Help 2] >>> [ERROR] Non-resolvable import POM: Failure to find >>> org.jboss.bom.wfk:jboss-javaee-6.0-with-deltaspike:pom:2.6.0-redhat-1 in >>> http://repo.maven.apache.org/maven2 was cached in the local repository, >>> resolution will not be reattempted until the update interval of central has >>> elapsed or updates are forced @ line 99, column 25 -> [Help 2] >>> [ERROR] Non-resolvable import POM: Failure to find >>> org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.2.GA in >>> http://repo.maven.apache.org/maven2 was cached in the local repository, >>> resolution will not be reattempted until the update interval of central has >>> elapsed or updates are forced @ line 107, column 25 -> [Help 2] >>> [ERROR] Non-resolvable import POM: Failure to find >>> org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.2.GA in >>> http://repo.maven.apache.org/maven2 was cached in the local repository, >>> resolution will not be reattempted until the update interval of central has >>> elapsed or updates are forced @ line 115, column 25 -> [Help 2] >>> [ERROR] Non-resolvable import POM: Failure to find >>> org.jboss.bom.eap:jboss-javaee-6.0-with-security:pom:6.2.2.GA in >>> http://repo.maven.apache.org/maven2 was cached in the local repository, >>> resolution will not be reattempted until the update interval of central has >>> elapsed or updates are forced @ line 122, column 25 -> [Help 2] >>> [ERROR] 'dependencies.dependency.version' for >>> javax.enterprise:cdi-api:jar is missing. @ line 167, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> javax.inject:javax.inject:jar is missing. @ line 172, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is >>> missing. @ line 179, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @ >>> line 186, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @ >>> line 193, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line 200, >>> column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ >>> line 207, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> javax.validation:validation-api:jar is missing. @ line 214, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.hibernate:hibernate-validator:jar is missing. @ line 223, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.resteasy:resteasy-jackson-provider:jar is missing. @ line 235, >>> column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.apache.deltaspike.core:deltaspike-core-api:jar is missing. @ line 283, >>> column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.apache.deltaspike.core:deltaspike-core-impl:jar is missing. @ line 291, >>> column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.apache.deltaspike.modules:deltaspike-security-module-api:jar is >>> missing. @ line 300, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.apache.deltaspike.modules:deltaspike-security-module-impl:jar is >>> missing. @ line 308, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 317, column 21 >>> [ERROR] 'dependencies.dependency.version' for junit:junit:jar is >>> missing. @ line 324, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @ >>> line 336, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is missing. @ >>> line 342, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.arquillian.container:arquillian-container-test-api:jar is >>> missing. @ line 348, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.arquillian.junit:arquillian-junit-core:jar is missing. @ line >>> 354, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.shrinkwrap:shrinkwrap-api:jar is missing. @ line 360, column 21 >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:jar is missing. >>> @ line 366, column 21 >>> [ERROR] >>> [ERROR] The project >>> org.jboss.quickstarts.wfk:jboss-contacts-mobile-proxy:1.0.0.Beta2-SNAPSHOT >>> (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-proxy/pom.xml) >>> has 4 errors >>> [ERROR] Non-resolvable import POM: Failure to find >>> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in >>> http://repo.maven.apache.org/maven2 was cached in the local repository, >>> resolution will not be reattempted until the update interval of central has >>> elapsed or updates are forced @ >>> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], >>> /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, >>> line 42, column 25 -> [Help 2] >>> [ERROR] Non-resolvable import POM: Could not find artifact >>> org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.0.GA in >>> central (http://repo.maven.apache.org/maven2) @ line 79, column 25 -> >>> [Help 2] >>> [ERROR] 'dependencies.dependency.version' for >>> org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ >>> line 92, column 21 >>> [ERROR] 'dependencies.dependency.version' for junit:junit:jar is >>> missing. @ line 117, column 21 >>> [ERROR] >>> [ERROR] To see the full stack trace of the errors, re-run Maven with the >>> -e switch. >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>> [ERROR] >>> [ERROR] For more information about the errors and possible solutions, >>> please read the following articles: >>> [ERROR] [Help 1] >>> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException >>> [ERROR] [Help 2] >>> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/799c2d30/attachment.html From edewit at redhat.com Tue Aug 12 04:05:42 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 12 Aug 2014 10:05:42 +0200 Subject: [aerogear-dev] cordova push plugin release Message-ID: Hi, We are going to release a new version of the cordova push plugin the new version 0.7.0 most important features are the ?content-availble? support for iOS and the iOS 8 support here the release notes: Bug [AGCORDOVA-22] - android binaries installed for other platforms Feature Request [AGCORDOVA-23] - Support content title with gcm notifications on android [AGCORDOVA-25] - iOS8 support for push registration I?ve created a branch 0.7.0-release [1] for your testing pleasure. If we don?t find issues we?ll perform the actual release on friday. [1] https://github.com/aerogear/aerogear-pushplugin-cordova/tree/0.7.0-release -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/c427ac68/attachment-0001.html From edewit at redhat.com Tue Aug 12 04:07:44 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 12 Aug 2014 10:07:44 +0200 Subject: [aerogear-dev] Push Quickstarts - Maven ? In-Reply-To: References: Message-ID: <64BBB87A-248C-4CA0-95EA-6E29D3EA0D0B@redhat.com> > One question: Should be use --setting settings.xml? Or contributor-settings.xml ? It?s contributor-settings.xml, but we should change that name / only have one to make that more simple. It confused me so? From matzew at apache.org Tue Aug 12 04:11:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 12 Aug 2014 10:11:54 +0200 Subject: [aerogear-dev] cordova push plugin release In-Reply-To: References: Message-ID: +1 sounds good to have a new release On Tue, Aug 12, 2014 at 10:05 AM, Erik Jan de Wit wrote: > Hi, > > We are going to release a new version of the cordova push plugin the new > version 0.7.0 most important features are the ?content-availble? support > for iOS and the iOS 8 support here the release notes: > Bug > > - [AGCORDOVA-22 ] - > android binaries installed for other platforms > > Feature Request > > - [AGCORDOVA-23 ] - > Support content title with gcm notifications on android > - [AGCORDOVA-25 ] - iOS8 > support for push registration > > > I?ve created a branch 0.7.0-release [1] for your testing pleasure. If we > don?t find issues we?ll perform the actual release on friday. > > [1] > https://github.com/aerogear/aerogear-pushplugin-cordova/tree/0.7.0-release > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/11b20c4d/attachment.html From daniel.bevenius at gmail.com Tue Aug 12 04:14:38 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 12 Aug 2014 10:14:38 +0200 Subject: [aerogear-dev] Push Quickstarts - Maven ? In-Reply-To: <64BBB87A-248C-4CA0-95EA-6E29D3EA0D0B@redhat.com> References: <64BBB87A-248C-4CA0-95EA-6E29D3EA0D0B@redhat.com> Message-ID: This is just a left over from the wfk quickstart and I agree that it's confusion. I guess we have to have one to be able to try things out with early releases but one should be enough. On 12 August 2014 10:07, Erik Jan de Wit wrote: > > One question: Should be use --setting settings.xml? Or > contributor-settings.xml ? > > It?s contributor-settings.xml, but we should change that name / only have > one to make that more simple. It confused me so? > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/30a7566a/attachment.html From mmusaji at redhat.com Tue Aug 12 04:26:45 2014 From: mmusaji at redhat.com (mmusaji) Date: Tue, 12 Aug 2014 01:26:45 -0700 (PDT) Subject: [aerogear-dev] JavaSender questions and a few other bits In-Reply-To: References: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> <1693815161.11914041.1407764521064.JavaMail.zimbra@redhat.com> <1407768174359-8833.post@n5.nabble.com> Message-ID: <3145901.28877537.1407831977470.JavaMail.zimbra@redhat.com> I feel stupid! Thanks a lot Matthias - I was just looking at the Variant ID and not the Application ID! If you have some time, be good to know how you got decoded the credentials :) Thanks Mus -------------- Mustafa Musaji Software Maintenance Engineer Red Hat UK Ltd 200 Fowler Avenue, Farnborough Business Park, Farnborough, Hants GU14 7JP Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charles Peters (USA), Michael O'Neill(Ireland) ----- Matthias Wessendorf [via aerogear-dev] wrote: > > > Hi Mus, > > I have decoded your credentials, submitted by the UnifiedPush Console. > ec8260b5-5db2-443a-90db-64e49d147c21:4b09a8b7-88da-4bc6-922a-c65fd40045f3 > > > however, your java code has this: > > 1. .pushApplicationId( > "73275d2d-5e83-4a87-8342-7a6cd15068f2") > 2. .masterSecret( > "cd9aabfa-e163-4a52-8f18-4ca3de3b1001") > > > > That does explain the 401 > > -Matthias > > > > > > > On Mon, Aug 11, 2014 at 4:42 PM, mmusaji wrote: > > > I'm using JavaSender 0.8.0. This is from the internal DR3 release. > > > > Here's the POST captured from the console. NOTE: this works fine, but the > > JavaSender fails so if you want me to capture anything from this side let > > me > > know how/what you need. > > > > Remote Address:10.33.1.143:8080 > > Request URL:http://10.33.1.143:8080/ag-push/rest/sender > > Request Method:POST > > Status Code:200 OK > > Request Headersview source > > Accept:application/json, text/plain, */* > > Accept-Encoding:gzip,deflate,sdch > > Accept-Language:en-US,en;q=0.8,en-GB;q=0.6 > > aerogear-sender:AeroGear UnifiedPush Console > > Authorization:Basic > > > > ZWM4MjYwYjUtNWRiMi00NDNhLTkwZGItNjRlNDlkMTQ3YzIxOjRiMDlhOGI3LTg4ZGEtNGJjNi05MjJhLWM2NWZkNDAwNDVmMw== > > Connection:keep-alive > > Content-Length:46 > > Content-Type:application/json;charset=UTF-8 > > Host:10.33.1.143:8080 > > Origin:http://10.33.1.143:8080 > > Referer:http://10.33.1.143:8080/ag-push/ > > User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like > > Gecko) Chrome/36.0.1985.125 Safari/537.36 > > Request Payloadview source > > {message:{sound:default, alert:Blah}} > > message: {sound:default, alert:Blah} > > Response Headersview source > > Content-Length:13 > > Content-Type:application/json > > Date:Mon, 11 Aug 2014 14:36:59 GMT > > Server:Apache-Coyote/1.1 > > > > > > > > -- > > View this message in context: > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaSender-questions-and-a-few-other-bits-tp8827p8833.html > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > If you reply to this email, your message will be added to the discussion below: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaSender-questions-and-a-few-other-bits-tp8827p8840.html > > To unsubscribe from [aerogear-dev] JavaSender questions and a few other bits, visit http://aerogear-dev.1069024.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=8827&code=bW11c2FqaUByZWRoYXQuY29tfDg4Mjd8LTIxMDg3NjI0OTU= -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaSender-questions-and-a-few-other-bits-tp8827p8856.html Sent from the aerogear-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/7ad4f26a/attachment.html From matzew at apache.org Tue Aug 12 04:32:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 12 Aug 2014 10:32:36 +0200 Subject: [aerogear-dev] JavaSender questions and a few other bits In-Reply-To: <3145901.28877537.1407831977470.JavaMail.zimbra@redhat.com> References: <1452862882.28136926.1407764118266.JavaMail.zimbra@redhat.com> <1693815161.11914041.1407764521064.JavaMail.zimbra@redhat.com> <1407768174359-8833.post@n5.nabble.com> <3145901.28877537.1407831977470.JavaMail.zimbra@redhat.com> Message-ID: Base64 based de and encoding. Here is what I did: https://gist.github.com/matzew/ed817310bc8ea523e536 On Tue, Aug 12, 2014 at 10:26 AM, mmusaji wrote: > I feel stupid! Thanks a lot Matthias - I was just looking at the Variant > ID and not the Application ID! > > If you have some time, be good to know how you got decoded the credentials > :) > > Thanks > Mus > > -------------- > Mustafa Musaji > Software Maintenance Engineer > Red Hat UK Ltd > 200 Fowler Avenue, Farnborough Business Park, Farnborough, Hants GU14 7JP > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charles Peters > (USA), Michael O'Neill(Ireland) > > ----- Matthias Wessendorf [via aerogear-dev] <[hidden email] > > wrote: > > > > > > > Hi Mus, > > > > I have decoded your credentials, submitted by the UnifiedPush Console. > > > ec8260b5-5db2-443a-90db-64e49d147c21:4b09a8b7-88da-4bc6-922a-c65fd40045f3 > > > > > > however, your java code has this: > > > > 1. .pushApplicationId( > > "73275d2d-5e83-4a87-8342-7a6cd15068f2") > > 2. .masterSecret( > > "cd9aabfa-e163-4a52-8f18-4ca3de3b1001") > > > > > > > > That does explain the 401 > > > > -Matthias > > > > > > > > > > > > > > On Mon, Aug 11, 2014 at 4:42 PM, mmusaji <[hidden email] > > wrote: > > > > > I'm using JavaSender 0.8.0. This is from the internal DR3 release. > > > > > > Here's the POST captured from the console. NOTE: this works fine, but > the > > > JavaSender fails so if you want me to capture anything from this side > let > > > me > > > know how/what you need. > > > > > > Remote Address:10.33.1.143:8080 > > > Request URL:http://10.33.1.143:8080/ag-push/rest/sender > > > Request Method:POST > > > Status Code:200 OK > > > Request Headersview source > > > Accept:application/json, text/plain, */* > > > Accept-Encoding:gzip,deflate,sdch > > > Accept-Language:en-US,en;q=0.8,en-GB;q=0.6 > > > aerogear-sender:AeroGear UnifiedPush Console > > > Authorization:Basic > > > > > > > ZWM4MjYwYjUtNWRiMi00NDNhLTkwZGItNjRlNDlkMTQ3YzIxOjRiMDlhOGI3LTg4ZGEtNGJjNi05MjJhLWM2NWZkNDAwNDVmMw== > > > > Connection:keep-alive > > > Content-Length:46 > > > Content-Type:application/json;charset=UTF-8 > > > Host:10.33.1.143:8080 > > > Origin:http://10.33.1.143:8080 > > > Referer:http://10.33.1.143:8080/ag-push/ > > > User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, > like > > > Gecko) Chrome/36.0.1985.125 Safari/537.36 > > > Request Payloadview source > > > {message:{sound:default, alert:Blah}} > > > message: {sound:default, alert:Blah} > > > Response Headersview source > > > Content-Length:13 > > > Content-Type:application/json > > > Date:Mon, 11 Aug 2014 14:36:59 GMT > > > Server:Apache-Coyote/1.1 > > > > > > > > > > > > -- > > > View this message in context: > > > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaSender-questions-and-a-few-other-bits-tp8827p8833.html > > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > > _______________________________________________ > > > aerogear-dev mailing list > > > [hidden email] > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > [hidden email] > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > _______________________________________________ > > If you reply to this email, your message will be added to the discussion > below: > > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-JavaSender-questions-and-a-few-other-bits-tp8827p8840.html > > > > To unsubscribe from [aerogear-dev] JavaSender questions and a few other > bits, visit > ------------------------------ > View this message in context: Re: [aerogear-dev] JavaSender questions and > a few other bits > > > Sent from the aerogear-dev mailing list archive > at Nabble.com. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/ea4e5aa1/attachment-0001.html From matzew at apache.org Tue Aug 12 06:45:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 12 Aug 2014 12:45:02 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta2 In-Reply-To: References: Message-ID: We have a bug that only is present on WF 8.1 Works fine on: * WF 8.0 * JBoss AS7.1.1 * EAP 6.3 https://github.com/aerogear/aerogear-unifiedpush-server/pull/351 What do folks think? Should we include this into the BETA2, and replace the staged bits ? On Fri, Aug 8, 2014 at 2:52 PM, Matthias Wessendorf wrote: > Hello folks! > > we are getting closer and closer to our 1.0.0 release! Thank you very > much, guys! > > However, before we are moving towards the 1.0.0.Final community release, > I'd love to get the current work out as 1.0.0.Beta2 > > Note this release contains a ton of work and new features. To name a few > highlights: > > * Keycloak beta-4 usage > * Wildfly support > * new documentation guide on UPS > * various improvements on the server and its UI! > > The did an outstanding job to get the Beta2 done. Details on all the JIRAs > can be found here: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092 > > The staging repository is located here: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3670/ > > > NOTE: Once this release has been approved the matching tag will be used to > get the OpenShift online bits updated! > > Let me know the results of your testing! > If I hear nothing bad by Tuesday evening, the release to maven central > will happen on Wednesday morning; > > Greetings, > Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/319b9278/attachment.html From bruno at abstractj.org Tue Aug 12 06:54:00 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 12 Aug 2014 07:54:00 -0300 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta2 In-Reply-To: References: Message-ID: <20140812105400.GA46740@abstractj.org> Add it to the release announcement with proper Jiras and let people know. Something like "we're aware of a bug on Wildfly 8.1....please see the Jira". And ship it. On 2014-08-12, Matthias Wessendorf wrote: > We have a bug that only is present on WF 8.1 > > Works fine on: > * WF 8.0 > * JBoss AS7.1.1 > * EAP 6.3 > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/351 > > What do folks think? Should we include this into the BETA2, and replace the > staged bits ? > > > > > > > > > > On Fri, Aug 8, 2014 at 2:52 PM, Matthias Wessendorf > wrote: > > > Hello folks! > > > > we are getting closer and closer to our 1.0.0 release! Thank you very > > much, guys! > > > > However, before we are moving towards the 1.0.0.Final community release, > > I'd love to get the current work out as 1.0.0.Beta2 > > > > Note this release contains a ton of work and new features. To name a few > > highlights: > > > > * Keycloak beta-4 usage > > * Wildfly support > > * new documentation guide on UPS > > * various improvements on the server and its UI! > > > > The did an outstanding job to get the Beta2 done. Details on all the JIRAs > > can be found here: > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092 > > > > The staging repository is located here: > > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3670/ > > > > > > NOTE: Once this release has been approved the matching tag will be used to > > get the OpenShift online bits updated! > > > > Let me know the results of your testing! > > If I hear nothing bad by Tuesday evening, the release to maven central > > will happen on Wednesday morning; > > > > Greetings, > > Matthias > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Tue Aug 12 07:02:41 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 12 Aug 2014 13:02:41 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta2 In-Reply-To: <20140812105400.GA46740@abstractj.org> References: <20140812105400.GA46740@abstractj.org> Message-ID: Good point. -M On Tue, Aug 12, 2014 at 12:54 PM, Bruno Oliveira wrote: > > Add it to the release announcement with proper Jiras and let people > know. Something like "we're aware of a bug on Wildfly 8.1....please see > the Jira". > > And ship it. > > On 2014-08-12, Matthias Wessendorf wrote: > > We have a bug that only is present on WF 8.1 > > > > Works fine on: > > * WF 8.0 > > * JBoss AS7.1.1 > > * EAP 6.3 > > > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/351 > > > > What do folks think? Should we include this into the BETA2, and replace > the > > staged bits ? > > > > > > > > > > > > > > > > > > > > On Fri, Aug 8, 2014 at 2:52 PM, Matthias Wessendorf > > wrote: > > > > > Hello folks! > > > > > > we are getting closer and closer to our 1.0.0 release! Thank you very > > > much, guys! > > > > > > However, before we are moving towards the 1.0.0.Final community > release, > > > I'd love to get the current work out as 1.0.0.Beta2 > > > > > > Note this release contains a ton of work and new features. To name a > few > > > highlights: > > > > > > * Keycloak beta-4 usage > > > * Wildfly support > > > * new documentation guide on UPS > > > * various improvements on the server and its UI! > > > > > > The did an outstanding job to get the Beta2 done. Details on all the > JIRAs > > > can be found here: > > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092 > > > > > > The staging repository is located here: > > > > > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3670/ > > > > > > > > > NOTE: Once this release has been approved the matching tag will be > used to > > > get the OpenShift online bits updated! > > > > > > Let me know the results of your testing! > > > If I hear nothing bad by Tuesday evening, the release to maven central > > > will happen on Wednesday morning; > > > > > > Greetings, > > > Matthias > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/51e17bc7/attachment.html From tkriz at redhat.com Tue Aug 12 07:06:52 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Tue, 12 Aug 2014 13:06:52 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta2 In-Reply-To: References: <20140812105400.GA46740@abstractj.org> Message-ID: <200C825A-D408-4625-8004-6045C2CA5298@redhat.com> I think that as we have the fix already, restaging would make sense, so until the next release there will be a working version. ? Tadeas Kriz On 12 Aug 2014, at 01:02 pm, Matthias Wessendorf wrote: > Good point. > > -M > > > On Tue, Aug 12, 2014 at 12:54 PM, Bruno Oliveira wrote: > > Add it to the release announcement with proper Jiras and let people > know. Something like "we're aware of a bug on Wildfly 8.1....please see > the Jira". > > And ship it. > > On 2014-08-12, Matthias Wessendorf wrote: > > We have a bug that only is present on WF 8.1 > > > > Works fine on: > > * WF 8.0 > > * JBoss AS7.1.1 > > * EAP 6.3 > > > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/351 > > > > What do folks think? Should we include this into the BETA2, and replace the > > staged bits ? > > > > > > > > > > > > > > > > > > > > On Fri, Aug 8, 2014 at 2:52 PM, Matthias Wessendorf > > wrote: > > > > > Hello folks! > > > > > > we are getting closer and closer to our 1.0.0 release! Thank you very > > > much, guys! > > > > > > However, before we are moving towards the 1.0.0.Final community release, > > > I'd love to get the current work out as 1.0.0.Beta2 > > > > > > Note this release contains a ton of work and new features. To name a few > > > highlights: > > > > > > * Keycloak beta-4 usage > > > * Wildfly support > > > * new documentation guide on UPS > > > * various improvements on the server and its UI! > > > > > > The did an outstanding job to get the Beta2 done. Details on all the JIRAs > > > can be found here: > > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092 > > > > > > The staging repository is located here: > > > > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3670/ > > > > > > > > > NOTE: Once this release has been approved the matching tag will be used to > > > get the OpenShift online bits updated! > > > > > > Let me know the results of your testing! > > > If I hear nothing bad by Tuesday evening, the release to maven central > > > will happen on Wednesday morning; > > > > > > Greetings, > > > Matthias > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/81aaa2e4/attachment-0001.html From matzew at apache.org Tue Aug 12 07:08:04 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 12 Aug 2014 13:08:04 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta2 In-Reply-To: <200C825A-D408-4625-8004-6045C2CA5298@redhat.com> References: <20140812105400.GA46740@abstractj.org> <200C825A-D408-4625-8004-6045C2CA5298@redhat.com> Message-ID: the next release will be out around 20th, or slightly later. Also, they could crack up the WAR and do the XML fu themselfs (see PR) On Tue, Aug 12, 2014 at 1:06 PM, Tadeas Kriz wrote: > I think that as we have the fix already, restaging would make sense, so > until the next release there will be a working version. > > ? > Tadeas Kriz > > On 12 Aug 2014, at 01:02 pm, Matthias Wessendorf > wrote: > > Good point. > > -M > > > On Tue, Aug 12, 2014 at 12:54 PM, Bruno Oliveira > wrote: > >> >> Add it to the release announcement with proper Jiras and let people >> know. Something like "we're aware of a bug on Wildfly 8.1....please see >> the Jira". >> >> And ship it. >> >> On 2014-08-12, Matthias Wessendorf wrote: >> > We have a bug that only is present on WF 8.1 >> > >> > Works fine on: >> > * WF 8.0 >> > * JBoss AS7.1.1 >> > * EAP 6.3 >> > >> > https://github.com/aerogear/aerogear-unifiedpush-server/pull/351 >> > >> > What do folks think? Should we include this into the BETA2, and replace >> the >> > staged bits ? >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > On Fri, Aug 8, 2014 at 2:52 PM, Matthias Wessendorf >> > wrote: >> > >> > > Hello folks! >> > > >> > > we are getting closer and closer to our 1.0.0 release! Thank you very >> > > much, guys! >> > > >> > > However, before we are moving towards the 1.0.0.Final community >> release, >> > > I'd love to get the current work out as 1.0.0.Beta2 >> > > >> > > Note this release contains a ton of work and new features. To name a >> few >> > > highlights: >> > > >> > > * Keycloak beta-4 usage >> > > * Wildfly support >> > > * new documentation guide on UPS >> > > * various improvements on the server and its UI! >> > > >> > > The did an outstanding job to get the Beta2 done. Details on all the >> JIRAs >> > > can be found here: >> > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092 >> > > >> > > The staging repository is located here: >> > > >> > > >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3670/ >> > > >> > > >> > > NOTE: Once this release has been approved the matching tag will be >> used to >> > > get the OpenShift online bits updated! >> > > >> > > Let me know the results of your testing! >> > > If I hear nothing bad by Tuesday evening, the release to maven central >> > > will happen on Wednesday morning; >> > > >> > > Greetings, >> > > Matthias >> > > >> > > >> > > -- >> > > Matthias Wessendorf >> > > >> > > blog: http://matthiaswessendorf.wordpress.com/ >> > > sessions: http://www.slideshare.net/mwessendorf >> > > twitter: http://twitter.com/mwessendorf >> > > >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/ceccea1c/attachment.html From bruno at abstractj.org Tue Aug 12 07:11:11 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 12 Aug 2014 08:11:11 -0300 Subject: [aerogear-dev] Push Quickstarts - Maven ? In-Reply-To: References: Message-ID: <20140812111111.GB46740@abstractj.org> Ahoy, commented on your PR https://github.com/aerogear/aerogear-push-quickstarts/pull/60 On 2014-08-12, Matthias Wessendorf wrote: > Bruno already improved some of the confusing instructions. > > I think with https://github.com/aerogear/aerogear-push-quickstarts/pull/60 > merged, we are good to go > > One question: Should be use --setting settings.xml? Or > contributor-settings.xml ? > > -Matthias > > > On Mon, Aug 11, 2014 at 8:33 PM, Matthias Wessendorf > wrote: > > > ah!!!!!!!!!!!!!!!! > > > > thanks, Sebi - I am on Apache Maven 3.2.2 > > (45f7c06d68e745d05611f7fd14efb6594181933e; 2014-06-17T15:51:42+02:00) > > > > > > I will update the README tomorrow! > > > > thanks! > > > > > > On Mon, Aug 11, 2014 at 8:14 PM, Sebastien Blanc > > wrote: > > > >> Which version of Maven are you using ? I remember Fred reported a bug > >> with Maven and resolving BOMs : https://jira.codehaus.org/browse/MNG-5663 > >> > >> > >> On Mon, Aug 11, 2014 at 7:27 PM, Matthias Wessendorf > >> wrote: > >> > >>> Hi, > >>> > >>> the README on the quickstarts have a "Configure Maven to Build and > >>> Deploy the Quickstarts". > >>> > >>> I am not able to build the thing, nor do I understand the "need" to do > >>> all that (especially "replace the repo" part). > >>> > >>> Doing "mvn clean -s ./contributor-settings.xml" (similar to using the > >>> "settings.xml" instead) on the root of the directory gives some maven > >>> trouble (as reported in a few PRs last week) > >>> > >>> > >>> So.... I am wondering how folks are building this... > >>> > >>> Ideally a "mvn clean install -s ./contributor-settings.xml" should work. > >>> Or if some magic profile needs to be enabled, our README should say so > >>> > >>> > >>> Thanks, > >>> Matthias > >>> > >>> > >>> > >>> > >>> > >>> > >>> [INFO] Scanning for projects... > >>> Downloading: > >>> http://repo.maven.apache.org/maven2/org/jboss/bom/eap/jboss-javaee-6.0-with-resteasy/6.2.0.GA/jboss-javaee-6.0-with-resteasy-6.2.0.GA.pom > >>> [ERROR] The build could not read 2 projects -> [Help 1] > >>> [ERROR] > >>> [ERROR] The project > >>> org.jboss.quickstarts.wfk:jboss-contacts-mobile-picketlink-secured:1.0.0.Beta2-SNAPSHOT > >>> (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-picketlink-secured/pom.xml) > >>> has 27 errors > >>> [ERROR] Non-resolvable import POM: Failure to find > >>> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in > >>> http://repo.maven.apache.org/maven2 was cached in the local repository, > >>> resolution will not be reattempted until the update interval of central has > >>> elapsed or updates are forced @ > >>> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], > >>> /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, > >>> line 42, column 25 -> [Help 2] > >>> [ERROR] Non-resolvable import POM: Failure to find > >>> org.jboss.bom.wfk:jboss-javaee-6.0-with-deltaspike:pom:2.6.0-redhat-1 in > >>> http://repo.maven.apache.org/maven2 was cached in the local repository, > >>> resolution will not be reattempted until the update interval of central has > >>> elapsed or updates are forced @ line 99, column 25 -> [Help 2] > >>> [ERROR] Non-resolvable import POM: Failure to find > >>> org.jboss.bom.eap:jboss-javaee-6.0-with-hibernate:pom:6.2.2.GA in > >>> http://repo.maven.apache.org/maven2 was cached in the local repository, > >>> resolution will not be reattempted until the update interval of central has > >>> elapsed or updates are forced @ line 107, column 25 -> [Help 2] > >>> [ERROR] Non-resolvable import POM: Failure to find > >>> org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.2.GA in > >>> http://repo.maven.apache.org/maven2 was cached in the local repository, > >>> resolution will not be reattempted until the update interval of central has > >>> elapsed or updates are forced @ line 115, column 25 -> [Help 2] > >>> [ERROR] Non-resolvable import POM: Failure to find > >>> org.jboss.bom.eap:jboss-javaee-6.0-with-security:pom:6.2.2.GA in > >>> http://repo.maven.apache.org/maven2 was cached in the local repository, > >>> resolution will not be reattempted until the update interval of central has > >>> elapsed or updates are forced @ line 122, column 25 -> [Help 2] > >>> [ERROR] 'dependencies.dependency.version' for > >>> javax.enterprise:cdi-api:jar is missing. @ line 167, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> javax.inject:javax.inject:jar is missing. @ line 172, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.spec.javax.annotation:jboss-annotations-api_1.1_spec:jar is > >>> missing. @ line 179, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.spec.javax.ws.rs:jboss-jaxrs-api_1.1_spec:jar is missing. @ > >>> line 186, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar is missing. @ > >>> line 193, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.spec.javax.ejb:jboss-ejb-api_3.1_spec:jar is missing. @ line 200, > >>> column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ > >>> line 207, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> javax.validation:validation-api:jar is missing. @ line 214, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.hibernate:hibernate-validator:jar is missing. @ line 223, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.resteasy:resteasy-jackson-provider:jar is missing. @ line 235, > >>> column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.apache.deltaspike.core:deltaspike-core-api:jar is missing. @ line 283, > >>> column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.apache.deltaspike.core:deltaspike-core-impl:jar is missing. @ line 291, > >>> column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.apache.deltaspike.modules:deltaspike-security-module-api:jar is > >>> missing. @ line 300, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.apache.deltaspike.modules:deltaspike-security-module-impl:jar is > >>> missing. @ line 308, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.hibernate:hibernate-jpamodelgen:jar is missing. @ line 317, column 21 > >>> [ERROR] 'dependencies.dependency.version' for junit:junit:jar is > >>> missing. @ line 324, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.arquillian.junit:arquillian-junit-container:jar is missing. @ > >>> line 336, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.arquillian.protocol:arquillian-protocol-servlet:jar is missing. @ > >>> line 342, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.arquillian.container:arquillian-container-test-api:jar is > >>> missing. @ line 348, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.arquillian.junit:arquillian-junit-core:jar is missing. @ line > >>> 354, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.shrinkwrap:shrinkwrap-api:jar is missing. @ line 360, column 21 > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:jar is missing. > >>> @ line 366, column 21 > >>> [ERROR] > >>> [ERROR] The project > >>> org.jboss.quickstarts.wfk:jboss-contacts-mobile-proxy:1.0.0.Beta2-SNAPSHOT > >>> (/Users/matzew/TEMP/QUICKI/aerogear-push-quickstarts/server/contacts-mobile-proxy/pom.xml) > >>> has 4 errors > >>> [ERROR] Non-resolvable import POM: Failure to find > >>> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-11 in > >>> http://repo.maven.apache.org/maven2 was cached in the local repository, > >>> resolution will not be reattempted until the update interval of central has > >>> elapsed or updates are forced @ > >>> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], > >>> /Users/matzew/.m2/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.6.0-redhat-1/jboss-javaee-6.0-with-tools-2.6.0-redhat-1.pom, > >>> line 42, column 25 -> [Help 2] > >>> [ERROR] Non-resolvable import POM: Could not find artifact > >>> org.jboss.bom.eap:jboss-javaee-6.0-with-resteasy:pom:6.2.0.GA in > >>> central (http://repo.maven.apache.org/maven2) @ line 79, column 25 -> > >>> [Help 2] > >>> [ERROR] 'dependencies.dependency.version' for > >>> org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec:jar is missing. @ > >>> line 92, column 21 > >>> [ERROR] 'dependencies.dependency.version' for junit:junit:jar is > >>> missing. @ line 117, column 21 > >>> [ERROR] > >>> [ERROR] To see the full stack trace of the errors, re-run Maven with the > >>> -e switch. > >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. > >>> [ERROR] > >>> [ERROR] For more information about the errors and possible solutions, > >>> please read the following articles: > >>> [ERROR] [Help 1] > >>> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException > >>> [ERROR] [Help 2] > >>> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException > >>> > >>> > >>> > >>> > >>> -- > >>> Matthias Wessendorf > >>> > >>> blog: http://matthiaswessendorf.wordpress.com/ > >>> sessions: http://www.slideshare.net/mwessendorf > >>> twitter: http://twitter.com/mwessendorf > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Aug 12 07:11:58 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 12 Aug 2014 08:11:58 -0300 Subject: [aerogear-dev] Push Quickstarts - Maven ? In-Reply-To: References: <64BBB87A-248C-4CA0-95EA-6E29D3EA0D0B@redhat.com> Message-ID: <20140812111158.GC46740@abstractj.org> I would just name it quickstart-settings.xml On 2014-08-12, Daniel Bevenius wrote: > This is just a left over from the wfk quickstart and I agree that it's > confusion. I guess we have to have one to be able to try things out with > early releases but one should be enough. > > > > > On 12 August 2014 10:07, Erik Jan de Wit wrote: > > > > One question: Should be use --setting settings.xml? Or > > contributor-settings.xml ? > > > > It?s contributor-settings.xml, but we should change that name / only have > > one to make that more simple. It confused me so? > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Aug 12 07:14:32 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 12 Aug 2014 08:14:32 -0300 Subject: [aerogear-dev] cordova push plugin release In-Reply-To: References: Message-ID: <20140812111432.GD46740@abstractj.org> Looks good, I want to test it Erik. Thanks for the heads up. On 2014-08-12, Erik Jan de Wit wrote: > Hi, > > We are going to release a new version of the cordova push plugin the new version 0.7.0 most important features are the ?content-availble? support for iOS and the iOS 8 support here the release notes: > Bug > [AGCORDOVA-22] - android binaries installed for other platforms > Feature Request > [AGCORDOVA-23] - Support content title with gcm notifications on android > [AGCORDOVA-25] - iOS8 support for push registration > > I?ve created a branch 0.7.0-release [1] for your testing pleasure. If we don?t find issues we?ll perform the actual release on friday. > > [1] https://github.com/aerogear/aerogear-pushplugin-cordova/tree/0.7.0-release > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From kpiwko at redhat.com Tue Aug 12 07:28:06 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 12 Aug 2014 11:30:06 +0002 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta2 In-Reply-To: References: Message-ID: <1407842886.20738.1@smtp.corp.redhat.com> I'm for restaging. Fix is already available and I guess there will be more folks trying with WF 8.1 then WF 8.0 - see http://wildfly.org/downloads/ . Not supporting a latest version of one of 3 containers we would like to support is not suitable even for Beta release in my opinion. Verification results are not lost, just diff comparison can be done for restaged release. Karel On Tue, Aug 12, 2014 at 12:45 PM, Matthias Wessendorf wrote: > We have a bug that only is present on WF 8.1 > > Works fine on: > * WF 8.0 > * JBoss AS7.1.1 > * EAP 6.3 > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/351 > > What do folks think? Should we include this into the BETA2, and > replace the staged bits ? > > > > > > > > > > On Fri, Aug 8, 2014 at 2:52 PM, Matthias Wessendorf > wrote: >> Hello folks! >> >> we are getting closer and closer to our 1.0.0 release! Thank you >> very much, guys! >> >> However, before we are moving towards the 1.0.0.Final community >> release, I'd love to get the current work out as 1.0.0.Beta2 >> >> Note this release contains a ton of work and new features. To name >> a few highlights: >> >> * Keycloak beta-4 usage >> * Wildfly support >> * new documentation guide on UPS >> * various improvements on the server and its UI! >> >> The did an outstanding job to get the Beta2 done. Details on all the >> JIRAs can be found here: >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092 >> >> The staging repository is located here: >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3670/ >> >> >> NOTE: Once this release has been approved the matching tag will be >> used to get the OpenShift online bits updated! >> >> Let me know the results of your testing! >> If I hear nothing bad by Tuesday evening, the release to maven >> central will happen on Wednesday morning; >> >> Greetings, >> Matthias >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf From kpiwko at redhat.com Tue Aug 12 07:53:25 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 12 Aug 2014 11:55:25 +0002 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <53E92A55.2080102@redhat.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> <53E8D47A.3040006@redhat.com> <53E92A55.2080102@redhat.com> Message-ID: <1407844405.20738.3@smtp.corp.redhat.com> Summers, you need to alter KC configuration - replace keycloak.json with https://gist.github.com/TadeasKriz/635c45adb2ad5f885e88 . I seriously consider this a major regression - https://issues.jboss.org/browse/AGPUSH-872 HTH, Karel On Mon, Aug 11, 2014 at 10:40 PM, Summers Pittman wrote: > Hey, since we've moved to KC for auth, do the restful login bits > still work? > > Here's what I've got so far : > https://gist.github.com/secondsun/9a2bd78fe94bf4031a8a > > I can rewrite the Android guide section on setting up a variant to > use the UI if we aren't using the restful end points. If we are I > can update them with the correct commands and such. > > On 8/11/2014 10:34 AM, Summers Pittman wrote: >> On 8/11/2014 9:26 AM, Burr Sutter wrote: >>> >>> On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf >>> wrote: >>> >>>> >>>> >>>> >>>> On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius >>>> wrote: >>>>> Tested aerogear-push-hellworld/cordova and found this issue: >>>>> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >>>>> >>>>> Other than that I was able to run both the Android and iOS >>>>> applications and receive push notifications. >>>>> >>>>> I did not have ant installed which generated an error which was >>>>> pretty clear, but perhaps we should add something about this >>>>> requirement unless it is mentioned elsewhere. >>>> >>>> oh, right - I think it does not hurt to have 'Ant' in the >>>> requirements section (install is also easy :-) -> brew install ant >>>> ) >>> Cordova and Android will mostly be developed on Windows machines. >>> >>> I assue the non-command-line user will be fine just using JBDS - >>> many Windows-based developers never see a command line (DOS prompt). >>> >>> And for those Windows-based devs who are comfortable with an >>> command line - we can specify what version of Ant they should have >>> in their PATH and they should know what the PATH is. >> I'll make the runs on windows and see how things go. >>> >>>> >>>>> >>>>> >>>>> >>>>> On 11 August 2014 12:24, Daniel Bevenius >>>>> wrote: >>>>>> Tested aerogear-push/helloworld/andorid and was able to follow >>>>>> the docs to setup everything and try out the application and >>>>>> receiving notifications by using Genymotion (thanks to Erik and >>>>>> Passos for helping me set that up). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11 August 2014 09:31, Daniel Bevenius >>>>>> wrote: >>>>>>> Tested aerogear-push-helloworld/ios and found the following >>>>>>> minor issues: >>>>>>> * https://issues.jboss.org/browse/AGPUSH-925 "iOS helloworld >>>>>>> example contains out dated information regarding sending push >>>>>>> messages." >>>>>>> * https://github.com/aerogear/aerogear.org/pull/350 "Minor >>>>>>> spelling corrections/suggestions" >>>>>>> Other than those I was able to follow the docs from scratch and >>>>>>> run the app and successfully received push notifications. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 10 August 2014 13:48, Matthias Wessendorf >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf >>>>>>>> wrote: >>>>>>>>> Hi team, >>>>>>>>> >>>>>>>>> now that we have votes for the UPS and the java-sender (see >>>>>>>>> [1] and [2]), I'd like to start testing the release bundle. >>>>>>>>> >>>>>>>>> As mentioned on IRC, the nominees for the testing, are: >>>>>>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>>>>>>> >>>>>>>>> Besides testing the UPS and sender staging repos, please test >>>>>>>>> our quickstarts as well: >>>>>>>>> 1) >>>>>>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest >>>>>>>>> (1.0.0.Beta2 tag) >>>>>>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>>> >>>>>>>>> Regarding 2), please use the master branch, for now. There >>>>>>>>> will be a .Beta2 tag as well, once the open PRs are merged >>>>>>>>> (and reviewed) >>>>>>>> >>>>>>>> Most of the PRs have been merged and reviewed. Those that are >>>>>>>> open require some additional work and it's perfectly fine to >>>>>>>> get them in for 1.0.0.Final. >>>>>>>> Therefore here is the Beta2 release/tag >>>>>>>> >>>>>>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>>>>>>> >>>>>>>>> >>>>>>>>> Last but not least, please 'test' (review) the documentation >>>>>>>>> as well, like our guide on the UnifiedPush Server: >>>>>>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>>>>>>> >>>>>>>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>>>>>>> http://staging.aerogear.org/docs/unifiedpush >>>>>>>>> >>>>>>>>> >>>>>>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and >>>>>>>>> shortly after that we can go to CODE_FREEZE for the >>>>>>>>> 1.0.0.Final >>>>>>>>> >>>>>>>>> Any thoughts ? >>>>>>>>> >>>>>>>>> -Matthias >>>>>>>>> >>>>>>>>> PS: besides the nominated folks, others are welcome to test >>>>>>>>> the things as well :) >>>>>>>>> >>>>>>>>> >>>>>>>>> -Matthias >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>>>>>>> [2] >>>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matthias Wessendorf >>>>>>>>> >>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matthias Wessendorf >>>>>>>> >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > From bruno at abstractj.org Tue Aug 12 07:58:29 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 12 Aug 2014 08:58:29 -0300 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <1407844405.20738.3@smtp.corp.redhat.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> <53E8D47A.3040006@redhat.com> <53E92A55.2080102@redhat.com> <1407844405.20738.3@smtp.corp.redhat.com> Message-ID: <20140812115829.GE46740@abstractj.org> I hope to get it fixed on 1.0.0, after get some tasks done before. On 2014-08-12, Karel Piwko wrote: > Summers, > > you need to alter KC configuration - replace keycloak.json with > https://gist.github.com/TadeasKriz/635c45adb2ad5f885e88 . I seriously > consider this a major regression - > https://issues.jboss.org/browse/AGPUSH-872 > > HTH, > > Karel > > > On Mon, Aug 11, 2014 at 10:40 PM, Summers Pittman > wrote: > > Hey, since we've moved to KC for auth, do the restful login bits > > still work? > > > > Here's what I've got so far : > > https://gist.github.com/secondsun/9a2bd78fe94bf4031a8a > > > > I can rewrite the Android guide section on setting up a variant to > > use the UI if we aren't using the restful end points. If we are I > > can update them with the correct commands and such. > > > > On 8/11/2014 10:34 AM, Summers Pittman wrote: > >> On 8/11/2014 9:26 AM, Burr Sutter wrote: > >>> > >>> On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf > >>> wrote: > >>> > >>>> > >>>> > >>>> > >>>> On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius > >>>> wrote: > >>>>> Tested aerogear-push-hellworld/cordova and found this issue: > >>>>> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 > >>>>> > >>>>> Other than that I was able to run both the Android and iOS > >>>>> applications and receive push notifications. > >>>>> > >>>>> I did not have ant installed which generated an error which was > >>>>> pretty clear, but perhaps we should add something about this > >>>>> requirement unless it is mentioned elsewhere. > >>>> > >>>> oh, right - I think it does not hurt to have 'Ant' in the > >>>> requirements section (install is also easy :-) -> brew install ant > >>>> ) > >>> Cordova and Android will mostly be developed on Windows machines. > >>> > >>> I assue the non-command-line user will be fine just using JBDS - > >>> many Windows-based developers never see a command line (DOS prompt). > >>> > >>> And for those Windows-based devs who are comfortable with an > >>> command line - we can specify what version of Ant they should have > >>> in their PATH and they should know what the PATH is. > >> I'll make the runs on windows and see how things go. > >>> > >>>> > >>>>> > >>>>> > >>>>> > >>>>> On 11 August 2014 12:24, Daniel Bevenius > >>>>> wrote: > >>>>>> Tested aerogear-push/helloworld/andorid and was able to follow > >>>>>> the docs to setup everything and try out the application and > >>>>>> receiving notifications by using Genymotion (thanks to Erik and > >>>>>> Passos for helping me set that up). > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 11 August 2014 09:31, Daniel Bevenius > >>>>>> wrote: > >>>>>>> Tested aerogear-push-helloworld/ios and found the following > >>>>>>> minor issues: > >>>>>>> * https://issues.jboss.org/browse/AGPUSH-925 "iOS helloworld > >>>>>>> example contains out dated information regarding sending push > >>>>>>> messages." > >>>>>>> * https://github.com/aerogear/aerogear.org/pull/350 "Minor > >>>>>>> spelling corrections/suggestions" > >>>>>>> Other than those I was able to follow the docs from scratch and > >>>>>>> run the app and successfully received push notifications. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 10 August 2014 13:48, Matthias Wessendorf > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf > >>>>>>>> wrote: > >>>>>>>>> Hi team, > >>>>>>>>> > >>>>>>>>> now that we have votes for the UPS and the java-sender (see > >>>>>>>>> [1] and [2]), I'd like to start testing the release bundle. > >>>>>>>>> > >>>>>>>>> As mentioned on IRC, the nominees for the testing, are: > >>>>>>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj > >>>>>>>>> > >>>>>>>>> Besides testing the UPS and sender staging repos, please test > >>>>>>>>> our quickstarts as well: > >>>>>>>>> 1) > >>>>>>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest > >>>>>>>>> (1.0.0.Beta2 tag) > >>>>>>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts > >>>>>>>>> > >>>>>>>>> Regarding 2), please use the master branch, for now. There > >>>>>>>>> will be a .Beta2 tag as well, once the open PRs are merged > >>>>>>>>> (and reviewed) > >>>>>>>> > >>>>>>>> Most of the PRs have been merged and reviewed. Those that are > >>>>>>>> open require some additional work and it's perfectly fine to > >>>>>>>> get them in for 1.0.0.Final. > >>>>>>>> Therefore here is the Beta2 release/tag > >>>>>>>> > >>>>>>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Last but not least, please 'test' (review) the documentation > >>>>>>>>> as well, like our guide on the UnifiedPush Server: > >>>>>>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > >>>>>>>>> > >>>>>>>>> BTW. there is more doc on the new 'UPS doc center' :-) > >>>>>>>>> http://staging.aerogear.org/docs/unifiedpush > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and > >>>>>>>>> shortly after that we can go to CODE_FREEZE for the > >>>>>>>>> 1.0.0.Final > >>>>>>>>> > >>>>>>>>> Any thoughts ? > >>>>>>>>> > >>>>>>>>> -Matthias > >>>>>>>>> > >>>>>>>>> PS: besides the nominated folks, others are welcome to test > >>>>>>>>> the things as well :) > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -Matthias > >>>>>>>>> > >>>>>>>>> [1] > >>>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html > >>>>>>>>> [2] > >>>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> Matthias Wessendorf > >>>>>>>>> > >>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>>>>>>> sessions: http://www.slideshare.net/mwessendorf > >>>>>>>>> twitter: http://twitter.com/mwessendorf > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Matthias Wessendorf > >>>>>>>> > >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>>>>>> sessions: http://www.slideshare.net/mwessendorf > >>>>>>>> twitter: http://twitter.com/mwessendorf > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> aerogear-dev mailing list > >>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>>> > >>>> > >>>> -- > >>>> Matthias Wessendorf > >>>> > >>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>> sessions: http://www.slideshare.net/mwessendorf > >>>> twitter: http://twitter.com/mwessendorf > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Tue Aug 12 08:38:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 12 Aug 2014 14:38:55 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta2 In-Reply-To: <1407842886.20738.1@smtp.corp.redhat.com> References: <1407842886.20738.1@smtp.corp.redhat.com> Message-ID: I have re-staged the Beta2 https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3682/ On Tue, Aug 12, 2014 at 1:28 PM, Karel Piwko wrote: > I'm for restaging. Fix is already available and I guess there will be > more folks trying with WF 8.1 then WF 8.0 - see > http://wildfly.org/downloads/ . > > Not supporting a latest version of one of 3 containers we would like to > support is not suitable even for Beta release in my opinion. > Verification results are not lost, just diff comparison can be done for > restaged release. > > Karel > > On Tue, Aug 12, 2014 at 12:45 PM, Matthias Wessendorf > wrote: > > We have a bug that only is present on WF 8.1 > > > > Works fine on: > > * WF 8.0 > > * JBoss AS7.1.1 > > * EAP 6.3 > > > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/351 > > > > What do folks think? Should we include this into the BETA2, and > > replace the staged bits ? > > > > > > > > > > > > > > > > > > > > On Fri, Aug 8, 2014 at 2:52 PM, Matthias Wessendorf > > wrote: > >> Hello folks! > >> > >> we are getting closer and closer to our 1.0.0 release! Thank you > >> very much, guys! > >> > >> However, before we are moving towards the 1.0.0.Final community > >> release, I'd love to get the current work out as 1.0.0.Beta2 > >> > >> Note this release contains a ton of work and new features. To name > >> a few highlights: > >> > >> * Keycloak beta-4 usage > >> * Wildfly support > >> * new documentation guide on UPS > >> * various improvements on the server and its UI! > >> > >> The did an outstanding job to get the Beta2 done. Details on all the > >> JIRAs can be found here: > >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12325092 > >> > >> The staging repository is located here: > >> > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3670/ > >> > >> > >> NOTE: Once this release has been approved the matching tag will be > >> used to get the OpenShift online bits updated! > >> > >> Let me know the results of your testing! > >> If I hear nothing bad by Tuesday evening, the release to maven > >> central will happen on Wednesday morning; > >> > >> Greetings, > >> Matthias > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/c7cb85a4/attachment-0001.html From supittma at redhat.com Tue Aug 12 09:44:53 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 12 Aug 2014 09:44:53 -0400 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> Message-ID: <53EA1A55.5010804@redhat.com> Barring some bitrot on the docs, UPS on EAP works in Windows 8. I even know how to replace the Unix curl commands with native Windows commands. (On Windows 8 with Powershell 4) On 8/11/2014 9:26 AM, Burr Sutter wrote: > > On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf > wrote: > >> >> >> >> On Mon, Aug 11, 2014 at 1:42 PM, Daniel >> Bevenius> >wrote: >> >> Tested aerogear-push-hellworld/cordova and found this issue: >> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >> >> Other than that I was able to run both the Android and iOS >> applications and receive push notifications. >> >> I did not have ant installed which generated an error which was >> pretty clear, but perhaps we should add something about this >> requirement unless it is mentioned elsewhere. >> >> >> oh, right - I think it does not hurt to have 'Ant' in the >> requirements section (install is also easy :-) -> brew install ant ) > Cordova and Android will mostly be developed on Windows machines. > > I assue the non-command-line user will be fine just using JBDS - many > Windows-based developers never see a command line (DOS prompt). > > And for those Windows-based devs who are comfortable with an command > line - we can specify what version of Ant they should have in their > PATH and they should know what the PATH is. > >> >> >> >> On 11 August 2014 12:24, Daniel >> Bevenius> >wrote: >> >> Tested aerogear-push/helloworld/andorid and was able to >> follow the docs to setup everything and try out the >> application and receiving notifications by using Genymotion >> (thanks to Erik and Passos for helping me set that up). >> >> >> >> >> >> On 11 August 2014 09:31, Daniel >> Bevenius> >wrote: >> >> Tested aerogear-push-helloworld/ios and found the >> following minor issues: >> * _https://issues.jboss.org/browse/AGPUSH-925_ "iOS >> helloworld example contains out dated information >> regarding sending push messages." >> * >> _https://github.com/aerogear/aerogear.org/pull/350_ "Minor spelling >> corrections/suggestions" >> Other than those I was able to follow the docs from >> scratch and run the app and successfully received push >> notifications. >> >> >> >> >> On 10 August 2014 13:48, Matthias >> Wessendorf> >wrote: >> >> >> >> >> On Fri, Aug 8, 2014 at 3:11 PM, Matthias >> Wessendorf> >wrote: >> >> Hi team, >> >> now that we have votes for the UPS and the >> java-sender (see [1] and [2]), I'd like to start >> testing the release bundle. >> >> As mentioned on IRC, the nominees for the >> testing, are: >> * sblanc, cvasilak, dbevenius, lholmquist, lfryc >> and abstractj >> >> Besides testing the UPS and sender staging repos, >> please test our quickstarts as well: >> 1)https://github.com/aerogear/aerogear-push-helloworld/releases/latest(1.0.0.Beta2 >> tag) >> 2)https://github.com/aerogear/aerogear-push-quickstarts >> >> >> Regarding 2), please use the master branch, for >> now. There will be a .Beta2 tag as well, once the >> open PRs are merged (and reviewed) >> >> >> Most of the PRs have been merged and reviewed. Those >> that are open require some additional work and it's >> perfectly fine to get them in for 1.0.0.Final. >> Therefore here is the Beta2 release/tag >> >> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >> >> >> Last but not least, please 'test' (review) the >> documentation as well, like our guide on the >> UnifiedPush Server: >> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >> >> BTW. there is more doc on the new 'UPS doc >> center' :-) >> http://staging.aerogear.org/docs/unifiedpush >> >> >> Hopefully, by Wednesday we have an awesome >> 1.0.0.Beta2 and shortly after that we can go to >> CODE_FREEZE for the 1.0.0.Final >> >> Any thoughts ? >> >> -Matthias >> >> PS: besides the nominated folks, others are >> welcome to test the things as well :) >> >> >> -Matthias >> >> [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >> [2]http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >> >> >> -- >> Matthias Wessendorf >> >> blog:http://matthiaswessendorf.wordpress.com/ >> sessions:http://www.slideshare.net/mwessendorf >> twitter:http://twitter.com/mwessendorf >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog:http://matthiaswessendorf.wordpress.com/ >> sessions:http://www.slideshare.net/mwessendorf >> twitter:http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog:http://matthiaswessendorf.wordpress.com/ >> sessions:http://www.slideshare.net/mwessendorf >> twitter:http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140812/5bb9c26a/attachment-0001.html From vivek.pandey at pinelabs.com Wed Aug 13 08:09:29 2014 From: vivek.pandey at pinelabs.com (Vivek Pandey) Date: Wed, 13 Aug 2014 17:39:29 +0530 Subject: [aerogear-dev] SQLGrammerException using unifiedpush-server-1.0.0.Beta1/JBoss 7.1.1/Postgres Message-ID: <003501cfb6ef$6f5b5810$4e120830$@pinelabs.com> Hello Guys, I see following error in logs when I try to create a variant Caused by: org.postgresql.util.PSQLException: ERROR: column "variant1_.type" must appear in the GROUP BY clause or be used in an aggregate function Position: 8 at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorI mpl.java:2161) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.ja va:1890) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.j ava:560) I am using JAVA: C:\jdk1.7.0_45 UPS: unifiedpush-server-1.0.0.Beta1 Postgres: 9.3 Postgres driver: postgresql-9.3-1100-jdbc4.jar Please find the log files attached This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/3c0aa9bc/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: server.log Type: application/octet-stream Size: 228839 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/3c0aa9bc/attachment-0001.obj From matzew at apache.org Wed Aug 13 08:16:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 13 Aug 2014 14:16:24 +0200 Subject: [aerogear-dev] SQLGrammerException using unifiedpush-server-1.0.0.Beta1/JBoss 7.1.1/Postgres In-Reply-To: <003501cfb6ef$6f5b5810$4e120830$@pinelabs.com> References: <003501cfb6ef$6f5b5810$4e120830$@pinelabs.com> Message-ID: Hi Vivek, thanks for reporting. I noticed the same bug a few days ago and this has has been fixed in the upcoming BETA2 https://issues.jboss.org/browse/AGPUSH-879 Greetings, Matthias On Wed, Aug 13, 2014 at 2:09 PM, Vivek Pandey wrote: > Hello Guys, > > > > I see following error in logs when I try to create a variant > > > > Caused by: org.postgresql.util.PSQLException: ERROR: column > "variant1_.type" must appear in the GROUP BY clause or be used in an > aggregate function > > Position: 8 > > at > org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2161) > > at > org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1890) > > at > org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) > > at > org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:560) > > > > > > I am using > > JAVA: C:\jdk1.7.0_45 > > UPS: unifiedpush-server-1.0.0.Beta1 > > Postgres: 9.3 > > Postgres driver: postgresql-9.3-1100-jdbc4.jar > > > > Please find the log files attached > > > > ------------------------------ > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/4767ca9e/attachment.html From vivek.pandey at pinelabs.com Wed Aug 13 08:32:27 2014 From: vivek.pandey at pinelabs.com (Vivek Pandey) Date: Wed, 13 Aug 2014 18:02:27 +0530 Subject: [aerogear-dev] SQLGrammerException using unifiedpush-server-1.0.0.Beta1/JBoss 7.1.1/Postgres In-Reply-To: References: <003501cfb6ef$6f5b5810$4e120830$@pinelabs.com> Message-ID: <004401cfb6f2$a5139aa0$ef3acfe0$@pinelabs.com> Thanks Matthias, I upgraded to Beta2 and that problem went away. I was able to create a variant (android). However, when I try to open the applications, I see following error ing.internal.CollectionLoadContext at cb54fdf 17:59:38,112 WARN [org.hibernate.engine.loading.internal.CollectionLoadContext] (http--127.0.0.1-10000-2) HHH000160: On CollectionLoadContext#cleanup, localLoadingColl ectionKeys contained [1] entries 17:59:38,113 ERROR [org.jboss.ejb3.invocation] (http--127.0.0.1-10000-2) JBAS014134: EJB Invocation failed on component PushApplicationEndpoint for method public javax. ws.rs.core.Response org.jboss.aerogear.unifiedpush.rest.registry.applications.PushApplicationEndpoint.listAllPushApplications(javax.servlet.http.HttpServletRequest): ja vax.ejb.EJBException: java.lang.IllegalArgumentException: Unknown name value for enum class org.jboss.aerogear.unifiedpush.api.VariantType: 0 at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7. 1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] From: mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, August 13, 2014 5:46 PM To: vivek.pandey at pinelabs.com; AeroGear Developer Mailing List Subject: Re: [aerogear-dev] SQLGrammerException using unifiedpush-server-1.0.0.Beta1/JBoss 7.1.1/Postgres Hi Vivek, thanks for reporting. I noticed the same bug a few days ago and this has has been fixed in the upcoming BETA2 https://issues.jboss.org/browse/AGPUSH-879 Greetings, Matthias On Wed, Aug 13, 2014 at 2:09 PM, Vivek Pandey wrote: Hello Guys, I see following error in logs when I try to create a variant Caused by: org.postgresql.util.PSQLException: ERROR: column "variant1_.type" must appear in the GROUP BY clause or be used in an aggregate function Position: 8 at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2161) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1890) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:560) I am using JAVA: C:\jdk1.7.0_45 UPS: unifiedpush-server-1.0.0.Beta1 Postgres: 9.3 Postgres driver: postgresql-9.3-1100-jdbc4.jar Please find the log files attached _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/96015a26/attachment-0001.html From vivek.pandey at pinelabs.com Wed Aug 13 08:52:36 2014 From: vivek.pandey at pinelabs.com (Vivek Pandey) Date: Wed, 13 Aug 2014 18:22:36 +0530 Subject: [aerogear-dev] SQLGrammerException using unifiedpush-server-1.0.0.Beta1/JBoss 7.1.1/Postgres In-Reply-To: <004401cfb6f2$a5139aa0$ef3acfe0$@pinelabs.com> References: <003501cfb6ef$6f5b5810$4e120830$@pinelabs.com> <004401cfb6f2$a5139aa0$ef3acfe0$@pinelabs.com> Message-ID: <005501cfb6f5$75ad2d00$61078700$@pinelabs.com> Works with a fresh database? Thanks Matthias From: aerogear-dev-bounces at lists.jboss.org [mailto:aerogear-dev-bounces at lists.jboss.org] On Behalf Of Vivek Pandey Sent: Wednesday, August 13, 2014 6:02 PM To: 'Matthias Wessendorf'; 'AeroGear Developer Mailing List' Subject: Re: [aerogear-dev] SQLGrammerException using unifiedpush-server-1.0.0.Beta1/JBoss 7.1.1/Postgres Thanks Matthias, I upgraded to Beta2 and that problem went away. I was able to create a variant (android). However, when I try to open the applications, I see following error ing.internal.CollectionLoadContext at cb54fdf 17:59:38,112 WARN [org.hibernate.engine.loading.internal.CollectionLoadContext] (http--127.0.0.1-10000-2) HHH000160: On CollectionLoadContext#cleanup, localLoadingColl ectionKeys contained [1] entries 17:59:38,113 ERROR [org.jboss.ejb3.invocation] (http--127.0.0.1-10000-2) JBAS014134: EJB Invocation failed on component PushApplicationEndpoint for method public javax. ws.rs.core.Response org.jboss.aerogear.unifiedpush.rest.registry.applications.PushApplicationEndpoint.listAllPushApplications(javax.servlet.http.HttpServletRequest): ja vax.ejb.EJBException: java.lang.IllegalArgumentException: Unknown name value for enum class org.jboss.aerogear.unifiedpush.api.VariantType: 0 at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:166) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:304) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:190) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7. 1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.1.1.Final.jar:7.1.1.Final] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] From: mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, August 13, 2014 5:46 PM To: vivek.pandey at pinelabs.com; AeroGear Developer Mailing List Subject: Re: [aerogear-dev] SQLGrammerException using unifiedpush-server-1.0.0.Beta1/JBoss 7.1.1/Postgres Hi Vivek, thanks for reporting. I noticed the same bug a few days ago and this has has been fixed in the upcoming BETA2 https://issues.jboss.org/browse/AGPUSH-879 Greetings, Matthias On Wed, Aug 13, 2014 at 2:09 PM, Vivek Pandey wrote: Hello Guys, I see following error in logs when I try to create a variant Caused by: org.postgresql.util.PSQLException: ERROR: column "variant1_.type" must appear in the GROUP BY clause or be used in an aggregate function Position: 8 at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2161) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1890) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:560) I am using JAVA: C:\jdk1.7.0_45 UPS: unifiedpush-server-1.0.0.Beta1 Postgres: 9.3 Postgres driver: postgresql-9.3-1100-jdbc4.jar Please find the log files attached _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/ccd8b803/attachment.html From matzew at apache.org Wed Aug 13 11:19:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 13 Aug 2014 17:19:49 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <53EA1A55.5010804@redhat.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> <53EA1A55.5010804@redhat.com> Message-ID: Looks like things are going well on this release. Thanks for testing! If nothing dramatic comes up - later 2nite I will click the "magic button", to push the artifacts out to maven central. Note: The work on 1.0.0.Final is already in progress on the master branch. That said, in a few days (likely early next week) things will slow-down for the code-freeze, for the 1.0.0.Final (to be released last week of August). Once the announcement of Beta2 has been sent out, I will get my head around the details -Matthias On Tue, Aug 12, 2014 at 3:44 PM, Summers Pittman wrote: > Barring some bitrot on the docs, > > UPS on EAP works in Windows 8. > > I even know how to replace the Unix curl commands with native Windows > commands. (On Windows 8 with Powershell 4) > > > On 8/11/2014 9:26 AM, Burr Sutter wrote: > > > On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf > wrote: > > > > > On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Tested aerogear-push-hellworld/cordova and found this issue: >> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >> >> Other than that I was able to run both the Android and iOS applications >> and receive push notifications. >> >> I did not have ant installed which generated an error which was pretty >> clear, but perhaps we should add something about this requirement unless it >> is mentioned elsewhere. >> > > oh, right - I think it does not hurt to have 'Ant' in the requirements > section (install is also easy :-) -> brew install ant ) > > Cordova and Android will mostly be developed on Windows machines. > > I assue the non-command-line user will be fine just using JBDS - many > Windows-based developers never see a command line (DOS prompt). > > And for those Windows-based devs who are comfortable with an command > line - we can specify what version of Ant they should have in their PATH > and they should know what the PATH is. > > > >> >> >> >> On 11 August 2014 12:24, Daniel Bevenius >> wrote: >> >>> Tested aerogear-push/helloworld/andorid and was able to follow the docs >>> to setup everything and try out the application and receiving notifications >>> by using Genymotion (thanks to Erik and Passos for helping me set that up). >>> >>> >>> >>> >>> >>> On 11 August 2014 09:31, Daniel Bevenius >>> wrote: >>> >>>> Tested aerogear-push-helloworld/ios and found the following minor >>>> issues: >>>> * *https://issues.jboss.org/browse/AGPUSH-925 >>>> * "iOS helloworld example >>>> contains out dated information regarding sending push messages." >>>> * *https://github.com/aerogear/aerogear.org/pull/350 >>>> * "Minor spelling >>>> corrections/suggestions" >>>> Other than those I was able to follow the docs from scratch and run the >>>> app and successfully received push notifications. >>>> >>>> >>>> >>>> >>>> On 10 August 2014 13:48, Matthias Wessendorf >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> Hi team, >>>>>> >>>>>> now that we have votes for the UPS and the java-sender (see [1] and >>>>>> [2]), I'd like to start testing the release bundle. >>>>>> >>>>>> As mentioned on IRC, the nominees for the testing, are: >>>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>>>> >>>>>> Besides testing the UPS and sender staging repos, please test our >>>>>> quickstarts as well: >>>>>> 1) >>>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 >>>>>> tag) >>>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>>>> >>>>>> Regarding 2), please use the master branch, for now. There will be >>>>>> a .Beta2 tag as well, once the open PRs are merged (and reviewed) >>>>>> >>>>> >>>>> Most of the PRs have been merged and reviewed. Those that are open >>>>> require some additional work and it's perfectly fine to get them in for >>>>> 1.0.0.Final. >>>>> Therefore here is the Beta2 release/tag >>>>> >>>>> >>>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>>>> >>>>> >>>>>> >>>>>> Last but not least, please 'test' (review) the documentation as >>>>>> well, like our guide on the UnifiedPush Server: >>>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>>>> >>>>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>>>> http://staging.aerogear.org/docs/unifiedpush >>>>>> >>>>>> >>>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly >>>>>> after that we can go to CODE_FREEZE for the 1.0.0.Final >>>>>> >>>>>> Any thoughts ? >>>>>> >>>>>> -Matthias >>>>>> >>>>>> PS: besides the nominated folks, others are welcome to test the >>>>>> things as well :) >>>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> [1] >>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>>>> [2] >>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/e1b08019/attachment-0001.html From daniel at passos.me Wed Aug 13 16:17:44 2014 From: daniel at passos.me (Daniel Passos) Date: Wed, 13 Aug 2014 17:17:44 -0300 Subject: [aerogear-dev] cordova push plugin release In-Reply-To: <20140812111432.GD46740@abstractj.org> References: <20140812111432.GD46740@abstractj.org> Message-ID: +1 On Tue, Aug 12, 2014 at 8:14 AM, Bruno Oliveira wrote: > Looks good, I want to test it Erik. > > Thanks for the heads up. > > On 2014-08-12, Erik Jan de Wit wrote: > > Hi, > > > > We are going to release a new version of the cordova push plugin the new > version 0.7.0 most important features are the ?content-availble? support > for iOS and the iOS 8 support here the release notes: > > Bug > > [AGCORDOVA-22] - android binaries installed for other platforms > > Feature Request > > [AGCORDOVA-23] - Support content title with gcm notifications on android > > [AGCORDOVA-25] - iOS8 support for push registration > > > > I?ve created a branch 0.7.0-release [1] for your testing pleasure. If we > don?t find issues we?ll perform the actual release on friday. > > > > [1] > https://github.com/aerogear/aerogear-pushplugin-cordova/tree/0.7.0-release > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/03cf1a4b/attachment.html From bruno at abstractj.org Wed Aug 13 17:36:39 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 13 Aug 2014 14:36:39 -0700 (PDT) Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: Message-ID: <1407965798951.7e15a33c@Nodemailer> Release the kraken, Docker images were updated based on the staging repository? abstractj PGP: 0x84DC9914 On Wed, Aug 13, 2014 at 12:19 PM, Matthias Wessendorf wrote: > Looks like things are going well on this release. Thanks for testing! > If nothing dramatic comes up - later 2nite I will click the "magic button", > to push the artifacts out to maven central. > Note: The work on 1.0.0.Final is already in progress on the master branch. > That said, in a few days (likely early next week) things will slow-down for > the code-freeze, for the 1.0.0.Final (to be released last week of August). > Once the announcement of Beta2 has been sent out, I will get my head around > the details > -Matthias > On Tue, Aug 12, 2014 at 3:44 PM, Summers Pittman > wrote: >> Barring some bitrot on the docs, >> >> UPS on EAP works in Windows 8. >> >> I even know how to replace the Unix curl commands with native Windows >> commands. (On Windows 8 with Powershell 4) >> >> >> On 8/11/2014 9:26 AM, Burr Sutter wrote: >> >> >> On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf >> wrote: >> >> >> >> >> On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Tested aerogear-push-hellworld/cordova and found this issue: >>> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >>> >>> Other than that I was able to run both the Android and iOS applications >>> and receive push notifications. >>> >>> I did not have ant installed which generated an error which was pretty >>> clear, but perhaps we should add something about this requirement unless it >>> is mentioned elsewhere. >>> >> >> oh, right - I think it does not hurt to have 'Ant' in the requirements >> section (install is also easy :-) -> brew install ant ) >> >> Cordova and Android will mostly be developed on Windows machines. >> >> I assue the non-command-line user will be fine just using JBDS - many >> Windows-based developers never see a command line (DOS prompt). >> >> And for those Windows-based devs who are comfortable with an command >> line - we can specify what version of Ant they should have in their PATH >> and they should know what the PATH is. >> >> >> >>> >>> >>> >>> On 11 August 2014 12:24, Daniel Bevenius >>> wrote: >>> >>>> Tested aerogear-push/helloworld/andorid and was able to follow the docs >>>> to setup everything and try out the application and receiving notifications >>>> by using Genymotion (thanks to Erik and Passos for helping me set that up). >>>> >>>> >>>> >>>> >>>> >>>> On 11 August 2014 09:31, Daniel Bevenius >>>> wrote: >>>> >>>>> Tested aerogear-push-helloworld/ios and found the following minor >>>>> issues: >>>>> * *https://issues.jboss.org/browse/AGPUSH-925 >>>>> * "iOS helloworld example >>>>> contains out dated information regarding sending push messages." >>>>> * *https://github.com/aerogear/aerogear.org/pull/350 >>>>> * "Minor spelling >>>>> corrections/suggestions" >>>>> Other than those I was able to follow the docs from scratch and run the >>>>> app and successfully received push notifications. >>>>> >>>>> >>>>> >>>>> >>>>> On 10 August 2014 13:48, Matthias Wessendorf >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Hi team, >>>>>>> >>>>>>> now that we have votes for the UPS and the java-sender (see [1] and >>>>>>> [2]), I'd like to start testing the release bundle. >>>>>>> >>>>>>> As mentioned on IRC, the nominees for the testing, are: >>>>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>>>>> >>>>>>> Besides testing the UPS and sender staging repos, please test our >>>>>>> quickstarts as well: >>>>>>> 1) >>>>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 >>>>>>> tag) >>>>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>>>>> >>>>>>> Regarding 2), please use the master branch, for now. There will be >>>>>>> a .Beta2 tag as well, once the open PRs are merged (and reviewed) >>>>>>> >>>>>> >>>>>> Most of the PRs have been merged and reviewed. Those that are open >>>>>> require some additional work and it's perfectly fine to get them in for >>>>>> 1.0.0.Final. >>>>>> Therefore here is the Beta2 release/tag >>>>>> >>>>>> >>>>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>>>>> >>>>>> >>>>>>> >>>>>>> Last but not least, please 'test' (review) the documentation as >>>>>>> well, like our guide on the UnifiedPush Server: >>>>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>>>>> >>>>>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>>>>> http://staging.aerogear.org/docs/unifiedpush >>>>>>> >>>>>>> >>>>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly >>>>>>> after that we can go to CODE_FREEZE for the 1.0.0.Final >>>>>>> >>>>>>> Any thoughts ? >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> PS: besides the nominated folks, others are welcome to test the >>>>>>> things as well :) >>>>>>> >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> [1] >>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>>>>> [2] >>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > -- > Matthias Wessendorf > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/87e11847/attachment-0001.html From bruno at abstractj.org Wed Aug 13 17:46:33 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 13 Aug 2014 14:46:33 -0700 (PDT) Subject: [aerogear-dev] cordova push plugin release In-Reply-To: References: Message-ID: <1407966393598.a0c9e0fa@Nodemailer> +1 thanks Erik? abstractj PGP: 0x84DC9914 On Wed, Aug 13, 2014 at 5:18 PM, Daniel Passos wrote: > +1 > On Tue, Aug 12, 2014 at 8:14 AM, Bruno Oliveira wrote: >> Looks good, I want to test it Erik. >> >> Thanks for the heads up. >> >> On 2014-08-12, Erik Jan de Wit wrote: >> > Hi, >> > >> > We are going to release a new version of the cordova push plugin the new >> version 0.7.0 most important features are the ?content-availble? support >> for iOS and the iOS 8 support here the release notes: >> > Bug >> > [AGCORDOVA-22] - android binaries installed for other platforms >> > Feature Request >> > [AGCORDOVA-23] - Support content title with gcm notifications on android >> > [AGCORDOVA-25] - iOS8 support for push registration >> > >> > I?ve created a branch 0.7.0-release [1] for your testing pleasure. If we >> don?t find issues we?ll perform the actual release on friday. >> > >> > [1] >> https://github.com/aerogear/aerogear-pushplugin-cordova/tree/0.7.0-release >> >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140813/afdbe3bc/attachment.html From daniel.bevenius at gmail.com Wed Aug 13 23:00:05 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 14 Aug 2014 05:00:05 +0200 Subject: [aerogear-dev] cordova push plugin release In-Reply-To: <1407966393598.a0c9e0fa@Nodemailer> References: <1407966393598.a0c9e0fa@Nodemailer> Message-ID: +1 onsdag 13 augusti 2014 skrev Bruno Oliveira : > +1 thanks Erik > ? > abstractj > PGP: 0x84DC9914 > > > On Wed, Aug 13, 2014 at 5:18 PM, Daniel Passos > wrote: > >> +1 >> >> >> On Tue, Aug 12, 2014 at 8:14 AM, Bruno Oliveira > > wrote: >> >>> Looks good, I want to test it Erik. >>> >>> Thanks for the heads up. >>> >>> On 2014-08-12, Erik Jan de Wit wrote: >>> > Hi, >>> > >>> > We are going to release a new version of the cordova push plugin the >>> new version 0.7.0 most important features are the ?content-availble? >>> support for iOS and the iOS 8 support here the release notes: >>> > Bug >>> > [AGCORDOVA-22] - android binaries installed for other platforms >>> > Feature Request >>> > [AGCORDOVA-23] - Support content title with gcm notifications on >>> android >>> > [AGCORDOVA-25] - iOS8 support for push registration >>> > >>> > I?ve created a branch 0.7.0-release [1] for your testing pleasure. If >>> we don?t find issues we?ll perform the actual release on friday. >>> > >>> > [1] >>> https://github.com/aerogear/aerogear-pushplugin-cordova/tree/0.7.0-release >>> >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140814/1ecbf0a9/attachment.html From cvasilak at gmail.com Thu Aug 14 01:56:04 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 14 Aug 2014 08:56:04 +0300 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> <53EA1A55.5010804@redhat.com> Message-ID: <9ED5B898-C45F-496F-97B7-B8F455CC06F3@gmail.com> +1 go for it! - Christos On Aug 13, 2014, at 6:19 PM, Matthias Wessendorf wrote: > Looks like things are going well on this release. Thanks for testing! > > If nothing dramatic comes up - later 2nite I will click the "magic button", to push the artifacts out to maven central. > > > Note: The work on 1.0.0.Final is already in progress on the master branch. > That said, in a few days (likely early next week) things will slow-down for the code-freeze, for the 1.0.0.Final (to be released last week of August). Once the announcement of Beta2 has been sent out, I will get my head around the details > > -Matthias > > > > On Tue, Aug 12, 2014 at 3:44 PM, Summers Pittman wrote: > Barring some bitrot on the docs, > > UPS on EAP works in Windows 8. > > I even know how to replace the Unix curl commands with native Windows commands. (On Windows 8 with Powershell 4) > > > On 8/11/2014 9:26 AM, Burr Sutter wrote: >> >> On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius wrote: >>> Tested aerogear-push-hellworld/cordova and found this issue: >>> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >>> >>> Other than that I was able to run both the Android and iOS applications and receive push notifications. >>> >>> I did not have ant installed which generated an error which was pretty clear, but perhaps we should add something about this requirement unless it is mentioned elsewhere. >>> >>> oh, right - I think it does not hurt to have 'Ant' in the requirements section (install is also easy :-) -> brew install ant ) >> Cordova and Android will mostly be developed on Windows machines. >> >> I assue the non-command-line user will be fine just using JBDS - many Windows-based developers never see a command line (DOS prompt). >> >> And for those Windows-based devs who are comfortable with an command line - we can specify what version of Ant they should have in their PATH and they should know what the PATH is. >> >>> >>> >>> >>> >>> On 11 August 2014 12:24, Daniel Bevenius wrote: >>> Tested aerogear-push/helloworld/andorid and was able to follow the docs to setup everything and try out the application and receiving notifications by using Genymotion (thanks to Erik and Passos for helping me set that up). >>> >>> >>> >>> >>> >>> On 11 August 2014 09:31, Daniel Bevenius wrote: >>> Tested aerogear-push-helloworld/ios and found the following minor issues: >>> * https://issues.jboss.org/browse/AGPUSH-925 "iOS helloworld example contains out dated information regarding sending push messages." >>> * https://github.com/aerogear/aerogear.org/pull/350 "Minor spelling corrections/suggestions" >>> Other than those I was able to follow the docs from scratch and run the app and successfully received push notifications. >>> >>> >>> >>> >>> On 10 August 2014 13:48, Matthias Wessendorf wrote: >>> >>> >>> >>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf wrote: >>> Hi team, >>> >>> now that we have votes for the UPS and the java-sender (see [1] and [2]), I'd like to start testing the release bundle. >>> >>> As mentioned on IRC, the nominees for the testing, are: >>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>> >>> Besides testing the UPS and sender staging repos, please test our quickstarts as well: >>> 1) https://github.com/aerogear/aerogear-push-helloworld/releases/latest (1.0.0.Beta2 tag) >>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>> >>> Regarding 2), please use the master branch, for now. There will be a .Beta2 tag as well, once the open PRs are merged (and reviewed) >>> >>> Most of the PRs have been merged and reviewed. Those that are open require some additional work and it's perfectly fine to get them in for 1.0.0.Final. >>> Therefore here is the Beta2 release/tag >>> >>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>> >>> >>> Last but not least, please 'test' (review) the documentation as well, like our guide on the UnifiedPush Server: >>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>> >>> BTW. there is more doc on the new 'UPS doc center' :-) >>> http://staging.aerogear.org/docs/unifiedpush >>> >>> >>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly after that we can go to CODE_FREEZE for the 1.0.0.Final >>> >>> Any thoughts ? >>> >>> -Matthias >>> >>> PS: besides the nominated folks, others are welcome to test the things as well :) >>> >>> >>> -Matthias >>> >>> [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>> [2] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140814/21d389de/attachment-0001.html From daniel.bevenius at gmail.com Thu Aug 14 02:18:06 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 14 Aug 2014 08:18:06 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <9ED5B898-C45F-496F-97B7-B8F455CC06F3@gmail.com> References: <0A5026D2-3505-46F4-A26D-1335736B5F09@redhat.com> <53EA1A55.5010804@redhat.com> <9ED5B898-C45F-496F-97B7-B8F455CC06F3@gmail.com> Message-ID: +1 torsdag 14 augusti 2014 skrev Christos Vasilakis : > +1 go for it! > > - > Christos > > > On Aug 13, 2014, at 6:19 PM, Matthias Wessendorf > wrote: > > Looks like things are going well on this release. Thanks for testing! > > If nothing dramatic comes up - later 2nite I will click the "magic > button", to push the artifacts out to maven central. > > > Note: The work on 1.0.0.Final is already in progress on the master branch. > That said, in a few days (likely early next week) things will slow-down > for the code-freeze, for the 1.0.0.Final (to be released last week of > August). Once the announcement of Beta2 has been sent out, I will get my > head around the details > > -Matthias > > > > On Tue, Aug 12, 2014 at 3:44 PM, Summers Pittman > wrote: > >> Barring some bitrot on the docs, >> >> UPS on EAP works in Windows 8. >> >> I even know how to replace the Unix curl commands with native Windows >> commands. (On Windows 8 with Powershell 4) >> >> >> On 8/11/2014 9:26 AM, Burr Sutter wrote: >> >> >> On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf > > wrote: >> >> >> >> >> On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius < >> daniel.bevenius at gmail.com >> > wrote: >> >>> Tested aerogear-push-hellworld/cordova and found this issue: >>> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >>> >>> Other than that I was able to run both the Android and iOS >>> applications and receive push notifications. >>> >>> I did not have ant installed which generated an error which was pretty >>> clear, but perhaps we should add something about this requirement unless it >>> is mentioned elsewhere. >>> >> >> oh, right - I think it does not hurt to have 'Ant' in the requirements >> section (install is also easy :-) -> brew install ant ) >> >> Cordova and Android will mostly be developed on Windows machines. >> >> I assue the non-command-line user will be fine just using JBDS - many >> Windows-based developers never see a command line (DOS prompt). >> >> And for those Windows-based devs who are comfortable with an command >> line - we can specify what version of Ant they should have in their PATH >> and they should know what the PATH is. >> >> >> >>> >>> >>> >>> On 11 August 2014 12:24, Daniel Bevenius >> > wrote: >>> >>>> Tested aerogear-push/helloworld/andorid and was able to follow the docs >>>> to setup everything and try out the application and receiving notifications >>>> by using Genymotion (thanks to Erik and Passos for helping me set that up). >>>> >>>> >>>> >>>> >>>> >>>> On 11 August 2014 09:31, Daniel Bevenius >>> > wrote: >>>> >>>>> Tested aerogear-push-helloworld/ios and found the following minor >>>>> issues: >>>>> * *https://issues.jboss.org/browse/AGPUSH-925 >>>>> * "iOS helloworld example >>>>> contains out dated information regarding sending push messages." >>>>> * *https://github.com/aerogear/aerogear.org/pull/350 >>>>> * "Minor spelling >>>>> corrections/suggestions" >>>>> Other than those I was able to follow the docs from scratch and run >>>>> the app and successfully received push notifications. >>>>> >>>>> >>>>> >>>>> >>>>> On 10 August 2014 13:48, Matthias Wessendorf >>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf < >>>>>> matzew at apache.org >>>>>> > wrote: >>>>>> >>>>>>> Hi team, >>>>>>> >>>>>>> now that we have votes for the UPS and the java-sender (see [1] >>>>>>> and [2]), I'd like to start testing the release bundle. >>>>>>> >>>>>>> As mentioned on IRC, the nominees for the testing, are: >>>>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>>>>> >>>>>>> Besides testing the UPS and sender staging repos, please test our >>>>>>> quickstarts as well: >>>>>>> 1) >>>>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest >>>>>>> (1.0.0.Beta2 tag) >>>>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>>>>> >>>>>>> Regarding 2), please use the master branch, for now. There will be >>>>>>> a .Beta2 tag as well, once the open PRs are merged (and reviewed) >>>>>>> >>>>>> >>>>>> Most of the PRs have been merged and reviewed. Those that are open >>>>>> require some additional work and it's perfectly fine to get them in for >>>>>> 1.0.0.Final. >>>>>> Therefore here is the Beta2 release/tag >>>>>> >>>>>> >>>>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>>>>> >>>>>> >>>>>>> >>>>>>> Last but not least, please 'test' (review) the documentation as >>>>>>> well, like our guide on the UnifiedPush Server: >>>>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>>>>> >>>>>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>>>>> http://staging.aerogear.org/docs/unifiedpush >>>>>>> >>>>>>> >>>>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and >>>>>>> shortly after that we can go to CODE_FREEZE for the 1.0.0.Final >>>>>>> >>>>>>> Any thoughts ? >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> PS: besides the nominated folks, others are welcome to test the >>>>>>> things as well :) >>>>>>> >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> [1] >>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>>>>> [2] >>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing listaerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140814/5bc22414/attachment-0001.html From matzew at apache.org Thu Aug 14 02:43:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 14 Aug 2014 08:43:59 +0200 Subject: [aerogear-dev] Call for arms -> Unified Push 1.0.0.Beta2 release bundle In-Reply-To: <1407965798951.7e15a33c@Nodemailer> References: <1407965798951.7e15a33c@Nodemailer> Message-ID: Will be on maven central tomorrow On Wednesday, August 13, 2014, Bruno Oliveira wrote: > Release the kraken, Docker images were updated based on the staging > repository > ? > abstractj > PGP: 0x84DC9914 > > > On Wed, Aug 13, 2014 at 12:19 PM, Matthias Wessendorf > wrote: > >> Looks like things are going well on this release. Thanks for testing! >> >> If nothing dramatic comes up - later 2nite I will click the "magic >> button", to push the artifacts out to maven central. >> >> >> Note: The work on 1.0.0.Final is already in progress on the master branch. >> That said, in a few days (likely early next week) things will slow-down >> for the code-freeze, for the 1.0.0.Final (to be released last week of >> August). Once the announcement of Beta2 has been sent out, I will get my >> head around the details >> >> -Matthias >> >> >> >> On Tue, Aug 12, 2014 at 3:44 PM, Summers Pittman > > wrote: >> >>> Barring some bitrot on the docs, >>> >>> UPS on EAP works in Windows 8. >>> >>> I even know how to replace the Unix curl commands with native Windows >>> commands. (On Windows 8 with Powershell 4) >>> >>> >>> On 8/11/2014 9:26 AM, Burr Sutter wrote: >>> >>> >>> On Aug 11, 2014, at 7:46 AM, Matthias Wessendorf >> > wrote: >>> >>> >>> >>> >>> On Mon, Aug 11, 2014 at 1:42 PM, Daniel Bevenius < >>> daniel.bevenius at gmail.com >>> > wrote: >>> >>>> Tested aerogear-push-hellworld/cordova and found this issue: >>>> * https://github.com/aerogear/aerogear-push-helloworld/pull/41 >>>> >>>> Other than that I was able to run both the Android and iOS applications >>>> and receive push notifications. >>>> >>>> I did not have ant installed which generated an error which was pretty >>>> clear, but perhaps we should add something about this requirement unless it >>>> is mentioned elsewhere. >>>> >>> >>> oh, right - I think it does not hurt to have 'Ant' in the requirements >>> section (install is also easy :-) -> brew install ant ) >>> >>> Cordova and Android will mostly be developed on Windows machines. >>> >>> I assue the non-command-line user will be fine just using JBDS - many >>> Windows-based developers never see a command line (DOS prompt). >>> >>> And for those Windows-based devs who are comfortable with an command >>> line - we can specify what version of Ant they should have in their PATH >>> and they should know what the PATH is. >>> >>> >>> >>>> >>>> >>>> >>>> On 11 August 2014 12:24, Daniel Bevenius >>> > wrote: >>>> >>>>> Tested aerogear-push/helloworld/andorid and was able to follow the >>>>> docs to setup everything and try out the application and receiving >>>>> notifications by using Genymotion (thanks to Erik and Passos for helping me >>>>> set that up). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 11 August 2014 09:31, Daniel Bevenius >>>> > wrote: >>>>> >>>>>> Tested aerogear-push-helloworld/ios and found the following minor >>>>>> issues: >>>>>> * *https://issues.jboss.org/browse/AGPUSH-925 >>>>>> * "iOS helloworld >>>>>> example contains out dated information regarding sending push messages." >>>>>> * *https://github.com/aerogear/aerogear.org/pull/350 >>>>>> * "Minor spelling >>>>>> corrections/suggestions" >>>>>> Other than those I was able to follow the docs from scratch and run >>>>>> the app and successfully received push notifications. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 10 August 2014 13:48, Matthias Wessendorf >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 8, 2014 at 3:11 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org >>>>>>> > wrote: >>>>>>> >>>>>>>> Hi team, >>>>>>>> >>>>>>>> now that we have votes for the UPS and the java-sender (see [1] and >>>>>>>> [2]), I'd like to start testing the release bundle. >>>>>>>> >>>>>>>> As mentioned on IRC, the nominees for the testing, are: >>>>>>>> * sblanc, cvasilak, dbevenius, lholmquist, lfryc and abstractj >>>>>>>> >>>>>>>> Besides testing the UPS and sender staging repos, please test our >>>>>>>> quickstarts as well: >>>>>>>> 1) >>>>>>>> https://github.com/aerogear/aerogear-push-helloworld/releases/latest >>>>>>>> (1.0.0.Beta2 tag) >>>>>>>> 2) https://github.com/aerogear/aerogear-push-quickstarts >>>>>>>> >>>>>>>> Regarding 2), please use the master branch, for now. There will be >>>>>>>> a .Beta2 tag as well, once the open PRs are merged (and reviewed) >>>>>>>> >>>>>>> >>>>>>> Most of the PRs have been merged and reviewed. Those that are open >>>>>>> require some additional work and it's perfectly fine to get them in for >>>>>>> 1.0.0.Final. >>>>>>> Therefore here is the Beta2 release/tag >>>>>>> >>>>>>> >>>>>>> https://github.com/aerogear/aerogear-push-quickstarts/releases/tag/1.0.0.Beta2 >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Last but not least, please 'test' (review) the documentation as >>>>>>>> well, like our guide on the UnifiedPush Server: >>>>>>>> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >>>>>>>> >>>>>>>> BTW. there is more doc on the new 'UPS doc center' :-) >>>>>>>> http://staging.aerogear.org/docs/unifiedpush >>>>>>>> >>>>>>>> >>>>>>>> Hopefully, by Wednesday we have an awesome 1.0.0.Beta2 and shortly >>>>>>>> after that we can go to CODE_FREEZE for the 1.0.0.Final >>>>>>>> >>>>>>>> Any thoughts ? >>>>>>>> >>>>>>>> -Matthias >>>>>>>> >>>>>>>> PS: besides the nominated folks, others are welcome to test the >>>>>>>> things as well :) >>>>>>>> >>>>>>>> >>>>>>>> -Matthias >>>>>>>> >>>>>>>> [1] >>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008710.html >>>>>>>> [2] >>>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008706.html >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matthias Wessendorf >>>>>>>> >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing listaerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140814/f4be750a/attachment-0001.html From bruno at abstractj.org Thu Aug 14 07:09:00 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 14 Aug 2014 08:09:00 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts Message-ID: <20140814110900.GA32805@abstractj.org> Good morning everyone, I need your feedback. I just build the initial version of docker images for quickstarts. - AS7: https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev - Wildfly: https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev Would be very appreciated if tell me what's missing. -- abstractj PGP: 0x84DC9914 From matzew at apache.org Thu Aug 14 07:16:59 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 14 Aug 2014 13:16:59 +0200 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: <20140814110900.GA32805@abstractj.org> References: <20140814110900.GA32805@abstractj.org> Message-ID: Awesome! Great work, Bruno! On Thursday, August 14, 2014, Bruno Oliveira wrote: > Good morning everyone, I need your feedback. I just build the initial > version of docker images for quickstarts. > > - AS7: > > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > - Wildfly: > > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > > Would be very appreciated if tell me what's missing. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140814/06633481/attachment.html From daniel at passos.me Thu Aug 14 08:46:47 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 14 Aug 2014 09:46:47 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: References: <20140814110900.GA32805@abstractj.org> Message-ID: Hi Guys, The links were updated - AS7 https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev - Wildfly https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev @abstract I'm testing it -- Passos On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf wrote: > Awesome! > Great work, Bruno! > > > On Thursday, August 14, 2014, Bruno Oliveira wrote: > >> Good morning everyone, I need your feedback. I just build the initial >> version of docker images for quickstarts. >> >> - AS7: >> >> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev >> - Wildfly: >> >> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev >> >> Would be very appreciated if tell me what's missing. >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > -- > Sent from Gmail Mobile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140814/2bc8a41d/attachment.html From bruno at abstractj.org Thu Aug 14 09:24:43 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 14 Aug 2014 10:24:43 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: References: <20140814110900.GA32805@abstractj.org> Message-ID: <20140814132443.GB38097@abstractj.org> Thank you Passos. On 2014-08-14, Daniel Passos wrote: > Hi Guys, > > The links were updated > > - AS7 > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > > - Wildfly > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > > @abstract I'm testing it > > -- Passos > > > > On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf > wrote: > > > Awesome! > > Great work, Bruno! > > > > > > On Thursday, August 14, 2014, Bruno Oliveira wrote: > > > >> Good morning everyone, I need your feedback. I just build the initial > >> version of docker images for quickstarts. > >> > >> - AS7: > >> > >> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > >> - Wildfly: > >> > >> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > >> > >> Would be very appreciated if tell me what's missing. > >> > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > -- > > Sent from Gmail Mobile > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Thu Aug 14 10:33:10 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 14 Aug 2014 16:33:10 +0200 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: <20140814132443.GB38097@abstractj.org> References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> Message-ID: This is really great and thanks working on this Bruno! Trying this out and I have a few questions. The server applications that are deployed are UPS and the jboss-mobile-contacts-picketlink-secured as far as I can tell. The configuration requires the configuration of the UnifiedPush server URL but this will only be used on this server by the jboss-mobile-contacts-picketlink-secured app. In the configuration we also have to specify the application id and the master secret which would not have been created yet as this is a fresh UPS installation. Or am I missing something here perhaps? I'd really like it if we could resolve the maven dependencies before starting the image to save to have having them downloaded every time one start. For example, this would be a real time saver for reviewing PR. I'll do some more testing tomorrow as I have some port forwarding issue locally at the moment. On 14 August 2014 15:24, Bruno Oliveira wrote: > Thank you Passos. > > On 2014-08-14, Daniel Passos wrote: > > Hi Guys, > > > > The links were updated > > > > - AS7 > > > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > > > > - Wildfly > > > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > > > > @abstract I'm testing it > > > > -- Passos > > > > > > > > On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf > > wrote: > > > > > Awesome! > > > Great work, Bruno! > > > > > > > > > On Thursday, August 14, 2014, Bruno Oliveira > wrote: > > > > > >> Good morning everyone, I need your feedback. I just build the initial > > >> version of docker images for quickstarts. > > >> > > >> - AS7: > > >> > > >> > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > > >> - Wildfly: > > >> > > >> > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > > >> > > >> Would be very appreciated if tell me what's missing. > > >> > > >> -- > > >> > > >> abstractj > > >> PGP: 0x84DC9914 > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > > > > > > > > -- > > > Sent from Gmail Mobile > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140814/e6cc35fa/attachment.html From daniel at passos.me Thu Aug 14 12:24:06 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 14 Aug 2014 13:24:06 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> Message-ID: On Thu, Aug 14, 2014 at 11:33 AM, Daniel Bevenius wrote: > This is really great and thanks working on this Bruno! > > Trying this out and I have a few questions. > The server applications that are deployed are UPS and the > jboss-mobile-contacts-picketlink-secured as far as I can tell. > The configuration requires the configuration of the UnifiedPush server URL > but this will only be used on this server by the > jboss-mobile-contacts-picketlink-secured app. In the configuration we also > have to specify the application id and the master secret which would not > have been created yet as this is a fresh UPS installation. Or am I missing > something here perhaps? > IMHO we shouldn't add UPS on this image, only the quickstarts things. I know the UPS is a pre req to use that, but we already have an image for it, or you can create an instance on openshift. > I'd really like it if we could resolve the maven dependencies before > starting the image to save to have having them downloaded every time one > start. For example, this would be a real time saver for reviewing PR. > I can't see it as a problem but +1 > I'll do some more testing tomorrow as I have some port forwarding issue > locally at the moment. > I can't find the webapp[1] on this imagem, maybe is a good idea add it. [1] https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp -- Passos > On 14 August 2014 15:24, Bruno Oliveira wrote: > >> Thank you Passos. >> >> On 2014-08-14, Daniel Passos wrote: >> > Hi Guys, >> > >> > The links were updated >> > >> > - AS7 >> > >> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev >> > >> > - Wildfly >> > >> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev >> > >> > @abstract I'm testing it >> > >> > -- Passos >> > >> > >> > >> > On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf > > >> > wrote: >> > >> > > Awesome! >> > > Great work, Bruno! >> > > >> > > >> > > On Thursday, August 14, 2014, Bruno Oliveira >> wrote: >> > > >> > >> Good morning everyone, I need your feedback. I just build the initial >> > >> version of docker images for quickstarts. >> > >> >> > >> - AS7: >> > >> >> > >> >> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev >> > >> - Wildfly: >> > >> >> > >> >> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev >> > >> >> > >> Would be very appreciated if tell me what's missing. >> > >> >> > >> -- >> > >> >> > >> abstractj >> > >> PGP: 0x84DC9914 >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > > >> > > >> > > -- >> > > Sent from Gmail Mobile >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140814/33bd4297/attachment-0001.html From preilly at php.net Thu Aug 14 14:13:42 2014 From: preilly at php.net (Patrick Reilly) Date: Thu, 14 Aug 2014 11:13:42 -0700 Subject: [aerogear-dev] public list of users of aerogear-unifiedpush-server Message-ID: Hello List, I was curious if there was currently a public list of users of aerogear-unifiedpush-server? ? Patrick From bruno at abstractj.org Thu Aug 14 19:19:51 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 14 Aug 2014 20:19:51 -0300 Subject: [aerogear-dev] public list of users of aerogear-unifiedpush-server In-Reply-To: References: Message-ID: <20140814231951.GA59381@abstractj.org> What do you mean? On 2014-08-14, Patrick Reilly wrote: > Hello List, > > I was curious if there was currently a public list of users of > aerogear-unifiedpush-server? > > ? Patrick > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From preilly at php.net Thu Aug 14 19:21:03 2014 From: preilly at php.net (Patrick Reilly) Date: Thu, 14 Aug 2014 16:21:03 -0700 Subject: [aerogear-dev] public list of users of aerogear-unifiedpush-server In-Reply-To: <20140814231951.GA59381@abstractj.org> References: <20140814231951.GA59381@abstractj.org> Message-ID: Well, I'm looking for a list of larger installations e.g., it's being used at XYZ start-up. ? Patrick On Thu, Aug 14, 2014 at 4:19 PM, Bruno Oliveira wrote: > What do you mean? > > On 2014-08-14, Patrick Reilly wrote: >> Hello List, >> >> I was curious if there was currently a public list of users of >> aerogear-unifiedpush-server? >> >> ? Patrick >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 14 19:26:39 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 14 Aug 2014 20:26:39 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> Message-ID: <20140814232639.GB59381@abstractj.org> Good morning, answers inline. On 2014-08-14, Daniel Bevenius wrote: > This is really great and thanks working on this Bruno! > > Trying this out and I have a few questions. > The server applications that are deployed are UPS and the > jboss-mobile-contacts-picketlink-secured as far as I can tell. You are correct Dan, I also added https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp. After the feedback from Passos. > The configuration requires the configuration of the UnifiedPush server URL > but this will only be used on this server by the > jboss-mobile-contacts-picketlink-secured app. In the configuration we also > have to specify the application id and the master secret which would not > have been created yet as this is a fresh UPS installation. Or am I missing > something here perhaps? Maybe the workflow is not the best here and I'm accepting suggestions. Basically this is what I had in mind (and can be wrong) 1. Start the server which already has UPS inside 2. Run the configuration scripts for the quickstarts 3. Deploy it Maybe we can improve it. What do you have in mind? > > I'd really like it if we could resolve the maven dependencies before > starting the image to save to have having them downloaded every time one > start. For example, this would be a real time saver for reviewing PR. I think that's totally possible, I will do that. > > I'll do some more testing tomorrow as I have some port forwarding issue > locally at the moment. Let me know if you have a better idea about the workflow. I will add the downloaded dependencies during the build time. > > > > > > On 14 August 2014 15:24, Bruno Oliveira wrote: > > > Thank you Passos. > > > > On 2014-08-14, Daniel Passos wrote: > > > Hi Guys, > > > > > > The links were updated > > > > > > - AS7 > > > > > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > > > > > > - Wildfly > > > > > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > > > > > > @abstract I'm testing it > > > > > > -- Passos > > > > > > > > > > > > On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf > > > wrote: > > > > > > > Awesome! > > > > Great work, Bruno! > > > > > > > > > > > > On Thursday, August 14, 2014, Bruno Oliveira > > wrote: > > > > > > > >> Good morning everyone, I need your feedback. I just build the initial > > > >> version of docker images for quickstarts. > > > >> > > > >> - AS7: > > > >> > > > >> > > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > > > >> - Wildfly: > > > >> > > > >> > > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > > > >> > > > >> Would be very appreciated if tell me what's missing. > > > >> > > > >> -- > > > >> > > > >> abstractj > > > >> PGP: 0x84DC9914 > > > >> _______________________________________________ > > > >> aerogear-dev mailing list > > > >> aerogear-dev at lists.jboss.org > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > >> > > > > > > > > > > > > -- > > > > Sent from Gmail Mobile > > > > > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 14 19:33:26 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 14 Aug 2014 20:33:26 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> Message-ID: <20140814233326.GC59381@abstractj.org> On 2014-08-14, Daniel Passos wrote: > On Thu, Aug 14, 2014 at 11:33 AM, Daniel Bevenius > wrote: > > > This is really great and thanks working on this Bruno! > > > > Trying this out and I have a few questions. > > The server applications that are deployed are UPS and the > > jboss-mobile-contacts-picketlink-secured as far as I can tell. > > The configuration requires the configuration of the UnifiedPush server URL > > but this will only be used on this server by the > > jboss-mobile-contacts-picketlink-secured app. In the configuration we also > > have to specify the application id and the master secret which would not > > have been created yet as this is a fresh UPS installation. Or am I missing > > something here perhaps? > > > > IMHO we shouldn't add UPS on this image, only the quickstarts things. I > know the UPS is a pre req to use that, but we already have an image for it, > or you can create an instance on openshift. Hi Passos, this is how the docker images are organized today, for example to Wildfly. wildfly | +----unifiedpush-wildfly-dev | +---push-quickstarts-wildfly-dev Pretty much one image use as base image another. So is not like we have duplicated images, is more like we extend. If the team choose on not having UPS inside the quickstarts, won't be a big deal for me. It's just the matter of decide. Thoughts? > > > > I'd really like it if we could resolve the maven dependencies before > > starting the image to save to have having them downloaded every time one > > start. For example, this would be a real time saver for reviewing PR. > > > > I can't see it as a problem but +1 > > > > I'll do some more testing tomorrow as I have some port forwarding issue > > locally at the moment. > > > > I can't find the webapp[1] on this imagem, maybe is a good idea add it. I already added that, but maybe we can double check tomorrow > > [1] > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp > > -- Passos > > > > On 14 August 2014 15:24, Bruno Oliveira wrote: > > > >> Thank you Passos. > >> > >> On 2014-08-14, Daniel Passos wrote: > >> > Hi Guys, > >> > > >> > The links were updated > >> > > >> > - AS7 > >> > > >> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > >> > > >> > - Wildfly > >> > > >> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > >> > > >> > @abstract I'm testing it > >> > > >> > -- Passos > >> > > >> > > >> > > >> > On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf >> > > >> > wrote: > >> > > >> > > Awesome! > >> > > Great work, Bruno! > >> > > > >> > > > >> > > On Thursday, August 14, 2014, Bruno Oliveira > >> wrote: > >> > > > >> > >> Good morning everyone, I need your feedback. I just build the initial > >> > >> version of docker images for quickstarts. > >> > >> > >> > >> - AS7: > >> > >> > >> > >> > >> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > >> > >> - Wildfly: > >> > >> > >> > >> > >> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > >> > >> > >> > >> Would be very appreciated if tell me what's missing. > >> > >> > >> > >> -- > >> > >> > >> > >> abstractj > >> > >> PGP: 0x84DC9914 > >> > >> _______________________________________________ > >> > >> aerogear-dev mailing list > >> > >> aerogear-dev at lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > > > >> > > > >> > > -- > >> > > Sent from Gmail Mobile > >> > > > >> > > _______________________________________________ > >> > > aerogear-dev mailing list > >> > > aerogear-dev at lists.jboss.org > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > >> > >> > _______________________________________________ > >> > aerogear-dev mailing list > >> > aerogear-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From cvasilak at gmail.com Fri Aug 15 02:25:23 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 15 Aug 2014 09:25:23 +0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: <20140814232639.GB59381@abstractj.org> References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> <20140814232639.GB59381@abstractj.org> Message-ID: <62D5E4F5-B15F-4B50-9C25-46CA51D07C11@gmail.com> nice work Bruno! some comments inline On Aug 15, 2014, at 2:26 AM, Bruno Oliveira wrote: > Good morning, answers inline. > > On 2014-08-14, Daniel Bevenius wrote: >> This is really great and thanks working on this Bruno! >> >> Trying this out and I have a few questions. >> The server applications that are deployed are UPS and the >> jboss-mobile-contacts-picketlink-secured as far as I can tell. > > You are correct Dan, I also added > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp. > After the feedback from Passos. > >> The configuration requires the configuration of the UnifiedPush server URL >> but this will only be used on this server by the >> jboss-mobile-contacts-picketlink-secured app. In the configuration we also >> have to specify the application id and the master secret which would not >> have been created yet as this is a fresh UPS installation. Or am I missing >> something here perhaps? > > Maybe the workflow is not the best here and I'm accepting suggestions. > Basically this is what I had in mind (and can be wrong) > > 1. Start the server which already has UPS inside Not sure if its possible and can be wrong.. but after this step, can _we_ pre-create the ?Contacts? application (only the app NOT the variants), gather the config details from the response (app_id, secret) > 2. Run the configuration scripts for the quick starts setup the config.json from the previous step > 3. Deploy it The user is left now only to login to UPS and setup his preferred variant (iOS/Android/SP) and then copy the variant_id/secret to his preferred native quick start client. The contacts-web-app is ready to use also. wdyth? - Christos > Maybe we can improve it. What do you have in mind? > >> >> I'd really like it if we could resolve the maven dependencies before >> starting the image to save to have having them downloaded every time one >> start. For example, this would be a real time saver for reviewing PR. > > I think that's totally possible, I will do that. >> >> I'll do some more testing tomorrow as I have some port forwarding issue >> locally at the moment. > > Let me know if you have a better idea about the workflow. I will add the > downloaded dependencies during the build time. > >> >> >> >> >> >> On 14 August 2014 15:24, Bruno Oliveira wrote: >> >>> Thank you Passos. >>> >>> On 2014-08-14, Daniel Passos wrote: >>>> Hi Guys, >>>> >>>> The links were updated >>>> >>>> - AS7 >>>> >>> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev >>>> >>>> - Wildfly >>>> >>> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev >>>> >>>> @abstract I'm testing it >>>> >>>> -- Passos >>>> >>>> >>>> >>>> On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf >>>> wrote: >>>> >>>>> Awesome! >>>>> Great work, Bruno! >>>>> >>>>> >>>>> On Thursday, August 14, 2014, Bruno Oliveira >>> wrote: >>>>> >>>>>> Good morning everyone, I need your feedback. I just build the initial >>>>>> version of docker images for quickstarts. >>>>>> >>>>>> - AS7: >>>>>> >>>>>> >>> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev >>>>>> - Wildfly: >>>>>> >>>>>> >>> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev >>>>>> >>>>>> Would be very appreciated if tell me what's missing. >>>>>> >>>>>> -- >>>>>> >>>>>> abstractj >>>>>> PGP: 0x84DC9914 >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sent from Gmail Mobile >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Fri Aug 15 03:27:37 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 15 Aug 2014 04:27:37 -0300 Subject: [aerogear-dev] public list of users of aerogear-unifiedpush-server In-Reply-To: References: <20140814231951.GA59381@abstractj.org> Message-ID: <20140815072737.GA62735@abstractj.org> As far as I know, we don't have such thing. On 2014-08-14, Patrick Reilly wrote: > Well, I'm looking for a list of larger installations e.g., it's being > used at XYZ start-up. > > ? Patrick > > On Thu, Aug 14, 2014 at 4:19 PM, Bruno Oliveira wrote: > > What do you mean? > > > > On 2014-08-14, Patrick Reilly wrote: > >> Hello List, > >> > >> I was curious if there was currently a public list of users of > >> aerogear-unifiedpush-server? > >> > >> ? Patrick > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > > > abstractj > > PGP: 0x84DC9914 -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Aug 15 03:38:45 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 15 Aug 2014 04:38:45 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: <62D5E4F5-B15F-4B50-9C25-46CA51D07C11@gmail.com> References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> <20140814232639.GB59381@abstractj.org> <62D5E4F5-B15F-4B50-9C25-46CA51D07C11@gmail.com> Message-ID: <20140815073845.GB62735@abstractj.org> On 2014-08-15, Christos Vasilakis wrote: > nice work Bruno! > > some comments inline > > On Aug 15, 2014, at 2:26 AM, Bruno Oliveira wrote: > > > Good morning, answers inline. > > > > On 2014-08-14, Daniel Bevenius wrote: > >> This is really great and thanks working on this Bruno! > >> > >> Trying this out and I have a few questions. > >> The server applications that are deployed are UPS and the > >> jboss-mobile-contacts-picketlink-secured as far as I can tell. > > > > You are correct Dan, I also added > > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp. > > > After the feedback from Passos. > > > >> The configuration requires the configuration of the UnifiedPush server URL > >> but this will only be used on this server by the > >> jboss-mobile-contacts-picketlink-secured app. In the configuration we also > >> have to specify the application id and the master secret which would not > >> have been created yet as this is a fresh UPS installation. Or am I missing > >> something here perhaps? > > > > Maybe the workflow is not the best here and I'm accepting suggestions. > > Basically this is what I had in mind (and can be wrong) > > > > 1. Start the server which already has UPS inside > > Not sure if its possible and can be wrong.. but after this step, can _we_ pre-create the ?Contacts? application (only the app NOT the variants), gather the config details from the response (app_id, secret) Hmmm not sure about that. I would like to leave it to the developer, pre-create anything might result in more maintenance. Maybe we should stick to Passos suggestion and consider having a Push server started and configured on Docker or OpenShift a requirement. > > > 2. Run the configuration scripts for the quick starts > > setup the config.json from the previous step > > > 3. Deploy it > > The user is left now only to login to UPS and setup his preferred variant (iOS/Android/SP) and then copy the variant_id/secret to his preferred native quick start client. The contacts-web-app is ready to use also. I'm fine with it as long as we skipt the fact of pre-create anything. But if all agreed on it, that's ok. > > wdyth? > > > - > Christos > > > > Maybe we can improve it. What do you have in mind? > > > > >> > >> I'd really like it if we could resolve the maven dependencies before > >> starting the image to save to have having them downloaded every time one > >> start. For example, this would be a real time saver for reviewing PR. > > > > I think that's totally possible, I will do that. > >> > >> I'll do some more testing tomorrow as I have some port forwarding issue > >> locally at the moment. > > > > Let me know if you have a better idea about the workflow. I will add the > > downloaded dependencies during the build time. > > > >> > >> > >> > >> > >> > >> On 14 August 2014 15:24, Bruno Oliveira wrote: > >> > >>> Thank you Passos. > >>> > >>> On 2014-08-14, Daniel Passos wrote: > >>>> Hi Guys, > >>>> > >>>> The links were updated > >>>> > >>>> - AS7 > >>>> > >>> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > >>>> > >>>> - Wildfly > >>>> > >>> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > >>>> > >>>> @abstract I'm testing it > >>>> > >>>> -- Passos > >>>> > >>>> > >>>> > >>>> On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf > >>>> wrote: > >>>> > >>>>> Awesome! > >>>>> Great work, Bruno! > >>>>> > >>>>> > >>>>> On Thursday, August 14, 2014, Bruno Oliveira > >>> wrote: > >>>>> > >>>>>> Good morning everyone, I need your feedback. I just build the initial > >>>>>> version of docker images for quickstarts. > >>>>>> > >>>>>> - AS7: > >>>>>> > >>>>>> > >>> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > >>>>>> - Wildfly: > >>>>>> > >>>>>> > >>> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > >>>>>> > >>>>>> Would be very appreciated if tell me what's missing. > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> abstractj > >>>>>> PGP: 0x84DC9914 > >>>>>> _______________________________________________ > >>>>>> aerogear-dev mailing list > >>>>>> aerogear-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Sent from Gmail Mobile > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > > > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Aug 15 04:01:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 15 Aug 2014 05:01:21 -0300 Subject: [aerogear-dev] Quickstarts revamp..or not... Message-ID: <20140815080121.GA63676@abstractj.org> Good morning, Today at our quickstarts, it doesn't make sense the server[1] without an interface[2] (I guess). I was just wondering if we could merge both in a single project. Or maybe make the webapp have the server as dependency, not sure. Btw the name "client" for the webapp is a little bit odd to me, once it requires a server. [1] - https://github.com/aerogear/aerogear-push-quickstarts/tree/master/server/contacts-mobile-picketlink-secured [2] - https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp -- abstractj PGP: 0x84DC9914 From matzew at apache.org Fri Aug 15 04:18:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 15 Aug 2014 10:18:42 +0200 Subject: [aerogear-dev] Quickstarts revamp..or not... In-Reply-To: <20140815080121.GA63676@abstractj.org> References: <20140815080121.GA63676@abstractj.org> Message-ID: Howdy! On Fri, Aug 15, 2014 at 10:01 AM, Bruno Oliveira wrote: > Good morning, > > Today at our quickstarts, it doesn't make sense the server[1] without an > interface[2] (I guess). > I think one of the reasons was: RESTful server/interface does not always require a "web-ui", especially since it was mainly created to serve mobile apps/clients. Instead of throwing the 'inherited' web-ui away, there was talks to have it separate. This would also allow one to deployed on a different machine (if there was a need for a web-ui). Dan worked on CORS for that. > > I was just wondering if we could merge both in a single project. Or > maybe make the webapp have the server as dependency, not sure. > If that makes things easier, I am for it - I don't have a strong feeling on that one. > > Btw the name "client" for the webapp is a little bit odd to me, once it > requires a server. > It's a client, similar to the mobile apps. The payload posted from both, mobile (e.g. iOS) and the web-app, go eventually against the 'backend server' for persistence. However the deployment environment is slightly different - yes. The iOS demo needs a mobile device as its 'container', while the web-ui needs a JavaEE/Web container. I think this is very similar to our old [TODO app], which had two WAR files as well. One is 'server.war', the other is the 'client.war' (containing the JS and HTML files). -Matthias [TODO app] https://github.com/aerogear/TODO > > > [1] - > > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/server/contacts-mobile-picketlink-secured > > [2] - > > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/51f6cce6/attachment.html From scm.blanc at gmail.com Fri Aug 15 04:22:46 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Fri, 15 Aug 2014 10:22:46 +0200 Subject: [aerogear-dev] Quickstarts revamp..or not... In-Reply-To: <20140815080121.GA63676@abstractj.org> References: <20140815080121.GA63676@abstractj.org> Message-ID: <2232E204-B504-43FC-A852-9B94CE58C356@gmail.com> These two projects were initially the same project. It was split because the webapp was not really in the scope of the QuickStart (it was a leftover of the wfk QuickStart). But I understand your point , one drastic option could also be to nuke completely the webapp project (as it can bring some confusion ) Envoy? de mon iPhone > Le 15 ao?t 2014 ? 10:01, Bruno Oliveira a ?crit : > > Good morning, > > Today at our quickstarts, it doesn't make sense the server[1] without an > interface[2] (I guess). > > I was just wondering if we could merge both in a single project. Or > maybe make the webapp have the server as dependency, not sure. > > Btw the name "client" for the webapp is a little bit odd to me, once it > requires a server. > > > [1] - > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/server/contacts-mobile-picketlink-secured > > [2] - > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel.bevenius at gmail.com Fri Aug 15 04:24:49 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 15 Aug 2014 10:24:49 +0200 Subject: [aerogear-dev] Quickstarts revamp..or not... In-Reply-To: <20140815080121.GA63676@abstractj.org> References: <20140815080121.GA63676@abstractj.org> Message-ID: >Today at our quickstarts, it doesn't make sense the server[1] without an >interface[2] (I guess). It might make sense if a user is only interested in testing the one of the mobile clients but they can just ignore the webapp in that case.. >I was just wondering if we could merge both in a single project. Or >maybe make the webapp have the server as dependency, not sure. I guess we can do that. The only reason I can think of for having them separated was to make the proxy quickstart a little nicer, where we could have the backend, the webapp, and the proxy all on different machines. So I think I'm +1 on this :) On 15 August 2014 10:01, Bruno Oliveira wrote: > Good morning, > > Today at our quickstarts, it doesn't make sense the server[1] without an > interface[2] (I guess). > > I was just wondering if we could merge both in a single project. Or > maybe make the webapp have the server as dependency, not sure. > > Btw the name "client" for the webapp is a little bit odd to me, once it > requires a server. > > > [1] - > > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/server/contacts-mobile-picketlink-secured > > [2] - > > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/44ddbe82/attachment.html From bruno at abstractj.org Fri Aug 15 04:54:13 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 15 Aug 2014 05:54:13 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> Message-ID: <20140815085413.GA65073@abstractj.org> Ahoy, I've already added Dan's request to pre-download the Maven dependencies and avoid the global warming. On 2014-08-14, Daniel Passos wrote: > On Thu, Aug 14, 2014 at 11:33 AM, Daniel Bevenius > wrote: > > > This is really great and thanks working on this Bruno! > > > > Trying this out and I have a few questions. > > The server applications that are deployed are UPS and the > > jboss-mobile-contacts-picketlink-secured as far as I can tell. > > The configuration requires the configuration of the UnifiedPush server URL > > but this will only be used on this server by the > > jboss-mobile-contacts-picketlink-secured app. In the configuration we also > > have to specify the application id and the master secret which would not > > have been created yet as this is a fresh UPS installation. Or am I missing > > something here perhaps? > > > > IMHO we shouldn't add UPS on this image, only the quickstarts things. I > know the UPS is a pre req to use that, but we already have an image for it, > or you can create an instance on openshift. > > > > I'd really like it if we could resolve the maven dependencies before > > starting the image to save to have having them downloaded every time one > > start. For example, this would be a real time saver for reviewing PR. > > > > I can't see it as a problem but +1 > > > > I'll do some more testing tomorrow as I have some port forwarding issue > > locally at the moment. > > > > I can't find the webapp[1] on this imagem, maybe is a good idea add it. > > [1] > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp > > -- Passos > > > > On 14 August 2014 15:24, Bruno Oliveira wrote: > > > >> Thank you Passos. > >> > >> On 2014-08-14, Daniel Passos wrote: > >> > Hi Guys, > >> > > >> > The links were updated > >> > > >> > - AS7 > >> > > >> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > >> > > >> > - Wildfly > >> > > >> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > >> > > >> > @abstract I'm testing it > >> > > >> > -- Passos > >> > > >> > > >> > > >> > On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf >> > > >> > wrote: > >> > > >> > > Awesome! > >> > > Great work, Bruno! > >> > > > >> > > > >> > > On Thursday, August 14, 2014, Bruno Oliveira > >> wrote: > >> > > > >> > >> Good morning everyone, I need your feedback. I just build the initial > >> > >> version of docker images for quickstarts. > >> > >> > >> > >> - AS7: > >> > >> > >> > >> > >> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > >> > >> - Wildfly: > >> > >> > >> > >> > >> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > >> > >> > >> > >> Would be very appreciated if tell me what's missing. > >> > >> > >> > >> -- > >> > >> > >> > >> abstractj > >> > >> PGP: 0x84DC9914 > >> > >> _______________________________________________ > >> > >> aerogear-dev mailing list > >> > >> aerogear-dev at lists.jboss.org > >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > > > >> > > > >> > > -- > >> > > Sent from Gmail Mobile > >> > > > >> > > _______________________________________________ > >> > > aerogear-dev mailing list > >> > > aerogear-dev at lists.jboss.org > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > >> > >> > _______________________________________________ > >> > aerogear-dev mailing list > >> > aerogear-dev at lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Fri Aug 15 05:02:20 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 15 Aug 2014 11:02:20 +0200 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: <20140815085413.GA65073@abstractj.org> References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> <20140815085413.GA65073@abstractj.org> Message-ID: >Ahoy, I've already added Dan's request to pre-download the Maven dependencies and avoid the global warming. Awesome! Regarding pre-creating an application to have the appId and master secret. I think it is fine to have that as a manual step. Users still need to be able to understand what they are doing. So the first step could be to start the UPS image, log in and create a new application. Next step could be to start a second image which contains the backed and when starting configure it with the correct url to UPS and their newly created appId and master secret. On 15 August 2014 10:54, Bruno Oliveira wrote: > Ahoy, I've already added Dan's request to pre-download the Maven > dependencies and > avoid the global warming. > > On 2014-08-14, Daniel Passos wrote: > > On Thu, Aug 14, 2014 at 11:33 AM, Daniel Bevenius < > daniel.bevenius at gmail.com > > > wrote: > > > > > This is really great and thanks working on this Bruno! > > > > > > Trying this out and I have a few questions. > > > The server applications that are deployed are UPS and the > > > jboss-mobile-contacts-picketlink-secured as far as I can tell. > > > The configuration requires the configuration of the UnifiedPush server > URL > > > but this will only be used on this server by the > > > jboss-mobile-contacts-picketlink-secured app. In the configuration we > also > > > have to specify the application id and the master secret which would > not > > > have been created yet as this is a fresh UPS installation. Or am I > missing > > > something here perhaps? > > > > > > > IMHO we shouldn't add UPS on this image, only the quickstarts things. I > > know the UPS is a pre req to use that, but we already have an image for > it, > > or you can create an instance on openshift. > > > > > > > I'd really like it if we could resolve the maven dependencies before > > > starting the image to save to have having them downloaded every time > one > > > start. For example, this would be a real time saver for reviewing PR. > > > > > > > I can't see it as a problem but +1 > > > > > > > I'll do some more testing tomorrow as I have some port forwarding issue > > > locally at the moment. > > > > > > > I can't find the webapp[1] on this imagem, maybe is a good idea add it. > > > > [1] > > > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp > > > > -- Passos > > > > > > > On 14 August 2014 15:24, Bruno Oliveira wrote: > > > > > >> Thank you Passos. > > >> > > >> On 2014-08-14, Daniel Passos wrote: > > >> > Hi Guys, > > >> > > > >> > The links were updated > > >> > > > >> > - AS7 > > >> > > > >> > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > > >> > > > >> > - Wildfly > > >> > > > >> > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > > >> > > > >> > @abstract I'm testing it > > >> > > > >> > -- Passos > > >> > > > >> > > > >> > > > >> > On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf < > matzew at apache.org > > >> > > > >> > wrote: > > >> > > > >> > > Awesome! > > >> > > Great work, Bruno! > > >> > > > > >> > > > > >> > > On Thursday, August 14, 2014, Bruno Oliveira > > > >> wrote: > > >> > > > > >> > >> Good morning everyone, I need your feedback. I just build the > initial > > >> > >> version of docker images for quickstarts. > > >> > >> > > >> > >> - AS7: > > >> > >> > > >> > >> > > >> > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > > >> > >> - Wildfly: > > >> > >> > > >> > >> > > >> > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > > >> > >> > > >> > >> Would be very appreciated if tell me what's missing. > > >> > >> > > >> > >> -- > > >> > >> > > >> > >> abstractj > > >> > >> PGP: 0x84DC9914 > > >> > >> _______________________________________________ > > >> > >> aerogear-dev mailing list > > >> > >> aerogear-dev at lists.jboss.org > > >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > >> > > >> > > > > >> > > > > >> > > -- > > >> > > Sent from Gmail Mobile > > >> > > > > >> > > _______________________________________________ > > >> > > aerogear-dev mailing list > > >> > > aerogear-dev at lists.jboss.org > > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > > > >> > > >> > _______________________________________________ > > >> > aerogear-dev mailing list > > >> > aerogear-dev at lists.jboss.org > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > >> > > >> -- > > >> > > >> abstractj > > >> PGP: 0x84DC9914 > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/3e82a696/attachment.html From matzew at apache.org Fri Aug 15 06:06:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 15 Aug 2014 12:06:15 +0200 Subject: [aerogear-dev] Beta2 of the UnifiedPush Server 1.0.0 released Message-ID: Good morning folks! Today we are announcing the second beta release of our 1.0.0 version. This release contains several improvements - WildFly 8.x support - PostgreSQL fix - Scheduler component for deleting analytics older than 30 days - Improvements on the AdminUI - Documentation The complete list of included items are avialble on our JIRA instance With the release of the server we also released new versions of the senders for Java and Node.js ! Docker The team is extremely excited about the work that Bruno Oliveira did on our new Docker images: - UnifiedPush Server for WildFly - UnifiedPush Server for AS7 *Check them out!* Documentation As mentioned above, the documentation for the UnifiedPush Server has been reorganized , including an all new guide on how to use the UnifiedPush Server . Demos To get easily started using the UnifiedPush Server we have a bunch of demos, supporting various client platforms: - Android - Apache Cordova (with jQuery and Angular/Ionic) - iOS The simple HelloWorld examples are located here . Some more advanced examples, including a Picketlink secured JAX-RS application, as well as a Fabric8 based Proxy, are available here . Docker For you convenience, there are Docker images for the Quickstart as well: - WildFly - AS7 Feedback We hope you enjoy the bits and we do appreciate your feedback! Swing by on our mailing list! We are looking forward to hear from you! NOTE: the Openshift online offering will be updated w/in the next day or two Enjoy! -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/9c27986e/attachment-0001.html From edewit at redhat.com Fri Aug 15 06:49:39 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 15 Aug 2014 12:49:39 +0200 Subject: [aerogear-dev] Cordova Push Plugin Release Message-ID: Hi all, After successful testing I?m happy to announce that the 0.7.0 version of the aerogear-pushplugin has been released. Thanks to everyone involved in making this release happen. The new features bugs fixed are: Bug [AGCORDOVA-22] - android binaries installed for other platforms Feature Request [AGCORDOVA-23] - Support content title with gcm notifications on android [AGCORDOVA-25] - iOS8 support for push registration -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/2f446d3e/attachment.html From matzew at apache.org Fri Aug 15 07:39:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 15 Aug 2014 13:39:03 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Way to 1.0.0.Final Message-ID: Hello team! 1.0.0.Beta2 is out and 1.0.0.Final is around the corner! The list of open JIRAs is looking really good (see [1]). The most tickets are around our quickstart demos and documentation. There are a few tickets that require commits to the UPS itself. Gabriel did a review of the UX/UI and filed three tickets (AGPUSH-934, AGPUSH-935 and AGPUSH-936) that he and Lukas will be working on. The release date for the 1.0.0.Final will be August 25th/26th and therefore I propose to do a 'code freeze' for the UPS around the 19th or 20th August to ensure its stability. However, in case something comes up (e.g. during testing), I think only 'blocker' or 'critical' fixes should be allowed to be merged during that time. Goal is to minimize risks! Once the UPS 1.0.0.Final is out, there are a few 1.0.x release planed to address things (if needed) and picking up new releases of our own dependencies (e.g. Keycloak) Any thoughts ? Greetings, Matthias [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/b63ec9c2/attachment.html From lholmqui at redhat.com Fri Aug 15 08:29:44 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 15 Aug 2014 08:29:44 -0400 Subject: [aerogear-dev] [UnifiedPush Server] Way to 1.0.0.Final In-Reply-To: References: Message-ID: On Aug 15, 2014, at 7:39 AM, Matthias Wessendorf wrote: > Hello team! > > 1.0.0.Beta2 is out and 1.0.0.Final is around the corner! Nice! Also, thanks to everyone for helping with those Cordova Quickstart JIRA's > > The list of open JIRAs is looking really good (see [1]). The most tickets are around our quickstart demos and documentation. There are a few tickets that require commits to the UPS itself. Gabriel did a review of the UX/UI and filed three tickets (AGPUSH-934, AGPUSH-935 and AGPUSH-936) that he and Lukas will be working on. > > The release date for the 1.0.0.Final will be August 25th/26th and therefore I propose to do a 'code freeze' for the UPS around the 19th or 20th August to ensure its stability. However, in case something comes up (e.g. during testing), I think only 'blocker' or 'critical' fixes should be allowed to be merged during that time. Goal is to minimize risks! > > Once the UPS 1.0.0.Final is out, there are a few 1.0.x release planed to address things (if needed) and picking up new releases of our own dependencies (e.g. Keycloak) > > Any thoughts ? > > Greetings, Matthias > > [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/7d26e143/attachment.html From daniel.bevenius at gmail.com Fri Aug 15 08:34:31 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 15 Aug 2014 14:34:31 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Way to 1.0.0.Final In-Reply-To: References: Message-ID: Nice work guys! On 15 August 2014 14:29, Lucas Holmquist wrote: > > On Aug 15, 2014, at 7:39 AM, Matthias Wessendorf > wrote: > > Hello team! > > 1.0.0.Beta2 is out and 1.0.0.Final is around the corner! > > Nice! > > > Also, thanks to everyone for helping with those Cordova Quickstart JIRA's > > > The list of open JIRAs is looking really good (see [1]). The most tickets > are around our quickstart demos and documentation. There are a few tickets > that require commits to the UPS itself. Gabriel did a review of the UX/UI > and filed three tickets (AGPUSH-934, AGPUSH-935 and AGPUSH-936) that he and > Lukas will be working on. > > The release date for the 1.0.0.Final will be August 25th/26th and > therefore I propose to do a 'code freeze' for the UPS around the 19th or > 20th August to ensure its stability. However, in case something comes up > (e.g. during testing), I think only 'blocker' or 'critical' fixes should be > allowed to be merged during that time. Goal is to minimize risks! > > Once the UPS 1.0.0.Final is out, there are a few 1.0.x release planed to > address things (if needed) and picking up new releases of our own > dependencies (e.g. Keycloak) > > Any thoughts ? > > Greetings, Matthias > > [1] > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/e6aea54a/attachment.html From bruno at abstractj.org Fri Aug 15 09:16:16 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 15 Aug 2014 10:16:16 -0300 Subject: [aerogear-dev] Cordova Push Plugin Release In-Reply-To: References: Message-ID: <20140815131616.GB65073@abstractj.org> Huzzah! On 2014-08-15, Erik Jan de Wit wrote: > Hi all, > > After successful testing I?m happy to announce that the 0.7.0 version of the aerogear-pushplugin has been released. Thanks to everyone involved in making this release happen. > > The new features bugs fixed are: > Bug > [AGCORDOVA-22] - android binaries installed for other platforms > Feature Request > [AGCORDOVA-23] - Support content title with gcm notifications on android > [AGCORDOVA-25] - iOS8 support for push registration > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Aug 15 09:19:24 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 15 Aug 2014 10:19:24 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> <20140815085413.GA65073@abstractj.org> Message-ID: <20140815131924.GC65073@abstractj.org> I'm +1 on it. What the others think? On 2014-08-15, Daniel Bevenius wrote: > >Ahoy, I've already added Dan's request to pre-download the Maven > dependencies and avoid the global warming. > Awesome! > > Regarding pre-creating an application to have the appId and master secret. > I think it is fine to have that as a manual step. Users still need to be > able to understand what they are doing. So the first step could be to start > the UPS image, log in and create a new application. Next step could be to > start a second image which contains the backed and when starting configure > it with the correct url to UPS and their newly created appId and master > secret. > > > > > > > On 15 August 2014 10:54, Bruno Oliveira wrote: > > > Ahoy, I've already added Dan's request to pre-download the Maven > > dependencies and > > avoid the global warming. > > > > On 2014-08-14, Daniel Passos wrote: > > > On Thu, Aug 14, 2014 at 11:33 AM, Daniel Bevenius < > > daniel.bevenius at gmail.com > > > > wrote: > > > > > > > This is really great and thanks working on this Bruno! > > > > > > > > Trying this out and I have a few questions. > > > > The server applications that are deployed are UPS and the > > > > jboss-mobile-contacts-picketlink-secured as far as I can tell. > > > > The configuration requires the configuration of the UnifiedPush server > > URL > > > > but this will only be used on this server by the > > > > jboss-mobile-contacts-picketlink-secured app. In the configuration we > > also > > > > have to specify the application id and the master secret which would > > not > > > > have been created yet as this is a fresh UPS installation. Or am I > > missing > > > > something here perhaps? > > > > > > > > > > IMHO we shouldn't add UPS on this image, only the quickstarts things. I > > > know the UPS is a pre req to use that, but we already have an image for > > it, > > > or you can create an instance on openshift. > > > > > > > > > > I'd really like it if we could resolve the maven dependencies before > > > > starting the image to save to have having them downloaded every time > > one > > > > start. For example, this would be a real time saver for reviewing PR. > > > > > > > > > > I can't see it as a problem but +1 > > > > > > > > > > I'll do some more testing tomorrow as I have some port forwarding issue > > > > locally at the moment. > > > > > > > > > > I can't find the webapp[1] on this imagem, maybe is a good idea add it. > > > > > > [1] > > > > > https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp > > > > > > -- Passos > > > > > > > > > > On 14 August 2014 15:24, Bruno Oliveira wrote: > > > > > > > >> Thank you Passos. > > > >> > > > >> On 2014-08-14, Daniel Passos wrote: > > > >> > Hi Guys, > > > >> > > > > >> > The links were updated > > > >> > > > > >> > - AS7 > > > >> > > > > >> > > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > > > >> > > > > >> > - Wildfly > > > >> > > > > >> > > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > > > >> > > > > >> > @abstract I'm testing it > > > >> > > > > >> > -- Passos > > > >> > > > > >> > > > > >> > > > > >> > On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf < > > matzew at apache.org > > > >> > > > > >> > wrote: > > > >> > > > > >> > > Awesome! > > > >> > > Great work, Bruno! > > > >> > > > > > >> > > > > > >> > > On Thursday, August 14, 2014, Bruno Oliveira > > > > > >> wrote: > > > >> > > > > > >> > >> Good morning everyone, I need your feedback. I just build the > > initial > > > >> > >> version of docker images for quickstarts. > > > >> > >> > > > >> > >> - AS7: > > > >> > >> > > > >> > >> > > > >> > > https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > > > >> > >> - Wildfly: > > > >> > >> > > > >> > >> > > > >> > > https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > > > >> > >> > > > >> > >> Would be very appreciated if tell me what's missing. > > > >> > >> > > > >> > >> -- > > > >> > >> > > > >> > >> abstractj > > > >> > >> PGP: 0x84DC9914 > > > >> > >> _______________________________________________ > > > >> > >> aerogear-dev mailing list > > > >> > >> aerogear-dev at lists.jboss.org > > > >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > >> > >> > > > >> > > > > > >> > > > > > >> > > -- > > > >> > > Sent from Gmail Mobile > > > >> > > > > > >> > > _______________________________________________ > > > >> > > aerogear-dev mailing list > > > >> > > aerogear-dev at lists.jboss.org > > > >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > >> > > > > > >> > > > >> > _______________________________________________ > > > >> > aerogear-dev mailing list > > > >> > aerogear-dev at lists.jboss.org > > > >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > >> > > > >> > > > >> -- > > > >> > > > >> abstractj > > > >> PGP: 0x84DC9914 > > > >> _______________________________________________ > > > >> aerogear-dev mailing list > > > >> aerogear-dev at lists.jboss.org > > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > >> > > > > > > > > > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Fri Aug 15 09:55:05 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 15 Aug 2014 15:55:05 +0200 Subject: [aerogear-dev] Cordova Push Plugin Release In-Reply-To: <20140815131616.GB65073@abstractj.org> References: <20140815131616.GB65073@abstractj.org> Message-ID: Nice! On 15 August 2014 15:16, Bruno Oliveira wrote: > Huzzah! > > On 2014-08-15, Erik Jan de Wit wrote: > > Hi all, > > > > After successful testing I?m happy to announce that the 0.7.0 version of > the aerogear-pushplugin has been released. Thanks to everyone involved in > making this release happen. > > > > The new features bugs fixed are: > > Bug > > [AGCORDOVA-22] - android binaries installed for other platforms > > Feature Request > > [AGCORDOVA-23] - Support content title with gcm notifications on android > > [AGCORDOVA-25] - iOS8 support for push registration > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/5d1b4005/attachment.html From cvasilak at gmail.com Fri Aug 15 10:13:17 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 15 Aug 2014 17:13:17 +0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: <20140815131924.GC65073@abstractj.org> References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> <20140815085413.GA65073@abstractj.org> <20140815131924.GC65073@abstractj.org> Message-ID: <36DC2420-FEBC-41D2-A324-29AAD22E2297@gmail.com> +1 with Daniel suggestion, let?s move on with that approach. - Christos On Aug 15, 2014, at 4:19 PM, Bruno Oliveira wrote: > I'm +1 on it. > > What the others think? > > On 2014-08-15, Daniel Bevenius wrote: >>> Ahoy, I've already added Dan's request to pre-download the Maven >> dependencies and avoid the global warming. >> Awesome! >> >> Regarding pre-creating an application to have the appId and master secret. >> I think it is fine to have that as a manual step. Users still need to be >> able to understand what they are doing. So the first step could be to start >> the UPS image, log in and create a new application. Next step could be to >> start a second image which contains the backed and when starting configure >> it with the correct url to UPS and their newly created appId and master >> secret. >> >> >> >> >> >> >> On 15 August 2014 10:54, Bruno Oliveira wrote: >> >>> Ahoy, I've already added Dan's request to pre-download the Maven >>> dependencies and >>> avoid the global warming. >>> >>> On 2014-08-14, Daniel Passos wrote: >>>> On Thu, Aug 14, 2014 at 11:33 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com >>>>> wrote: >>>> >>>>> This is really great and thanks working on this Bruno! >>>>> >>>>> Trying this out and I have a few questions. >>>>> The server applications that are deployed are UPS and the >>>>> jboss-mobile-contacts-picketlink-secured as far as I can tell. >>>>> The configuration requires the configuration of the UnifiedPush server >>> URL >>>>> but this will only be used on this server by the >>>>> jboss-mobile-contacts-picketlink-secured app. In the configuration we >>> also >>>>> have to specify the application id and the master secret which would >>> not >>>>> have been created yet as this is a fresh UPS installation. Or am I >>> missing >>>>> something here perhaps? >>>>> >>>> >>>> IMHO we shouldn't add UPS on this image, only the quickstarts things. I >>>> know the UPS is a pre req to use that, but we already have an image for >>> it, >>>> or you can create an instance on openshift. >>>> >>>> >>>>> I'd really like it if we could resolve the maven dependencies before >>>>> starting the image to save to have having them downloaded every time >>> one >>>>> start. For example, this would be a real time saver for reviewing PR. >>>>> >>>> >>>> I can't see it as a problem but +1 >>>> >>>> >>>>> I'll do some more testing tomorrow as I have some port forwarding issue >>>>> locally at the moment. >>>>> >>>> >>>> I can't find the webapp[1] on this imagem, maybe is a good idea add it. >>>> >>>> [1] >>>> >>> https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp >>>> >>>> -- Passos >>>> >>>> >>>>> On 14 August 2014 15:24, Bruno Oliveira wrote: >>>>> >>>>>> Thank you Passos. >>>>>> >>>>>> On 2014-08-14, Daniel Passos wrote: >>>>>>> Hi Guys, >>>>>>> >>>>>>> The links were updated >>>>>>> >>>>>>> - AS7 >>>>>>> >>>>>> >>> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev >>>>>>> >>>>>>> - Wildfly >>>>>>> >>>>>> >>> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev >>>>>>> >>>>>>> @abstract I'm testing it >>>>>>> >>>>>>> -- Passos >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf < >>> matzew at apache.org >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> Awesome! >>>>>>>> Great work, Bruno! >>>>>>>> >>>>>>>> >>>>>>>> On Thursday, August 14, 2014, Bruno Oliveira >>> >>>>>> wrote: >>>>>>>> >>>>>>>>> Good morning everyone, I need your feedback. I just build the >>> initial >>>>>>>>> version of docker images for quickstarts. >>>>>>>>> >>>>>>>>> - AS7: >>>>>>>>> >>>>>>>>> >>>>>> >>> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev >>>>>>>>> - Wildfly: >>>>>>>>> >>>>>>>>> >>>>>> >>> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev >>>>>>>>> >>>>>>>>> Would be very appreciated if tell me what's missing. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> abstractj >>>>>>>>> PGP: 0x84DC9914 >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sent from Gmail Mobile >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> abstractj >>>>>> PGP: 0x84DC9914 >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Fri Aug 15 10:14:08 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 15 Aug 2014 17:14:08 +0300 Subject: [aerogear-dev] [UnifiedPush Server] Way to 1.0.0.Final In-Reply-To: References: Message-ID: nice work all! - Christos On Aug 15, 2014, at 2:39 PM, Matthias Wessendorf wrote: > Hello team! > > 1.0.0.Beta2 is out and 1.0.0.Final is around the corner! > > The list of open JIRAs is looking really good (see [1]). The most tickets are around our quickstart demos and documentation. There are a few tickets that require commits to the UPS itself. Gabriel did a review of the UX/UI and filed three tickets (AGPUSH-934, AGPUSH-935 and AGPUSH-936) that he and Lukas will be working on. > > The release date for the 1.0.0.Final will be August 25th/26th and therefore I propose to do a 'code freeze' for the UPS around the 19th or 20th August to ensure its stability. However, in case something comes up (e.g. during testing), I think only 'blocker' or 'critical' fixes should be allowed to be merged during that time. Goal is to minimize risks! > > Once the UPS 1.0.0.Final is out, there are a few 1.0.x release planed to address things (if needed) and picking up new releases of our own dependencies (e.g. Keycloak) > > Any thoughts ? > > Greetings, Matthias > > [1] https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/f9f4e210/attachment.html From tolisemm at gmail.com Fri Aug 15 13:13:14 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Fri, 15 Aug 2014 20:13:14 +0300 Subject: [aerogear-dev] aerogear-js lock library dependencies Message-ID: Hi, After taking a look at the PR [1] that Matthias made on AeroGear JS, I have noticed that some of our library's dependencies have been changed. For instance, the version of the Vert.x javascript client used in our integration tests is 2.0.0.Final. However the new version is 2.1.2. The same happens with the Eclipse Paho MQTT WS JavaScript Client. Its API has been changed since Jan 29 so the AeroGear-JS notifier adapter needs to comply with these changes. I would suggest to lock the dependency versions and update our docs to point these specific versions (at least for the cases where the dependencies API is changed and AeroGear-JS code needs to be updated). Then we can open JIRA(S) and start updating the code. wdyt? [1]: https://github.com/aerogear/aerogear-js/pull/141 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/1d27b69f/attachment.html From lholmqui at redhat.com Fri Aug 15 13:31:21 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 15 Aug 2014 13:31:21 -0400 Subject: [aerogear-dev] aerogear-js lock library dependencies In-Reply-To: References: Message-ID: <8B26DEDE-149D-49F1-83D7-6E1AF242B66E@redhat.com> On Aug 15, 2014, at 1:13 PM, tolis emmanouilidis wrote: > Hi, > > After taking a look at the PR [1] that Matthias made on AeroGear JS, I have noticed that some of our library's dependencies have been changed. For instance, the version of the Vert.x javascript client used in our integration tests is 2.0.0.Final. However the new version is 2.1.2. The same happens with the Eclipse Paho MQTT WS JavaScript Client. Its API has been changed since Jan 29 so the AeroGear-JS notifier adapter needs to comply with these changes. > > I would suggest to lock the dependency versions and update our docs to point these specific versions (at least for the cases where the dependencies API is changed and AeroGear-JS code needs to be updated). Then we can open JIRA(S) and start updating the code. > that is probably a good idea. I know once things from push land slow down, we are going to look at re-working the integration tests. > wdyt? > > [1]: https://github.com/aerogear/aerogear-js/pull/141 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140815/5e1c7909/attachment.html From bruno at abstractj.org Fri Aug 15 15:52:06 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 15 Aug 2014 16:52:06 -0300 Subject: [aerogear-dev] Docker images for the Push quickstarts In-Reply-To: <36DC2420-FEBC-41D2-A324-29AAD22E2297@gmail.com> References: <20140814110900.GA32805@abstractj.org> <20140814132443.GB38097@abstractj.org> <20140815085413.GA65073@abstractj.org> <20140815131924.GC65073@abstractj.org> <36DC2420-FEBC-41D2-A324-29AAD22E2297@gmail.com> Message-ID: <20140815195206.GA75248@abstractj.org> Ahoy, done for both images AS7 and WildFly. On 2014-08-15, Christos Vasilakis wrote: > +1 with Daniel suggestion, let?s move on with that approach. > > - > Christos > > On Aug 15, 2014, at 4:19 PM, Bruno Oliveira wrote: > > > I'm +1 on it. > > > > What the others think? > > > > On 2014-08-15, Daniel Bevenius wrote: > >>> Ahoy, I've already added Dan's request to pre-download the Maven > >> dependencies and avoid the global warming. > >> Awesome! > >> > >> Regarding pre-creating an application to have the appId and master secret. > >> I think it is fine to have that as a manual step. Users still need to be > >> able to understand what they are doing. So the first step could be to start > >> the UPS image, log in and create a new application. Next step could be to > >> start a second image which contains the backed and when starting configure > >> it with the correct url to UPS and their newly created appId and master > >> secret. > >> > >> > >> > >> > >> > >> > >> On 15 August 2014 10:54, Bruno Oliveira wrote: > >> > >>> Ahoy, I've already added Dan's request to pre-download the Maven > >>> dependencies and > >>> avoid the global warming. > >>> > >>> On 2014-08-14, Daniel Passos wrote: > >>>> On Thu, Aug 14, 2014 at 11:33 AM, Daniel Bevenius < > >>> daniel.bevenius at gmail.com > >>>>> wrote: > >>>> > >>>>> This is really great and thanks working on this Bruno! > >>>>> > >>>>> Trying this out and I have a few questions. > >>>>> The server applications that are deployed are UPS and the > >>>>> jboss-mobile-contacts-picketlink-secured as far as I can tell. > >>>>> The configuration requires the configuration of the UnifiedPush server > >>> URL > >>>>> but this will only be used on this server by the > >>>>> jboss-mobile-contacts-picketlink-secured app. In the configuration we > >>> also > >>>>> have to specify the application id and the master secret which would > >>> not > >>>>> have been created yet as this is a fresh UPS installation. Or am I > >>> missing > >>>>> something here perhaps? > >>>>> > >>>> > >>>> IMHO we shouldn't add UPS on this image, only the quickstarts things. I > >>>> know the UPS is a pre req to use that, but we already have an image for > >>> it, > >>>> or you can create an instance on openshift. > >>>> > >>>> > >>>>> I'd really like it if we could resolve the maven dependencies before > >>>>> starting the image to save to have having them downloaded every time > >>> one > >>>>> start. For example, this would be a real time saver for reviewing PR. > >>>>> > >>>> > >>>> I can't see it as a problem but +1 > >>>> > >>>> > >>>>> I'll do some more testing tomorrow as I have some port forwarding issue > >>>>> locally at the moment. > >>>>> > >>>> > >>>> I can't find the webapp[1] on this imagem, maybe is a good idea add it. > >>>> > >>>> [1] > >>>> > >>> https://github.com/aerogear/aerogear-push-quickstarts/tree/master/client/contacts-mobile-webapp > >>>> > >>>> -- Passos > >>>> > >>>> > >>>>> On 14 August 2014 15:24, Bruno Oliveira wrote: > >>>>> > >>>>>> Thank you Passos. > >>>>>> > >>>>>> On 2014-08-14, Daniel Passos wrote: > >>>>>>> Hi Guys, > >>>>>>> > >>>>>>> The links were updated > >>>>>>> > >>>>>>> - AS7 > >>>>>>> > >>>>>> > >>> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-as7-dev > >>>>>>> > >>>>>>> - Wildfly > >>>>>>> > >>>>>> > >>> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-wildfly-dev > >>>>>>> > >>>>>>> @abstract I'm testing it > >>>>>>> > >>>>>>> -- Passos > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Thu, Aug 14, 2014 at 8:16 AM, Matthias Wessendorf < > >>> matzew at apache.org > >>>>>>> > >>>>>>> wrote: > >>>>>>> > >>>>>>>> Awesome! > >>>>>>>> Great work, Bruno! > >>>>>>>> > >>>>>>>> > >>>>>>>> On Thursday, August 14, 2014, Bruno Oliveira >>>> > >>>>>> wrote: > >>>>>>>> > >>>>>>>>> Good morning everyone, I need your feedback. I just build the > >>> initial > >>>>>>>>> version of docker images for quickstarts. > >>>>>>>>> > >>>>>>>>> - AS7: > >>>>>>>>> > >>>>>>>>> > >>>>>> > >>> https://github.com/abstractj/docker/tree/master/aerogear/as7/push-quickstarts-dev > >>>>>>>>> - Wildfly: > >>>>>>>>> > >>>>>>>>> > >>>>>> > >>> https://github.com/abstractj/docker/tree/master/aerogear/wildfly/push-quickstarts-dev > >>>>>>>>> > >>>>>>>>> Would be very appreciated if tell me what's missing. > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> abstractj > >>>>>>>>> PGP: 0x84DC9914 > >>>>>>>>> _______________________________________________ > >>>>>>>>> aerogear-dev mailing list > >>>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Sent from Gmail Mobile > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> aerogear-dev mailing list > >>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>> > >>>>>> > >>>>>>> _______________________________________________ > >>>>>>> aerogear-dev mailing list > >>>>>>> aerogear-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> abstractj > >>>>>> PGP: 0x84DC9914 > >>>>>> _______________________________________________ > >>>>>> aerogear-dev mailing list > >>>>>> aerogear-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > > > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Mon Aug 18 01:02:09 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 18 Aug 2014 07:02:09 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140818 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/3bec6e73/attachment.html From matzew at apache.org Mon Aug 18 05:05:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 11:05:55 +0200 Subject: [aerogear-dev] Push SDK versions Message-ID: hi, this week we will get our client SDKs for push upgraded to 1.0.0. Once the native (Android and iOS) versions are done, the Cordova SDK will be updated as well, to pick up the latest from Android and iOS. Any thoughts? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/f76a1cf4/attachment.html From edewit at redhat.com Mon Aug 18 05:08:17 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 18 Aug 2014 11:08:17 +0200 Subject: [aerogear-dev] Push SDK versions In-Reply-To: References: Message-ID: <7590A7C9-696E-4F44-8821-693BE8CB6B1E@redhat.com> Sounds like a plan ;) On 18 Aug,2014, at 11:05 , Matthias Wessendorf wrote: > hi, > > this week we will get our client SDKs for push upgraded to 1.0.0. > > Once the native (Android and iOS) versions are done, the Cordova SDK will be updated as well, to pick up the latest from Android and iOS. > > Any thoughts? > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/cd9174c0/attachment.html From cvasilak at gmail.com Mon Aug 18 06:26:23 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 18 Aug 2014 13:26:23 +0300 Subject: [aerogear-dev] Push SDK versions In-Reply-To: References: Message-ID: <72AE2A13-2313-4675-96D8-8744D9D9C711@gmail.com> On Aug 18, 2014, at 12:05 PM, Matthias Wessendorf wrote: > hi, > > this week we will get our client SDKs for push upgraded to 1.0.0. +1 started the process to tag and release to cocoapods of our iOS push-sdk > > Once the native (Android and iOS) versions are done, the Cordova SDK will be updated as well, to pick up the latest from Android and iOS. +1 > > Any thoughts? > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/2f455fec/attachment.html From matzew at apache.org Mon Aug 18 08:01:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 14:01:50 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> <96E5A52E-9917-4AFA-81C1-464D036DABD5@gmail.com> <20140725141114.GB14148@abstractj.org> Message-ID: Hi, the "aerogear-push-ios-registration" repo has been renamed to "aerogear-ios-push" https://github.com/aerogear/aerogear-ios-push https://issues.jboss.org/browse/AGIOS-241 -Matthias On Fri, Jul 25, 2014 at 4:22 PM, Matthias Wessendorf wrote: > > > > On Fri, Jul 25, 2014 at 4:11 PM, Bruno Oliveira > wrote: > >> Hi Corinne, >> >> I'm not against removing the prefix, but to keep the consistency, if the >> remove is called potatos-iOS, it must have the same name on Cocoapods. >> >> We discussed this during the F2F about getting rid of the prefix, but I'm >> not >> sure what has changed now to other team members. Regarding the argument >> of keeping it organized, that's not valid to me, is always possible to >> create a >> folder with all the projects inside. >> >> But if most of the team disagree, seems like our suggestion during the >> meeting is not valid anymore. >> > > * gh/ag/ag-foo -> feels redundant, so gh/ag/foo does make sense, yeah > ** forks... there is still the "forked from gh/ag/foo" > > * on java, we have APIs and JAR names, I'd think the aerogear name is > still visible there. > the jar for "gh/ag/foo", could still be named aearogear-foo-1.0.0 > (including the o.j.a packages) > * On JS we have namesspaces on the API (e.g. AG.Notifier) - on iOS we have > classes (AGBlah) > > And I now recall Bruno's original point: making it more interesting to > others, hence droppoing the name. > Even if the get rid of the ag-foo, and name if "foo", its fineprint does > not take away the aerogear brand. > > -Matthias > > >> >> >> On 2014-07-25, Corinne Krych wrote: >> > >> > On 25 Jul 2014, at 09:46, Sebastien Blanc wrote: >> > >> > > >> > > >> > > >> > > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych < >> corinnekrych at gmail.com> wrote: >> > > >> > > On 25 Jul 2014, at 09:13, Matthias Wessendorf >> wrote: >> > > >> > > > >> > > > >> > > > >> > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych < >> corinnekrych at gmail.com> wrote: >> > > > Hello Guys, >> > > > >> > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked >> about modularization. We agreed with Android team modularization is >> scheduled for 2.0. >> > > > >> > > > For iOS we have several actions: >> > > > >> > > > 1. rename existing repos (too bad we don?t follow well Android >> convention) >> > > > ? aerogear-ios-crypto >> > > > ? aerogear-ios-push (thanks passos for the suggestion) >> > > > ? aerogear-ios-otp >> > > > ? aerogear-ios-xcode-template >> > > > ? aerogear-ios-cookbook >> > > > >> > > > Since we?re talking about renaming, what about dropping ?arerogear? >> for the repo name? >> > > > >> > > > +1 makes sense >> > > >> > > >> > > It looks like we don?t have the same view here. Obviously if we go >> renaming we will have to change all the repos. With or without, >> coonsistency is key. >> > > >> > > My main motivation for dropping aerogear prefex was that ag is >> already present in the name of the organisation. Besides as we go with fine >> grained modularisation, our libs can be used independently, the naming >> without prefix is to enforce that. >> > > >> > > @passos and all others guys not in favor for dropping prefix, may I >> ask why? >> > > >> > > If we put GH and organization appart, will the name "AeroGear" >> appears anywhere in the lib name/pod when someone install it through >> cocoapods ? >> > > >> > >> > Yeap we?ll keep aerogear as a prefix for cocoapods >> > >> https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18 >> > >> > Good question: What about the other modules? >> > >> > > >> > > >> > > > >> > > > all those repos belong to aerogear organization anyway. Maybe >> removing the aerogear part will stress more the small libraries aspect. >> Maybe sth we already discussed but can?t remember/find it. wdyt? >> > > > >> > > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 >> version and will be marked deprecated. >> > > > But ?. don?t be scared new modules will replace them: >> > > > >> > > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease >> HTTP calls with pluggable request and response Serializers. Very very Draft >> version [3] with some cookbook recipe [4]. With this module we will work >> directly with NSURLSession (iOS foundation networking) instead of using >> AFNetworking. Sure Andrea will like it: no dependency :) >> > > > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all >> the good stuff like AccountManager, OAuth2 extensible adapters, fluid http >> post/get ... >> > > > ? aerogear-ios-storage usage of incrementalStorage to plug into >> Core Data >> > > > >> > > > >> > > > +1 all of that sounds awesome! >> > > > >> > > > >> > > > Those modules will be written in Swift code. We?ll test them both >> in iOS7 and iOS8. >> > > > >> > > > +1 on Swift! >> > > > >> > > > >> > > > 3. Cookbook recipes rpo >> > > > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook >> demos but with the move from 1.X to 2.) I think we should >> > > > * Swift demo naming convention add ?-swift? for Swift version like >> we did [5]. We should also append ?-objc? to other recipes to be consistent. >> > > > >> > > > yeah >> > > > >> > > > >> > > > 4. Differentiate Swift vs Objective-C libs >> > > > How to differenctiate Swift code. Specially for aerogear-ios-push >> which will be declined in 2 versions? One suggestion from Matthias was to >> have 2 separate branches. >> > > > master -> objc-c >> > > > until iOS8 is released and stable. >> > > > I?m +1 with that idea. >> > > > >> > > > yeah, let's have ObjC on master now; >> > > > The master can, later this year, contain the Swift lib, and we move >> ObjC to be deprecated as soon as we do have iOS8 (~September) >> > > > >> > > > >> > > > Let me know if you have suggestions/objections. When we reach an >> agreement, I?ll create associated JIRA. >> > > > >> > > > ++ >> > > > Corinne >> > > > >> > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 >> > > > [2] >> http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt >> > > > [3] https://github.com/corinnekrych/aerogear-ios-http >> > > > [4] https://github.com/corinnekrych/Weather >> > > > [5] >> https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift >> > > > _______________________________________________ >> > > > aerogear-dev mailing list >> > > > aerogear-dev at lists.jboss.org >> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > >> > > > >> > > > >> > > > -- >> > > > Matthias Wessendorf >> > > > >> > > > blog: http://matthiaswessendorf.wordpress.com/ >> > > > sessions: http://www.slideshare.net/mwessendorf >> > > > twitter: http://twitter.com/mwessendorf >> > > > _______________________________________________ >> > > > aerogear-dev mailing list >> > > > aerogear-dev at lists.jboss.org >> > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/f42e2c4e/attachment-0001.html From corinnekrych at gmail.com Mon Aug 18 08:23:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 18 Aug 2014 14:23:05 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> <96E5A52E-9917-4AFA-81C1-464D036DABD5@gmail.com> <20140725141114.GB14148@abstractj.org> Message-ID: On 18 Aug 2014, at 14:01, Matthias Wessendorf wrote: > Hi, > > the "aerogear-push-ios-registration" repo has been renamed to "aerogear-ios-push" > > https://github.com/aerogear/aerogear-ios-push > https://issues.jboss.org/browse/AGIOS-241 Thanks! > > -Matthias > > > > > On Fri, Jul 25, 2014 at 4:22 PM, Matthias Wessendorf wrote: > > > > On Fri, Jul 25, 2014 at 4:11 PM, Bruno Oliveira wrote: > Hi Corinne, > > I'm not against removing the prefix, but to keep the consistency, if the > remove is called potatos-iOS, it must have the same name on Cocoapods. > > We discussed this during the F2F about getting rid of the prefix, but I'm not > sure what has changed now to other team members. Regarding the argument > of keeping it organized, that's not valid to me, is always possible to create a > folder with all the projects inside. > > But if most of the team disagree, seems like our suggestion during the > meeting is not valid anymore. > > * gh/ag/ag-foo -> feels redundant, so gh/ag/foo does make sense, yeah > ** forks... there is still the "forked from gh/ag/foo" > > * on java, we have APIs and JAR names, I'd think the aerogear name is still visible there. > the jar for "gh/ag/foo", could still be named aearogear-foo-1.0.0 (including the o.j.a packages) > * On JS we have namesspaces on the API (e.g. AG.Notifier) - on iOS we have classes (AGBlah) > > And I now recall Bruno's original point: making it more interesting to others, hence droppoing the name. > Even if the get rid of the ag-foo, and name if "foo", its fineprint does not take away the aerogear brand. > > -Matthias > > > > On 2014-07-25, Corinne Krych wrote: > > > > On 25 Jul 2014, at 09:46, Sebastien Blanc wrote: > > > > > > > > > > > > > > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych wrote: > > > > > > On 25 Jul 2014, at 09:13, Matthias Wessendorf wrote: > > > > > > > > > > > > > > > > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych wrote: > > > > Hello Guys, > > > > > > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0. > > > > > > > > For iOS we have several actions: > > > > > > > > 1. rename existing repos (too bad we don?t follow well Android convention) > > > > ? aerogear-ios-crypto > > > > ? aerogear-ios-push (thanks passos for the suggestion) > > > > ? aerogear-ios-otp > > > > ? aerogear-ios-xcode-template > > > > ? aerogear-ios-cookbook > > > > > > > > Since we?re talking about renaming, what about dropping ?arerogear? for the repo name? > > > > > > > > +1 makes sense > > > > > > > > > It looks like we don?t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key. > > > > > > My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that. > > > > > > @passos and all others guys not in favor for dropping prefix, may I ask why? > > > > > > If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ? > > > > > > > Yeap we?ll keep aerogear as a prefix for cocoapods > > https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18 > > > > Good question: What about the other modules? > > > > > > > > > > > > > > > > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? > > > > > > > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version and will be marked deprecated. > > > > But ?. don?t be scared new modules will replace them: > > > > > > > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :) > > > > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ... > > > > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > > > > > > > > > > > > +1 all of that sounds awesome! > > > > > > > > > > > > Those modules will be written in Swift code. We?ll test them both in iOS7 and iOS8. > > > > > > > > +1 on Swift! > > > > > > > > > > > > 3. Cookbook recipes rpo > > > > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should > > > > * Swift demo naming convention add ?-swift? for Swift version like we did [5]. We should also append ?-objc? to other recipes to be consistent. > > > > > > > > yeah > > > > > > > > > > > > 4. Differentiate Swift vs Objective-C libs > > > > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches. > > > > master -> objc-c > > > > until iOS8 is released and stable. > > > > I?m +1 with that idea. > > > > > > > > yeah, let's have ObjC on master now; > > > > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September) > > > > > > > > > > > > Let me know if you have suggestions/objections. When we reach an agreement, I?ll create associated JIRA. > > > > > > > > ++ > > > > Corinne > > > > > > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > > > > [2]http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > > > > [3] https://github.com/corinnekrych/aerogear-ios-http > > > > [4] https://github.com/corinnekrych/Weather > > > > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Mon Aug 18 09:11:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 15:11:02 +0200 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next Message-ID: Hello, as mentioned in [1] we should have a code-freeze period of a few days before we do the final release. Release for UPS.1.0.0.Final date will be August 26th. I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd like to create a 1.0.0.Final tag (or a branch) and only 'blocker' or 'critical' fixes should be allowed to be merged during that time (to that particular branch/tag). Basic goal: minimize risks! (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all around Quickstarts and our docs, see [2]) Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for follow-up releases, as needed (see [3]). The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER branch as well. Moving forward to our next 1.1.0 UPS release, on MASTER, we will be working on new features, like: * More analytics * More mobile network (Windows, Kindle, etc) * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) * Alternative Datastores (like Mongo) ? Any thoughts ? -Matthias [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html [2] https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/5d3d9b34/attachment.html From matzew at apache.org Mon Aug 18 09:13:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 15:13:37 +0200 Subject: [aerogear-dev] AeroGear.org - Download of the UPS release bundle Message-ID: Hello, starting w/ the 1.0.0.Final release we will have a bundle to download the UPS bits (see [1]). I am wondering where to put the bundle on the homepage ? Should we create a "aerogear.org/dist " folder for that ? Let me know what's best :-) -Matthias [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/350 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/cca9351c/attachment.html From lholmqui at redhat.com Mon Aug 18 09:17:46 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 18 Aug 2014 09:17:46 -0400 Subject: [aerogear-dev] AeroGear.org - Download of the UPS release bundle In-Reply-To: References: Message-ID: On Aug 18, 2014, at 9:13 AM, Matthias Wessendorf wrote: > Hello, > > starting w/ the 1.0.0.Final release we will have a bundle to download the UPS bits (see [1]). > > I am wondering where to put the bundle on the homepage ? > Should we create a "aerogear.org/dist " folder for that ? with the github release button thingy, we can also include binaries for download, i suggest that we use that and just link to it on the website > > Let me know what's best :-) > > -Matthias > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/350 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/b307accc/attachment.html From matzew at apache.org Mon Aug 18 09:25:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 15:25:10 +0200 Subject: [aerogear-dev] AeroGear.org - Download of the UPS release bundle In-Reply-To: References: Message-ID: On Mon, Aug 18, 2014 at 3:17 PM, Lucas Holmquist wrote: > > On Aug 18, 2014, at 9:13 AM, Matthias Wessendorf > wrote: > > Hello, > > starting w/ the 1.0.0.Final release we will have a bundle to download the > UPS bits (see [1]). > > I am wondering where to put the bundle on the homepage ? > Should we create a "aerogear.org/dist " folder for that ? > > > with the github release button thingy, we can also include binaries for > download, i suggest that we use that and just link to it on the website > oh, I can upload files ? that would be extremely cool > > > > Let me know what's best :-) > > -Matthias > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/350 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/4c491a95/attachment-0001.html From daniel at passos.me Mon Aug 18 09:26:27 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 18 Aug 2014 10:26:27 -0300 Subject: [aerogear-dev] AeroGear Android Push 1.0.0 - Staged Message-ID: Hey Everyone, AeroGear Android Push 1.0.0 was staged on Nexus. \o/ We planned press the button and release it to maven central next wednesday Feel free to test it[1]! [1] https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3723/ -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/0110b57b/attachment.html From supittma at redhat.com Mon Aug 18 09:27:19 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 18 Aug 2014 09:27:19 -0400 Subject: [aerogear-dev] Android integration tests and modules Message-ID: <53F1FF37.30100@redhat.com> Ideally we would like to quit using the Robolectric Android stubs and begin using Google's Android APIs for linking and testing. This is one of the reasons that the unit tests havn't been brought over to the modules YET. Over the weekend (between family duties and internet issues) I did a lot of research and coding towards moving our tests into the module packages. With the release of X86 emulators and stability Genymotion, I think that using solely integration test projects for our testing is now doable. The Android SDK (current, ANT/Eclipse based) way is to have a separate test project. The Android SDK (future Gradle based) way is to have your tests in a test package. The maven way (Maven based Android builds) is to have a parent project with two children: one child being code and the other child being tests. Currently we have one BIG integration test project which contains all of our integration tests. I think that we should move the tests out of our monolithic project and into the modules where they probably belong. I also propose that we make each module in the two child project pattern that then Maven based builds recommend. When it is time to move to Gradle then we can just fiddle with sourceSets and kill the Maven build. Wdyt? -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From daniel.bevenius at gmail.com Mon Aug 18 09:31:23 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 18 Aug 2014 15:31:23 +0200 Subject: [aerogear-dev] Android integration tests and modules In-Reply-To: <53F1FF37.30100@redhat.com> References: <53F1FF37.30100@redhat.com> Message-ID: +1 One the two child project pattern. On 18 August 2014 15:27, Summers Pittman wrote: > Ideally we would like to quit using the Robolectric Android stubs and > begin using Google's Android APIs for linking and testing. This is one > of the reasons that the unit tests havn't been brought over to the > modules YET. Over the weekend (between family duties and internet > issues) I did a lot of research and coding towards moving our tests into > the module packages. With the release of X86 emulators and stability > Genymotion, I think that using solely integration test projects for our > testing is now doable. > > The Android SDK (current, ANT/Eclipse based) way is to have a separate > test project. The Android SDK (future Gradle based) way is to have your > tests in a test package. The maven way (Maven based Android builds) is > to have a parent project with two children: one child being code and the > other child being tests. > > Currently we have one BIG integration test project which contains all of > our integration tests. I think that we should move the tests out of our > monolithic project and into the modules where they probably belong. I > also propose that we make each module in the two child project pattern > that then Maven based builds recommend. When it is time to move to > Gradle then we can just fiddle with sourceSets and kill the Maven build. > > Wdyt? > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/447dca87/attachment.html From daniel.bevenius at gmail.com Mon Aug 18 09:31:48 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 18 Aug 2014 15:31:48 +0200 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next In-Reply-To: References: Message-ID: Sounds good. On 18 August 2014 15:11, Matthias Wessendorf wrote: > Hello, > > as mentioned in [1] we should have a code-freeze period of a few days > before we do the final release. > Release for UPS.1.0.0.Final date will be August 26th. > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd like > to create a 1.0.0.Final tag (or a branch) and only > 'blocker' or 'critical' fixes should be allowed to be merged during that > time (to that particular branch/tag). > Basic goal: minimize risks! > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all around > Quickstarts and our docs, see [2]) > > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for > follow-up releases, as needed (see [3]). > The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER branch > as well. > > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be > working on new features, like: > * More analytics > * More mobile network (Windows, Kindle, etc) > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) > * Alternative Datastores (like Mongo) ? > > > Any thoughts ? > -Matthias > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html > [2] > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/0142616d/attachment.html From daniel.bevenius at gmail.com Mon Aug 18 09:32:12 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 18 Aug 2014 15:32:12 +0200 Subject: [aerogear-dev] AeroGear Android Push 1.0.0 - Staged In-Reply-To: References: Message-ID: Nice, I'll try it out. On 18 August 2014 15:26, Daniel Passos wrote: > Hey Everyone, > > AeroGear Android Push 1.0.0 was staged on Nexus. \o/ > > We planned press the button and release it to maven central next wednesday > > > Feel free to test it[1]! > > [1] > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3723/ > > -- Passos > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/52754814/attachment.html From matzew at apache.org Mon Aug 18 09:58:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 15:58:52 +0200 Subject: [aerogear-dev] Android integration tests and modules In-Reply-To: References: <53F1FF37.30100@redhat.com> Message-ID: sounds good with me! On Mon, Aug 18, 2014 at 3:31 PM, Daniel Bevenius wrote: > +1 One the two child project pattern. > > > On 18 August 2014 15:27, Summers Pittman wrote: > >> Ideally we would like to quit using the Robolectric Android stubs and >> begin using Google's Android APIs for linking and testing. This is one >> of the reasons that the unit tests havn't been brought over to the >> modules YET. Over the weekend (between family duties and internet >> issues) I did a lot of research and coding towards moving our tests into >> the module packages. With the release of X86 emulators and stability >> Genymotion, I think that using solely integration test projects for our >> testing is now doable. >> >> The Android SDK (current, ANT/Eclipse based) way is to have a separate >> test project. The Android SDK (future Gradle based) way is to have your >> tests in a test package. The maven way (Maven based Android builds) is >> to have a parent project with two children: one child being code and the >> other child being tests. >> >> Currently we have one BIG integration test project which contains all of >> our integration tests. I think that we should move the tests out of our >> monolithic project and into the modules where they probably belong. I >> also propose that we make each module in the two child project pattern >> that then Maven based builds recommend. When it is time to move to >> Gradle then we can just fiddle with sourceSets and kill the Maven build. >> >> Wdyt? >> >> -- >> Summers Pittman >> >>Phone:404 941 4698 >> >>Java is my crack. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/b75bb972/attachment-0001.html From cvasilak at gmail.com Mon Aug 18 10:23:54 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 18 Aug 2014 17:23:54 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Mon Aug 18 14:22:16 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-18-14.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-18-14.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-18-14.00.log.html On Aug 18, 2014, at 8:02 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140818 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/e274966e/attachment.html From matzew at apache.org Mon Aug 18 10:57:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 16:57:22 +0200 Subject: [aerogear-dev] AeroGear Android Push 1.0.0 - Staged In-Reply-To: References: Message-ID: -1 on this The 1.0.0 tag does not contain the fix from PR #8 -Matthias [1] https://github.com/aerogear/aerogear-android-push/blob/1.0.0/pom.xml [2] https://github.com/aerogear/aerogear-android-push/pull/8/files On Mon, Aug 18, 2014 at 3:32 PM, Daniel Bevenius wrote: > Nice, I'll try it out. > > > On 18 August 2014 15:26, Daniel Passos wrote: > >> Hey Everyone, >> >> AeroGear Android Push 1.0.0 was staged on Nexus. \o/ >> >> We planned press the button and release it to maven central next >> wednesday >> >> Feel free to test it[1]! >> >> [1] >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3723/ >> >> -- Passos >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/3cb84bf3/attachment.html From cvasilak at gmail.com Mon Aug 18 12:05:02 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 18 Aug 2014 19:05:02 +0300 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next In-Reply-To: References: Message-ID: sounds good Matthias - Christos On Aug 18, 2014, at 4:11 PM, Matthias Wessendorf wrote: > Hello, > > as mentioned in [1] we should have a code-freeze period of a few days before we do the final release. > Release for UPS.1.0.0.Final date will be August 26th. > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd like to create a 1.0.0.Final tag (or a branch) and only > 'blocker' or 'critical' fixes should be allowed to be merged during that time (to that particular branch/tag). > Basic goal: minimize risks! > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all around Quickstarts and our docs, see [2]) > > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for follow-up releases, as needed (see [3]). > The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER branch as well. > > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be working on new features, like: > * More analytics > * More mobile network (Windows, Kindle, etc) > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) > * Alternative Datastores (like Mongo) ? > > > Any thoughts ? > -Matthias > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html > [2] https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/5926bc46/attachment.html From bruno at abstractj.org Mon Aug 18 12:08:45 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 18 Aug 2014 13:08:45 -0300 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 Message-ID: <20140818160845.GA93150@abstractj.org> Good morning, AeroGear Crypto was staged at: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 I'm planning to release it on Wednesday. -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Mon Aug 18 12:10:58 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 18 Aug 2014 18:10:58 +0200 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: <20140818160845.GA93150@abstractj.org> References: <20140818160845.GA93150@abstractj.org> Message-ID: Yay! On 18 August 2014 18:08, Bruno Oliveira wrote: > Good morning, AeroGear Crypto was staged at: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 > > I'm planning to release it on Wednesday. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/98d546d6/attachment.html From daniel at passos.me Mon Aug 18 12:21:13 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 18 Aug 2014 13:21:13 -0300 Subject: [aerogear-dev] AeroGear Android Push 1.0.0 - Staged In-Reply-To: References: Message-ID: Sorry about that. I just fixed it and send a new one to JBoss Nexus[1] [1] https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3727/ -- Passos On Mon, Aug 18, 2014 at 11:57 AM, Matthias Wessendorf wrote: > -1 on this > > The 1.0.0 tag does not contain the fix from PR #8 > > -Matthias > > > [1] https://github.com/aerogear/aerogear-android-push/blob/1.0.0/pom.xml > [2] https://github.com/aerogear/aerogear-android-push/pull/8/files > > > On Mon, Aug 18, 2014 at 3:32 PM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Nice, I'll try it out. >> >> >> On 18 August 2014 15:26, Daniel Passos wrote: >> >>> Hey Everyone, >>> >>> AeroGear Android Push 1.0.0 was staged on Nexus. \o/ >>> >>> We planned press the button and release it to maven central next >>> wednesday >>> >>> Feel free to test it[1]! >>> >>> [1] >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3723/ >>> >>> -- Passos >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/264d26ad/attachment-0001.html From matzew at apache.org Mon Aug 18 13:34:20 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 19:34:20 +0200 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: References: <20140818160845.GA93150@abstractj.org> Message-ID: Hi Bruno, +1 on this release. I have tested UPS w/ the 0.1.5 version (on WildFly 8.1). The PKCS12 class works as expected when creating or updating an iOS Variant! -Matthias On Mon, Aug 18, 2014 at 6:10 PM, Daniel Bevenius wrote: > Yay! > > > On 18 August 2014 18:08, Bruno Oliveira wrote: > >> Good morning, AeroGear Crypto was staged at: >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 >> >> I'm planning to release it on Wednesday. >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/b636c375/attachment.html From matzew at apache.org Mon Aug 18 13:56:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 18 Aug 2014 19:56:37 +0200 Subject: [aerogear-dev] AeroGear.org - Download of the UPS release bundle In-Reply-To: References: Message-ID: Alright, I tested it and it works great. I could upload both zip and tarball. Great tip, Luke! With that, the update on the AeroGear homepage is also easy :-) We just point to "latest" and simply update only the version string, on the link (instead of the link itself) -Matthias On Mon, Aug 18, 2014 at 3:25 PM, Matthias Wessendorf wrote: > > > > On Mon, Aug 18, 2014 at 3:17 PM, Lucas Holmquist > wrote: > >> >> On Aug 18, 2014, at 9:13 AM, Matthias Wessendorf >> wrote: >> >> Hello, >> >> starting w/ the 1.0.0.Final release we will have a bundle to download the >> UPS bits (see [1]). >> >> I am wondering where to put the bundle on the homepage ? >> Should we create a "aerogear.org/dist " folder for that ? >> >> >> with the github release button thingy, we can also include binaries for >> download, i suggest that we use that and just link to it on the website >> > > oh, I can upload files ? that would be extremely cool > > >> >> >> >> Let me know what's best :-) >> >> -Matthias >> >> [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/350 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/f951ad2f/attachment.html From bruno at abstractj.org Mon Aug 18 15:22:00 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 18 Aug 2014 16:22:00 -0300 Subject: [aerogear-dev] Android integration tests and modules In-Reply-To: <53F1FF37.30100@redhat.com> References: <53F1FF37.30100@redhat.com> Message-ID: <20140818192159.GA99093@abstractj.org> +1 On 2014-08-18, Summers Pittman wrote: > Ideally we would like to quit using the Robolectric Android stubs and > begin using Google's Android APIs for linking and testing. This is one > of the reasons that the unit tests havn't been brought over to the > modules YET. Over the weekend (between family duties and internet > issues) I did a lot of research and coding towards moving our tests into > the module packages. With the release of X86 emulators and stability > Genymotion, I think that using solely integration test projects for our > testing is now doable. > > The Android SDK (current, ANT/Eclipse based) way is to have a separate > test project. The Android SDK (future Gradle based) way is to have your > tests in a test package. The maven way (Maven based Android builds) is > to have a parent project with two children: one child being code and the > other child being tests. > > Currently we have one BIG integration test project which contains all of > our integration tests. I think that we should move the tests out of our > monolithic project and into the modules where they probably belong. I > also propose that we make each module in the two child project pattern > that then Maven based builds recommend. When it is time to move to > Gradle then we can just fiddle with sourceSets and kill the Maven build. > > Wdyt? > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Mon Aug 18 15:34:30 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 18 Aug 2014 16:34:30 -0300 Subject: [aerogear-dev] AeroGear.org - Download of the UPS release bundle In-Reply-To: References: Message-ID: <20140818193430.GA99480@abstractj.org> On 2014-08-18, Lucas Holmquist wrote: > > On Aug 18, 2014, at 9:13 AM, Matthias Wessendorf wrote: > > > Hello, > > > > starting w/ the 1.0.0.Final release we will have a bundle to download the UPS bits (see [1]). > > > > I am wondering where to put the bundle on the homepage ? > > Should we create a "aerogear.org/dist " folder for that ? > > with the github release button thingy, we can also include binaries for download, i suggest that we use that and just link to it on the website > +1, please > > > > > Let me know what's best :-) > > > > -Matthias > > > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/350 > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From supittma at redhat.com Mon Aug 18 16:55:26 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 18 Aug 2014 16:55:26 -0400 Subject: [aerogear-dev] Android integration tests and modules In-Reply-To: <53F1FF37.30100@redhat.com> References: <53F1FF37.30100@redhat.com> Message-ID: <53F2683E.5030503@redhat.com> On 08/18/2014 09:27 AM, Summers Pittman wrote: > Ideally we would like to quit using the Robolectric Android stubs and > begin using Google's Android APIs for linking and testing. This is one > of the reasons that the unit tests havn't been brought over to the > modules YET. Over the weekend (between family duties and internet > issues) I did a lot of research and coding towards moving our tests into > the module packages. With the release of X86 emulators and stability > Genymotion, I think that using solely integration test projects for our > testing is now doable. > > The Android SDK (current, ANT/Eclipse based) way is to have a separate > test project. The Android SDK (future Gradle based) way is to have your > tests in a test package. The maven way (Maven based Android builds) is > to have a parent project with two children: one child being code and the > other child being tests. > > Currently we have one BIG integration test project which contains all of > our integration tests. I think that we should move the tests out of our > monolithic project and into the modules where they probably belong. I > also propose that we make each module in the two child project pattern > that then Maven based builds recommend. When it is time to move to > Gradle then we can just fiddle with sourceSets and kill the Maven build. > > Wdyt? > Here is an example of what I think things should be like. (Still a bit of a work in progress). https://github.com/secondsun/aerogear-android-store/tree/multiproject To build the parent project you need a adb device connected to run the tests. If you prefer you can just build the library subproject. Perhaps there should be a different way to skip testing? -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From supittma at redhat.com Mon Aug 18 16:57:33 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 18 Aug 2014 16:57:33 -0400 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next In-Reply-To: References: Message-ID: <53F268BD.2010505@redhat.com> On 08/18/2014 09:11 AM, Matthias Wessendorf wrote: > Hello, > > as mentioned in [1] we should have a code-freeze period of a few days > before we do the final release. > Release for UPS.1.0.0.Final date will be August 26th. > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd > like to create a 1.0.0.Final tag (or a branch) and only > 'blocker' or 'critical' fixes should be allowed to be merged during > that time (to that particular branch/tag). > Basic goal: minimize risks! > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all > around Quickstarts and our docs, see [2]) > > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch > for follow-up releases, as needed (see [3]). > The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER > branch as well. > > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be > working on new features, like: > * More analytics +1 in principle, which are you thinking of? > * More mobile network (Windows, Kindle, etc) +1 > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) Can you be more specific? What problems/shortcomings are we trying to solve? > * Alternative Datastores (like Mongo) ? What do we get from Mongo other than to say "we support mongo"? > > > Any thoughts ? > -Matthias > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html > [2] > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140818/3628101b/attachment-0001.html From supittma at redhat.com Mon Aug 18 16:58:42 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 18 Aug 2014 16:58:42 -0400 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: <20140818160845.GA93150@abstractj.org> References: <20140818160845.GA93150@abstractj.org> Message-ID: <53F26902.9060407@redhat.com> On 08/18/2014 12:08 PM, Bruno Oliveira wrote: > Good morning, AeroGear Crypto was staged at: > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 > > I'm planning to release it on Wednesday. Bug me tomorrow and I will run the Android projects against it. > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From cvasilak at gmail.com Tue Aug 19 00:35:29 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 19 Aug 2014 07:35:29 +0300 Subject: [aerogear-dev] Android integration tests and modules In-Reply-To: <53F2683E.5030503@redhat.com> References: <53F1FF37.30100@redhat.com> <53F2683E.5030503@redhat.com> Message-ID: <0FB19803-6B8C-4FF2-9281-33B8BC5B874B@gmail.com> On Aug 18, 2014, at 11:55 PM, Summers Pittman wrote: > On 08/18/2014 09:27 AM, Summers Pittman wrote: >> Ideally we would like to quit using the Robolectric Android stubs and >> begin using Google's Android APIs for linking and testing. This is one >> of the reasons that the unit tests havn't been brought over to the >> modules YET. Over the weekend (between family duties and internet >> issues) I did a lot of research and coding towards moving our tests into >> the module packages. With the release of X86 emulators and stability >> Genymotion, I think that using solely integration test projects for our >> testing is now doable. nice! >> >> The Android SDK (current, ANT/Eclipse based) way is to have a separate >> test project. The Android SDK (future Gradle based) way is to have your >> tests in a test package. The maven way (Maven based Android builds) is >> to have a parent project with two children: one child being code and the >> other child being tests. >> >> Currently we have one BIG integration test project which contains all of >> our integration tests. I think that we should move the tests out of our >> monolithic project and into the modules where they probably belong. I >> also propose that we make each module in the two child project pattern >> that then Maven based builds recommend. When it is time to move to >> Gradle then we can just fiddle with sourceSets and kill the Maven build. >> +1 sounds good! thanks for the heads up - Christos >> Wdyt? >> > > Here is an example of what I think things should be like. (Still a bit > of a work in progress). > > https://github.com/secondsun/aerogear-android-store/tree/multiproject > > To build the parent project you need a adb device connected to run the > tests. If you prefer you can just build the library subproject. > Perhaps there should be a different way to skip testing? > > -- > Summers Pittman >>> Phone:404 941 4698 >>> Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Aug 19 02:51:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 19 Aug 2014 08:51:48 +0200 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next In-Reply-To: <53F268BD.2010505@redhat.com> References: <53F268BD.2010505@redhat.com> Message-ID: Hi Summers! Thanks for your feedback, some comments inline On Mon, Aug 18, 2014 at 10:57 PM, Summers Pittman wrote: > On 08/18/2014 09:11 AM, Matthias Wessendorf wrote: > > Hello, > > as mentioned in [1] we should have a code-freeze period of a few days > before we do the final release. > Release for UPS.1.0.0.Final date will be August 26th. > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd like > to create a 1.0.0.Final tag (or a branch) and only > 'blocker' or 'critical' fixes should be allowed to be merged during that > time (to that particular branch/tag). > Basic goal: minimize risks! > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all > around Quickstarts and our docs, see [2]) > > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for > follow-up releases, as needed (see [3]). > The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER > branch as well. > > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be > working on new features, like: > * More analytics > > +1 in principle, which are you thinking of? > e.g. app opened, app opened due to push. like we discussed at the Face2Face: http://oksoclap.com/p/jbrS1EHWkI Some of the "UPS.next" items are already captured in JIRA, some not. Once the 1.0.0.Final is out, I will have more time to create more JIRAs for 1.1.x > > * More mobile network (Windows, Kindle, etc) > > +1 > > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) > > Can you be more specific? What problems/shortcomings are we trying to > solve? > As discussed in the above oksoclap, this might be lower priority. Nothing specific planed here, besides updating to the latest specs, if needed. For instance the concurrency utils from EE7 could be an option for us to get rid of async. > > * Alternative Datastores (like Mongo) ? > > What do we get from Mongo other than to say "we support mongo"? > yeah, I am not sure here too :-) Mongo was a request from the mailing list early 2014. At face2face, in a phone call, Emmanuel suggested Hibernate OGM, so this *might* be something we do, or not. Currently we have these JIRAs for 1.1.x: https://issues.jboss.org/browse/AGPUSH/fixforversion/12323762/ and based on the clap, some more will follow, but that happens once the 1.0.0 is out :-) Greetings, Matthias > > > Any thoughts ? > -Matthias > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html > > [2] > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/b79effd2/attachment.html From matzew at apache.org Tue Aug 19 04:05:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 19 Aug 2014 10:05:27 +0200 Subject: [aerogear-dev] AeroGear Android Push 1.0.0 - Staged In-Reply-To: References: Message-ID: +1 on this release! I have tested the new staging repo w/ the "HelloWorld" example against master of UPS on WF8.1: works perfectly fine On Mon, Aug 18, 2014 at 6:21 PM, Daniel Passos wrote: > Sorry about that. > > I just fixed it and send a new one to JBoss Nexus[1] > > [1] > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3727/ > > -- Passos > > > On Mon, Aug 18, 2014 at 11:57 AM, Matthias Wessendorf > wrote: > >> -1 on this >> >> The 1.0.0 tag does not contain the fix from PR #8 >> >> -Matthias >> >> >> [1] https://github.com/aerogear/aerogear-android-push/blob/1.0.0/pom.xml >> [2] https://github.com/aerogear/aerogear-android-push/pull/8/files >> >> >> On Mon, Aug 18, 2014 at 3:32 PM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Nice, I'll try it out. >>> >>> >>> On 18 August 2014 15:26, Daniel Passos wrote: >>> >>>> Hey Everyone, >>>> >>>> AeroGear Android Push 1.0.0 was staged on Nexus. \o/ >>>> >>>> We planned press the button and release it to maven central next >>>> wednesday >>>> >>>> Feel free to test it[1]! >>>> >>>> [1] >>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3723/ >>>> >>>> -- Passos >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/936997c6/attachment-0001.html From matzew at apache.org Tue Aug 19 04:38:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 19 Aug 2014 10:38:56 +0200 Subject: [aerogear-dev] New User List Message-ID: Hi, a while ago we had the discussion to have a user list, versus only a -dev list. Before our Face2Face meeting this list got created. I have finished configuration (e.g. welcome text) For user specific questions (versus developement mode), we are happy to announce this new list: http://lists.jboss.org/pipermail/aerogear-users/ -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/18b0b89a/attachment.html From cvasilak at gmail.com Tue Aug 19 09:20:51 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 19 Aug 2014 16:20:51 +0300 Subject: [aerogear-dev] AeroGear iOS Push SDK 1.0.0 - released Message-ID: Hi all, happy to announce the 1.0.0 release of our iOS push-sdk[1]. No major changes since our last release (0.9.1), apart from some documentation polishes. Already, the SDK is published on cocoapods [2] for easily consumption and our demos and quickstarts[3][4] have been updated to use it. To get started, check out our newly updated push tutorial here [5] Enjoy and spread the love! - Christos [1] https://github.com/aerogear/aerogear-ios-push [2] http://cocoapods.org/?q=AeroGear-Push [3] https://github.com/aerogear/aerogear-push-quickstarts [4] https://github.com/aerogear/aerogear-push-ios-demo.git [5] http://aerogear.org/docs/unifiedpush/aerogear-push-ios/ From daniel.bevenius at gmail.com Tue Aug 19 09:33:48 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 19 Aug 2014 15:33:48 +0200 Subject: [aerogear-dev] AeroGear iOS Push SDK 1.0.0 - released In-Reply-To: References: Message-ID: Nice! On 19 August 2014 15:20, Christos Vasilakis wrote: > Hi all, > > happy to announce the 1.0.0 release of our iOS push-sdk[1]. No major > changes since our last release (0.9.1), apart from some documentation > polishes. Already, the SDK is published on cocoapods [2] for easily > consumption and our demos and quickstarts[3][4] have been updated to use it. > > To get started, check out our newly updated push tutorial here [5] > > Enjoy and spread the love! > > - > Christos > > > [1] https://github.com/aerogear/aerogear-ios-push > [2] http://cocoapods.org/?q=AeroGear-Push > [3] https://github.com/aerogear/aerogear-push-quickstarts > [4] https://github.com/aerogear/aerogear-push-ios-demo.git > [5] http://aerogear.org/docs/unifiedpush/aerogear-push-ios/ > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/55bf2f20/attachment.html From daniel at passos.me Tue Aug 19 09:47:41 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 19 Aug 2014 10:47:41 -0300 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: <53F26902.9060407@redhat.com> References: <20140818160845.GA93150@abstractj.org> <53F26902.9060407@redhat.com> Message-ID: No android *classifier* found -- Passos On Mon, Aug 18, 2014 at 5:58 PM, Summers Pittman wrote: > On 08/18/2014 12:08 PM, Bruno Oliveira wrote: > > Good morning, AeroGear Crypto was staged at: > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 > > > > I'm planning to release it on Wednesday. > > Bug me tomorrow and I will run the Android projects against it. > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/35768a3b/attachment.html From daniel at passos.me Tue Aug 19 09:48:48 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 19 Aug 2014 10:48:48 -0300 Subject: [aerogear-dev] AeroGear.org - Download of the UPS release bundle In-Reply-To: <20140818193430.GA99480@abstractj.org> References: <20140818193430.GA99480@abstractj.org> Message-ID: +1 On Mon, Aug 18, 2014 at 4:34 PM, Bruno Oliveira wrote: > On 2014-08-18, Lucas Holmquist wrote: > > > > On Aug 18, 2014, at 9:13 AM, Matthias Wessendorf > wrote: > > > > > Hello, > > > > > > starting w/ the 1.0.0.Final release we will have a bundle to download > the UPS bits (see [1]). > > > > > > I am wondering where to put the bundle on the homepage ? > > > Should we create a "aerogear.org/dist " folder for that ? > > > > with the github release button thingy, we can also include binaries for > download, i suggest that we use that and just link to it on the website > > > > +1, please > > > > > > > > > Let me know what's best :-) > > > > > > -Matthias > > > > > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/350 > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/e12ff681/attachment.html From bruno at abstractj.org Tue Aug 19 10:02:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 19 Aug 2014 11:02:21 -0300 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: References: <20140818160845.GA93150@abstractj.org> <53F26902.9060407@redhat.com> Message-ID: <20140819140221.GA44453@abstractj.org> This is the new repository: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3734/org/jboss/aerogear/aerogear-crypto/0.1.5/ Thanks for testing and sorry about that. On 2014-08-19, Daniel Passos wrote: > No android *classifier* found > > -- Passos > > On Mon, Aug 18, 2014 at 5:58 PM, Summers Pittman > wrote: > > > On 08/18/2014 12:08 PM, Bruno Oliveira wrote: > > > Good morning, AeroGear Crypto was staged at: > > > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 > > > > > > I'm planning to release it on Wednesday. > > > > Bug me tomorrow and I will run the Android projects against it. > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > Summers Pittman > > >>Phone:404 941 4698 > > >>Java is my crack. > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From lholmqui at redhat.com Tue Aug 19 10:16:14 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 19 Aug 2014 10:16:14 -0400 Subject: [aerogear-dev] JS 1.5.2-pre release Message-ID: I?ve just drafted a pre-release of the AeroGear.js 1.5.2 release https://github.com/aerogear/aerogear-js/releases/tag/1.5.2-pre this contains some bug fixes and mainly some enhancements related to push to coincide with the UnifiedPush Servers 1.0.0 release I will do the main release in a couple days time -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/3a440515/attachment-0001.html From matzew at apache.org Tue Aug 19 10:32:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 19 Aug 2014 16:32:26 +0200 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: <20140819140221.GA44453@abstractj.org> References: <20140818160845.GA93150@abstractj.org> <53F26902.9060407@redhat.com> <20140819140221.GA44453@abstractj.org> Message-ID: Hello Bruno, I have redone my tests, using the new staging repo. +1 on this stays ;-) On Tue, Aug 19, 2014 at 4:02 PM, Bruno Oliveira wrote: > This is the new repository: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3734/org/jboss/aerogear/aerogear-crypto/0.1.5/ > > Thanks for testing and sorry about that. > > On 2014-08-19, Daniel Passos wrote: > > No android *classifier* found > > > > -- Passos > > > > On Mon, Aug 18, 2014 at 5:58 PM, Summers Pittman > > wrote: > > > > > On 08/18/2014 12:08 PM, Bruno Oliveira wrote: > > > > Good morning, AeroGear Crypto was staged at: > > > > > > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 > > > > > > > > I'm planning to release it on Wednesday. > > > > > > Bug me tomorrow and I will run the Android projects against it. > > > > > > > -- > > > > > > > > abstractj > > > > PGP: 0x84DC9914 > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > -- > > > Summers Pittman > > > >>Phone:404 941 4698 > > > >>Java is my crack. > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/52ceca81/attachment.html From supittma at redhat.com Tue Aug 19 11:17:37 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 19 Aug 2014 11:17:37 -0400 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: <53F26902.9060407@redhat.com> References: <20140818160845.GA93150@abstractj.org> <53F26902.9060407@redhat.com> Message-ID: <53F36A91.2030904@redhat.com> On 08/18/2014 04:58 PM, Summers Pittman wrote: > On 08/18/2014 12:08 PM, Bruno Oliveira wrote: >> Good morning, AeroGear Crypto was staged at: >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 >> >> I'm planning to release it on Wednesday. > Bug me tomorrow and I will run the Android projects against it. Android-security and android encrypted store stuff run and pass their tests. > >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From daniel at passos.me Tue Aug 19 14:01:37 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 19 Aug 2014 15:01:37 -0300 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: <53F36A91.2030904@redhat.com> References: <20140818160845.GA93150@abstractj.org> <53F26902.9060407@redhat.com> <53F36A91.2030904@redhat.com> Message-ID: [image: +1] Tested using AeroGear Android Security[1] and AeroGear Crypto Android Demo[2] +1 [1] https://github.com/aerogear/aerogear-android-security/pull/3 [2] https://github.com/danielpassos/aerogear-crypto-android-demo/tree/2.0 -- Passos ? On Tue, Aug 19, 2014 at 12:17 PM, Summers Pittman wrote: > On 08/18/2014 04:58 PM, Summers Pittman wrote: > > On 08/18/2014 12:08 PM, Bruno Oliveira wrote: > >> Good morning, AeroGear Crypto was staged at: > >> > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 > >> > >> I'm planning to release it on Wednesday. > > Bug me tomorrow and I will run the Android projects against it. > Android-security and android encrypted store stuff run and pass their > tests. > > > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140819/5a7f39e2/attachment.html From bruno at abstractj.org Tue Aug 19 14:42:44 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 19 Aug 2014 15:42:44 -0300 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: References: <20140818160845.GA93150@abstractj.org> <53F26902.9060407@redhat.com> <53F36A91.2030904@redhat.com> Message-ID: <20140819184244.GA25816@abstractj.org> Yay, thank you guys. On 2014-08-19, Daniel Passos wrote: > [image: +1] > > Tested using AeroGear Android Security[1] and AeroGear Crypto Android > Demo[2] +1 > > [1] https://github.com/aerogear/aerogear-android-security/pull/3 > > [2] https://github.com/danielpassos/aerogear-crypto-android-demo/tree/2.0 > > -- Passos > ? > > > On Tue, Aug 19, 2014 at 12:17 PM, Summers Pittman > wrote: > > > On 08/18/2014 04:58 PM, Summers Pittman wrote: > > > On 08/18/2014 12:08 PM, Bruno Oliveira wrote: > > >> Good morning, AeroGear Crypto was staged at: > > >> > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3725 > > >> > > >> I'm planning to release it on Wednesday. > > > Bug me tomorrow and I will run the Android projects against it. > > Android-security and android encrypted store stuff run and pass their > > tests. > > > > > >> -- > > >> > > >> abstractj > > >> PGP: 0x84DC9914 > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > -- > > Summers Pittman > > >>Phone:404 941 4698 > > >>Java is my crack. > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel at passos.me Wed Aug 20 07:29:44 2014 From: daniel at passos.me (Daniel Passos) Date: Wed, 20 Aug 2014 08:29:44 -0300 Subject: [aerogear-dev] AeroGear Android Push 1.0.0 - Staged In-Reply-To: References: Message-ID: I just pressed the button to release it to the maven central -- Passos On Tue, Aug 19, 2014 at 5:05 AM, Matthias Wessendorf wrote: > +1 on this release! > > I have tested the new staging repo w/ the "HelloWorld" example against > master of UPS on WF8.1: works perfectly fine > > > On Mon, Aug 18, 2014 at 6:21 PM, Daniel Passos wrote: > >> Sorry about that. >> >> I just fixed it and send a new one to JBoss Nexus[1] >> >> [1] >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3727/ >> >> -- Passos >> >> >> On Mon, Aug 18, 2014 at 11:57 AM, Matthias Wessendorf >> wrote: >> >>> -1 on this >>> >>> The 1.0.0 tag does not contain the fix from PR #8 >>> >>> -Matthias >>> >>> >>> [1] https://github.com/aerogear/aerogear-android-push/blob/1.0.0/pom.xml >>> [2] https://github.com/aerogear/aerogear-android-push/pull/8/files >>> >>> >>> On Mon, Aug 18, 2014 at 3:32 PM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Nice, I'll try it out. >>>> >>>> >>>> On 18 August 2014 15:26, Daniel Passos wrote: >>>> >>>>> Hey Everyone, >>>>> >>>>> AeroGear Android Push 1.0.0 was staged on Nexus. \o/ >>>>> >>>>> We planned press the button and release it to maven central next >>>>> wednesday >>>>> >>>>> Feel free to test it[1]! >>>>> >>>>> [1] >>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3723/ >>>>> >>>>> -- Passos >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140820/af0a0702/attachment-0001.html From matzew at apache.org Wed Aug 20 07:46:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 20 Aug 2014 13:46:51 +0200 Subject: [aerogear-dev] AeroGear Android Push 1.0.0 - Staged In-Reply-To: References: Message-ID: yay On Wed, Aug 20, 2014 at 1:29 PM, Daniel Passos wrote: > I just pressed the button to release it to the maven central > > -- Passos > > > On Tue, Aug 19, 2014 at 5:05 AM, Matthias Wessendorf > wrote: > >> +1 on this release! >> >> I have tested the new staging repo w/ the "HelloWorld" example against >> master of UPS on WF8.1: works perfectly fine >> >> >> On Mon, Aug 18, 2014 at 6:21 PM, Daniel Passos wrote: >> >>> Sorry about that. >>> >>> I just fixed it and send a new one to JBoss Nexus[1] >>> >>> [1] >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3727/ >>> >>> -- Passos >>> >>> >>> On Mon, Aug 18, 2014 at 11:57 AM, Matthias Wessendorf >> > wrote: >>> >>>> -1 on this >>>> >>>> The 1.0.0 tag does not contain the fix from PR #8 >>>> >>>> -Matthias >>>> >>>> >>>> [1] >>>> https://github.com/aerogear/aerogear-android-push/blob/1.0.0/pom.xml >>>> [2] https://github.com/aerogear/aerogear-android-push/pull/8/files >>>> >>>> >>>> On Mon, Aug 18, 2014 at 3:32 PM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> Nice, I'll try it out. >>>>> >>>>> >>>>> On 18 August 2014 15:26, Daniel Passos wrote: >>>>> >>>>>> Hey Everyone, >>>>>> >>>>>> AeroGear Android Push 1.0.0 was staged on Nexus. \o/ >>>>>> >>>>>> We planned press the button and release it to maven central next >>>>>> wednesday >>>>>> >>>>>> Feel free to test it[1]! >>>>>> >>>>>> [1] >>>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3723/ >>>>>> >>>>>> -- Passos >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140820/1c644a19/attachment.html From corinnekrych at gmail.com Wed Aug 20 10:30:58 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 20 Aug 2014 16:30:58 +0200 Subject: [aerogear-dev] iOS meeting on 22nd August Message-ID: Hello iOS lovers, Let?s talk about 2.0.0 release coming next. See you Friday 22nd August at 2pm (CEST - UTC + 2hours). Here is a proposal agenda: http://oksoclap.com/p/aerogear-ios-22082014 Feel free to add topics you would like to discuss. See you all, ++ Corinne From matzew at apache.org Wed Aug 20 16:19:18 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 20 Aug 2014 22:19:18 +0200 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next In-Reply-To: References: Message-ID: Hello, I will tag tomorrow morning. This PR will get in as well https://github.com/aerogear/aerogear-unifiedpush-server/pull/364 This gives us a few days (Thurs, Friday, Monday, Tuesday, and perhaps Wednesday next week) to test the TAG. So we can have the release to Maven Central by next Wednesday/Thursday. Oh, one more thing: ATM Bill Burk is already doing the rc-1 release, followed by a rc-2 next week: http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002460.html If there are no concerns, I'd like to get that rc-1 in as well. It fixes a few minor bugs on our "UI": * https://issues.jboss.org/browse/AGPUSH-950 -> Luke found it * logout sessions from KC admin, works not 100% w/ beta4. noticed tonight. Tested w/ rc-1 -> works there. Any thoughts? Thanks! Matthias On Mon, Aug 18, 2014 at 3:11 PM, Matthias Wessendorf wrote: > Hello, > > as mentioned in [1] we should have a code-freeze period of a few days > before we do the final release. > Release for UPS.1.0.0.Final date will be August 26th. > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd like > to create a 1.0.0.Final tag (or a branch) and only > 'blocker' or 'critical' fixes should be allowed to be merged during that > time (to that particular branch/tag). > Basic goal: minimize risks! > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all around > Quickstarts and our docs, see [2]) > > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for > follow-up releases, as needed (see [3]). > The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER branch > as well. > > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be > working on new features, like: > * More analytics > * More mobile network (Windows, Kindle, etc) > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) > * Alternative Datastores (like Mongo) ? > > > Any thoughts ? > -Matthias > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html > [2] > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140820/89dcfde5/attachment.html From bruno at abstractj.org Wed Aug 20 17:12:38 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 20 Aug 2014 18:12:38 -0300 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next In-Reply-To: References: Message-ID: <20140820211238.GA14978@abstractj.org> +1 on get RC1 in. On 2014-08-20, Matthias Wessendorf wrote: > Hello, > > I will tag tomorrow morning. > This PR will get in as well > https://github.com/aerogear/aerogear-unifiedpush-server/pull/364 > > This gives us a few days (Thurs, Friday, Monday, Tuesday, and perhaps > Wednesday next week) to test the TAG. > So we can have the release to Maven Central by next Wednesday/Thursday. > > Oh, one more thing: > ATM Bill Burk is already doing the rc-1 release, followed by a rc-2 next > week: > http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002460.html > > If there are no concerns, I'd like to get that rc-1 in as well. It fixes a > few minor bugs on our "UI": > * https://issues.jboss.org/browse/AGPUSH-950 -> Luke found it > * logout sessions from KC admin, works not 100% w/ beta4. noticed tonight. > Tested w/ rc-1 -> works there. > > > Any thoughts? > > Thanks! > Matthias > > > > On Mon, Aug 18, 2014 at 3:11 PM, Matthias Wessendorf > wrote: > > > Hello, > > > > as mentioned in [1] we should have a code-freeze period of a few days > > before we do the final release. > > Release for UPS.1.0.0.Final date will be August 26th. > > > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd like > > to create a 1.0.0.Final tag (or a branch) and only > > 'blocker' or 'critical' fixes should be allowed to be merged during that > > time (to that particular branch/tag). > > Basic goal: minimize risks! > > > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all around > > Quickstarts and our docs, see [2]) > > > > > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for > > follow-up releases, as needed (see [3]). > > The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT > > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. > > > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER branch > > as well. > > > > > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be > > working on new features, like: > > * More analytics > > * More mobile network (Windows, Kindle, etc) > > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) > > * Alternative Datastores (like Mongo) ? > > > > > > Any thoughts ? > > -Matthias > > > > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html > > [2] > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Thu Aug 21 01:26:20 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 21 Aug 2014 07:26:20 +0200 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next In-Reply-To: <20140820211238.GA14978@abstractj.org> References: <20140820211238.GA14978@abstractj.org> Message-ID: +1 Sounds good to me getting RC1 in. On 20 August 2014 23:12, Bruno Oliveira wrote: > +1 on get RC1 in. > > On 2014-08-20, Matthias Wessendorf wrote: > > Hello, > > > > I will tag tomorrow morning. > > This PR will get in as well > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/364 > > > > This gives us a few days (Thurs, Friday, Monday, Tuesday, and perhaps > > Wednesday next week) to test the TAG. > > So we can have the release to Maven Central by next Wednesday/Thursday. > > > > Oh, one more thing: > > ATM Bill Burk is already doing the rc-1 release, followed by a rc-2 next > > week: > > http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002460.html > > > > If there are no concerns, I'd like to get that rc-1 in as well. It fixes > a > > few minor bugs on our "UI": > > * https://issues.jboss.org/browse/AGPUSH-950 -> Luke found it > > * logout sessions from KC admin, works not 100% w/ beta4. noticed > tonight. > > Tested w/ rc-1 -> works there. > > > > > > Any thoughts? > > > > Thanks! > > Matthias > > > > > > > > On Mon, Aug 18, 2014 at 3:11 PM, Matthias Wessendorf > > wrote: > > > > > Hello, > > > > > > as mentioned in [1] we should have a code-freeze period of a few days > > > before we do the final release. > > > Release for UPS.1.0.0.Final date will be August 26th. > > > > > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd > like > > > to create a 1.0.0.Final tag (or a branch) and only > > > 'blocker' or 'critical' fixes should be allowed to be merged during > that > > > time (to that particular branch/tag). > > > Basic goal: minimize risks! > > > > > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all > around > > > Quickstarts and our docs, see [2]) > > > > > > > > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for > > > follow-up releases, as needed (see [3]). > > > The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT > > > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. > > > > > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER > branch > > > as well. > > > > > > > > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be > > > working on new features, like: > > > * More analytics > > > * More mobile network (Windows, Kindle, etc) > > > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) > > > * Alternative Datastores (like Mongo) ? > > > > > > > > > Any thoughts ? > > > -Matthias > > > > > > > > > [1] > http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html > > > [2] > > > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/fea5d50c/attachment.html From cvasilak at gmail.com Thu Aug 21 01:49:28 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 21 Aug 2014 08:49:28 +0300 Subject: [aerogear-dev] UnifiedPush Server: Code-Freeze - and UPS.next In-Reply-To: References: <20140820211238.GA14978@abstractj.org> Message-ID: <1F38FFF7-4446-45FD-A4EE-5B01E9CAB586@gmail.com> +1 to include RC1, sounds good - Christos On Aug 21, 2014, at 8:26 AM, Daniel Bevenius wrote: > +1 Sounds good to me getting RC1 in. > > > On 20 August 2014 23:12, Bruno Oliveira wrote: > +1 on get RC1 in. > > On 2014-08-20, Matthias Wessendorf wrote: > > Hello, > > > > I will tag tomorrow morning. > > This PR will get in as well > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/364 > > > > This gives us a few days (Thurs, Friday, Monday, Tuesday, and perhaps > > Wednesday next week) to test the TAG. > > So we can have the release to Maven Central by next Wednesday/Thursday. > > > > Oh, one more thing: > > ATM Bill Burk is already doing the rc-1 release, followed by a rc-2 next > > week: > > http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002460.html > > > > If there are no concerns, I'd like to get that rc-1 in as well. It fixes a > > few minor bugs on our "UI": > > * https://issues.jboss.org/browse/AGPUSH-950 -> Luke found it > > * logout sessions from KC admin, works not 100% w/ beta4. noticed tonight. > > Tested w/ rc-1 -> works there. > > > > > > Any thoughts? > > > > Thanks! > > Matthias > > > > > > > > On Mon, Aug 18, 2014 at 3:11 PM, Matthias Wessendorf > > wrote: > > > > > Hello, > > > > > > as mentioned in [1] we should have a code-freeze period of a few days > > > before we do the final release. > > > Release for UPS.1.0.0.Final date will be August 26th. > > > > > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd like > > > to create a 1.0.0.Final tag (or a branch) and only > > > 'blocker' or 'critical' fixes should be allowed to be merged during that > > > time (to that particular branch/tag). > > > Basic goal: minimize risks! > > > > > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all around > > > Quickstarts and our docs, see [2]) > > > > > > > > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch for > > > follow-up releases, as needed (see [3]). > > > The version number on the "1.0.x" branch will start with 1.0.1-SNAPSHOT > > > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. > > > > > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER branch > > > as well. > > > > > > > > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be > > > working on new features, like: > > > * More analytics > > > * More mobile network (Windows, Kindle, etc) > > > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) > > > * Alternative Datastores (like Mongo) ? > > > > > > > > > Any thoughts ? > > > -Matthias > > > > > > > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html > > > [2] > > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/464e4e77/attachment.html From matzew at apache.org Thu Aug 21 04:58:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 10:58:14 +0200 Subject: [aerogear-dev] Release: Java SENDER - 1.0.0 Message-ID: Hi, this is basically the same version as 0.9.0 - just version alignment for our upcoming "Push 1.0.0" release. The staging repo is her: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3753/org/jboss/aerogear/unifiedpush-java-client/1.0.0/ Daniel Bevenius and Luk?? Fry?, can you do the tests? Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/d579d10f/attachment.html From daniel.bevenius at gmail.com Thu Aug 21 05:01:50 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 21 Aug 2014 11:01:50 +0200 Subject: [aerogear-dev] Release: Java SENDER - 1.0.0 In-Reply-To: References: Message-ID: Sure, will give it a go. On 21 August 2014 10:58, Matthias Wessendorf wrote: > Hi, > > this is basically the same version as 0.9.0 - just version alignment for > our upcoming "Push 1.0.0" release. > > The staging repo is her: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3753/org/jboss/aerogear/unifiedpush-java-client/1.0.0/ > > Daniel Bevenius and Luk?? Fry?, can you do the tests? > > Thanks! > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/bc494fcc/attachment-0001.html From matzew at apache.org Thu Aug 21 05:07:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 11:07:36 +0200 Subject: [aerogear-dev] Branches and 1.0.0.Final tag (was: Re: UnifiedPush Server: Code-Freeze - and UPS.next) Message-ID: Hi team, the 1.0.0.Final has been tagged for testing - will share the staging repo soon. Besides that, we now have a 1.0.x branch ([1]), used for the 1.0.x release series - as discussed in [2]. As mentioned earlier, the master version has been set to "1.1.0-SNAPSHOT" and will contain new features (e.g. WindowsPush) and backports of fixes from the 1.0.x branch. Greetings, Matthias [1] https://github.com/aerogear/aerogear-unifiedpush-server/tree/1.0.x [2] http://staging.aerogear.org/docs/planning/roadmaps/UnifiedPush On Thu, Aug 21, 2014 at 7:49 AM, Christos Vasilakis wrote: > +1 to include RC1, sounds good > > > - > Christos > > > On Aug 21, 2014, at 8:26 AM, Daniel Bevenius > wrote: > > +1 Sounds good to me getting RC1 in. > > > On 20 August 2014 23:12, Bruno Oliveira wrote: > >> +1 on get RC1 in. >> >> On 2014-08-20, Matthias Wessendorf wrote: >> > Hello, >> > >> > I will tag tomorrow morning. >> > This PR will get in as well >> > https://github.com/aerogear/aerogear-unifiedpush-server/pull/364 >> > >> > This gives us a few days (Thurs, Friday, Monday, Tuesday, and perhaps >> > Wednesday next week) to test the TAG. >> > So we can have the release to Maven Central by next Wednesday/Thursday. >> > >> > Oh, one more thing: >> > ATM Bill Burk is already doing the rc-1 release, followed by a rc-2 next >> > week: >> > http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002460.html >> > >> > If there are no concerns, I'd like to get that rc-1 in as well. It >> fixes a >> > few minor bugs on our "UI": >> > * https://issues.jboss.org/browse/AGPUSH-950 -> Luke found it >> > * logout sessions from KC admin, works not 100% w/ beta4. noticed >> tonight. >> > Tested w/ rc-1 -> works there. >> > >> > >> > Any thoughts? >> > >> > Thanks! >> > Matthias >> > >> > >> > >> > On Mon, Aug 18, 2014 at 3:11 PM, Matthias Wessendorf > > >> > wrote: >> > >> > > Hello, >> > > >> > > as mentioned in [1] we should have a code-freeze period of a few days >> > > before we do the final release. >> > > Release for UPS.1.0.0.Final date will be August 26th. >> > > >> > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd >> like >> > > to create a 1.0.0.Final tag (or a branch) and only >> > > 'blocker' or 'critical' fixes should be allowed to be merged during >> that >> > > time (to that particular branch/tag). >> > > Basic goal: minimize risks! >> > > >> > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all >> around >> > > Quickstarts and our docs, see [2]) >> > > >> > > >> > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch >> for >> > > follow-up releases, as needed (see [3]). >> > > The version number on the "1.0.x" branch will start with >> 1.0.1-SNAPSHOT >> > > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. >> > > >> > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER >> branch >> > > as well. >> > > >> > > >> > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be >> > > working on new features, like: >> > > * More analytics >> > > * More mobile network (Windows, Kindle, etc) >> > > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, etc) >> > > * Alternative Datastores (like Mongo) ? >> > > >> > > >> > > Any thoughts ? >> > > -Matthias >> > > >> > > >> > > [1] >> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html >> > > [2] >> > > >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >> > > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >> > > >> > > >> > > -- >> > > Matthias Wessendorf >> > > >> > > blog: http://matthiaswessendorf.wordpress.com/ >> > > sessions: http://www.slideshare.net/mwessendorf >> > > twitter: http://twitter.com/mwessendorf >> > > >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/d2cd45d7/attachment.html From lukas.fryc at gmail.com Thu Aug 21 05:29:00 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 21 Aug 2014 11:29:00 +0200 Subject: [aerogear-dev] Release: Java SENDER - 1.0.0 In-Reply-To: References: Message-ID: Tested with /w contacts-mobile-picketlink-secured and works fine. PR with upgrade for quickstart: https://github.com/aerogear/aerogear-push-quickstarts/pull/84 On Thu, Aug 21, 2014 at 11:01 AM, Daniel Bevenius wrote: > Sure, will give it a go. > > > On 21 August 2014 10:58, Matthias Wessendorf wrote: > >> Hi, >> >> this is basically the same version as 0.9.0 - just version alignment for >> our upcoming "Push 1.0.0" release. >> >> The staging repo is her: >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3753/org/jboss/aerogear/unifiedpush-java-client/1.0.0/ >> >> Daniel Bevenius and Luk?? Fry?, can you do the tests? >> >> Thanks! >> Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/1d67595b/attachment.html From matzew at apache.org Thu Aug 21 05:41:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 11:41:29 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Final Message-ID: Hello folks! we are getting really close to our 1.0.0 release! In fact, it's now under testing/review. Thank you very much, guys!!!! Note this release contains a handful fixes on-top of the last BETA2 release. To name a few highlights: * Keycloak rc-1 usage * UI improvements (e.g. new style of the account mgmt section, and more links to docs/guides) * APNs fixes: improved server-side logging and fixing broken iOS Variant updates The team did an outstanding job to get to this point! Thanks again guys! Details on all the JIRAs can be found here: https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754 The staging repository is located here: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/ For testing this review, I nominate Corinne Krych, Erik Jan de Wit and Tadeas Kriz Regarding Docker, I have sent a PR against Bruno's repo, to go w/ the WAR files from the above staging repo: https://github.com/abstractj/docker/pull/8 Let me know the results of your testing! If I hear nothing bad by Tuesday (August 26th) evening, the release to maven central will happen on Wednesday morning; NOTE: Once this release has been approved the matching tag will be used to get the OpenShift online bits updated! Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/cfa4b1e7/attachment.html From daniel.bevenius at gmail.com Thu Aug 21 05:43:54 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 21 Aug 2014 11:43:54 +0200 Subject: [aerogear-dev] Release: Java SENDER - 1.0.0 In-Reply-To: References: Message-ID: Did the same test and it worked without issues. On 21 August 2014 11:29, Luk?? Fry? wrote: > Tested with /w contacts-mobile-picketlink-secured and works fine. > > PR with upgrade for quickstart: > https://github.com/aerogear/aerogear-push-quickstarts/pull/84 > > > On Thu, Aug 21, 2014 at 11:01 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Sure, will give it a go. >> >> >> On 21 August 2014 10:58, Matthias Wessendorf wrote: >> >>> Hi, >>> >>> this is basically the same version as 0.9.0 - just version alignment for >>> our upcoming "Push 1.0.0" release. >>> >>> The staging repo is her: >>> >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3753/org/jboss/aerogear/unifiedpush-java-client/1.0.0/ >>> >>> Daniel Bevenius and Luk?? Fry?, can you do the tests? >>> >>> Thanks! >>> Matthias >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/e2c67cc5/attachment-0001.html From matzew at apache.org Thu Aug 21 05:47:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 11:47:07 +0200 Subject: [aerogear-dev] Branches and 1.0.0.Final tag (was: Re: UnifiedPush Server: Code-Freeze - and UPS.next) In-Reply-To: References: Message-ID: On Thu, Aug 21, 2014 at 11:07 AM, Matthias Wessendorf wrote: > Hi team, > > the 1.0.0.Final has been tagged for testing - will share the staging repo > soon. > oh, yeah - as with the 'Beta2', only blockers or critical fixes will be merged. Everything else goes straight to 1.0.1 (which is happening early Sept.) > > Besides that, we now have a 1.0.x branch ([1]), used for the 1.0.x release > series - as discussed in [2]. > > As mentioned earlier, the master version has been set to "1.1.0-SNAPSHOT" > and will contain new features (e.g. WindowsPush) and backports of fixes > from the 1.0.x branch. > > Greetings, > Matthias > > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/tree/1.0.x > [2] http://staging.aerogear.org/docs/planning/roadmaps/UnifiedPush > > > > > > On Thu, Aug 21, 2014 at 7:49 AM, Christos Vasilakis > wrote: > >> +1 to include RC1, sounds good >> >> >> - >> Christos >> >> >> On Aug 21, 2014, at 8:26 AM, Daniel Bevenius >> wrote: >> >> +1 Sounds good to me getting RC1 in. >> >> >> On 20 August 2014 23:12, Bruno Oliveira wrote: >> >>> +1 on get RC1 in. >>> >>> On 2014-08-20, Matthias Wessendorf wrote: >>> > Hello, >>> > >>> > I will tag tomorrow morning. >>> > This PR will get in as well >>> > https://github.com/aerogear/aerogear-unifiedpush-server/pull/364 >>> > >>> > This gives us a few days (Thurs, Friday, Monday, Tuesday, and perhaps >>> > Wednesday next week) to test the TAG. >>> > So we can have the release to Maven Central by next Wednesday/Thursday. >>> > >>> > Oh, one more thing: >>> > ATM Bill Burk is already doing the rc-1 release, followed by a rc-2 >>> next >>> > week: >>> > http://lists.jboss.org/pipermail/keycloak-dev/2014-August/002460.html >>> > >>> > If there are no concerns, I'd like to get that rc-1 in as well. It >>> fixes a >>> > few minor bugs on our "UI": >>> > * https://issues.jboss.org/browse/AGPUSH-950 -> Luke found it >>> > * logout sessions from KC admin, works not 100% w/ beta4. noticed >>> tonight. >>> > Tested w/ rc-1 -> works there. >>> > >>> > >>> > Any thoughts? >>> > >>> > Thanks! >>> > Matthias >>> > >>> > >>> > >>> > On Mon, Aug 18, 2014 at 3:11 PM, Matthias Wessendorf < >>> matzew at apache.org> >>> > wrote: >>> > >>> > > Hello, >>> > > >>> > > as mentioned in [1] we should have a code-freeze period of a few days >>> > > before we do the final release. >>> > > Release for UPS.1.0.0.Final date will be August 26th. >>> > > >>> > > I'd like to do the code-freeze tomorrow(Tuesday, 19th) evening. I'd >>> like >>> > > to create a 1.0.0.Final tag (or a branch) and only >>> > > 'blocker' or 'critical' fixes should be allowed to be merged during >>> that >>> > > time (to that particular branch/tag). >>> > > Basic goal: minimize risks! >>> > > >>> > > (The JIRA tickets for the umbrella "Mobile Push 1.0" are almost all >>> around >>> > > Quickstarts and our docs, see [2]) >>> > > >>> > > >>> > > Once the 1.0.0.Final is released, I'd like to create a 1.0.x branch >>> for >>> > > follow-up releases, as needed (see [3]). >>> > > The version number on the "1.0.x" branch will start with >>> 1.0.1-SNAPSHOT >>> > > On MASTER branch, I'd like to set the version to 1.1.0-SNAPSHOT. >>> > > >>> > > Fixes done on the 1.0.x branch will be merged/cherry-picked MASTER >>> branch >>> > > as well. >>> > > >>> > > >>> > > Moving forward to our next 1.1.0 UPS release, on MASTER, we will be >>> > > working on new features, like: >>> > > * More analytics >>> > > * More mobile network (Windows, Kindle, etc) >>> > > * JavaEE7 updates (focus on WildFly / Undertow, ConcurrencyUtils, >>> etc) >>> > > * Alternative Datastores (like Mongo) ? >>> > > >>> > > >>> > > Any thoughts ? >>> > > -Matthias >>> > > >>> > > >>> > > [1] >>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008810.html >>> > > [2] >>> > > >>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >>> > > [3] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ >>> > > >>> > > >>> > > -- >>> > > Matthias Wessendorf >>> > > >>> > > blog: http://matthiaswessendorf.wordpress.com/ >>> > > sessions: http://www.slideshare.net/mwessendorf >>> > > twitter: http://twitter.com/mwessendorf >>> > > >>> > >>> > >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/ca71d339/attachment.html From bruno at abstractj.org Thu Aug 21 05:56:20 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 21 Aug 2014 06:56:20 -0300 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 Message-ID: <20140821095620.GA18356@abstractj.org> Good morning, AeroGear Crypto 0.1.5 is already available on Maven Central: http://search.maven.org/#artifactdetails|org.jboss.aerogear|aerogear-crypto|0.1.5|jar Have fun! -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Thu Aug 21 05:58:25 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 21 Aug 2014 11:58:25 +0200 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: <20140821095620.GA18356@abstractj.org> References: <20140821095620.GA18356@abstractj.org> Message-ID: Yay! On 21 August 2014 11:56, Bruno Oliveira wrote: > Good morning, > > AeroGear Crypto 0.1.5 is already available on Maven Central: > > http://search.maven.org/#artifactdetails|org.jboss.aerogear|aerogear-crypto|0.1.5|jar > > Have fun! > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/22587f25/attachment.html From matzew at apache.org Thu Aug 21 06:22:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 12:22:45 +0200 Subject: [aerogear-dev] AeroGear Crypto 0.1.5 In-Reply-To: References: <20140821095620.GA18356@abstractj.org> Message-ID: Awesome! UPS was already updated to use it On Thursday, August 21, 2014, Daniel Bevenius wrote: > Yay! > > > On 21 August 2014 11:56, Bruno Oliveira > wrote: > >> Good morning, >> >> AeroGear Crypto 0.1.5 is already available on Maven Central: >> >> http://search.maven.org/#artifactdetails|org.jboss.aerogear|aerogear-crypto|0.1.5|jar >> >> Have fun! >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/8c82d5b7/attachment.html From edewit at redhat.com Thu Aug 21 07:09:41 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 21 Aug 2014 13:09:41 +0200 Subject: [aerogear-dev] message format change proposal Message-ID: Hi, With the upcoming windows support and simple push change (making simple push more like 'normal') the number of ?special? keys in our message is increasing. Right now we are mixing our ?special? keys with those the user can add, but we keep simple push out of it: { "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], "alias" : ["user at account.com", "someone at aerogear.org", ....], "categories" : ["someCategory", "otherCategory"], "deviceType" : ["iPad", "AndroidTablet"], "ttl" : 3600, "message": { "alert":"HELLO!", "sound":"default", "badge":7, "content-available" : true, "action-category" : "some_category", "someKey":"some value", "anotherCustomKey":"some other value" }, "simple-push": "version=123? } As simple push is going to be more like ?normal? push why not move the simple-push into the message as well. As for the windows support there are a lot more types of messages you can send. The most normal form is called ?toast?, but there are other ones for when you app is pinned to the home screen. Then one can send message that contain pictures. To support all of this we need something like this: https://gist.github.com/edewit/305d76c31960aa6254a9 Adding all these ?special? keys will make it easier to get into a conflict with the users own data, so I propose we put the user data into a separate data object, like so: { "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], "alias" : ["user at account.com", "someone at aerogear.org", ....], "categories" : ["someCategory", "otherCategory"], "deviceType" : ["iPad", "AndroidTablet"], "ttl" : 3600, "message": { "alert":"HELLO!", "sound":"default", "badge":7, "content-available" : true, "action-category" : "some_category", "simple-push": "version=123", "data" : { "someKey":"some value", "anotherCustomKey":"some other value" } } } WDYT? Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/6fe9681c/attachment-0001.html From corinnekrych at gmail.com Thu Aug 21 07:30:36 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 21 Aug 2014 13:30:36 +0200 Subject: [aerogear-dev] message format change proposal In-Reply-To: References: Message-ID: +1 on a custom-data section. Going even further as we add more platforms support, I think having sth like cordova push config: http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_sample_example where you have platform specific section would be nice. ++ Corinne On 21 Aug 2014, at 13:09, Erik Jan de Wit wrote: > Hi, > > With the upcoming windows support and simple push change (making simple push more like 'normal') the number of ?special? keys in our message is increasing. Right now we are mixing our ?special? keys with those the user can add, but we keep simple push out of it: > > { > > > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], > > > "alias" : ["user at account.com", "someone at aerogear.org", ....], > > > "categories" : ["someCategory", "otherCategory"], > > > "deviceType" : ["iPad", "AndroidTablet"], > > > "ttl" : 3600, > > > "message": { > > > "alert":"HELLO!", > > > "sound":"default", > > > "badge":7, > > > "content-available" : true, > > > "action-category" : "some_category", > > > > "someKey":"some value", > > > "anotherCustomKey":"some other value" > > > }, > "simple-push": "version=123? > } > > > As simple push is going to be more like ?normal? push why not move the simple-push into the message as well. As for the windows support there are a lot more types of messages you can send. The most normal form is called ?toast?, but there are other ones for when you app is pinned to the home screen. Then one can send message that contain pictures. To support all of this we need something like this: https://gist.github.com/edewit/305d76c31960aa6254a9 > > Adding all these ?special? keys will make it easier to get into a conflict with the users own data, so I propose we put the user data into a separate data object, like so: > > { > > > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], > > > "alias" : ["user at account.com", "someone at aerogear.org", ....], > > > "categories" : ["someCategory", "otherCategory"], > > > "deviceType" : ["iPad", "AndroidTablet"], > > > "ttl" : 3600, > > > "message": { > > > "alert":"HELLO!", > > > "sound":"default", > > > "badge":7, > > > "content-available" : true, > > > "action-category" : "some_category", > "simple-push": "version=123", > > > "data" : { > > > "someKey":"some value", > > > "anotherCustomKey":"some other value" > > > } > > > } > } > > > WDYT? > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Aug 21 07:34:41 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 13:34:41 +0200 Subject: [aerogear-dev] message format change proposal In-Reply-To: References: Message-ID: Hi Erik, overall I am not against changes for 1.1.x, on our master branch. Here is something that Sebi mentioned a few month ago: https://issues.jboss.org/browse/AGPUSH-534 With some API change, coming up, let's not forget about "REST API Versioning", he discussed at our Face2Face meeting: http://oksoclap.com/p/jbrS1EHWkI (looks like in that session the majority preferred headers over URI). We have to support the 1.0.0 APIs for quite a while. -Matthias On Thu, Aug 21, 2014 at 1:09 PM, Erik Jan de Wit wrote: > Hi, > > With the upcoming windows support and simple push change (making simple > push more like 'normal') the number of ?special? keys in our message is > increasing. Right now we are mixing our ?special? keys with those the user > can add, but we keep simple push out of it: > > { > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], > "alias" : ["user at account.com", "someone at aerogear.org", ....], > "categories" : ["someCategory", "otherCategory"], > "deviceType" : ["iPad", "AndroidTablet"], > "ttl" : 3600, > "message": { > "alert":"HELLO!", > "sound":"default", > "badge":7, > "content-available" : true, > "action-category" : "some_category", > > "someKey":"some value", > "anotherCustomKey":"some other value" > }, > > "simple-push": "version=123? > > } > > > > As simple push is going to be more like ?normal? push why not move the > simple-push into the message as well. As for the windows support there are > a lot more types of messages you can send. The most normal form is called > ?toast?, but there are other ones for when you app is pinned to the home > screen. Then one can send message that contain pictures. To support all of > this we need something like this: > https://gist.github.com/edewit/305d76c31960aa6254a9 > > Adding all these ?special? keys will make it easier to get into a conflict > with the users own data, so I propose we put the user data into a separate > data object, like so: > > { > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], > "alias" : ["user at account.com", "someone at aerogear.org", ....], > "categories" : ["someCategory", "otherCategory"], > "deviceType" : ["iPad", "AndroidTablet"], > "ttl" : 3600, > "message": { > "alert":"HELLO!", > "sound":"default", > "badge":7, > "content-available" : true, > "action-category" : "some_category",* "simple-push": "version=123",* > *"data"* : { > "someKey":"some value", > "anotherCustomKey":"some other value" > } > }} > > > > WDYT? > > Cheers, > Erik Jan > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/648212a9/attachment.html From matzew at apache.org Thu Aug 21 07:35:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 13:35:37 +0200 Subject: [aerogear-dev] message format change proposal In-Reply-To: References: Message-ID: On Thu, Aug 21, 2014 at 1:30 PM, Corinne Krych wrote: > +1 on a custom-data section. > Going even further as we add more platforms support, I think having sth > like cordova push config: > > http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/#_sample_example > where you have platform specific section would be nice. > perhaps, not fully convinced atm. Original idea was to have a simple format for multiple platforms. > > ++ > Corinne > > On 21 Aug 2014, at 13:09, Erik Jan de Wit wrote: > > > Hi, > > > > With the upcoming windows support and simple push change (making simple > push more like 'normal') the number of ?special? keys in our message is > increasing. Right now we are mixing our ?special? keys with those the user > can add, but we keep simple push out of it: > > > > { > > > > > > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", > "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], > > > > > > "alias" : ["user at account.com", "someone at aerogear.org", ....], > > > > > > "categories" : ["someCategory", "otherCategory"], > > > > > > "deviceType" : ["iPad", "AndroidTablet"], > > > > > > "ttl" : 3600, > > > > > > "message": { > > > > > > "alert":"HELLO!", > > > > > > "sound":"default", > > > > > > "badge":7, > > > > > > "content-available" : true, > > > > > > "action-category" : "some_category", > > > > > > > > "someKey":"some value", > > > > > > "anotherCustomKey":"some other value" > > > > > > }, > > "simple-push": "version=123? > > } > > > > > > As simple push is going to be more like ?normal? push why not move the > simple-push into the message as well. As for the windows support there are > a lot more types of messages you can send. The most normal form is called > ?toast?, but there are other ones for when you app is pinned to the home > screen. Then one can send message that contain pictures. To support all of > this we need something like this: > https://gist.github.com/edewit/305d76c31960aa6254a9 > > > > Adding all these ?special? keys will make it easier to get into a > conflict with the users own data, so I propose we put the user data into a > separate data object, like so: > > > > { > > > > > > "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", > "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], > > > > > > "alias" : ["user at account.com", "someone at aerogear.org", ....], > > > > > > "categories" : ["someCategory", "otherCategory"], > > > > > > "deviceType" : ["iPad", "AndroidTablet"], > > > > > > "ttl" : 3600, > > > > > > "message": { > > > > > > "alert":"HELLO!", > > > > > > "sound":"default", > > > > > > "badge":7, > > > > > > "content-available" : true, > > > > > > "action-category" : "some_category", > > "simple-push": "version=123", > > > > > > "data" : { > > > > > > "someKey":"some value", > > > > > > "anotherCustomKey":"some other value" > > > > > > } > > > > > > } > > } > > > > > > WDYT? > > > > Cheers, > > Erik Jan > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/cd88bd04/attachment-0001.html From edewit at redhat.com Thu Aug 21 07:46:04 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 21 Aug 2014 13:46:04 +0200 Subject: [aerogear-dev] message format change proposal In-Reply-To: References: Message-ID: > > overall I am not against changes for 1.1.x, on our master branch. Here is something that Sebi mentioned a few month ago: https://issues.jboss.org/browse/AGPUSH-534 right I like this as well, but here the users data is also mixed with the message, that was the point. > > With some API change, coming up, let's not forget about "REST API Versioning", he discussed at our Face2Face meeting: http://oksoclap.com/p/jbrS1EHWkI > (looks like in that session the majority preferred headers over URI). > > We have to support the 1.0.0 APIs for quite a while. Sure, but because we have a version can?t mean that we cannot change things I hope. We just need to have a good mechanism inlace to maintain these versions. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/c15542e9/attachment.html From matzew at apache.org Thu Aug 21 07:51:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 13:51:54 +0200 Subject: [aerogear-dev] message format change proposal In-Reply-To: References: Message-ID: On Thu, Aug 21, 2014 at 1:46 PM, Erik Jan de Wit wrote: > > overall I am not against changes for 1.1.x, on our master branch. Here is > something that Sebi mentioned a few month ago: > https://issues.jboss.org/browse/AGPUSH-534 > > > right I like this as well, but here the users data is also mixed with the > message, that was the point. > > > With some API change, coming up, let's not forget about "REST API > Versioning", he discussed at our Face2Face meeting: > http://oksoclap.com/p/jbrS1EHWkI > (looks like in that session the majority preferred headers over URI). > > We have to support the 1.0.0 APIs for quite a while. > > > Sure, but because we have a version can?t mean that we cannot change > things I hope. > nah, not at all :-) That's why we discussed 'REST API Versioning' at the meeting > We just need to have a good mechanism inlace to maintain these versions. > yep, I'd say once that is in place, we can look at changing APIs > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/77fd330d/attachment.html From lukas.fryc at gmail.com Thu Aug 21 09:48:45 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 21 Aug 2014 15:48:45 +0200 Subject: [aerogear-dev] Fwd: Visual consistency for the UPS console In-Reply-To: <53F5F7A0.7080200@redhat.com> References: <9B9327F4-475E-4DD2-9384-B2D785F698F8@redhat.com> <53F5F7A0.7080200@redhat.com> Message-ID: Hey guys, Gabriel, who did a great job polishing the design of the AdminUI and aligning design of Account Management screen of UPS console, came with a proposal to change the theme color of the UPS console, see screens bellow: We could get this change to 1.0.x. WDYT? ~ Lukas ---------- Forwarded message ---------- From: Lukas Fryc Date: Thu, Aug 21, 2014 at 3:44 PM Subject: Fwd: Visual consistency for the UPS console To: lukas.fryc at gmail.com -------- Original Message -------- Subject: Visual consistency for the UPS console Date: Wed, 20 Aug 2014 11:51:13 -0300 From: Gabriel Cardoso To: Lukas Fryc Hi Lukas, As we discussed in the hangout, I worked on a proposal to improve the visual consistency of the UPS console. What happens right now is that the login page is using the Keycloak style (with its font-family, colours and shapes from its logo), and the admin console has a blue top bar which is not visually related to the AeroGear logo colours. I?m proposing to update the blue top bar and apply one of the logo colours. Also, update the login screen to use this same color and change the graphics to a shape related to the gears in the logo. You can see the proposals in the screenshots below: In terms of time, it wouldn?t require much effort. I could do these changes in a day. Thanks, Gabriel Begin forwarded message: *From: *Matt Carrano *Subject: **Re: Style adjustments for AeroGear* *Date: *August 19, 2014 at 5:09:58 PM GMT-3 *To: *Gabriel Cardoso *Cc: *Matthias Wessendorf Hi Gabriel, I think this looks great, so it is good to go from my perspective. I especially like that you added the gear motif as part of the background fill for the Login page. I'm just copying in Matthias so he is aware of this change and can just confirm that he is good with it before checking in. BTW, what does the Cancel button do from the Login screen? Is this needed? Matt ----- Original Message ----- From: "Gabriel Cardoso" To: "Matt Carrano" Sent: Tuesday, August 19, 2014 3:39:28 PM Subject: Style adjustments for AeroGear Hi Matt, I played a bit with the login page on that color. I believe this will make the project look more consistent. What do you think? Do you think I can implement this changes or should I get some approval from someone first? Gabriel --- Gabriel Cardoso User Experience Designer @ Red Hat --- Gabriel Cardoso User Experience Designer @ Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/3d8aab84/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 53321 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/3d8aab84/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 44960 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/3d8aab84/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 33230 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/3d8aab84/attachment-0005.png From matzew at apache.org Thu Aug 21 09:54:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 15:54:17 +0200 Subject: [aerogear-dev] Fwd: Visual consistency for the UPS console In-Reply-To: References: <9B9327F4-475E-4DD2-9384-B2D785F698F8@redhat.com> <53F5F7A0.7080200@redhat.com> Message-ID: how about 1.1.x - meaning on master ? On Thu, Aug 21, 2014 at 3:48 PM, Luk?? Fry? wrote: > Hey guys, > > Gabriel, who did a great job polishing the design of the AdminUI and > aligning design of Account Management screen of UPS console, > > came with a proposal to change the theme color of the UPS console, > > see screens bellow: > > > We could get this change to 1.0.x. > > WDYT? > > > ~ Lukas > > ---------- Forwarded message ---------- > From: Lukas Fryc > Date: Thu, Aug 21, 2014 at 3:44 PM > Subject: Fwd: Visual consistency for the UPS console > To: lukas.fryc at gmail.com > > > > -------- Original Message -------- Subject: Visual consistency for the > UPS console Date: Wed, 20 Aug 2014 11:51:13 -0300 From: Gabriel Cardoso > To: Lukas Fryc > > > Hi Lukas, > > As we discussed in the hangout, I worked on a proposal to improve the > visual consistency of the UPS console. What happens right now is that the > login page is using the Keycloak style (with its font-family, colours and > shapes from its logo), and the admin console has a blue top bar which is > not visually related to the AeroGear logo colours. > > I?m proposing to update the blue top bar and apply one of the logo > colours. Also, update the login screen to use this same color and change > the graphics to a shape related to the gears in the logo. You can see the > proposals in the screenshots below: > > > > > In terms of time, it wouldn?t require much effort. I could do these > changes in a day. > > Thanks, > Gabriel > > Begin forwarded message: > > *From: *Matt Carrano > *Subject: **Re: Style adjustments for AeroGear* > *Date: *August 19, 2014 at 5:09:58 PM GMT-3 > *To: *Gabriel Cardoso > *Cc: *Matthias Wessendorf > > Hi Gabriel, > > I think this looks great, so it is good to go from my perspective. I > especially like that you added the gear motif as part of the background > fill for the Login page. I'm just copying in Matthias so he is aware of > this change and can just confirm that he is good with it before checking > in. BTW, what does the Cancel button do from the Login screen? Is this > needed? > > Matt > > ----- Original Message ----- > From: "Gabriel Cardoso" > To: "Matt Carrano" > Sent: Tuesday, August 19, 2014 3:39:28 PM > Subject: Style adjustments for AeroGear > > Hi Matt, > > I played a bit with the login page on that color. I believe this will make > the project look more consistent. What do you think? > > > > Do you think I can implement this changes or should I get some approval > from someone first? > > Gabriel > > --- > Gabriel Cardoso > User Experience Designer @ Red Hat > > > --- > Gabriel Cardoso > User Experience Designer @ Red Hat > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/5e90f206/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 53321 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/5e90f206/attachment-0003.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 44960 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/5e90f206/attachment-0004.png -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 33230 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/5e90f206/attachment-0005.png From edewit at redhat.com Thu Aug 21 09:56:56 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 21 Aug 2014 15:56:56 +0200 Subject: [aerogear-dev] Fwd: Visual consistency for the UPS console In-Reply-To: References: <9B9327F4-475E-4DD2-9384-B2D785F698F8@redhat.com> <53F5F7A0.7080200@redhat.com> Message-ID: <07B9F60B-FA56-428F-85AA-17A58D63250C@redhat.com> +1 I really like the login screen and love the idea of using the blue from the aerogear logo, but should we then also adjust the colours of the buttons to be more pastel colours instead of the hard blue? On 21 Aug,2014, at 15:48 , Luk?? Fry? wrote: > Hey guys, > > Gabriel, who did a great job polishing the design of the AdminUI and aligning design of Account Management screen of UPS console, > > came with a proposal to change the theme color of the UPS console, > > see screens bellow: > > > We could get this change to 1.0.x. > > WDYT? > > > ~ Lukas > > ---------- Forwarded message ---------- > From: Lukas Fryc > Date: Thu, Aug 21, 2014 at 3:44 PM > Subject: Fwd: Visual consistency for the UPS console > To: lukas.fryc at gmail.com > > > > -------- Original Message -------- > Subject: Visual consistency for the UPS console > Date: Wed, 20 Aug 2014 11:51:13 -0300 > From: Gabriel Cardoso > To: Lukas Fryc > > Hi Lukas, > > As we discussed in the hangout, I worked on a proposal to improve the visual consistency of the UPS console. What happens right now is that the login page is using the Keycloak style (with its font-family, colours and shapes from its logo), and the admin console has a blue top bar which is not visually related to the AeroGear logo colours. > > I?m proposing to update the blue top bar and apply one of the logo colours. Also, update the login screen to use this same color and change the graphics to a shape related to the gears in the logo. You can see the proposals in the screenshots below: > > > > > > > > In terms of time, it wouldn?t require much effort. I could do these changes in a day. > > Thanks, > Gabriel > > Begin forwarded message: > >> From: Matt Carrano >> Subject: Re: Style adjustments for AeroGear >> Date: August 19, 2014 at 5:09:58 PM GMT-3 >> To: Gabriel Cardoso >> Cc: Matthias Wessendorf >> >> Hi Gabriel, >> >> I think this looks great, so it is good to go from my perspective. I especially like that you added the gear motif as part of the background fill for the Login page. I'm just copying in Matthias so he is aware of this change and can just confirm that he is good with it before checking in. BTW, what does the Cancel button do from the Login screen? Is this needed? >> >> Matt >> >> ----- Original Message ----- >> From: "Gabriel Cardoso" >> To: "Matt Carrano" >> Sent: Tuesday, August 19, 2014 3:39:28 PM >> Subject: Style adjustments for AeroGear >> >> Hi Matt, >> >> I played a bit with the login page on that color. I believe this will make the project look more consistent. What do you think? >> >> >> >> Do you think I can implement this changes or should I get some approval from someone first? >> >> Gabriel >> >> --- >> Gabriel Cardoso >> User Experience Designer @ Red Hat >> > > --- > Gabriel Cardoso > User Experience Designer @ Red Hat > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/183f1c10/attachment.html From daniel.bevenius at gmail.com Thu Aug 21 10:11:28 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 21 Aug 2014 16:11:28 +0200 Subject: [aerogear-dev] Fwd: Visual consistency for the UPS console In-Reply-To: <07B9F60B-FA56-428F-85AA-17A58D63250C@redhat.com> References: <9B9327F4-475E-4DD2-9384-B2D785F698F8@redhat.com> <53F5F7A0.7080200@redhat.com> <07B9F60B-FA56-428F-85AA-17A58D63250C@redhat.com> Message-ID: I kinda liked the darker version I must say, but it makes more sense to have the blue colour from the logo. Plus don't trust myself when it comes to design questions. Just the fact that I liked the darker version makes me thing this lighter blue must be the correct choice. On 21 August 2014 15:56, Erik Jan de Wit wrote: > +1 I really like the login screen and love the idea of using the blue from > the aerogear logo, but should we then also adjust the colours of the > buttons to be more pastel colours instead of the hard blue? > > On 21 Aug,2014, at 15:48 , Luk?? Fry? wrote: > > Hey guys, > > Gabriel, who did a great job polishing the design of the AdminUI and > aligning design of Account Management screen of UPS console, > > came with a proposal to change the theme color of the UPS console, > > see screens bellow: > > > We could get this change to 1.0.x. > > WDYT? > > > ~ Lukas > > ---------- Forwarded message ---------- > From: Lukas Fryc > Date: Thu, Aug 21, 2014 at 3:44 PM > Subject: Fwd: Visual consistency for the UPS console > To: lukas.fryc at gmail.com > > > > -------- Original Message -------- Subject: Visual consistency for the > UPS console Date: Wed, 20 Aug 2014 11:51:13 -0300 From: Gabriel Cardoso > To: Lukas Fryc > > > Hi Lukas, > > As we discussed in the hangout, I worked on a proposal to improve the > visual consistency of the UPS console. What happens right now is that the > login page is using the Keycloak style (with its font-family, colours and > shapes from its logo), and the admin console has a blue top bar which is > not visually related to the AeroGear logo colours. > > I?m proposing to update the blue top bar and apply one of the logo > colours. Also, update the login screen to use this same color and change > the graphics to a shape related to the gears in the logo. You can see the > proposals in the screenshots below: > > > > > > > > In terms of time, it wouldn?t require much effort. I could do these > changes in a day. > > Thanks, > Gabriel > > Begin forwarded message: > > *From: *Matt Carrano > *Subject: **Re: Style adjustments for AeroGear* > *Date: *August 19, 2014 at 5:09:58 PM GMT-3 > *To: *Gabriel Cardoso > *Cc: *Matthias Wessendorf > > Hi Gabriel, > > I think this looks great, so it is good to go from my perspective. I > especially like that you added the gear motif as part of the background > fill for the Login page. I'm just copying in Matthias so he is aware of > this change and can just confirm that he is good with it before checking > in. BTW, what does the Cancel button do from the Login screen? Is this > needed? > > Matt > > ----- Original Message ----- > From: "Gabriel Cardoso" > To: "Matt Carrano" > Sent: Tuesday, August 19, 2014 3:39:28 PM > Subject: Style adjustments for AeroGear > > Hi Matt, > > I played a bit with the login page on that color. I believe this will make > the project look more consistent. What do you think? > > > > Do you think I can implement this changes or should I get some approval > from someone first? > > Gabriel > > --- > Gabriel Cardoso > User Experience Designer @ Red Hat > > > --- > Gabriel Cardoso > User Experience Designer @ Red Hat > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/3ad86b16/attachment.html From bruno at abstractj.org Thu Aug 21 10:15:25 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 21 Aug 2014 07:15:25 -0700 (PDT) Subject: [aerogear-dev] Fwd: Visual consistency for the UPS console In-Reply-To: References: Message-ID: <1408630525087.5365bf19@Nodemailer> +1 looks great? abstractj On Thu, Aug 21, 2014 at 10:49 AM, Luk?? Fry? wrote: > Hey guys, > Gabriel, who did a great job polishing the design of the AdminUI and > aligning design of Account Management screen of UPS console, > came with a proposal to change the theme color of the UPS console, > see screens bellow: > We could get this change to 1.0.x. > WDYT? > ~ Lukas > ---------- Forwarded message ---------- > From: Lukas Fryc > Date: Thu, Aug 21, 2014 at 3:44 PM > Subject: Fwd: Visual consistency for the UPS console > To: lukas.fryc at gmail.com > -------- Original Message -------- Subject: Visual consistency for the UPS > console Date: Wed, 20 Aug 2014 11:51:13 -0300 From: Gabriel Cardoso > To: Lukas Fryc > > Hi Lukas, > As we discussed in the hangout, I worked on a proposal to improve the > visual consistency of the UPS console. What happens right now is that the > login page is using the Keycloak style (with its font-family, colours and > shapes from its logo), and the admin console has a blue top bar which is > not visually related to the AeroGear logo colours. > I?m proposing to update the blue top bar and apply one of the logo > colours. Also, update the login screen to use this same color and change > the graphics to a shape related to the gears in the logo. You can see the > proposals in the screenshots below: > In terms of time, it wouldn?t require much effort. I could do these > changes in a day. > Thanks, > Gabriel > Begin forwarded message: > *From: *Matt Carrano > *Subject: **Re: Style adjustments for AeroGear* > *Date: *August 19, 2014 at 5:09:58 PM GMT-3 > *To: *Gabriel Cardoso > *Cc: *Matthias Wessendorf > Hi Gabriel, > I think this looks great, so it is good to go from my perspective. I > especially like that you added the gear motif as part of the background > fill for the Login page. I'm just copying in Matthias so he is aware of > this change and can just confirm that he is good with it before checking > in. BTW, what does the Cancel button do from the Login screen? Is this > needed? > Matt > ----- Original Message ----- > From: "Gabriel Cardoso" > To: "Matt Carrano" > Sent: Tuesday, August 19, 2014 3:39:28 PM > Subject: Style adjustments for AeroGear > Hi Matt, > I played a bit with the login page on that color. I believe this will make > the project look more consistent. What do you think? > Do you think I can implement this changes or should I get some approval > from someone first? > Gabriel > --- > Gabriel Cardoso > User Experience Designer @ Red Hat > --- > Gabriel Cardoso > User Experience Designer @ Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/f2f4b7da/attachment-0001.html From matzew at apache.org Thu Aug 21 11:25:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 21 Aug 2014 17:25:08 +0200 Subject: [aerogear-dev] Openshift - old versions on Push cartridge Message-ID: Hello, on the push cartrige we have a collection of old versions. They are not really needed/used... https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/tree/master/versions The UPS_1.0.0.Final will be version 1.0.0. I'd like to get rid of the old ones, except 0.13.0, which contains the Beta2 release. Any thoughts ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/de60ef0a/attachment.html From cvasilak at gmail.com Thu Aug 21 11:43:52 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 21 Aug 2014 18:43:52 +0300 Subject: [aerogear-dev] Swift - Frameworks/Static libs and Cocoapods In-Reply-To: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> References: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> Message-ID: Hi all, just some heads up on this to be a little more clear on how we approach the framework issues mentioned in this thread with our demos/quickstarts written in Swift. Because of the issue mentioned in the mail, we opted for our demos that use ?Swift? frameworks (as in the case with our push-sdk swift port[1 ), to have the library embedded in [2], instead of using the ?github submodule? process. At least for demos, we believe it?s better for the user experience to just fire it and run the project instead of manual fetching the dependent library with git. Eventually, when the framework issues is resolved by Swift, the source code of the folder containing the library will be removed and replaced with a binary framework build. Just to clear this up in case you come wondering what is this extra 'aerogear-ios-push? folder doing inside the project ;) if you have any question/comments let us know Thanks! - Christos [1] https://github.com/aerogear/aerogear-ios-push/tree/swift [2] https://github.com/cvasilak/aerogear-push-helloworld/tree/swift/ios-swift/aerogear-ios-push On Jul 22, 2014, at 11:09 AM, Christos Vasilakis wrote: > Hi all, > > want to give a heads up on the current status of Swift frameworks/static libs generation and cocoapods support. This is based on the current state of affairs, as in Xcode beta 4 (released yesterday). > > Note: "Since rapid developments are taking place, will update this thread as more information becomes available and with any breaking changes" > > First, let me start by making three observations: > > a) quoting Apple release notes[1], "Xcode does not support building static libraries that include Swift code?. You can notice that in Xcode 6 when choosing ?Cocoa Touch Static Library? there is no option to select ?Swift? as the preferred language. > > b) new in Xcode 6 is the generation of ?dynamic? frameworks for library targets. The reason for ?dynamic? linking, as explained by apple in [2], is to enable the new functionality in iOS 8 called ?extensions?. Per apple quote "Frameworks work perfectly with extensions, sharing logic that can be used by both the main application, and the bundled extensions? > > c) Dynamic framework for a swift library (the only option offered by Xcode) , in the current state requires the source code of the library to be build together with the app that uses it. This is due to the binary interface, which has not being finalised yet. Quoting apple blog [3] ("Binary Compatibility and Frameworks? section): > > ? > "While your app?s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together. > > This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift ? especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.? > ? > > What does all that gives us? > In plain form, "Distribution of the push-sdk (swift port) should be done in source form with polished documentation on how the user can add it to their own project.? > > Already, looking at the various swift-libs currently in existence[4], that is the current approach, a well-written README.md on how the user can add the library dependency into their own projects. For example, something like the section ?How to Install Library? found here [5] > > As for cocoapods, currently no support is provided for swift projects. There is an on-going discussion on the issues list found here [6] on how to effectively support ?dynamic framework? for swift projects, and still keep backwards compatibility, but things are not yet finalised. > > Let me know your thoughts / comments. > > Thanks, > Christos > > [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf > [2] https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14 > [3] https://developer.apple.com/swift/blog/?id=2 > [4] http://www.swifttoolbox.io > [5] https://github.com/Quick/Quick > [6] https://github.com/CocoaPods/CocoaPods/issues/2272 From cvasilak at gmail.com Thu Aug 21 12:36:11 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 21 Aug 2014 19:36:11 +0300 Subject: [aerogear-dev] Visual consistency for the UPS console In-Reply-To: References: <9B9327F4-475E-4DD2-9384-B2D785F698F8@redhat.com> <53F5F7A0.7080200@redhat.com> Message-ID: <1D41DD6E-14A0-4E01-BEE8-48AE914728B4@gmail.com> not an expert but they do look nice to me! +1 - Christos On Aug 21, 2014, at 4:54 PM, Matthias Wessendorf wrote: > how about 1.1.x - meaning on master ? > > > On Thu, Aug 21, 2014 at 3:48 PM, Luk?? Fry? wrote: > Hey guys, > > Gabriel, who did a great job polishing the design of the AdminUI and aligning design of Account Management screen of UPS console, > > came with a proposal to change the theme color of the UPS console, > > see screens bellow: > > > We could get this change to 1.0.x. > > WDYT? > > > ~ Lukas > > ---------- Forwarded message ---------- > From: Lukas Fryc > Date: Thu, Aug 21, 2014 at 3:44 PM > Subject: Fwd: Visual consistency for the UPS console > To: lukas.fryc at gmail.com > > > > -------- Original Message -------- > Subject: Visual consistency for the UPS console > Date: Wed, 20 Aug 2014 11:51:13 -0300 > From: Gabriel Cardoso > To: Lukas Fryc > > Hi Lukas, > > As we discussed in the hangout, I worked on a proposal to improve the visual consistency of the UPS console. What happens right now is that the login page is using the Keycloak style (with its font-family, colours and shapes from its logo), and the admin console has a blue top bar which is not visually related to the AeroGear logo colours. > > I?m proposing to update the blue top bar and apply one of the logo colours. Also, update the login screen to use this same color and change the graphics to a shape related to the gears in the logo. You can see the proposals in the screenshots below: > > > > > > > > In terms of time, it wouldn?t require much effort. I could do these changes in a day. > > Thanks, > Gabriel > > Begin forwarded message: > >> From: Matt Carrano >> Subject: Re: Style adjustments for AeroGear >> Date: August 19, 2014 at 5:09:58 PM GMT-3 >> To: Gabriel Cardoso >> Cc: Matthias Wessendorf >> >> Hi Gabriel, >> >> I think this looks great, so it is good to go from my perspective. I especially like that you added the gear motif as part of the background fill for the Login page. I'm just copying in Matthias so he is aware of this change and can just confirm that he is good with it before checking in. BTW, what does the Cancel button do from the Login screen? Is this needed? >> >> Matt >> >> ----- Original Message ----- >> From: "Gabriel Cardoso" >> To: "Matt Carrano" >> Sent: Tuesday, August 19, 2014 3:39:28 PM >> Subject: Style adjustments for AeroGear >> >> Hi Matt, >> >> I played a bit with the login page on that color. I believe this will make the project look more consistent. What do you think? >> >> >> >> Do you think I can implement this changes or should I get some approval from someone first? >> >> Gabriel >> >> --- >> Gabriel Cardoso >> User Experience Designer @ Red Hat >> > > --- > Gabriel Cardoso > User Experience Designer @ Red Hat > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/75453f27/attachment.html From cvasilak at gmail.com Thu Aug 21 12:38:46 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 21 Aug 2014 19:38:46 +0300 Subject: [aerogear-dev] Openshift - old versions on Push cartridge In-Reply-To: References: Message-ID: On Aug 21, 2014, at 6:25 PM, Matthias Wessendorf wrote: > Hello, > > on the push cartrige we have a collection of old versions. They are not really needed/used... > > https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/tree/master/versions > > The UPS_1.0.0.Final will be version 1.0.0. > > I'd like to get rid of the old ones, except 0.13.0, which contains the Beta2 release. > > Any thoughts ? +1 sounds good to remove old unused ones - Christos > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140821/338fe725/attachment-0001.html From daniel.bevenius at gmail.com Fri Aug 22 01:42:15 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 22 Aug 2014 07:42:15 +0200 Subject: [aerogear-dev] Openshift - old versions on Push cartridge In-Reply-To: References: Message-ID: +1 Out with the old. On 21 August 2014 18:38, Christos Vasilakis wrote: > > On Aug 21, 2014, at 6:25 PM, Matthias Wessendorf > wrote: > > Hello, > > on the push cartrige we have a collection of old versions. They are not > really needed/used... > > > https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/tree/master/versions > > The UPS_1.0.0.Final will be version 1.0.0. > > I'd like to get rid of the old ones, except 0.13.0, which contains the > Beta2 release. > > Any thoughts ? > > > +1 sounds good to remove old unused ones > > - > Christos > > > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140822/24bdc019/attachment.html From corinnekrych at gmail.com Fri Aug 22 03:22:24 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 22 Aug 2014 09:22:24 +0200 Subject: [aerogear-dev] iOS Bytes podcast talks about httpstubs Message-ID: Hello Folks I?d like to share with you this link http://iosbytes.envylabs.com/episodes/34-episode-34-august-21-2014 it?s a 5minutes podcast, go to 2?50 to hear our mention. This is an iOS podcast talking about an article I wrote about Swift Swizzling: http://corinnekrych.blogspot.fr/2014/07/http-stubs-lets-go-swift-swizzling.html This article is based on the work started by cvasilak about aerogear-ios-httpstubs, our latest lib addition in AeroGear organisation. ++ Corinne From daniel.bevenius at gmail.com Fri Aug 22 03:26:17 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 22 Aug 2014 09:26:17 +0200 Subject: [aerogear-dev] iOS Bytes podcast talks about httpstubs In-Reply-To: References: Message-ID: Very nice! On 22 August 2014 09:22, Corinne Krych wrote: > Hello Folks > > I?d like to share with you this link > http://iosbytes.envylabs.com/episodes/34-episode-34-august-21-2014 > it?s a 5minutes podcast, go to 2?50 to hear our mention. > > This is an iOS podcast talking about an article I wrote about Swift > Swizzling: > > http://corinnekrych.blogspot.fr/2014/07/http-stubs-lets-go-swift-swizzling.html > > This article is based on the work started by cvasilak about > aerogear-ios-httpstubs, our latest lib addition in AeroGear organisation. > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140822/a28cb4fa/attachment.html From corinnekrych at gmail.com Fri Aug 22 03:40:39 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 22 Aug 2014 09:40:39 +0200 Subject: [aerogear-dev] Swift - Frameworks/Static libs and Cocoapods In-Reply-To: References: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> Message-ID: <91DB35FA-E93C-4472-9635-7F58D2A2D2FA@gmail.com> On 21 Aug 2014, at 17:43, Christos Vasilakis wrote: > Hi all, > > just some heads up on this to be a little more clear on how we approach the framework issues mentioned in this thread with our demos/quickstarts written in Swift. > > Because of the issue mentioned in the mail, we opted for our demos that use ?Swift? frameworks (as in the case with our push-sdk swift port[1 > ), to have the library embedded in [2], instead of using the ?github submodule? process. At least for demos, we believe it?s better for the user experience to just fire it and run the project instead of manual fetching the dependent library with git. > +1 I?ll use the same approach for our swift cookbook demos coming soon > Eventually, when the framework issues is resolved by Swift, the source code of the folder containing the library will be removed and replaced with a binary framework build. > > Just to clear this up in case you come wondering what is this extra 'aerogear-ios-push? folder doing inside the project ;) > > if you have any question/comments let us know > > Thanks! > > - > Christos > > > [1] https://github.com/aerogear/aerogear-ios-push/tree/swift > [2] https://github.com/cvasilak/aerogear-push-helloworld/tree/swift/ios-swift/aerogear-ios-push > > > On Jul 22, 2014, at 11:09 AM, Christos Vasilakis wrote: >> Hi all, >> >> want to give a heads up on the current status of Swift frameworks/static libs generation and cocoapods support. This is based on the current state of affairs, as in Xcode beta 4 (released yesterday). >> >> Note: "Since rapid developments are taking place, will update this thread as more information becomes available and with any breaking changes" >> >> First, let me start by making three observations: >> >> a) quoting Apple release notes[1], "Xcode does not support building static libraries that include Swift code?. You can notice that in Xcode 6 when choosing ?Cocoa Touch Static Library? there is no option to select ?Swift? as the preferred language. >> >> b) new in Xcode 6 is the generation of ?dynamic? frameworks for library targets. The reason for ?dynamic? linking, as explained by apple in [2], is to enable the new functionality in iOS 8 called ?extensions?. Per apple quote "Frameworks work perfectly with extensions, sharing logic that can be used by both the main application, and the bundled extensions? >> >> c) Dynamic framework for a swift library (the only option offered by Xcode) , in the current state requires the source code of the library to be build together with the app that uses it. This is due to the binary interface, which has not being finalised yet. Quoting apple blog [3] ("Binary Compatibility and Frameworks? section): >> >> ? >> "While your app?s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together. >> >> This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift ? especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.? >> ? >> >> What does all that gives us? >> In plain form, "Distribution of the push-sdk (swift port) should be done in source form with polished documentation on how the user can add it to their own project.? >> >> Already, looking at the various swift-libs currently in existence[4], that is the current approach, a well-written README.md on how the user can add the library dependency into their own projects. For example, something like the section ?How to Install Library? found here [5] >> >> As for cocoapods, currently no support is provided for swift projects. There is an on-going discussion on the issues list found here [6] on how to effectively support ?dynamic framework? for swift projects, and still keep backwards compatibility, but things are not yet finalised. >> >> Let me know your thoughts / comments. >> >> Thanks, >> Christos >> >> [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf >> [2] https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14 >> [3] https://developer.apple.com/swift/blog/?id=2 >> [4] http://www.swifttoolbox.io >> [5] https://github.com/Quick/Quick >> [6] https://github.com/CocoaPods/CocoaPods/issues/2272 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Aug 22 05:59:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Aug 2014 11:59:52 +0200 Subject: [aerogear-dev] Release: Java SENDER - 1.0.0 In-Reply-To: References: Message-ID: and this PR was tested successfully w/ the 1.0.0 as well: https://github.com/aerogear/aerogear-push-quickstarts/pull/84 I clicked the button, and will give you all a heads-up, once the JAR hits Maven_Central -M On Thu, Aug 21, 2014 at 11:43 AM, Daniel Bevenius wrote: > Did the same test and it worked without issues. > > > On 21 August 2014 11:29, Luk?? Fry? wrote: > >> Tested with /w contacts-mobile-picketlink-secured and works fine. >> >> PR with upgrade for quickstart: >> https://github.com/aerogear/aerogear-push-quickstarts/pull/84 >> >> >> On Thu, Aug 21, 2014 at 11:01 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Sure, will give it a go. >>> >>> >>> On 21 August 2014 10:58, Matthias Wessendorf wrote: >>> >>>> Hi, >>>> >>>> this is basically the same version as 0.9.0 - just version alignment >>>> for our upcoming "Push 1.0.0" release. >>>> >>>> The staging repo is her: >>>> >>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3753/org/jboss/aerogear/unifiedpush-java-client/1.0.0/ >>>> >>>> Daniel Bevenius and Luk?? Fry?, can you do the tests? >>>> >>>> Thanks! >>>> Matthias >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140822/e5638536/attachment.html From lholmqui at redhat.com Fri Aug 22 08:12:25 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 22 Aug 2014 08:12:25 -0400 Subject: [aerogear-dev] iOS Bytes podcast talks about httpstubs In-Reply-To: References: Message-ID: <14043297-C073-4AA8-9B8C-1804137BE3F2@redhat.com> righteous!! On Aug 22, 2014, at 3:22 AM, Corinne Krych wrote: > Hello Folks > > I?d like to share with you this link > http://iosbytes.envylabs.com/episodes/34-episode-34-august-21-2014 > it?s a 5minutes podcast, go to 2?50 to hear our mention. > > This is an iOS podcast talking about an article I wrote about Swift Swizzling: > http://corinnekrych.blogspot.fr/2014/07/http-stubs-lets-go-swift-swizzling.html > > This article is based on the work started by cvasilak about aerogear-ios-httpstubs, our latest lib addition in AeroGear organisation. > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Fri Aug 22 08:56:15 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 22 Aug 2014 15:56:15 +0300 Subject: [aerogear-dev] iOS meeting on 22nd August In-Reply-To: References: Message-ID: <22DC3381-9207-4470-B225-3289FC12B581@gmail.com> fyi, meeting minutes: Ending meeting. Generating minutes. Be patient :) Meeting ended Fri Aug 22 12:37:05 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-22-12.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-22-12.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-22-12.00.log.html - Christos On Aug 20, 2014, at 5:30 PM, Corinne Krych wrote: > Hello iOS lovers, > > Let?s talk about 2.0.0 release coming next. > > See you Friday 22nd August at 2pm (CEST - UTC + 2hours). Here is a proposal agenda: > http://oksoclap.com/p/aerogear-ios-22082014 > > Feel free to add topics you would like to discuss. > > See you all, > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Fri Aug 22 09:30:41 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 22 Aug 2014 09:30:41 -0400 Subject: [aerogear-dev] Fwd: Visual consistency for the UPS console In-Reply-To: References: <9B9327F4-475E-4DD2-9384-B2D785F698F8@redhat.com> <53F5F7A0.7080200@redhat.com> <07B9F60B-FA56-428F-85AA-17A58D63250C@redhat.com> Message-ID: <53F74601.10507@redhat.com> On 08/21/2014 10:11 AM, Daniel Bevenius wrote: > I kinda liked the darker version I must say, but it makes more sense > to have the blue colour from the logo. Plus don't trust myself when it > comes to design questions. Just the fact that I liked the darker > version makes me thing this lighter blue must be the correct choice. +1 to the darker version. > > > > > > > On 21 August 2014 15:56, Erik Jan de Wit > wrote: > > +1 I really like the login screen and love the idea of using the > blue from the aerogear logo, but should we then also adjust the > colours of the buttons to be more pastel colours instead of the > hard blue? > > On 21 Aug,2014, at 15:48 , Luk?s( Fryc( > wrote: > >> Hey guys, >> >> Gabriel, who did a great job polishing the design of the AdminUI >> and aligning design of Account Management screen of UPS console, >> >> came with a proposal to change the theme color of the UPS console, >> >> see screens bellow: >> >> >> We could get this change to 1.0.x. >> >> WDYT? >> >> >> ~ Lukas >> >> ---------- Forwarded message ---------- >> From: *Lukas Fryc* > >> Date: Thu, Aug 21, 2014 at 3:44 PM >> Subject: Fwd: Visual consistency for the UPS console >> To: lukas.fryc at gmail.com >> >> >> >> -------- Original Message -------- >> Subject: Visual consistency for the UPS console >> Date: Wed, 20 Aug 2014 11:51:13 -0300 >> From: Gabriel Cardoso >> >> To: Lukas Fryc >> >> >> >> Hi Lukas, >> >> As we discussed in the hangout, I worked on a proposal to improve >> the visual consistency of the UPS console. What happens right now >> is that the login page is using the Keycloak style (with its >> font-family, colours and shapes from its logo), and the admin >> console has a blue top bar which is not visually related to the >> AeroGear logo colours. >> >> I'm proposing to update the blue top bar and apply one of the >> logo colours. Also, update the login screen to use this same >> color and change the graphics to a shape related to the gears in >> the logo. You can see the proposals in the screenshots below: >> >> >> >> >> >> >> >> In terms of time, it wouldn't require much effort. I could do >> these changes in a day. >> >> Thanks, >> Gabriel >> >> Begin forwarded message: >> >>> *From: *Matt Carrano >> > >>> *Subject: **Re: Style adjustments for AeroGear* >>> *Date: *August 19, 2014 at 5:09:58 PM GMT-3 >>> *To: *Gabriel Cardoso >> > >>> *Cc: *Matthias Wessendorf >> > >>> >>> Hi Gabriel, >>> >>> I think this looks great, so it is good to go from my >>> perspective. I especially like that you added the gear motif as >>> part of the background fill for the Login page. I'm just >>> copying in Matthias so he is aware of this change and can just >>> confirm that he is good with it before checking in. BTW, what >>> does the Cancel button do from the Login screen? Is this needed? >>> >>> Matt >>> >>> ----- Original Message ----- >>> From: "Gabriel Cardoso" >> > >>> To: "Matt Carrano" >> > >>> Sent: Tuesday, August 19, 2014 3:39:28 PM >>> Subject: Style adjustments for AeroGear >>> >>> Hi Matt, >>> >>> I played a bit with the login page on that color. I believe this >>> will make the project look more consistent. What do you think? >>> >>> >>> >>> Do you think I can implement this changes or should I get some >>> approval from someone first? >>> >>> Gabriel >>> >>> --- >>> Gabriel Cardoso >>> User Experience Designer @ Red Hat >>> >> >> --- >> Gabriel Cardoso >> User Experience Designer @ Red Hat >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140822/6cfbf500/attachment.html From matzew at apache.org Fri Aug 22 11:01:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Aug 2014 17:01:15 +0200 Subject: [aerogear-dev] Openshift: UnifiedPush Server on WildFly Message-ID: Hi, with the help of Farah, I was able to get our UnifiedPush Server up and running on Openshift, using the WildFly cartrige: https://github.com/aerogear/openshift-origin-cartridge-aerogear-push-wildfly Give it a test drive: rhc app create --no-git https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push-wildfly Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140822/0a7f17bd/attachment-0001.html From matzew at apache.org Fri Aug 22 11:04:41 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 22 Aug 2014 17:04:41 +0200 Subject: [aerogear-dev] Openshift: UnifiedPush Server on WildFly In-Reply-To: References: Message-ID: btw, I still need to add the SimplePush Server ;-) but that comes next week On Fri, Aug 22, 2014 at 5:01 PM, Matthias Wessendorf wrote: > Hi, > > with the help of Farah, I was able to get our UnifiedPush Server up and > running on Openshift, using the WildFly cartrige: > > > https://github.com/aerogear/openshift-origin-cartridge-aerogear-push-wildfly > > > Give it a test drive: > > rhc app create --no-git > https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push-wildfly > > > > Greetings, > Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140822/e35dfa35/attachment.html From avibelli at redhat.com Sun Aug 24 10:06:50 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Sun, 24 Aug 2014 07:06:50 -0700 (PDT) Subject: [aerogear-dev] Error while deploying UnifiedPush Server 1.0.0.Final Message-ID: <1408889210118-9002.post@n5.nabble.com> Hello all, I have just deployed on top of EAP.6.3.0.GA (fresh install) the latest version of AeroGear UnifiedPush Server, 1.0.0.Final. However, I get the following error during the deployment (and then the server is not working): 15:52:51,869 INFO [org.jboss.web] (ServerService Thread Pool -- 49) JBAS018210: Register web context: /ag-push 15:52:51,878 INFO [org.keycloak.services.managers.ApplianceBootstrap] (ServerService Thread Pool -- 51) Initializing master realm 15:52:51,895 INFO [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] (ServerService Thread Pool -- 49) **** using /WEB-INF/keycloak.json 15:52:52,580 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] (ServerService Thread Pool -- 51) JBWEB000289: Servlet Keycloak REST Interface threw load() exception: java.lang.ClassNotFoundException: org.bouncycastle.openssl.PEMWriter from [Module "deployment.auth-server.war:main" from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.3.Final-redhat-1] at org.keycloak.models.utils.KeycloakModelUtils.getPemFromKey(KeycloakModelUtils.java:67) [keycloak-model-api-1.0-rc-1.jar:] at org.keycloak.models.jpa.RealmAdapter.setPrivateKey(RealmAdapter.java:407) [keycloak-model-jpa-1.0-rc-1.jar:] at org.keycloak.models.utils.KeycloakModelUtils.generateRealmKeys(KeycloakModelUtils.java:85) [keycloak-model-api-1.0-rc-1.jar:] at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:61) [keycloak-services-1.0-rc-1.jar:] at org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33) [keycloak-services-1.0-rc-1.jar:] at org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137) [keycloak-services-1.0-rc-1.jar:] at org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40) [classes:] at org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:86) [keycloak-services-1.0-rc-1.jar:] at org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.(UpsKeycloakApplication.java:35) [classes:] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_45] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_45] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_45] at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_45] at org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:290) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:267) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:228) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1194) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1100) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3591) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3798) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_45] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] at org.jboss.threads.JBossThread.run(JBossThread.java:122) 15:52:52,814 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "ag-push.war" (runtime-name : "ag-push.war") 15:52:52,815 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "auth-server.war" (runtime-name : "auth-server.war") 15:55:50,754 INFO [org.keycloak.services.resources.KeycloakApplication] (http-/127.0.0.1:8080-1) Loaded config from vfs:/content/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json The previous version, 1.0.0.Beta2, works with no problems at all. Am I missing something? Thanks Andrea -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Error-while-deploying-UnifiedPush-Server-1-0-0-Final-tp9002.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Sun Aug 24 12:48:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 24 Aug 2014 18:48:53 +0200 Subject: [aerogear-dev] Error while deploying UnifiedPush Server 1.0.0.Final In-Reply-To: <1408889210118-9002.post@n5.nabble.com> References: <1408889210118-9002.post@n5.nabble.com> Message-ID: Hi Andrea, I am not seeing that. I killed my local EAP 6.3 (JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19)) and deployed the database file (unifiedpush-h2-ds.xml), followed by these two server WAR files: * https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/org/jboss/aerogear/unifiedpush/unifiedpush-auth-server/1.0.0.Final/unifiedpush-auth-server-1.0.0.Final.war * https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/org/jboss/aerogear/unifiedpush/unifiedpush-server-as7/1.0.0.Final/unifiedpush-server-as7-1.0.0.Final.war works fine here. It deploys and I can login and create push applications. On Sun, Aug 24, 2014 at 4:06 PM, Andrea Vibelli wrote: > Hello all, > I have just deployed on top of EAP.6.3.0.GA (fresh install) the latest > version of AeroGear UnifiedPush Server, 1.0.0.Final. > However, I get the following error during the deployment (and then the > server is not working): > > 15:52:51,869 INFO [org.jboss.web] (ServerService Thread Pool -- 49) > JBAS018210: Register web context: /ag-push > 15:52:51,878 INFO [org.keycloak.services.managers.ApplianceBootstrap] > (ServerService Thread Pool -- 51) Initializing master realm > 15:52:51,895 INFO [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] > (ServerService Thread Pool -- 49) **** using /WEB-INF/keycloak.json > 15:52:52,580 ERROR > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] > (ServerService Thread Pool -- 51) JBWEB000289: Servlet Keycloak REST > Interface threw load() exception: java.lang.ClassNotFoundException: > org.bouncycastle.openssl.PEMWriter from [Module > "deployment.auth-server.war:main" from Service Module Loader] > at > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) > [jboss-modules.jar:1.3.3.Final-redhat-1] > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) > [jboss-modules.jar:1.3.3.Final-redhat-1] > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) > [jboss-modules.jar:1.3.3.Final-redhat-1] > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) > [jboss-modules.jar:1.3.3.Final-redhat-1] > at > > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) > [jboss-modules.jar:1.3.3.Final-redhat-1] > at > > org.keycloak.models.utils.KeycloakModelUtils.getPemFromKey(KeycloakModelUtils.java:67) > [keycloak-model-api-1.0-rc-1.jar:] > at > org.keycloak.models.jpa.RealmAdapter.setPrivateKey(RealmAdapter.java:407) > [keycloak-model-jpa-1.0-rc-1.jar:] > at > > org.keycloak.models.utils.KeycloakModelUtils.generateRealmKeys(KeycloakModelUtils.java:85) > [keycloak-model-api-1.0-rc-1.jar:] > at > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:61) > [keycloak-services-1.0-rc-1.jar:] > at > > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33) > [keycloak-services-1.0-rc-1.jar:] > at > > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137) > [keycloak-services-1.0-rc-1.jar:] > at > > org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40) > [classes:] > at > > org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:86) > [keycloak-services-1.0-rc-1.jar:] > at > > org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.(UpsKeycloakApplication.java:35) > [classes:] > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > [rt.jar:1.7.0_45] > at > > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > [rt.jar:1.7.0_45] > at > > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > [rt.jar:1.7.0_45] > at java.lang.reflect.Constructor.newInstance(Constructor.java:526) > [rt.jar:1.7.0_45] > at > > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132) > [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at > > org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:290) > [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at > > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:267) > [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at > > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:228) > [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at > > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67) > [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at > > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at > > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1194) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1100) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3591) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:3798) > [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at > > org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) > [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at > > org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) > [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at > > org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) > [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > [rt.jar:1.7.0_45] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) > [rt.jar:1.7.0_45] > at > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > [rt.jar:1.7.0_45] > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > [rt.jar:1.7.0_45] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > > 15:52:52,814 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) > JBAS018559: Deployed "ag-push.war" (runtime-name : "ag-push.war") > 15:52:52,815 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) > JBAS018559: Deployed "auth-server.war" (runtime-name : "auth-server.war") > 15:55:50,754 INFO [org.keycloak.services.resources.KeycloakApplication] > (http-/127.0.0.1:8080-1) Loaded config from > vfs:/content/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json > > The previous version, 1.0.0.Beta2, works with no problems at all. > Am I missing something? > > Thanks > Andrea > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Error-while-deploying-UnifiedPush-Server-1-0-0-Final-tp9002.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140824/edb139c1/attachment-0001.html From matzew at apache.org Sun Aug 24 14:06:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 24 Aug 2014 20:06:08 +0200 Subject: [aerogear-dev] Error while deploying UnifiedPush Server 1.0.0.Final In-Reply-To: References: <1408889210118-9002.post@n5.nabble.com> Message-ID: and, I just checked, the bouncycastle jar (bcprov-jdk16-1.46.jar), used in that WAR file, does contain the org.bouncycastle.openssl.PEMWriter class On Sun, Aug 24, 2014 at 6:48 PM, Matthias Wessendorf wrote: > Hi Andrea, > > I am not seeing that. I killed my local EAP 6.3 (JBoss EAP 6.3.0.GA (AS > 7.4.0.Final-redhat-19)) and deployed the database file > (unifiedpush-h2-ds.xml), followed by these two server WAR files: > * > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/org/jboss/aerogear/unifiedpush/unifiedpush-auth-server/1.0.0.Final/unifiedpush-auth-server-1.0.0.Final.war > > * > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/org/jboss/aerogear/unifiedpush/unifiedpush-server-as7/1.0.0.Final/unifiedpush-server-as7-1.0.0.Final.war > > works fine here. It deploys and I can login and create push applications. > > > > > > > On Sun, Aug 24, 2014 at 4:06 PM, Andrea Vibelli > wrote: > >> Hello all, >> I have just deployed on top of EAP.6.3.0.GA (fresh install) the latest >> version of AeroGear UnifiedPush Server, 1.0.0.Final. >> However, I get the following error during the deployment (and then the >> server is not working): >> >> 15:52:51,869 INFO [org.jboss.web] (ServerService Thread Pool -- 49) >> JBAS018210: Register web context: /ag-push >> 15:52:51,878 INFO [org.keycloak.services.managers.ApplianceBootstrap] >> (ServerService Thread Pool -- 51) Initializing master realm >> 15:52:51,895 INFO [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] >> (ServerService Thread Pool -- 49) **** using /WEB-INF/keycloak.json >> 15:52:52,580 ERROR >> >> [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] >> (ServerService Thread Pool -- 51) JBWEB000289: Servlet Keycloak REST >> Interface threw load() exception: java.lang.ClassNotFoundException: >> org.bouncycastle.openssl.PEMWriter from [Module >> "deployment.auth-server.war:main" from Service Module Loader] >> at >> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) >> [jboss-modules.jar:1.3.3.Final-redhat-1] >> at >> >> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) >> [jboss-modules.jar:1.3.3.Final-redhat-1] >> at >> >> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) >> [jboss-modules.jar:1.3.3.Final-redhat-1] >> at >> >> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) >> [jboss-modules.jar:1.3.3.Final-redhat-1] >> at >> >> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) >> [jboss-modules.jar:1.3.3.Final-redhat-1] >> at >> >> org.keycloak.models.utils.KeycloakModelUtils.getPemFromKey(KeycloakModelUtils.java:67) >> [keycloak-model-api-1.0-rc-1.jar:] >> at >> org.keycloak.models.jpa.RealmAdapter.setPrivateKey(RealmAdapter.java:407) >> [keycloak-model-jpa-1.0-rc-1.jar:] >> at >> >> org.keycloak.models.utils.KeycloakModelUtils.generateRealmKeys(KeycloakModelUtils.java:85) >> [keycloak-model-api-1.0-rc-1.jar:] >> at >> >> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:61) >> [keycloak-services-1.0-rc-1.jar:] >> at >> >> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33) >> [keycloak-services-1.0-rc-1.jar:] >> at >> >> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137) >> [keycloak-services-1.0-rc-1.jar:] >> at >> >> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40) >> [classes:] >> at >> >> org.keycloak.services.resources.KeycloakApplication.(KeycloakApplication.java:86) >> [keycloak-services-1.0-rc-1.jar:] >> at >> >> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.(UpsKeycloakApplication.java:35) >> [classes:] >> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >> Method) >> [rt.jar:1.7.0_45] >> at >> >> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >> [rt.jar:1.7.0_45] >> at >> >> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >> [rt.jar:1.7.0_45] >> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) >> [rt.jar:1.7.0_45] >> at >> >> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132) >> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >> at >> >> org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:290) >> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >> at >> >> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:267) >> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >> at >> >> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:228) >> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >> at >> >> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67) >> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >> at >> >> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >> at >> >> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1194) >> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] >> at >> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1100) >> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] >> at >> >> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3591) >> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] >> at >> org.apache.catalina.core.StandardContext.start(StandardContext.java:3798) >> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] >> at >> >> org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) >> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] >> at >> >> org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) >> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] >> at >> >> org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) >> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] >> at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >> [rt.jar:1.7.0_45] >> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >> [rt.jar:1.7.0_45] >> at >> >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> [rt.jar:1.7.0_45] >> at >> >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> [rt.jar:1.7.0_45] >> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] >> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >> >> 15:52:52,814 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) >> JBAS018559: Deployed "ag-push.war" (runtime-name : "ag-push.war") >> 15:52:52,815 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) >> JBAS018559: Deployed "auth-server.war" (runtime-name : "auth-server.war") >> 15:55:50,754 INFO [org.keycloak.services.resources.KeycloakApplication] >> (http-/127.0.0.1:8080-1) Loaded config from >> vfs:/content/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json >> >> The previous version, 1.0.0.Beta2, works with no problems at all. >> Am I missing something? >> >> Thanks >> Andrea >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/Error-while-deploying-UnifiedPush-Server-1-0-0-Final-tp9002.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140824/53954cba/attachment.html From daniel.bevenius at gmail.com Mon Aug 25 02:45:33 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 25 Aug 2014 08:45:33 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140825 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/98e237b6/attachment.html From daniel.bevenius at gmail.com Mon Aug 25 03:30:45 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 25 Aug 2014 09:30:45 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap Message-ID: We have been working on a roadmap for DataSync to help our planning of the features and time frames. A suggestion for the roadmap can be found in this branch: https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap If you don't feel like building it yourself you can try this OpenShift instance: http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ Please note that the dates are just made up and something that we need help from each client library project to provide feedback on what is reasonable. Let us know what you think and from the feedback given, either here or as PRs, we will try to break this down further and start creating JIRAs to link to the roadmap. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/890b4c4d/attachment.html From avibelli at redhat.com Mon Aug 25 03:47:20 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Mon, 25 Aug 2014 00:47:20 -0700 (PDT) Subject: [aerogear-dev] Error while deploying UnifiedPush Server 1.0.0.Final In-Reply-To: References: <1408889210118-9002.post@n5.nabble.com> Message-ID: <1408952840865-9007.post@n5.nabble.com> Hi Matt, I figured out what was wrong on my side...I had a dirty local maven repository and the bcprov-jdk16-1.46.jar binary was broken (1.6kb binary instead of 1.9Mb). I cleaned the maven repo, rebuilt the server and everything works as expected. Thanks and sorry for the scare I have generated :-) Andrea Matthias Wessendorf wrote > and, I just checked, the bouncycastle jar (bcprov-jdk16-1.46.jar), used in > that WAR file, does contain the org.bouncycastle.openssl.PEMWriter class > > > > > On Sun, Aug 24, 2014 at 6:48 PM, Matthias Wessendorf < > matzew@ > > > wrote: > >> Hi Andrea, >> >> I am not seeing that. I killed my local EAP 6.3 (JBoss EAP 6.3.0.GA (AS >> 7.4.0.Final-redhat-19)) and deployed the database file >> (unifiedpush-h2-ds.xml), followed by these two server WAR files: >> * >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/org/jboss/aerogear/unifiedpush/unifiedpush-auth-server/1.0.0.Final/unifiedpush-auth-server-1.0.0.Final.war >> >> * >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/org/jboss/aerogear/unifiedpush/unifiedpush-server-as7/1.0.0.Final/unifiedpush-server-as7-1.0.0.Final.war >> >> works fine here. It deploys and I can login and create push applications. >> >> >> >> >> >> >> On Sun, Aug 24, 2014 at 4:06 PM, Andrea Vibelli < > avibelli@ > > >> wrote: >> >>> Hello all, >>> I have just deployed on top of EAP.6.3.0.GA (fresh install) the latest >>> version of AeroGear UnifiedPush Server, 1.0.0.Final. >>> However, I get the following error during the deployment (and then the >>> server is not working): >>> >>> 15:52:51,869 INFO [org.jboss.web] (ServerService Thread Pool -- 49) >>> JBAS018210: Register web context: /ag-push >>> 15:52:51,878 INFO [org.keycloak.services.managers.ApplianceBootstrap] >>> (ServerService Thread Pool -- 51) Initializing master realm >>> 15:52:51,895 INFO >>> [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] >>> (ServerService Thread Pool -- 49) **** using /WEB-INF/keycloak.json >>> 15:52:52,580 ERROR >>> >>> [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] >>> (ServerService Thread Pool -- 51) JBWEB000289: Servlet Keycloak REST >>> Interface threw load() exception: java.lang.ClassNotFoundException: >>> org.bouncycastle.openssl.PEMWriter from [Module >>> "deployment.auth-server.war:main" from Service Module Loader] >>> at >>> org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) >>> [jboss-modules.jar:1.3.3.Final-redhat-1] >>> at >>> >>> org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) >>> [jboss-modules.jar:1.3.3.Final-redhat-1] >>> at >>> >>> org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) >>> [jboss-modules.jar:1.3.3.Final-redhat-1] >>> at >>> >>> org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) >>> [jboss-modules.jar:1.3.3.Final-redhat-1] >>> at >>> >>> org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) >>> [jboss-modules.jar:1.3.3.Final-redhat-1] >>> at >>> >>> org.keycloak.models.utils.KeycloakModelUtils.getPemFromKey(KeycloakModelUtils.java:67) >>> [keycloak-model-api-1.0-rc-1.jar:] >>> at >>> org.keycloak.models.jpa.RealmAdapter.setPrivateKey(RealmAdapter.java:407) >>> [keycloak-model-jpa-1.0-rc-1.jar:] >>> at >>> >>> org.keycloak.models.utils.KeycloakModelUtils.generateRealmKeys(KeycloakModelUtils.java:85) >>> [keycloak-model-api-1.0-rc-1.jar:] >>> at >>> >>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:61) >>> [keycloak-services-1.0-rc-1.jar:] >>> at >>> >>> org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33) >>> [keycloak-services-1.0-rc-1.jar:] >>> at >>> >>> org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137) >>> [keycloak-services-1.0-rc-1.jar:] >>> at >>> >>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40) >>> [classes:] >>> at >>> >>> org.keycloak.services.resources.KeycloakApplication. > > (KeycloakApplication.java:86) >>> [keycloak-services-1.0-rc-1.jar:] >>> at >>> >>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication. > > (UpsKeycloakApplication.java:35) >>> [classes:] >>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native >>> Method) >>> [rt.jar:1.7.0_45] >>> at >>> >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) >>> [rt.jar:1.7.0_45] >>> at >>> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) >>> [rt.jar:1.7.0_45] >>> at >>> java.lang.reflect.Constructor.newInstance(Constructor.java:526) >>> [rt.jar:1.7.0_45] >>> at >>> >>> org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132) >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >>> at >>> >>> org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:290) >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >>> at >>> >>> org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:267) >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >>> at >>> >>> org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:228) >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >>> at >>> >>> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67) >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >>> at >>> >>> org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] >>> at >>> >>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1194) >>> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] >>> at >>> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1100) >>> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] >>> at >>> >>> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3591) >>> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] >>> at >>> org.apache.catalina.core.StandardContext.start(StandardContext.java:3798) >>> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] >>> at >>> >>> org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) >>> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] >>> at >>> >>> org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) >>> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] >>> at >>> >>> org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) >>> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] >>> at >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >>> [rt.jar:1.7.0_45] >>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) >>> [rt.jar:1.7.0_45] >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >>> [rt.jar:1.7.0_45] >>> at >>> >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >>> [rt.jar:1.7.0_45] >>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] >>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) >>> >>> 15:52:52,814 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) >>> JBAS018559: Deployed "ag-push.war" (runtime-name : "ag-push.war") >>> 15:52:52,815 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) >>> JBAS018559: Deployed "auth-server.war" (runtime-name : >>> "auth-server.war") >>> 15:55:50,754 INFO [org.keycloak.services.resources.KeycloakApplication] >>> (http-/127.0.0.1:8080-1) Loaded config from >>> vfs:/content/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json >>> >>> The previous version, 1.0.0.Beta2, works with no problems at all. >>> Am I missing something? >>> >>> Thanks >>> Andrea >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-dev.1069024.n5.nabble.com/Error-while-deploying-UnifiedPush-Server-1-0-0-Final-tp9002.html >>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> aerogear-dev mailing list >>> > aerogear-dev at .jboss >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at .jboss > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Error-while-deploying-UnifiedPush-Server-1-0-0-Final-tp9002p9007.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Mon Aug 25 03:57:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 25 Aug 2014 09:57:28 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: 0.2.0 (Nov, 2015) Conflict resolvers is Nov, 2014, right? On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius wrote: > We have been working on a roadmap for DataSync to help our planning of the > features and time frames. > > A suggestion for the roadmap can be found in this branch: > https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap > > If you don't feel like building it yourself you can try this OpenShift > instance: > http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ > > Please note that the dates are just made up and something that we need > help from each client library project to provide feedback on what is > reasonable. > > Let us know what you think and from the feedback given, either here or as > PRs, we will try to break this down further and start creating JIRAs to > link to the roadmap. > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/3027e926/attachment.html From matzew at apache.org Mon Aug 25 03:58:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 25 Aug 2014 09:58:03 +0200 Subject: [aerogear-dev] Error while deploying UnifiedPush Server 1.0.0.Final In-Reply-To: <1408952840865-9007.post@n5.nabble.com> References: <1408889210118-9002.post@n5.nabble.com> <1408952840865-9007.post@n5.nabble.com> Message-ID: awesome, thanks for the report! you scared me off my couch last night :-) On Mon, Aug 25, 2014 at 9:47 AM, Andrea Vibelli wrote: > Hi Matt, > I figured out what was wrong on my side...I had a dirty local maven > repository and the bcprov-jdk16-1.46.jar binary was broken (1.6kb binary > instead of 1.9Mb). > I cleaned the maven repo, rebuilt the server and everything works as > expected. > Thanks and sorry for the scare I have generated :-) > > Andrea > > > > Matthias Wessendorf wrote > > and, I just checked, the bouncycastle jar (bcprov-jdk16-1.46.jar), used > in > > that WAR file, does contain the org.bouncycastle.openssl.PEMWriter class > > > > > > > > > > On Sun, Aug 24, 2014 at 6:48 PM, Matthias Wessendorf < > > > matzew@ > > > > > > wrote: > > > >> Hi Andrea, > >> > >> I am not seeing that. I killed my local EAP 6.3 (JBoss EAP 6.3.0.GA (AS > >> 7.4.0.Final-redhat-19)) and deployed the database file > >> (unifiedpush-h2-ds.xml), followed by these two server WAR files: > >> * > >> > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/org/jboss/aerogear/unifiedpush/unifiedpush-auth-server/1.0.0.Final/unifiedpush-auth-server-1.0.0.Final.war > >> > >> * > >> > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/org/jboss/aerogear/unifiedpush/unifiedpush-server-as7/1.0.0.Final/unifiedpush-server-as7-1.0.0.Final.war > >> > >> works fine here. It deploys and I can login and create push > applications. > >> > >> > >> > >> > >> > >> > >> On Sun, Aug 24, 2014 at 4:06 PM, Andrea Vibelli < > > > avibelli@ > > > > > >> wrote: > >> > >>> Hello all, > >>> I have just deployed on top of EAP.6.3.0.GA (fresh install) the latest > >>> version of AeroGear UnifiedPush Server, 1.0.0.Final. > >>> However, I get the following error during the deployment (and then the > >>> server is not working): > >>> > >>> 15:52:51,869 INFO [org.jboss.web] (ServerService Thread Pool -- 49) > >>> JBAS018210: Register web context: /ag-push > >>> 15:52:51,878 INFO [org.keycloak.services.managers.ApplianceBootstrap] > >>> (ServerService Thread Pool -- 51) Initializing master realm > >>> 15:52:51,895 INFO > >>> [org.keycloak.adapters.as7.KeycloakAuthenticatorValve] > >>> (ServerService Thread Pool -- 49) **** using /WEB-INF/keycloak.json > >>> 15:52:52,580 ERROR > >>> > >>> > [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/auth]] > >>> (ServerService Thread Pool -- 51) JBWEB000289: Servlet Keycloak REST > >>> Interface threw load() exception: java.lang.ClassNotFoundException: > >>> org.bouncycastle.openssl.PEMWriter from [Module > >>> "deployment.auth-server.war:main" from Service Module Loader] > >>> at > >>> > org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) > >>> [jboss-modules.jar:1.3.3.Final-redhat-1] > >>> at > >>> > >>> > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) > >>> [jboss-modules.jar:1.3.3.Final-redhat-1] > >>> at > >>> > >>> > org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) > >>> [jboss-modules.jar:1.3.3.Final-redhat-1] > >>> at > >>> > >>> > org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) > >>> [jboss-modules.jar:1.3.3.Final-redhat-1] > >>> at > >>> > >>> > org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) > >>> [jboss-modules.jar:1.3.3.Final-redhat-1] > >>> at > >>> > >>> > org.keycloak.models.utils.KeycloakModelUtils.getPemFromKey(KeycloakModelUtils.java:67) > >>> [keycloak-model-api-1.0-rc-1.jar:] > >>> at > >>> > org.keycloak.models.jpa.RealmAdapter.setPrivateKey(RealmAdapter.java:407) > >>> [keycloak-model-jpa-1.0-rc-1.jar:] > >>> at > >>> > >>> > org.keycloak.models.utils.KeycloakModelUtils.generateRealmKeys(KeycloakModelUtils.java:85) > >>> [keycloak-model-api-1.0-rc-1.jar:] > >>> at > >>> > >>> > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:61) > >>> [keycloak-services-1.0-rc-1.jar:] > >>> at > >>> > >>> > org.keycloak.services.managers.ApplianceBootstrap.bootstrap(ApplianceBootstrap.java:33) > >>> [keycloak-services-1.0-rc-1.jar:] > >>> at > >>> > >>> > org.keycloak.services.resources.KeycloakApplication.setupDefaultRealm(KeycloakApplication.java:137) > >>> [keycloak-services-1.0-rc-1.jar:] > >>> at > >>> > >>> > org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication.setupDefaultRealm(UpsKeycloakApplication.java:40) > >>> [classes:] > >>> at > >>> > >>> org.keycloak.services.resources.KeycloakApplication. > > > > (KeycloakApplication.java:86) > >>> [keycloak-services-1.0-rc-1.jar:] > >>> at > >>> > >>> org.jboss.aerogear.unifiedpush.keycloak.UpsKeycloakApplication. > > > > (UpsKeycloakApplication.java:35) > >>> [classes:] > >>> at > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > >>> Method) > >>> [rt.jar:1.7.0_45] > >>> at > >>> > >>> > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) > >>> [rt.jar:1.7.0_45] > >>> at > >>> > >>> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > >>> [rt.jar:1.7.0_45] > >>> at > >>> java.lang.reflect.Constructor.newInstance(Constructor.java:526) > >>> [rt.jar:1.7.0_45] > >>> at > >>> > >>> > org.jboss.resteasy.core.ConstructorInjectorImpl.construct(ConstructorInjectorImpl.java:132) > >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > >>> at > >>> > >>> > org.jboss.resteasy.spi.ResteasyDeployment.createFromInjectorFactory(ResteasyDeployment.java:290) > >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > >>> at > >>> > >>> > org.jboss.resteasy.spi.ResteasyDeployment.createApplication(ResteasyDeployment.java:267) > >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > >>> at > >>> > >>> > org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:228) > >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > >>> at > >>> > >>> > org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:67) > >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > >>> at > >>> > >>> > org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) > >>> [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > >>> at > >>> > >>> > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1194) > >>> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > >>> at > >>> > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1100) > >>> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > >>> at > >>> > >>> > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3591) > >>> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > >>> at > >>> > org.apache.catalina.core.StandardContext.start(StandardContext.java:3798) > >>> [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > >>> at > >>> > >>> > org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) > >>> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > >>> at > >>> > >>> > org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) > >>> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > >>> at > >>> > >>> > org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) > >>> [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > >>> at > >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > >>> [rt.jar:1.7.0_45] > >>> at java.util.concurrent.FutureTask.run(FutureTask.java:262) > >>> [rt.jar:1.7.0_45] > >>> at > >>> > >>> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > >>> [rt.jar:1.7.0_45] > >>> at > >>> > >>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > >>> [rt.jar:1.7.0_45] > >>> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] > >>> at org.jboss.threads.JBossThread.run(JBossThread.java:122) > >>> > >>> 15:52:52,814 INFO [org.jboss.as.server] (DeploymentScanner-threads - > 2) > >>> JBAS018559: Deployed "ag-push.war" (runtime-name : "ag-push.war") > >>> 15:52:52,815 INFO [org.jboss.as.server] (DeploymentScanner-threads - > 2) > >>> JBAS018559: Deployed "auth-server.war" (runtime-name : > >>> "auth-server.war") > >>> 15:55:50,754 INFO > [org.keycloak.services.resources.KeycloakApplication] > >>> (http-/127.0.0.1:8080-1) Loaded config from > >>> > vfs:/content/auth-server.war/WEB-INF/classes/META-INF/keycloak-server.json > >>> > >>> The previous version, 1.0.0.Beta2, works with no problems at all. > >>> Am I missing something? > >>> > >>> Thanks > >>> Andrea > >>> > >>> > >>> > >>> -- > >>> View this message in context: > >>> > http://aerogear-dev.1069024.n5.nabble.com/Error-while-deploying-UnifiedPush-Server-1-0-0-Final-tp9002.html > >>> Sent from the aerogear-dev mailing list archive at Nabble.com. > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> > > > aerogear-dev at .jboss > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > > aerogear-dev at .jboss > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Error-while-deploying-UnifiedPush-Server-1-0-0-Final-tp9002p9007.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/d53b8b33/attachment-0001.html From daniel.bevenius at gmail.com Mon Aug 25 03:58:35 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 25 Aug 2014 09:58:35 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: >is Nov, 2014, right? Yep, sorry that should be 2015. I'll correct that. Thx On 25 August 2014 09:57, Matthias Wessendorf wrote: > 0.2.0 (Nov, 2015) Conflict resolvers > is Nov, 2014, right? > > > On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> We have been working on a roadmap for DataSync to help our planning of >> the features and time frames. >> >> A suggestion for the roadmap can be found in this branch: >> https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap >> >> If you don't feel like building it yourself you can try this OpenShift >> instance: >> http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ >> >> Please note that the dates are just made up and something that we need >> help from each client library project to provide feedback on what is >> reasonable. >> >> Let us know what you think and from the feedback given, either here or as >> PRs, we will try to break this down further and start creating JIRAs to >> link to the roadmap. >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/b450abd6/attachment.html From lukas.fryc at gmail.com Mon Aug 25 05:20:28 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 25 Aug 2014 11:20:28 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: Hey Dan, this sounds good. I expect in the mean time we should also play with prototypes and figure out what approaches fit best the needs, and evaluate that functionally and performance-wise on sample apps. Something what I'm missing is more comprehensive elaboration / insight in what are the target use cases and requirements on final architecture: *Requirements:* * integrate /w any general REST interface (compliant with given limitations) ** HATEOAS-compliant backend? ** generic JAX-RS? * integrate seamlessly with LiveOak *Use cases / end-user stories:* * mobile sales client * mobile warehouse manager * delivery agent Inspiration: https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit I expect we target different use cases in different phases. So we could indicate what use cases are valid in what phase. Should we brainstorm this on wiki or so? Cheers! ~ Lukas On Mon, Aug 25, 2014 at 9:58 AM, Daniel Bevenius wrote: > >is Nov, 2014, right? > Yep, sorry that should be 2015. I'll correct that. Thx > > > On 25 August 2014 09:57, Matthias Wessendorf wrote: > >> 0.2.0 (Nov, 2015) Conflict resolvers >> is Nov, 2014, right? >> >> >> On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> We have been working on a roadmap for DataSync to help our planning of >>> the features and time frames. >>> >>> A suggestion for the roadmap can be found in this branch: >>> >>> https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap >>> >>> If you don't feel like building it yourself you can try this OpenShift >>> instance: >>> http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ >>> >>> Please note that the dates are just made up and something that we need >>> help from each client library project to provide feedback on what is >>> reasonable. >>> >>> Let us know what you think and from the feedback given, either here or >>> as PRs, we will try to break this down further and start creating JIRAs to >>> link to the roadmap. >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/48f00bd9/attachment.html From edewit at redhat.com Mon Aug 25 05:21:09 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 25 Aug 2014 11:21:09 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Final In-Reply-To: References: Message-ID: <8B3D8899-8AB4-4F5D-9E83-B0A12EFC9ED9@redhat.com> Tested the cordova plugin with the UPS android and iOS and worked like a charm. On 21 Aug,2014, at 11:41 , Matthias Wessendorf wrote: > Hello folks! > > we are getting really close to our 1.0.0 release! In fact, it's now under testing/review. Thank you very much, guys!!!! > > Note this release contains a handful fixes on-top of the last BETA2 release. To name a few highlights: > > * Keycloak rc-1 usage > * UI improvements (e.g. new style of the account mgmt section, and more links to docs/guides) > * APNs fixes: improved server-side logging and fixing broken iOS Variant updates > > The team did an outstanding job to get to this point! Thanks again guys! > > Details on all the JIRAs can be found here: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754 > > The staging repository is located here: > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/ > > For testing this review, I nominate Corinne Krych, Erik Jan de Wit and Tadeas Kriz > > Regarding Docker, I have sent a PR against Bruno's repo, to go w/ the WAR files from the above staging repo: > https://github.com/abstractj/docker/pull/8 > > > Let me know the results of your testing! > If I hear nothing bad by Tuesday (August 26th) evening, the release to maven central will happen on Wednesday morning; > > > > NOTE: Once this release has been approved the matching tag will be used to get the OpenShift online bits updated! > > > Greetings, > Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/305ffc87/attachment.html From matzew at apache.org Mon Aug 25 05:22:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 25 Aug 2014 11:22:06 +0200 Subject: [aerogear-dev] Release: Java SENDER - 1.0.0 In-Reply-To: References: Message-ID: Hello, this software hit maven central over the weekend and its README has been updated to show usage of the latest (1.0.0) -M On Fri, Aug 22, 2014 at 11:59 AM, Matthias Wessendorf wrote: > and this PR was tested successfully w/ the 1.0.0 as well: > > https://github.com/aerogear/aerogear-push-quickstarts/pull/84 > > > I clicked the button, and will give you all a heads-up, once the JAR hits > Maven_Central > > > -M > > > On Thu, Aug 21, 2014 at 11:43 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Did the same test and it worked without issues. >> >> >> On 21 August 2014 11:29, Luk?? Fry? wrote: >> >>> Tested with /w contacts-mobile-picketlink-secured and works fine. >>> >>> PR with upgrade for quickstart: >>> https://github.com/aerogear/aerogear-push-quickstarts/pull/84 >>> >>> >>> On Thu, Aug 21, 2014 at 11:01 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Sure, will give it a go. >>>> >>>> >>>> On 21 August 2014 10:58, Matthias Wessendorf wrote: >>>> >>>>> Hi, >>>>> >>>>> this is basically the same version as 0.9.0 - just version alignment >>>>> for our upcoming "Push 1.0.0" release. >>>>> >>>>> The staging repo is her: >>>>> >>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3753/org/jboss/aerogear/unifiedpush-java-client/1.0.0/ >>>>> >>>>> Daniel Bevenius and Luk?? Fry?, can you do the tests? >>>>> >>>>> Thanks! >>>>> Matthias >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/f6346d2f/attachment-0001.html From daniel.bevenius at gmail.com Mon Aug 25 06:39:00 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 25 Aug 2014 12:39:00 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: >I expect in the mean time we should also play with prototypes and figure out what approaches fit best the needs, > and evaluate that functionally and performance-wise on sample apps. Yeah, we should definitely do that and especially with the later version as we still don't know the exact direction there. >Something what I'm missing is more comprehensive elaboration / insight in what are the target use cases and requirements on final architecture: Yeah, we should probably have some links from the road map to a page that elaborates more on these. I thought having too much in the road map would not be very nice but rather keep it pretty simple. We already have some information in the Specifications section [1] and perhaps that is the correct place to add such details and then link to them from the roadmap. What do you (all) think? >* integrate /w any general REST interface (compliant with given limitations) For the first stage we're thinking that the only requirement would be that the server can detect a conflict and return a 409 accompanied with the latest version of that the server has. This is what was discussed at the f2f and which Erik has a Forge plugin to generate. But the "real" data sync version will have much more impact on the backend and it would have to follow an application protocol that we define. >HATEOAS-compliant backend? Does this differ from the REST interface describe above now that some background information was provided? If it does that it would be great to either gather them here or that we add to aerogear.org. I'll push the branch to master so we can all work off it. > generic JAX-RS? Not sure about this, but would Erik's Forge plugin take care the generic JAX-RS backend case. Users would not need to use Forge if they choose not to, and we should document the requirements upon the backend like described in the first version. Again, if there are things we've missed then please add them. >*Use cases / end-user stories:* These could be added to the existing use cases I think. See the last section of [1]. Thanks for comments and the link to that document, I'll read through it. [1] http://diy-dbevenius.rhcloud.com/docs/specs/aerogear-data-sync/ On 25 August 2014 11:20, Luk?? Fry? wrote: > Hey Dan, > > this sounds good. > > I expect in the mean time we should also play with prototypes and figure > out what approaches fit best the needs, > and evaluate that functionally and performance-wise on sample apps. > > > > Something what I'm missing is more comprehensive elaboration / insight in > what are the target use cases and requirements on final architecture: > > *Requirements:* > > * integrate /w any general REST interface (compliant with given > limitations) > ** HATEOAS-compliant backend? > ** generic JAX-RS? > * integrate seamlessly with LiveOak > > *Use cases / end-user stories:* > > * mobile sales client > * mobile warehouse manager > * delivery agent > > Inspiration: > https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit > > > I expect we target different use cases in different phases. > So we could indicate what use cases are valid in what phase. > > Should we brainstorm this on wiki or so? > > > Cheers! > > ~ Lukas > > > > On Mon, Aug 25, 2014 at 9:58 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> >is Nov, 2014, right? >> Yep, sorry that should be 2015. I'll correct that. Thx >> >> >> On 25 August 2014 09:57, Matthias Wessendorf wrote: >> >>> 0.2.0 (Nov, 2015) Conflict resolvers >>> is Nov, 2014, right? >>> >>> >>> On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> We have been working on a roadmap for DataSync to help our planning of >>>> the features and time frames. >>>> >>>> A suggestion for the roadmap can be found in this branch: >>>> >>>> https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap >>>> >>>> If you don't feel like building it yourself you can try this OpenShift >>>> instance: >>>> >>>> http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ >>>> >>>> Please note that the dates are just made up and something that we need >>>> help from each client library project to provide feedback on what is >>>> reasonable. >>>> >>>> Let us know what you think and from the feedback given, either here or >>>> as PRs, we will try to break this down further and start creating JIRAs to >>>> link to the roadmap. >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/887a199c/attachment.html From bruno at abstractj.org Mon Aug 25 08:12:25 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 25 Aug 2014 09:12:25 -0300 Subject: [aerogear-dev] Openshift - old versions on Push cartridge In-Reply-To: References: Message-ID: <20140825121225.GA16148@abstractj.org> +1 for getting rid of it. On 2014-08-22, Daniel Bevenius wrote: > +1 Out with the old. > > > On 21 August 2014 18:38, Christos Vasilakis wrote: > > > > > On Aug 21, 2014, at 6:25 PM, Matthias Wessendorf > > wrote: > > > > Hello, > > > > on the push cartrige we have a collection of old versions. They are not > > really needed/used... > > > > > > https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/tree/master/versions > > > > The UPS_1.0.0.Final will be version 1.0.0. > > > > I'd like to get rid of the old ones, except 0.13.0, which contains the > > Beta2 release. > > > > Any thoughts ? > > > > > > +1 sounds good to remove old unused ones > > > > - > > Christos > > > > > > > > -Matthias > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Mon Aug 25 08:13:55 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 25 Aug 2014 14:13:55 +0200 Subject: [aerogear-dev] aerogear-sync-server repository Message-ID: The aerogear-sync-server [1] repository contains a single server implementation which is based on the 409 Conflict handling which is now also available via the Forge plugin. So I'd like to remove the rest server. There was also some early differential synchronization work done [2] which is out dated and could be removed. For those interested the experimental work that Luke and I have been working on is in this branch [3] and I'd be happy to push it. Any objections? [1] https://github.com/aerogear/aerogear-sync-server [2] https://github.com/aerogear/aerogear-sync-server/tree/diff-sync [3] https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/ff96462f/attachment.html From daniel.bevenius at gmail.com Mon Aug 25 08:38:47 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 25 Aug 2014 14:38:47 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: Sorry forgot this one... >integrate seamlessly with LiveOak For the first versions where there is only the requirement to detect conflicts and return the latest version, this would have to be implemented in LiveOak. For the later version the way I see it would be similar to how the experimental differential synchronization (DS) server is "embedded" in a Netty server [1]. Instead of running it in a Netty server it would be run inside of LiveOak and they could hook it up with there storage. Note sure if this will actually work but at least that is the idea. I know that DS not be the path we choose, but perhaps a similar approach could be used for the actual server later on. [1] https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization/diffsync/server-netty On 25 August 2014 12:39, Daniel Bevenius wrote: > >I expect in the mean time we should also play with prototypes and figure > out what approaches fit best the needs, > > and evaluate that functionally and performance-wise on sample apps. > Yeah, we should definitely do that and especially with the later version > as we still don't know the exact direction there. > > >Something what I'm missing is more comprehensive elaboration / insight in > what are the target use cases and requirements on final architecture: > Yeah, we should probably have some links from the road map to a page that > elaborates more on these. I thought having too much in the road map would > not be very nice but rather keep it pretty simple. We already have some > information in the Specifications section [1] and perhaps that is the > correct place to add such details and then link to them from the roadmap. > What do you (all) think? > > >* integrate /w any general REST interface (compliant with given > limitations) > For the first stage we're thinking that the only requirement would be > that the server can detect a conflict and return a 409 accompanied with the > latest version of that the server has. This is what was discussed at the > f2f and which Erik has a Forge plugin to generate. > But the "real" data sync version will have much more impact on the backend > and it would have to follow an application protocol that we define. > > >HATEOAS-compliant backend? > Does this differ from the REST interface describe above now that some > background information was provided? > If it does that it would be great to either gather them here or that we > add to aerogear.org. I'll push the branch to master so we can all work > off it. > > > generic JAX-RS? > Not sure about this, but would Erik's Forge plugin take care the generic > JAX-RS backend case. Users would not need to use Forge if they choose not > to, and we should document the requirements upon the backend like described > in the first version. Again, if there are things we've missed then please > add them. > > >*Use cases / end-user stories:* > These could be added to the existing use cases I think. See the last > section of [1]. > > Thanks for comments and the link to that document, I'll read through it. > > > [1] http://diy-dbevenius.rhcloud.com/docs/specs/aerogear-data-sync/ > > > On 25 August 2014 11:20, Luk?? Fry? wrote: > >> Hey Dan, >> >> this sounds good. >> >> I expect in the mean time we should also play with prototypes and figure >> out what approaches fit best the needs, >> and evaluate that functionally and performance-wise on sample apps. >> >> >> >> Something what I'm missing is more comprehensive elaboration / insight in >> what are the target use cases and requirements on final architecture: >> >> *Requirements:* >> >> * integrate /w any general REST interface (compliant with given >> limitations) >> ** HATEOAS-compliant backend? >> ** generic JAX-RS? >> * integrate seamlessly with LiveOak >> >> *Use cases / end-user stories:* >> >> * mobile sales client >> * mobile warehouse manager >> * delivery agent >> >> Inspiration: >> https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit >> >> >> I expect we target different use cases in different phases. >> So we could indicate what use cases are valid in what phase. >> >> Should we brainstorm this on wiki or so? >> >> >> Cheers! >> >> ~ Lukas >> >> >> >> On Mon, Aug 25, 2014 at 9:58 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> >is Nov, 2014, right? >>> Yep, sorry that should be 2015. I'll correct that. Thx >>> >>> >>> On 25 August 2014 09:57, Matthias Wessendorf wrote: >>> >>>> 0.2.0 (Nov, 2015) Conflict resolvers >>>> is Nov, 2014, right? >>>> >>>> >>>> On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> We have been working on a roadmap for DataSync to help our planning of >>>>> the features and time frames. >>>>> >>>>> A suggestion for the roadmap can be found in this branch: >>>>> >>>>> https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap >>>>> >>>>> If you don't feel like building it yourself you can try this OpenShift >>>>> instance: >>>>> >>>>> http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ >>>>> >>>>> Please note that the dates are just made up and something that we need >>>>> help from each client library project to provide feedback on what is >>>>> reasonable. >>>>> >>>>> Let us know what you think and from the feedback given, either here or >>>>> as PRs, we will try to break this down further and start creating JIRAs to >>>>> link to the roadmap. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/eca13627/attachment-0001.html From lukas.fryc at gmail.com Mon Aug 25 08:40:19 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 25 Aug 2014 14:40:19 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: On Mon, Aug 25, 2014 at 12:39 PM, Daniel Bevenius wrote: > >I expect in the mean time we should also play with prototypes and figure > out what approaches fit best the needs, > > and evaluate that functionally and performance-wise on sample apps. > Yeah, we should definitely do that and especially with the later version > as we still don't know the exact direction there. > > >Something what I'm missing is more comprehensive elaboration / insight in > what are the target use cases and requirements on final architecture: > Yeah, we should probably have some links from the road map to a page that > elaborates more on these. I thought having too much in the road map would > not be very nice but rather keep it pretty simple. We already have some > information in the Specifications section [1] and perhaps that is the > correct place to add such details and then link to them from the roadmap. > What do you (all) think? > > +1 for linking them (I didn't notice that page, my bad, and good summary btw) > >* integrate /w any general REST interface (compliant with given > limitations) > For the first stage we're thinking that the only requirement would be > that the server can detect a conflict and return a 409 accompanied with the > latest version of that the server has. This is what was discussed at the > f2f and which Erik has a Forge plugin to generate. > But the "real" data sync version will have much more impact on the backend > and it would have to follow an application protocol that we define. > > >HATEOAS-compliant backend? > Does this differ from the REST interface describe above now that some > background information was provided? > If it does that it would be great to either gather them here or that we > add to aerogear.org. I'll push the branch to master so we can all work > off it. > > > generic JAX-RS? > Not sure about this, but would Erik's Forge plugin take care the generic > JAX-RS backend case. Users would not need to use Forge if they choose not > to, and we should document the requirements upon the backend like described > in the first version. Again, if there are things we've missed then please > add them. > The main architectural point I'm missing here is whether AeroGear sync server should be primarily at the end: 1) standalone storage mechanism with data sync capability (such as CouchDB) CLIENT <--> DATA SYNC SERVER 2) mediator for synchronization with storage mechanism CLIENT <--> DATA SYNC SERVER <--> STORE (pluggable) And here pluggable storage mechanism could be JAX-RS server with interceptors, LiveOak server, MongoDB or CouchDB... The proposals that I've seen (and I apologize if I've missed something) talk about synchronization protocol (DS, OT), conflict resolution and means of communication (request/response, realtime), but doesn't talk about restrictions on backend architecture. And this I guess applies to 0.2, 0.3 and 0.4 versions as on the Roadmap. Just one more question, how are these documents up to date? http://aerogear.org/docs/specs/aerogear-sync-client-api/ http://aerogear.org/docs/specs/aerogear-sync-server-api/ Is it something that fully reflects current implementation state / plans? > > >*Use cases / end-user stories:* > These could be added to the existing use cases I think. See the last > section of [1]. > > Thanks for comments and the link to that document, I'll read through it. > > > [1] http://diy-dbevenius.rhcloud.com/docs/specs/aerogear-data-sync/ > > > On 25 August 2014 11:20, Luk?? Fry? wrote: > >> Hey Dan, >> >> this sounds good. >> >> I expect in the mean time we should also play with prototypes and figure >> out what approaches fit best the needs, >> and evaluate that functionally and performance-wise on sample apps. >> >> >> >> Something what I'm missing is more comprehensive elaboration / insight in >> what are the target use cases and requirements on final architecture: >> >> *Requirements:* >> >> * integrate /w any general REST interface (compliant with given >> limitations) >> ** HATEOAS-compliant backend? >> ** generic JAX-RS? >> * integrate seamlessly with LiveOak >> >> *Use cases / end-user stories:* >> >> * mobile sales client >> * mobile warehouse manager >> * delivery agent >> >> Inspiration: >> https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit >> >> >> I expect we target different use cases in different phases. >> So we could indicate what use cases are valid in what phase. >> >> Should we brainstorm this on wiki or so? >> >> >> Cheers! >> >> ~ Lukas >> >> >> >> On Mon, Aug 25, 2014 at 9:58 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> >is Nov, 2014, right? >>> Yep, sorry that should be 2015. I'll correct that. Thx >>> >>> >>> On 25 August 2014 09:57, Matthias Wessendorf wrote: >>> >>>> 0.2.0 (Nov, 2015) Conflict resolvers >>>> is Nov, 2014, right? >>>> >>>> >>>> On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> We have been working on a roadmap for DataSync to help our planning of >>>>> the features and time frames. >>>>> >>>>> A suggestion for the roadmap can be found in this branch: >>>>> >>>>> https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap >>>>> >>>>> If you don't feel like building it yourself you can try this OpenShift >>>>> instance: >>>>> >>>>> http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ >>>>> >>>>> Please note that the dates are just made up and something that we need >>>>> help from each client library project to provide feedback on what is >>>>> reasonable. >>>>> >>>>> Let us know what you think and from the feedback given, either here or >>>>> as PRs, we will try to break this down further and start creating JIRAs to >>>>> link to the roadmap. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/e15f1974/attachment.html From edewit at redhat.com Mon Aug 25 08:46:43 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 25 Aug 2014 14:46:43 +0200 Subject: [aerogear-dev] cordova plugin release Message-ID: Hi, We are going to release a new version of the cordova push plugin the new version 1.0.0 most important features are the updated push libraries and a fix in the content-availble flag [AGCORDOVA-26] - When app is in background notifications no longer appear on iOS I?ve created a 1.0.0-release [1] branch for your testing pleasure. If we don?t find issues we?ll perform the actual release on wednesday. [1] https://github.com/aerogear/aerogear-pushplugin-cordova/tree/1.0.0-release -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/20665934/attachment.html From daniel.bevenius at gmail.com Mon Aug 25 08:47:47 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 25 Aug 2014 14:47:47 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: >The main architectural point I'm missing here is whether AeroGear sync server should be primarily at the end: >1) standalone storage mechanism with data sync capability (such as CouchDB) >CLIENT <--> DATA SYNC SERVER >2) mediator for synchronization with storage mechanism >CLIENT <--> DATA SYNC SERVER <--> STORE (pluggable) >And here pluggable storage mechanism could be JAX-RS server with interceptors, LiveOak server, MongoDB or CouchDB... I'l like to see this done using option 2 in your list above. >Just one more question, how are these documents up to date? >http://aerogear.org/docs/specs/aerogear-sync-client-api/ >http://aerogear.org/docs/specs/aerogear-sync-server-api/ No sorry, these are have not been updated only the roadmap and minor spelling corrections have been done to the DataSync spec page at this stage. On 25 August 2014 14:40, Luk?? Fry? wrote: > > > > On Mon, Aug 25, 2014 at 12:39 PM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> >I expect in the mean time we should also play with prototypes and >> figure out what approaches fit best the needs, >> > and evaluate that functionally and performance-wise on sample apps. >> Yeah, we should definitely do that and especially with the later version >> as we still don't know the exact direction there. >> >> >Something what I'm missing is more comprehensive elaboration / insight >> in what are the target use cases and requirements on final architecture: >> Yeah, we should probably have some links from the road map to a page that >> elaborates more on these. I thought having too much in the road map would >> not be very nice but rather keep it pretty simple. We already have some >> information in the Specifications section [1] and perhaps that is the >> correct place to add such details and then link to them from the roadmap. >> What do you (all) think? >> >> > +1 for linking them (I didn't notice that page, my bad, and good summary > btw) > > >> >* integrate /w any general REST interface (compliant with given >> limitations) >> For the first stage we're thinking that the only requirement would be >> that the server can detect a conflict and return a 409 accompanied with the >> latest version of that the server has. This is what was discussed at the >> f2f and which Erik has a Forge plugin to generate. >> But the "real" data sync version will have much more impact on the >> backend and it would have to follow an application protocol that we define. >> >> >HATEOAS-compliant backend? >> Does this differ from the REST interface describe above now that some >> background information was provided? >> If it does that it would be great to either gather them here or that we >> add to aerogear.org. I'll push the branch to master so we can all work >> off it. >> >> > generic JAX-RS? >> Not sure about this, but would Erik's Forge plugin take care the generic >> JAX-RS backend case. Users would not need to use Forge if they choose not >> to, and we should document the requirements upon the backend like described >> in the first version. Again, if there are things we've missed then please >> add them. >> > > The main architectural point I'm missing here is whether AeroGear sync > server should be primarily at the end: > > > 1) standalone storage mechanism with data sync capability (such as CouchDB) > > CLIENT <--> DATA SYNC SERVER > > > > 2) mediator for synchronization with storage mechanism > > CLIENT <--> DATA SYNC SERVER <--> STORE (pluggable) > > And here pluggable storage mechanism could be JAX-RS server with > interceptors, LiveOak server, MongoDB or CouchDB... > > > > The proposals that I've seen (and I apologize if I've missed something) > talk about synchronization protocol (DS, OT), conflict resolution and means > of communication (request/response, realtime), > but doesn't talk about restrictions on backend architecture. And this I > guess applies to 0.2, 0.3 and 0.4 versions as on the Roadmap. > > > > Just one more question, how are these documents up to date? > > http://aerogear.org/docs/specs/aerogear-sync-client-api/ > http://aerogear.org/docs/specs/aerogear-sync-server-api/ > > Is it something that fully reflects current implementation state / plans? > > >> >> >*Use cases / end-user stories:* >> These could be added to the existing use cases I think. See the last >> section of [1]. >> >> Thanks for comments and the link to that document, I'll read through it. >> >> >> [1] http://diy-dbevenius.rhcloud.com/docs/specs/aerogear-data-sync/ >> >> >> On 25 August 2014 11:20, Luk?? Fry? wrote: >> >>> Hey Dan, >>> >>> this sounds good. >>> >>> I expect in the mean time we should also play with prototypes and figure >>> out what approaches fit best the needs, >>> and evaluate that functionally and performance-wise on sample apps. >>> >>> >>> >>> Something what I'm missing is more comprehensive elaboration / insight >>> in what are the target use cases and requirements on final architecture: >>> >>> *Requirements:* >>> >>> * integrate /w any general REST interface (compliant with given >>> limitations) >>> ** HATEOAS-compliant backend? >>> ** generic JAX-RS? >>> * integrate seamlessly with LiveOak >>> >>> *Use cases / end-user stories:* >>> >>> * mobile sales client >>> * mobile warehouse manager >>> * delivery agent >>> >>> Inspiration: >>> https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit >>> >>> >>> I expect we target different use cases in different phases. >>> So we could indicate what use cases are valid in what phase. >>> >>> Should we brainstorm this on wiki or so? >>> >>> >>> Cheers! >>> >>> ~ Lukas >>> >>> >>> >>> On Mon, Aug 25, 2014 at 9:58 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> >is Nov, 2014, right? >>>> Yep, sorry that should be 2015. I'll correct that. Thx >>>> >>>> >>>> On 25 August 2014 09:57, Matthias Wessendorf wrote: >>>> >>>>> 0.2.0 (Nov, 2015) Conflict resolvers >>>>> is Nov, 2014, right? >>>>> >>>>> >>>>> On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> We have been working on a roadmap for DataSync to help our planning >>>>>> of the features and time frames. >>>>>> >>>>>> A suggestion for the roadmap can be found in this branch: >>>>>> >>>>>> https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap >>>>>> >>>>>> If you don't feel like building it yourself you can try this >>>>>> OpenShift instance: >>>>>> >>>>>> http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ >>>>>> >>>>>> Please note that the dates are just made up and something that we >>>>>> need help from each client library project to provide feedback on what is >>>>>> reasonable. >>>>>> >>>>>> Let us know what you think and from the feedback given, either here >>>>>> or as PRs, we will try to break this down further and start creating JIRAs >>>>>> to link to the roadmap. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/d280c65f/attachment-0001.html From daniel.bevenius at gmail.com Mon Aug 25 08:50:33 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 25 Aug 2014 14:50:33 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: Message-ID: Yay! On 25 August 2014 14:46, Erik Jan de Wit wrote: > Hi, > > We are going to release a new version of the cordova push plugin the new > version 1.0.0 most important features are the updated push libraries and a > fix in the content-availble flag > > [AGCORDOVA-26 ] - When app > is in background notifications no longer appear on iOS > > I?ve created a 1.0.0-release [1] branch for your testing pleasure. If we > don?t find issues we?ll perform the actual release on wednesday. > > [1] > https://github.com/aerogear/aerogear-pushplugin-cordova/tree/1.0.0-release > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/8d12db99/attachment.html From bruno at abstractj.org Mon Aug 25 09:03:36 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 25 Aug 2014 10:03:36 -0300 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: References: Message-ID: <20140825130336.GA17484@abstractj.org> On 2014-08-25, Daniel Bevenius wrote: > The aerogear-sync-server [1] repository contains a single server > implementation which is based on the 409 Conflict handling which is now > also available via the Forge plugin. So I'd like to remove the rest server. +1 > > There was also some early differential synchronization work done [2] which > is out dated and could be removed. +1 > > For those interested the experimental work that Luke and I have been > working on is in this branch [3] and I'd be happy to push it. Push it! > > Any objections? > > > [1] https://github.com/aerogear/aerogear-sync-server > [2] https://github.com/aerogear/aerogear-sync-server/tree/diff-sync > [3] > https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From supittma at redhat.com Mon Aug 25 09:14:03 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 25 Aug 2014 09:14:03 -0400 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: References: Message-ID: <53FB369B.9020205@redhat.com> On 08/25/2014 08:13 AM, Daniel Bevenius wrote: > The aerogear-sync-server [1] repository contains a single server > implementation which is based on the 409 Conflict handling which is > now also available via the Forge plugin. So I'd like to remove the > rest server. > +1 > There was also some early differential synchronization work done [2] > which is out dated and could be removed. +1 > > For those interested the experimental work that Luke and I have been > working on is in this branch [3] and I'd be happy to push it. +1 > > Any objections? > > > [1] https://github.com/aerogear/aerogear-sync-server > [2] https://github.com/aerogear/aerogear-sync-server/tree/diff-sync > [3] > https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/f0b9dc49/attachment.html From matzew at apache.org Mon Aug 25 09:26:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 25 Aug 2014 15:26:15 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: Message-ID: One minor thing: https://github.com/aerogear/aerogear-pushplugin-cordova/pull/49 Besides that, I have tested the 1.0.0-release branch w/ the "HelloWorld" example against the UPS.1.0.0.Final (staged) server, on Android (4.4) and iOS (7.x). Works fine, in both modes, foreground and background After merging #49, I am +1 on releasing the branch -Matthias On Mon, Aug 25, 2014 at 2:46 PM, Erik Jan de Wit wrote: > Hi, > > We are going to release a new version of the cordova push plugin the new > version 1.0.0 most important features are the updated push libraries and a > fix in the content-availble flag > > [AGCORDOVA-26 ] - When app > is in background notifications no longer appear on iOS > > I?ve created a 1.0.0-release [1] branch for your testing pleasure. If we > don?t find issues we?ll perform the actual release on wednesday. > > [1] > https://github.com/aerogear/aerogear-pushplugin-cordova/tree/1.0.0-release > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/7fc60dc1/attachment.html From daniel.bevenius at gmail.com Mon Aug 25 10:19:24 2014 From: daniel.bevenius at gmail.com (danielbevenius) Date: Mon, 25 Aug 2014 07:19:24 -0700 (PDT) Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: <1408976364002-9025.post@n5.nabble.com> Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-25-14.10.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-25-14.10.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-25-14.10.log.html -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Team-meeting-tp9005p9025.html Sent from the aerogear-dev mailing list archive at Nabble.com. From lholmqui at redhat.com Mon Aug 25 11:00:07 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 25 Aug 2014 11:00:07 -0400 Subject: [aerogear-dev] AeroGear.js 1.5.2 Message-ID: AeroGear JS 1.5.2 This release has mostly updates to the push related bits to align with the upcoming 1.0.0-Final release of the AeroGear UnifiedPush Server However; there were some bugs (i know, shocking!!) that we needed to get rid of Code As always, you can view the source code here If bower is your thing: $ bower install aerogear Or if you want to create a custom build, JS Custom Builder or use can use the custom grunt command!! Release Notes - AeroGear JavaScript - Version 1.5.2 Release Notes - AeroGear JavaScript - Version 1.5.2 Bug [AGJS-164] - SimplePush Notifier, subscribe does nothing with "callback" [AGJS-169] - SimplePush - no onConnect for Native [AGJS-200] - AeroGear.ajax - InvalidStateError [AGJS-206] - UPS client doesn't need double encoding Enhancement [AGJS-205] - Prefixed name should be mozSetMessageHandler (instead of setMozMessageHandler) [AGJS-207] - Strip trailing slash in provided UPS URL Feature Request [AGJS-139] - Add reference to mozSetMessageHandler in SimplePush lib [AGJS-208] - Fix notifier jsdoc for hostname/port and use simply host [AGJS-209] - Update MQTT-WS notifier adapter to use Eclipse Paho MQTT v1.0.0 JavaScript Client Task [AGJS-52] - Sync SimplePush with Mozilla spec [AGJS-203] - SImplePush - Notifications should include the pushEndpoint -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140825/6a889296/attachment-0001.html From matzew at apache.org Tue Aug 26 05:36:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 26 Aug 2014 11:36:16 +0200 Subject: [aerogear-dev] AeroGear.org - Download of the UPS release bundle In-Reply-To: References: Message-ID: On Mon, Aug 18, 2014 at 3:17 PM, Lucas Holmquist wrote: > > On Aug 18, 2014, at 9:13 AM, Matthias Wessendorf > wrote: > > Hello, > > starting w/ the 1.0.0.Final release we will have a bundle to download the > UPS bits (see [1]). > > I am wondering where to put the bundle on the homepage ? > Should we create a "aerogear.org/dist " folder for that ? > > > with the github release button thingy, we can also include binaries for > download, i suggest that we use that and just link to it on the website > Alright, I have tested the github release thingy, and binary upload works. ONCE the release is out (e.g. hit maven central), I will upload these files: http://people.apache.org/~matzew/aerogear-unifiedpush-server-1.0.0.Final/ That contains the signed release bundle (zip and tarball). As discussed the website update will link to "latest", and just use the "1.0.0" as a label, on the link. -Matthias > > > > Let me know what's best :-) > > -Matthias > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/350 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140826/627778bb/attachment.html From corinnekrych at gmail.com Tue Aug 26 10:08:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 26 Aug 2014 16:08:05 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Final In-Reply-To: <8B3D8899-8AB4-4F5D-9E83-B0A12EFC9ED9@redhat.com> References: <8B3D8899-8AB4-4F5D-9E83-B0A12EFC9ED9@redhat.com> Message-ID: Tested with iOS7, iOS8 on HelloWorld app and Cordova Contacts app. Works great. On 25 Aug 2014, at 11:21, Erik Jan de Wit wrote: > Tested the cordova plugin with the UPS android and iOS and worked like a charm. > > On 21 Aug,2014, at 11:41 , Matthias Wessendorf wrote: > >> Hello folks! >> >> we are getting really close to our 1.0.0 release! In fact, it's now under testing/review. Thank you very much, guys!!!! >> >> Note this release contains a handful fixes on-top of the last BETA2 release. To name a few highlights: >> >> * Keycloak rc-1 usage >> * UI improvements (e.g. new style of the account mgmt section, and more links to docs/guides) >> * APNs fixes: improved server-side logging and fixing broken iOS Variant updates >> >> The team did an outstanding job to get to this point! Thanks again guys! >> >> Details on all the JIRAs can be found here: >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754 >> >> The staging repository is located here: >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/ >> >> For testing this review, I nominate Corinne Krych, Erik Jan de Wit and Tadeas Kriz >> >> Regarding Docker, I have sent a PR against Bruno's repo, to go w/ the WAR files from the above staging repo: >> https://github.com/abstractj/docker/pull/8 >> >> >> Let me know the results of your testing! >> If I hear nothing bad by Tuesday (August 26th) evening, the release to maven central will happen on Wednesday morning; >> >> >> >> NOTE: Once this release has been approved the matching tag will be used to get the OpenShift online bits updated! >> >> >> Greetings, >> Matthias >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From tkriz at redhat.com Tue Aug 26 10:36:27 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Tue, 26 Aug 2014 16:36:27 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Final In-Reply-To: References: <8B3D8899-8AB4-4F5D-9E83-B0A12EFC9ED9@redhat.com> Message-ID: <155D5FF5-5C65-44DA-AFEA-2B3A597770A5@redhat.com> Hey guys, I?ve run integration tests on JBoss AS7, WildFly 8.1 and EAP 6.3.0 for both standalone and domain modes. I?ve also run unit tests and went through the manual UI testing which involved adding new applications and variants, setting up Google Authenticator and login using the OTP. All went well and I encountered and reported only one bug [1] which I believe should not block the release. Great job team! 1 - https://issues.jboss.org/browse/AGPUSH-958 ? Tadeas Kriz On 26 Aug 2014, at 04:08 pm, Corinne Krych wrote: > Tested with iOS7, iOS8 > on HelloWorld app and Cordova Contacts app. > Works great. > > On 25 Aug 2014, at 11:21, Erik Jan de Wit wrote: > >> Tested the cordova plugin with the UPS android and iOS and worked like a charm. >> >> On 21 Aug,2014, at 11:41 , Matthias Wessendorf wrote: >> >>> Hello folks! >>> >>> we are getting really close to our 1.0.0 release! In fact, it's now under testing/review. Thank you very much, guys!!!! >>> >>> Note this release contains a handful fixes on-top of the last BETA2 release. To name a few highlights: >>> >>> * Keycloak rc-1 usage >>> * UI improvements (e.g. new style of the account mgmt section, and more links to docs/guides) >>> * APNs fixes: improved server-side logging and fixing broken iOS Variant updates >>> >>> The team did an outstanding job to get to this point! Thanks again guys! >>> >>> Details on all the JIRAs can be found here: >>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12323754 >>> >>> The staging repository is located here: >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3752/ >>> >>> For testing this review, I nominate Corinne Krych, Erik Jan de Wit and Tadeas Kriz >>> >>> Regarding Docker, I have sent a PR against Bruno's repo, to go w/ the WAR files from the above staging repo: >>> https://github.com/abstractj/docker/pull/8 >>> >>> >>> Let me know the results of your testing! >>> If I hear nothing bad by Tuesday (August 26th) evening, the release to maven central will happen on Wednesday morning; >>> >>> >>> >>> NOTE: Once this release has been approved the matching tag will be used to get the OpenShift online bits updated! >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel at passos.me Tue Aug 26 15:29:05 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 26 Aug 2014 16:29:05 -0300 Subject: [aerogear-dev] Openshift - old versions on Push cartridge In-Reply-To: <20140825121225.GA16148@abstractj.org> References: <20140825121225.GA16148@abstractj.org> Message-ID: +1 On Mon, Aug 25, 2014 at 9:12 AM, Bruno Oliveira wrote: > +1 for getting rid of it. > > On 2014-08-22, Daniel Bevenius wrote: > > +1 Out with the old. > > > > > > On 21 August 2014 18:38, Christos Vasilakis wrote: > > > > > > > > On Aug 21, 2014, at 6:25 PM, Matthias Wessendorf > > > wrote: > > > > > > Hello, > > > > > > on the push cartrige we have a collection of old versions. They are not > > > really needed/used... > > > > > > > > > > https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/tree/master/versions > > > > > > The UPS_1.0.0.Final will be version 1.0.0. > > > > > > I'd like to get rid of the old ones, except 0.13.0, which contains the > > > Beta2 release. > > > > > > Any thoughts ? > > > > > > > > > +1 sounds good to remove old unused ones > > > > > > - > > > Christos > > > > > > > > > > > > -Matthias > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140826/4bd47981/attachment.html From corinnekrych at gmail.com Tue Aug 26 16:19:14 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 26 Aug 2014 22:19:14 +0200 Subject: [aerogear-dev] Blank page for iOS Cookbook Message-ID: Hello Swift lovers, As discussed in our last iOS meeting [1], I?ve create a dedicated branch to our aerogear-ios-cookbook. All cookbook apps should be updated in Swift and uses new iOS Swift repos like aerogear-ios-http or Swift branch for aerogear-ios-push. To keep branch name consistent I?ve named the cookbook branch ?swift.? As we?re starting from blank page, I?ve removed all all not yet migrated. The only apps left are linked sub-module to HelloWorld (Swift branch) and Quickstart (swift branch). If you create new demos for next release or migrate existing demos, please target ?swift? branch [2]. ++ Corinne [1] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-22-12.00.txt [2] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift From daniel.bevenius at gmail.com Wed Aug 27 03:12:24 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 27 Aug 2014 09:12:24 +0200 Subject: [aerogear-dev] aerogear-sync-server repository In-Reply-To: <53FB369B.9020205@redhat.com> References: <53FB369B.9020205@redhat.com> Message-ID: Just an update on this. I've now removed almost everything from https://github.com/aerogear/aerogear-sync-server and pushed a branch named differential-synchronization. This branch currently still includes the REST server that we've been using for testing. The reason for this is that Lukas and I chatted about this yesterday on IRC, and even though we have the Forge plugin we still need something to test are client libraries against. Until we have something else I'll leave that i the branch. On 25 August 2014 15:14, Summers Pittman wrote: > On 08/25/2014 08:13 AM, Daniel Bevenius wrote: > > The aerogear-sync-server [1] repository contains a single server > implementation which is based on the 409 Conflict handling which is now > also available via the Forge plugin. So I'd like to remove the rest > server. > > +1 > > There was also some early differential synchronization work done [2] > which is out dated and could be removed. > > +1 > > > For those interested the experimental work that Luke and I have been > working on is in this branch [3] and I'd be happy to push it. > > +1 > > > Any objections? > > > [1] https://github.com/aerogear/aerogear-sync-server > [2] https://github.com/aerogear/aerogear-sync-server/tree/diff-sync > [3] > https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/4e4a91dd/attachment-0001.html From matzew at apache.org Wed Aug 27 03:14:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 27 Aug 2014 09:14:47 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: Message-ID: Looks like there is a different, new bug: https://github.com/aerogear/aerogear-push-quickstarts/pull/88#issuecomment-53534157 -M On Mon, Aug 25, 2014 at 3:26 PM, Matthias Wessendorf wrote: > One minor thing: > https://github.com/aerogear/aerogear-pushplugin-cordova/pull/49 > > Besides that, I have tested the 1.0.0-release branch w/ the "HelloWorld" > example against the UPS.1.0.0.Final (staged) server, on Android (4.4) and > iOS (7.x). > Works fine, in both modes, foreground and background > > > After merging #49, I am +1 on releasing the branch > > -Matthias > > > > > > On Mon, Aug 25, 2014 at 2:46 PM, Erik Jan de Wit > wrote: > >> Hi, >> >> We are going to release a new version of the cordova push plugin the new >> version 1.0.0 most important features are the updated push libraries and a >> fix in the content-availble flag >> >> [AGCORDOVA-26 ] - When app >> is in background notifications no longer appear on iOS >> >> I?ve created a 1.0.0-release [1] branch for your testing pleasure. If we >> don?t find issues we?ll perform the actual release on wednesday. >> >> [1] >> https://github.com/aerogear/aerogear-pushplugin-cordova/tree/1.0.0-release >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/501feb4d/attachment.html From matzew at apache.org Wed Aug 27 03:37:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 27 Aug 2014 09:37:22 +0200 Subject: [aerogear-dev] Blank page for iOS Cookbook In-Reply-To: References: Message-ID: nice! On Tue, Aug 26, 2014 at 10:19 PM, Corinne Krych wrote: > Hello Swift lovers, > > As discussed in our last iOS meeting [1], I?ve create a dedicated branch > to our aerogear-ios-cookbook. All cookbook apps should be updated in Swift > and uses new iOS Swift repos like aerogear-ios-http or Swift branch for > aerogear-ios-push. > > To keep branch name consistent I?ve named the cookbook branch ?swift.? > > As we?re starting from blank page, I?ve removed all all not yet migrated. > The only apps left are linked sub-module to HelloWorld (Swift branch) and > Quickstart (swift branch). > > If you create new demos for next release or migrate existing demos, please > target ?swift? branch [2]. > > ++ > Corinne > [1] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-08-22-12.00.txt > [2] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/0df23248/attachment.html From edewit at redhat.com Wed Aug 27 04:37:26 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 27 Aug 2014 10:37:26 +0200 Subject: [aerogear-dev] cordova plugin release Message-ID: <82DEE48B-E441-412E-89F4-122BB2C5B387@redhat.com> Hi all, After testing and finding some small issues we are happy to announce that the 1.0.0 version of the cordova push plugin has been released. Thanks to everyone for testing and making this release happen. Release Notes Bug AGCORDOVA-26 When app is in background notifications no longer appear on iOS AGCORDOVA-28 Remote Notifications not enabled in generated xcode project Feature Request AGCORDOVA-27 Improve callback behaviour documentation AGCORDOVA-10 Background push notification -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/6ef33481/attachment.html From corinnekrych at gmail.com Wed Aug 27 05:04:36 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 27 Aug 2014 11:04:36 +0200 Subject: [aerogear-dev] Swift - Frameworks/Static libs and Cocoapods In-Reply-To: <91DB35FA-E93C-4472-9635-7F58D2A2D2FA@gmail.com> References: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> <91DB35FA-E93C-4472-9635-7F58D2A2D2FA@gmail.com> Message-ID: One thing that came out when starting working with cookbook recipes with Erik in ?swift? branch is that many recipes may shared the same libs. So it would make sense to share the lib in a common folder. We will have a libs folder containing latest version of aerogear-ios-htpp etc? See [1] ++ Corinne [1] https://github.com/aerogear/aerogear-ios-cookbook/tree/swift/libs/AeroGearHttp On 22 Aug 2014, at 09:40, Corinne Krych wrote: > > On 21 Aug 2014, at 17:43, Christos Vasilakis wrote: > >> Hi all, >> >> just some heads up on this to be a little more clear on how we approach the framework issues mentioned in this thread with our demos/quickstarts written in Swift. >> >> Because of the issue mentioned in the mail, we opted for our demos that use ?Swift? frameworks (as in the case with our push-sdk swift port[1 >> ), to have the library embedded in [2], instead of using the ?github submodule? process. At least for demos, we believe it?s better for the user experience to just fire it and run the project instead of manual fetching the dependent library with git. >> > > +1 > I?ll use the same approach for our swift cookbook demos coming soon > >> Eventually, when the framework issues is resolved by Swift, the source code of the folder containing the library will be removed and replaced with a binary framework build. >> >> Just to clear this up in case you come wondering what is this extra 'aerogear-ios-push? folder doing inside the project ;) >> >> if you have any question/comments let us know >> >> Thanks! >> >> - >> Christos >> >> >> [1] https://github.com/aerogear/aerogear-ios-push/tree/swift >> [2] https://github.com/cvasilak/aerogear-push-helloworld/tree/swift/ios-swift/aerogear-ios-push >> >> >> On Jul 22, 2014, at 11:09 AM, Christos Vasilakis wrote: >>> Hi all, >>> >>> want to give a heads up on the current status of Swift frameworks/static libs generation and cocoapods support. This is based on the current state of affairs, as in Xcode beta 4 (released yesterday). >>> >>> Note: "Since rapid developments are taking place, will update this thread as more information becomes available and with any breaking changes" >>> >>> First, let me start by making three observations: >>> >>> a) quoting Apple release notes[1], "Xcode does not support building static libraries that include Swift code?. You can notice that in Xcode 6 when choosing ?Cocoa Touch Static Library? there is no option to select ?Swift? as the preferred language. >>> >>> b) new in Xcode 6 is the generation of ?dynamic? frameworks for library targets. The reason for ?dynamic? linking, as explained by apple in [2], is to enable the new functionality in iOS 8 called ?extensions?. Per apple quote "Frameworks work perfectly with extensions, sharing logic that can be used by both the main application, and the bundled extensions? >>> >>> c) Dynamic framework for a swift library (the only option offered by Xcode) , in the current state requires the source code of the library to be build together with the app that uses it. This is due to the binary interface, which has not being finalised yet. Quoting apple blog [3] ("Binary Compatibility and Frameworks? section): >>> >>> ? >>> "While your app?s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together. >>> >>> This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift ? especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.? >>> ? >>> >>> What does all that gives us? >>> In plain form, "Distribution of the push-sdk (swift port) should be done in source form with polished documentation on how the user can add it to their own project.? >>> >>> Already, looking at the various swift-libs currently in existence[4], that is the current approach, a well-written README.md on how the user can add the library dependency into their own projects. For example, something like the section ?How to Install Library? found here [5] >>> >>> As for cocoapods, currently no support is provided for swift projects. There is an on-going discussion on the issues list found here [6] on how to effectively support ?dynamic framework? for swift projects, and still keep backwards compatibility, but things are not yet finalised. >>> >>> Let me know your thoughts / comments. >>> >>> Thanks, >>> Christos >>> >>> [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf >>> [2] https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14 >>> [3] https://developer.apple.com/swift/blog/?id=2 >>> [4] http://www.swifttoolbox.io >>> [5] https://github.com/Quick/Quick >>> [6] https://github.com/CocoaPods/CocoaPods/issues/2272 >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > From lholmqui at redhat.com Wed Aug 27 09:28:12 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 27 Aug 2014 09:28:12 -0400 Subject: [aerogear-dev] Chrome Push Messages Message-ID: Hello, now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i?m starting to look at the new API that Chrome apps use for sending push notifications. the TL;DR of it is, it?s basically the same as Android now.( no more refresh tokens and access tokens and such ) So the question is, do we need to have a deprecation period on what is currently there? The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1 While i have looked to deeply, it?s possible we can use the same ?Variant? structure for Chrome Apps, Since they will be using the same Network wdyt? -Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/92d7e6eb/attachment-0001.html From lukas.fryc at gmail.com Wed Aug 27 14:15:28 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 27 Aug 2014 20:15:28 +0200 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: References: Message-ID: Hey Luke, ad) Variants it would be ideal if we could just use the same variant! ad) Compatibility I would say we should preserve the compatibility with 1.x as long as it does not make much efforts to keep both supported. If it would be too much hassle, let's remove it in 1.1. Chrome is updated pro-actively anyway, so no one will hear about the old API in few months. Cheers, ~ Lukas On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist wrote: > Hello, > > now that the 1.0.0-final is pretty much out for the UnifiedPush Server, > i?m starting to look at the new API that Chrome apps use for sending push > notifications. > > the TL;DR of it is, it?s basically the same as Android now.( no more > refresh tokens and access tokens and such ) > > So the question is, do we need to have a deprecation period on what is > currently there? > > The v1 of the chrome pushMessaging api has become legacy and it is > recommended to use the new stuff. > https://developer.chrome.com/apps/cloudMessagingV1 > > While i have looked to deeply, it?s possible we can use the same > ?Variant? structure for Chrome Apps, Since they will be using the same > Network > > wdyt? > > -Luke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/07b937e8/attachment.html From scm.blanc at gmail.com Wed Aug 27 14:37:23 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 27 Aug 2014 20:37:23 +0200 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: References: Message-ID: On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist wrote: > Hello, > > now that the 1.0.0-final is pretty much out for the UnifiedPush Server, > i?m starting to look at the new API that Chrome apps use for sending push > notifications. > > the TL;DR of it is, it?s basically the same as Android now.( no more > refresh tokens and access tokens and such ) > Maybe stupid and totally undoable but could we not use the current Android infra in UPS also for Chrome Apps, is there any difference ? In this case we could have a variant type "GCM" (just renaming the android type) , a Chrome App Variant will then just be a of the type GCM like an Android variant. > > So the question is, do we need to have a deprecation period on what is > currently there? > > The v1 of the chrome pushMessaging api has become legacy and it is > recommended to use the new stuff. > https://developer.chrome.com/apps/cloudMessagingV1 > > While i have looked to deeply, it?s possible we can use the same > ?Variant? structure for Chrome Apps, Since they will be using the same > Network > > wdyt? > > -Luke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/75136c5f/attachment.html From lholmqui at redhat.com Wed Aug 27 14:52:14 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 27 Aug 2014 14:52:14 -0400 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: References: Message-ID: <5BA743F8-BA55-491F-96E7-92BBF465E450@redhat.com> On Aug 27, 2014, at 2:37 PM, Sebastien Blanc wrote: > > > > On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist wrote: > Hello, > > now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i?m starting to look at the new API that Chrome apps use for sending push notifications. > > the TL;DR of it is, it?s basically the same as Android now.( no more refresh tokens and access tokens and such ) > > Maybe stupid and totally undoable but could we not use the current Android infra in UPS also for Chrome Apps, is there any difference ? In this case we could have a variant type "GCM" (just renaming the android type) , a Chrome App Variant will then just be a of the type GCM like an Android variant. I just ran a quick test using an android variant as a "chrome app?, and all worked perfectly. was able to register with AeroGear.js to the UPS and get sent a push notification to my chrome app. no code changes needed on the UPS side of things!! We might want to rename the Android Variant to GCM or something similar similar since the network is now used for both types of applications. This will probably also be the same thing when adding Safari Push notifications since it also uses APN?s, although there are some slight differences So, really, some one can use the new Chrome API stuff today with the UPS, they just need to create an Android Variant > > > So the question is, do we need to have a deprecation period on what is currently there? > > The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1 > > While i have looked to deeply, it?s possible we can use the same ?Variant? structure for Chrome Apps, Since they will be using the same Network > > wdyt? > > -Luke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/afe532a8/attachment.html From scm.blanc at gmail.com Wed Aug 27 14:55:44 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Wed, 27 Aug 2014 20:55:44 +0200 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: <5BA743F8-BA55-491F-96E7-92BBF465E450@redhat.com> References: <5BA743F8-BA55-491F-96E7-92BBF465E450@redhat.com> Message-ID: Envoy? de mon iPhone > Le 27 ao?t 2014 ? 20:52, Lucas Holmquist a ?crit : > > >> On Aug 27, 2014, at 2:37 PM, Sebastien Blanc wrote: >> >> >> >> >>> On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist wrote: >>> Hello, >>> >>> now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i?m starting to look at the new API that Chrome apps use for sending push notifications. >>> >>> the TL;DR of it is, it?s basically the same as Android now.( no more refresh tokens and access tokens and such ) >> >> Maybe stupid and totally undoable but could we not use the current Android infra in UPS also for Chrome Apps, is there any difference ? In this case we could have a variant type "GCM" (just renaming the android type) , a Chrome App Variant will then just be a of the type GCM like an Android variant. > > I just ran a quick test using an android variant as a "chrome app?, and all worked perfectly. was able to register with AeroGear.js to the UPS and get sent a push notification to my chrome app. > > no code changes needed on the UPS side of things!! > > > We might want to rename the Android Variant to GCM or something similar similar since the network is now used for both types of applications. > > This will probably also be the same thing when adding Safari Push notifications since it also uses APN?s, although there are some slight differences > > > So, really, some one can use the new Chrome API stuff today with the UPS, they just need to create an Android Variant Awesome ! Now we are even more unified and this for free :) > >> >>> >>> So the question is, do we need to have a deprecation period on what is currently there? >>> >>> The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1 >>> >>> While i have looked to deeply, it?s possible we can use the same ?Variant? structure for Chrome Apps, Since they will be using the same Network >>> >>> wdyt? >>> >>> -Luke >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/9f0049be/attachment-0001.html From lholmqui at redhat.com Wed Aug 27 14:58:33 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 27 Aug 2014 14:58:33 -0400 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: References: <5BA743F8-BA55-491F-96E7-92BBF465E450@redhat.com> Message-ID: of course we will need to update the UI/examples so they know about it :) but the user can differentiate between the 2 using the meta data then send back when registering On Aug 27, 2014, at 2:55 PM, S?bastien Blanc wrote: > > > Envoy? de mon iPhone > > Le 27 ao?t 2014 ? 20:52, Lucas Holmquist a ?crit : > >> >> On Aug 27, 2014, at 2:37 PM, Sebastien Blanc wrote: >> >>> >>> >>> >>> On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist wrote: >>> Hello, >>> >>> now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i?m starting to look at the new API that Chrome apps use for sending push notifications. >>> >>> the TL;DR of it is, it?s basically the same as Android now.( no more refresh tokens and access tokens and such ) >>> >>> Maybe stupid and totally undoable but could we not use the current Android infra in UPS also for Chrome Apps, is there any difference ? In this case we could have a variant type "GCM" (just renaming the android type) , a Chrome App Variant will then just be a of the type GCM like an Android variant. >> >> I just ran a quick test using an android variant as a "chrome app?, and all worked perfectly. was able to register with AeroGear.js to the UPS and get sent a push notification to my chrome app. >> >> no code changes needed on the UPS side of things!! >> >> >> We might want to rename the Android Variant to GCM or something similar similar since the network is now used for both types of applications. >> >> This will probably also be the same thing when adding Safari Push notifications since it also uses APN?s, although there are some slight differences >> >> >> So, really, some one can use the new Chrome API stuff today with the UPS, they just need to create an Android Variant > Awesome ! Now we are even more unified and this for free :) >> >>> >>> >>> So the question is, do we need to have a deprecation period on what is currently there? >>> >>> The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1 >>> >>> While i have looked to deeply, it?s possible we can use the same ?Variant? structure for Chrome Apps, Since they will be using the same Network >>> >>> wdyt? >>> >>> -Luke >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/c9c5d9d4/attachment.html From lholmqui at redhat.com Wed Aug 27 14:19:09 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 27 Aug 2014 14:19:09 -0400 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: References: Message-ID: On Aug 27, 2014, at 2:15 PM, Luk?? Fry? wrote: > Hey Luke, > > ad) Variants > > it would be ideal if we could just use the same variant! yea, it?s looking like it will be the same thing, we might just have to make a note of it on the UI > > > ad) Compatibility > > I would say we should preserve the compatibility with 1.x as long as it does not make much efforts to keep both supported. > > If it would be too much hassle, let's remove it in 1.1. > Chrome is updated pro-actively anyway, so no one will hear about the old API in few months. exactly, so maybe a warning or something > > > Cheers, > > ~ Lukas > > > On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist wrote: > Hello, > > now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i?m starting to look at the new API that Chrome apps use for sending push notifications. > > the TL;DR of it is, it?s basically the same as Android now.( no more refresh tokens and access tokens and such ) > > So the question is, do we need to have a deprecation period on what is currently there? > > The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1 > > While i have looked to deeply, it?s possible we can use the same ?Variant? structure for Chrome Apps, Since they will be using the same Network > > wdyt? > > -Luke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140827/2387195d/attachment.html From matzew at apache.org Thu Aug 28 01:50:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Aug 2014 07:50:52 +0200 Subject: [aerogear-dev] REST-based API Versioning Message-ID: Hello, for the 1.1.x (master) we are potentially doing some changes on the Sender-API (see [1]). However, for backwards compatibility we need to think about API versioning. For REST APIs there are (IMO) two options: * accept header * URIs On our Face2Face meeting we briefly talked about this and I think the "accept header" solution was the one that had most fans. I think QMX added that it is better for migration. One thing we were not clear on (I think): What are HATEOS defined semantics? Besides the what (headers vs. URI), I think we should think about possible implementations, to switch different versions. Not sure, but wouldn't it be possible to inject an annotated SenderService into the RESTful endpoint, based on header values ? We could have a default impl (version 1.0.0) and an alternate one, that is injected if the accept header indicate API version 1.1 Any thoughts ? -Matthias [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/f0484b5c/attachment.html From daniel.bevenius at gmail.com Thu Aug 28 02:07:46 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 28 Aug 2014 08:07:46 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: +1 For using the Accept header to specify the version in the media type. On 28 August 2014 07:50, Matthias Wessendorf wrote: > Hello, > > for the 1.1.x (master) we are potentially doing some changes on the > Sender-API (see [1]). > > However, for backwards compatibility we need to think about API versioning. > > For REST APIs there are (IMO) two options: > * accept header > * URIs > > On our Face2Face meeting we briefly talked about this and I think the > "accept header" solution was the one that had most fans. I think QMX added > that it is better for migration. One thing we were not clear on (I think): > What are HATEOS defined semantics? > > > Besides the what (headers vs. URI), I think we should think about possible > implementations, to switch different versions. > > Not sure, but wouldn't it be possible to inject an annotated SenderService > into the RESTful endpoint, based on header values ? > We could have a default impl (version 1.0.0) and an alternate one, that is > injected if the accept header indicate API version 1.1 > > Any thoughts ? > > -Matthias > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/ad46fc95/attachment-0001.html From scm.blanc at gmail.com Thu Aug 28 03:25:47 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 28 Aug 2014 09:25:47 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: Some questions : * If we go for the accept header and the consumer don't provide it, what do we do ? Return an error or use implicitly the latest version ? * What will be our deprecation policy ? Do we want keep maintaining all the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 we drop 1.0 ? About the implementation : * I like the suggested CDI solution, if possible. * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno Sebi ps : I just read this blog post and it's really interesting : http://apiux.com/2013/05/14/api-versioning/ On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius wrote: > +1 For using the Accept header to specify the version in the media type. > > > On 28 August 2014 07:50, Matthias Wessendorf wrote: > >> Hello, >> >> for the 1.1.x (master) we are potentially doing some changes on the >> Sender-API (see [1]). >> >> However, for backwards compatibility we need to think about API >> versioning. >> >> For REST APIs there are (IMO) two options: >> * accept header >> * URIs >> >> On our Face2Face meeting we briefly talked about this and I think the >> "accept header" solution was the one that had most fans. I think QMX added >> that it is better for migration. One thing we were not clear on (I think): >> What are HATEOS defined semantics? >> >> >> Besides the what (headers vs. URI), I think we should think about >> possible implementations, to switch different versions. >> >> Not sure, but wouldn't it be possible to inject an annotated >> SenderService into the RESTful endpoint, based on header values ? >> We could have a default impl (version 1.0.0) and an alternate one, that >> is injected if the accept header indicate API version 1.1 >> >> Any thoughts ? >> >> -Matthias >> >> >> [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/8b636ae9/attachment.html From daniel.bevenius at gmail.com Thu Aug 28 03:29:02 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 28 Aug 2014 09:29:02 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: >If we go for the accept header and the consumer don't provide it, what do we do ? Return an error or use implicitly the latest version ? Perhaps we can return the current version to not break any existing clients. New clients will need to provide an explicit version. On 28 August 2014 09:25, Sebastien Blanc wrote: > Some questions : > > * If we go for the accept header and the consumer don't provide it, what > do we do ? Return an error or use implicitly the latest version ? > * What will be our deprecation policy ? Do we want keep maintaining all > the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 > we drop 1.0 ? > > About the implementation : > * I like the suggested CDI solution, if possible. > * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno > > Sebi > ps : I just read this blog post and it's really interesting : > http://apiux.com/2013/05/14/api-versioning/ > > > > On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> +1 For using the Accept header to specify the version in the media type. >> >> >> On 28 August 2014 07:50, Matthias Wessendorf wrote: >> >>> Hello, >>> >>> for the 1.1.x (master) we are potentially doing some changes on the >>> Sender-API (see [1]). >>> >>> However, for backwards compatibility we need to think about API >>> versioning. >>> >>> For REST APIs there are (IMO) two options: >>> * accept header >>> * URIs >>> >>> On our Face2Face meeting we briefly talked about this and I think the >>> "accept header" solution was the one that had most fans. I think QMX added >>> that it is better for migration. One thing we were not clear on (I think): >>> What are HATEOS defined semantics? >>> >>> >>> Besides the what (headers vs. URI), I think we should think about >>> possible implementations, to switch different versions. >>> >>> Not sure, but wouldn't it be possible to inject an annotated >>> SenderService into the RESTful endpoint, based on header values ? >>> We could have a default impl (version 1.0.0) and an alternate one, that >>> is injected if the accept header indicate API version 1.1 >>> >>> Any thoughts ? >>> >>> -Matthias >>> >>> >>> [1] >>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/c9f37eee/attachment.html From matzew at apache.org Thu Aug 28 03:38:58 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Aug 2014 09:38:58 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: On Thu, Aug 28, 2014 at 9:25 AM, Sebastien Blanc wrote: > Some questions : > > * If we go for the accept header and the consumer don't provide it, what > do we do ? Return an error or use implicitly the latest version ? > * What will be our deprecation policy ? Do we want keep maintaining all > the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 > we drop 1.0 ? > > About the implementation : > * I like the suggested CDI solution, if possible. > * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno > that OSGI suggestion was a joke ;-) > > Sebi > ps : I just read this blog post and it's really interesting : > http://apiux.com/2013/05/14/api-versioning/ > > > > On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> +1 For using the Accept header to specify the version in the media type. >> >> >> On 28 August 2014 07:50, Matthias Wessendorf wrote: >> >>> Hello, >>> >>> for the 1.1.x (master) we are potentially doing some changes on the >>> Sender-API (see [1]). >>> >>> However, for backwards compatibility we need to think about API >>> versioning. >>> >>> For REST APIs there are (IMO) two options: >>> * accept header >>> * URIs >>> >>> On our Face2Face meeting we briefly talked about this and I think the >>> "accept header" solution was the one that had most fans. I think QMX added >>> that it is better for migration. One thing we were not clear on (I think): >>> What are HATEOS defined semantics? >>> >>> >>> Besides the what (headers vs. URI), I think we should think about >>> possible implementations, to switch different versions. >>> >>> Not sure, but wouldn't it be possible to inject an annotated >>> SenderService into the RESTful endpoint, based on header values ? >>> We could have a default impl (version 1.0.0) and an alternate one, that >>> is injected if the accept header indicate API version 1.1 >>> >>> Any thoughts ? >>> >>> -Matthias >>> >>> >>> [1] >>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/ea519918/attachment-0001.html From corinnekrych at gmail.com Thu Aug 28 03:54:01 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 28 Aug 2014 09:54:01 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: On 28 Aug 2014, at 09:29, Daniel Bevenius wrote: > Perhaps we can return the current version to not break any existing clients. New clients will need to provide an explicit version. +1 From scm.blanc at gmail.com Thu Aug 28 04:14:12 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 28 Aug 2014 10:14:12 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius wrote: > >If we go for the accept header and the consumer don't provide it, what > do we do ? Return an error or use implicitly the latest version ? > Perhaps we can return the current version to not break any existing > clients. New clients will need to provide an explicit version. > Why not but for how long do we return the "old" version by default ? (cf my questions around deprecation) > > > On 28 August 2014 09:25, Sebastien Blanc wrote: > >> Some questions : >> >> * If we go for the accept header and the consumer don't provide it, what >> do we do ? Return an error or use implicitly the latest version ? >> * What will be our deprecation policy ? Do we want keep maintaining all >> the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 >> we drop 1.0 ? >> >> About the implementation : >> * I like the suggested CDI solution, if possible. >> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno >> >> Sebi >> ps : I just read this blog post and it's really interesting : >> http://apiux.com/2013/05/14/api-versioning/ >> >> >> >> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> +1 For using the Accept header to specify the version in the media type. >>> >>> >>> On 28 August 2014 07:50, Matthias Wessendorf wrote: >>> >>>> Hello, >>>> >>>> for the 1.1.x (master) we are potentially doing some changes on the >>>> Sender-API (see [1]). >>>> >>>> However, for backwards compatibility we need to think about API >>>> versioning. >>>> >>>> For REST APIs there are (IMO) two options: >>>> * accept header >>>> * URIs >>>> >>>> On our Face2Face meeting we briefly talked about this and I think the >>>> "accept header" solution was the one that had most fans. I think QMX added >>>> that it is better for migration. One thing we were not clear on (I think): >>>> What are HATEOS defined semantics? >>>> >>>> >>>> Besides the what (headers vs. URI), I think we should think about >>>> possible implementations, to switch different versions. >>>> >>>> Not sure, but wouldn't it be possible to inject an annotated >>>> SenderService into the RESTful endpoint, based on header values ? >>>> We could have a default impl (version 1.0.0) and an alternate one, that >>>> is injected if the accept header indicate API version 1.1 >>>> >>>> Any thoughts ? >>>> >>>> -Matthias >>>> >>>> >>>> [1] >>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/29a5043b/attachment.html From matzew at apache.org Thu Aug 28 04:14:30 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Aug 2014 10:14:30 +0200 Subject: [aerogear-dev] AeroGear Mobile Push 1.0.0 is out! Message-ID: Hi all, we are happy to announce the availability of our Push 1.0.0 bundle! http://aerogear.org/news/2014/08/27/aerogear-push-1.0.0-is-out/index.html We hope you enjoy it. As always, questions, feedback are more than welcome! Happy push! -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/be421d00/attachment.html From matzew at apache.org Thu Aug 28 04:15:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Aug 2014 10:15:48 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc wrote: > > > > On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> >If we go for the accept header and the consumer don't provide it, what >> do we do ? Return an error or use implicitly the latest version ? >> Perhaps we can return the current version to not break any existing >> clients. New clients will need to provide an explicit version. >> > Why not but for how long do we return the "old" version by default ? (cf > my questions around deprecation) > yep - I am for that: looks like I forgot, and I think we had that on our face2face: no version == 1.0.0 (old) -M > >> >> On 28 August 2014 09:25, Sebastien Blanc wrote: >> >>> Some questions : >>> >>> * If we go for the accept header and the consumer don't provide it, what >>> do we do ? Return an error or use implicitly the latest version ? >>> * What will be our deprecation policy ? Do we want keep maintaining all >>> the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 >>> we drop 1.0 ? >>> >>> About the implementation : >>> * I like the suggested CDI solution, if possible. >>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno >>> >>> Sebi >>> ps : I just read this blog post and it's really interesting : >>> http://apiux.com/2013/05/14/api-versioning/ >>> >>> >>> >>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> +1 For using the Accept header to specify the version in the media type. >>>> >>>> >>>> On 28 August 2014 07:50, Matthias Wessendorf wrote: >>>> >>>>> Hello, >>>>> >>>>> for the 1.1.x (master) we are potentially doing some changes on the >>>>> Sender-API (see [1]). >>>>> >>>>> However, for backwards compatibility we need to think about API >>>>> versioning. >>>>> >>>>> For REST APIs there are (IMO) two options: >>>>> * accept header >>>>> * URIs >>>>> >>>>> On our Face2Face meeting we briefly talked about this and I think the >>>>> "accept header" solution was the one that had most fans. I think QMX added >>>>> that it is better for migration. One thing we were not clear on (I think): >>>>> What are HATEOS defined semantics? >>>>> >>>>> >>>>> Besides the what (headers vs. URI), I think we should think about >>>>> possible implementations, to switch different versions. >>>>> >>>>> Not sure, but wouldn't it be possible to inject an annotated >>>>> SenderService into the RESTful endpoint, based on header values ? >>>>> We could have a default impl (version 1.0.0) and an alternate one, >>>>> that is injected if the accept header indicate API version 1.1 >>>>> >>>>> Any thoughts ? >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> [1] >>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/8120bf31/attachment-0001.html From bruno at abstractj.org Thu Aug 28 04:32:42 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 28 Aug 2014 05:32:42 -0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: <20140828083242.GA57031@abstractj.org> +1 on accept header On 2014-08-28, Matthias Wessendorf wrote: > Hello, > > for the 1.1.x (master) we are potentially doing some changes on the > Sender-API (see [1]). > > However, for backwards compatibility we need to think about API versioning. > > For REST APIs there are (IMO) two options: > * accept header > * URIs > > On our Face2Face meeting we briefly talked about this and I think the > "accept header" solution was the one that had most fans. I think QMX added > that it is better for migration. One thing we were not clear on (I think): > What are HATEOS defined semantics? > > > Besides the what (headers vs. URI), I think we should think about possible > implementations, to switch different versions. > > Not sure, but wouldn't it be possible to inject an annotated SenderService > into the RESTful endpoint, based on header values ? > We could have a default impl (version 1.0.0) and an alternate one, that is > injected if the accept header indicate API version 1.1 > > Any thoughts ? > > -Matthias > > > [1] http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 28 04:34:28 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 28 Aug 2014 05:34:28 -0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: <20140828083428.GB57031@abstractj.org> On 2014-08-28, Daniel Bevenius wrote: > >If we go for the accept header and the consumer don't provide it, what do > we do ? Return an error or use implicitly the latest version ? > Perhaps we can return the current version to not break any existing > clients. New clients will need to provide an explicit version. +1 on return the latest version > > > On 28 August 2014 09:25, Sebastien Blanc wrote: > > > Some questions : > > > > * If we go for the accept header and the consumer don't provide it, what > > do we do ? Return an error or use implicitly the latest version ? > > * What will be our deprecation policy ? Do we want keep maintaining all > > the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 > > we drop 1.0 ? > > > > About the implementation : > > * I like the suggested CDI solution, if possible. > > * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno > > > > Sebi > > ps : I just read this blog post and it's really interesting : > > http://apiux.com/2013/05/14/api-versioning/ > > > > > > > > On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < > > daniel.bevenius at gmail.com> wrote: > > > >> +1 For using the Accept header to specify the version in the media type. > >> > >> > >> On 28 August 2014 07:50, Matthias Wessendorf wrote: > >> > >>> Hello, > >>> > >>> for the 1.1.x (master) we are potentially doing some changes on the > >>> Sender-API (see [1]). > >>> > >>> However, for backwards compatibility we need to think about API > >>> versioning. > >>> > >>> For REST APIs there are (IMO) two options: > >>> * accept header > >>> * URIs > >>> > >>> On our Face2Face meeting we briefly talked about this and I think the > >>> "accept header" solution was the one that had most fans. I think QMX added > >>> that it is better for migration. One thing we were not clear on (I think): > >>> What are HATEOS defined semantics? > >>> > >>> > >>> Besides the what (headers vs. URI), I think we should think about > >>> possible implementations, to switch different versions. > >>> > >>> Not sure, but wouldn't it be possible to inject an annotated > >>> SenderService into the RESTful endpoint, based on header values ? > >>> We could have a default impl (version 1.0.0) and an alternate one, that > >>> is injected if the accept header indicate API version 1.1 > >>> > >>> Any thoughts ? > >>> > >>> -Matthias > >>> > >>> > >>> [1] > >>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html > >>> > >>> -- > >>> Matthias Wessendorf > >>> > >>> blog: http://matthiaswessendorf.wordpress.com/ > >>> sessions: http://www.slideshare.net/mwessendorf > >>> twitter: http://twitter.com/mwessendorf > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Thu Aug 28 04:36:34 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 28 Aug 2014 05:36:34 -0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: <20140828083634.GC57031@abstractj.org> On 2014-08-28, Matthias Wessendorf wrote: > On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc > wrote: > > > > > > > > > On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < > > daniel.bevenius at gmail.com> wrote: > > > >> >If we go for the accept header and the consumer don't provide it, what > >> do we do ? Return an error or use implicitly the latest version ? > >> Perhaps we can return the current version to not break any existing > >> clients. New clients will need to provide an explicit version. > >> > > Why not but for how long do we return the "old" version by default ? (cf > > my questions around deprecation) > > > > yep - I am for that: looks like I forgot, and I think we had that on our > face2face: no version == 1.0.0 (old) I vote for return the latest, instead of something old. And specify old versions if you want to. > > -M > > > > > >> > >> On 28 August 2014 09:25, Sebastien Blanc wrote: > >> > >>> Some questions : > >>> > >>> * If we go for the accept header and the consumer don't provide it, what > >>> do we do ? Return an error or use implicitly the latest version ? > >>> * What will be our deprecation policy ? Do we want keep maintaining all > >>> the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 > >>> we drop 1.0 ? > >>> > >>> About the implementation : > >>> * I like the suggested CDI solution, if possible. > >>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno > >>> > >>> Sebi > >>> ps : I just read this blog post and it's really interesting : > >>> http://apiux.com/2013/05/14/api-versioning/ > >>> > >>> > >>> > >>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < > >>> daniel.bevenius at gmail.com> wrote: > >>> > >>>> +1 For using the Accept header to specify the version in the media type. > >>>> > >>>> > >>>> On 28 August 2014 07:50, Matthias Wessendorf wrote: > >>>> > >>>>> Hello, > >>>>> > >>>>> for the 1.1.x (master) we are potentially doing some changes on the > >>>>> Sender-API (see [1]). > >>>>> > >>>>> However, for backwards compatibility we need to think about API > >>>>> versioning. > >>>>> > >>>>> For REST APIs there are (IMO) two options: > >>>>> * accept header > >>>>> * URIs > >>>>> > >>>>> On our Face2Face meeting we briefly talked about this and I think the > >>>>> "accept header" solution was the one that had most fans. I think QMX added > >>>>> that it is better for migration. One thing we were not clear on (I think): > >>>>> What are HATEOS defined semantics? > >>>>> > >>>>> > >>>>> Besides the what (headers vs. URI), I think we should think about > >>>>> possible implementations, to switch different versions. > >>>>> > >>>>> Not sure, but wouldn't it be possible to inject an annotated > >>>>> SenderService into the RESTful endpoint, based on header values ? > >>>>> We could have a default impl (version 1.0.0) and an alternate one, > >>>>> that is injected if the accept header indicate API version 1.1 > >>>>> > >>>>> Any thoughts ? > >>>>> > >>>>> -Matthias > >>>>> > >>>>> > >>>>> [1] > >>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html > >>>>> > >>>>> -- > >>>>> Matthias Wessendorf > >>>>> > >>>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>>> sessions: http://www.slideshare.net/mwessendorf > >>>>> twitter: http://twitter.com/mwessendorf > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From edewit at redhat.com Thu Aug 28 04:39:33 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 28 Aug 2014 10:39:33 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: <93681088-36D6-460D-BFDB-32F88554D128@redhat.com> > > On our Face2Face meeting we briefly talked about this and I think the "accept header" solution was the one that had most fans. I think QMX added that it is better for migration. One thing we were not clear on (I think): What are HATEOS defined semantics? > +1 for accept header > > Besides the what (headers vs. URI), I think we should think about possible implementations, to switch different versions. > > Not sure, but wouldn't it be possible to inject an annotated SenderService into the RESTful endpoint, based on header values ? > We could have a default impl (version 1.0.0) and an alternate one, that is injected if the accept header indicate API version 1.1 Don?t know of anything that can do something like that automatically and rest easy doesn?t provide anything for versioning. I would propose to keep it simple and let UPS internally use the latest version and provide something like a servlet filter that converts old calls to the new API or dispatches to another rest end point WDYT From scm.blanc at gmail.com Thu Aug 28 04:42:01 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 28 Aug 2014 10:42:01 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <93681088-36D6-460D-BFDB-32F88554D128@redhat.com> References: <93681088-36D6-460D-BFDB-32F88554D128@redhat.com> Message-ID: On Thu, Aug 28, 2014 at 10:39 AM, Erik Jan de Wit wrote: > > > > On our Face2Face meeting we briefly talked about this and I think the > "accept header" solution was the one that had most fans. I think QMX added > that it is better for migration. One thing we were not clear on (I think): > What are HATEOS defined semantics? > > > +1 for accept header > > > > Besides the what (headers vs. URI), I think we should think about > possible implementations, to switch different versions. > > > > Not sure, but wouldn't it be possible to inject an annotated > SenderService into the RESTful endpoint, based on header values ? > > We could have a default impl (version 1.0.0) and an alternate one, that > is injected if the accept header indicate API version 1.1 > > Don?t know of anything that can do something like that automatically and > rest easy doesn?t provide anything for versioning. I would propose to keep > it simple and let UPS internally use the latest version and provide > something like a servlet filter that converts old calls to the new API or > dispatches to another rest end point > > WDYT > +1 I like the Servlet Filter approach > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/4d6c5272/attachment.html From edewit at redhat.com Thu Aug 28 07:09:08 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 28 Aug 2014 13:09:08 +0200 Subject: [aerogear-dev] swift cordova plugin Message-ID: <6CDB0A05-6DA2-4FA6-9A8A-AB6FE064D4DA@redhat.com> Hi Swift lovers, In order to test if Swift could even be used to write cordova plugins and truly test the objective-c -> Swift interoperability. I?ve created a port of a very simple hello world plugin to Swfit to see if that could work. It seems that there is only one small hurdle the Bridging-Header is not automatically added to the compiler options and the runtime libs are not there. After changing these settings by hand one can use it. I?ve asked the cordova ML if there are any solutions to these problems. Cheers, Erik Jan have a look that the github plugin project https://github.com/edewit/cordova-plugin-hello/tree/swift -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/8535ccee/attachment-0001.html From lholmqui at redhat.com Thu Aug 28 08:39:40 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 28 Aug 2014 08:39:40 -0400 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <20140828083634.GC57031@abstractj.org> References: <20140828083634.GC57031@abstractj.org> Message-ID: <1E4B9FA5-E620-4407-B6F5-21A2BB9FF1B7@redhat.com> +1 on Accept headers and also using the latest and greatest if no version is specified/ i believe this is what github also does On Aug 28, 2014, at 4:36 AM, Bruno Oliveira wrote: > On 2014-08-28, Matthias Wessendorf wrote: >> On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc >> wrote: >> >>> >>> >>> >>> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>>> If we go for the accept header and the consumer don't provide it, what >>>> do we do ? Return an error or use implicitly the latest version ? >>>> Perhaps we can return the current version to not break any existing >>>> clients. New clients will need to provide an explicit version. >>>> >>> Why not but for how long do we return the "old" version by default ? (cf >>> my questions around deprecation) >>> >> >> yep - I am for that: looks like I forgot, and I think we had that on our >> face2face: no version == 1.0.0 (old) > > I vote for return the latest, instead of something old. And specify old > versions if you want to. > >> >> -M >> >> >>> >>>> >>>> On 28 August 2014 09:25, Sebastien Blanc wrote: >>>> >>>>> Some questions : >>>>> >>>>> * If we go for the accept header and the consumer don't provide it, what >>>>> do we do ? Return an error or use implicitly the latest version ? >>>>> * What will be our deprecation policy ? Do we want keep maintaining all >>>>> the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 >>>>> we drop 1.0 ? >>>>> >>>>> About the implementation : >>>>> * I like the suggested CDI solution, if possible. >>>>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno >>>>> >>>>> Sebi >>>>> ps : I just read this blog post and it's really interesting : >>>>> http://apiux.com/2013/05/14/api-versioning/ >>>>> >>>>> >>>>> >>>>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> +1 For using the Accept header to specify the version in the media type. >>>>>> >>>>>> >>>>>> On 28 August 2014 07:50, Matthias Wessendorf wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> for the 1.1.x (master) we are potentially doing some changes on the >>>>>>> Sender-API (see [1]). >>>>>>> >>>>>>> However, for backwards compatibility we need to think about API >>>>>>> versioning. >>>>>>> >>>>>>> For REST APIs there are (IMO) two options: >>>>>>> * accept header >>>>>>> * URIs >>>>>>> >>>>>>> On our Face2Face meeting we briefly talked about this and I think the >>>>>>> "accept header" solution was the one that had most fans. I think QMX added >>>>>>> that it is better for migration. One thing we were not clear on (I think): >>>>>>> What are HATEOS defined semantics? >>>>>>> >>>>>>> >>>>>>> Besides the what (headers vs. URI), I think we should think about >>>>>>> possible implementations, to switch different versions. >>>>>>> >>>>>>> Not sure, but wouldn't it be possible to inject an annotated >>>>>>> SenderService into the RESTful endpoint, based on header values ? >>>>>>> We could have a default impl (version 1.0.0) and an alternate one, >>>>>>> that is injected if the accept header indicate API version 1.1 >>>>>>> >>>>>>> Any thoughts ? >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/5a343fac/attachment.html From daniel at passos.me Thu Aug 28 08:46:39 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 28 Aug 2014 09:46:39 -0300 Subject: [aerogear-dev] swift cordova plugin In-Reply-To: <6CDB0A05-6DA2-4FA6-9A8A-AB6FE064D4DA@redhat.com> References: <6CDB0A05-6DA2-4FA6-9A8A-AB6FE064D4DA@redhat.com> Message-ID: Very nice! On Thu, Aug 28, 2014 at 8:09 AM, Erik Jan de Wit wrote: > Hi Swift lovers, > > In order to test if Swift could even be used to write cordova plugins and > truly test the objective-c -> Swift interoperability. I?ve created a port > of a very simple hello world plugin to Swfit to see if that could work. > > It seems that there is only one small hurdle the Bridging-Header is not > automatically added to the compiler options and the runtime libs are not > there. After changing these settings by hand one can use it. I?ve asked the > cordova ML if there are any solutions to these problems. > > Cheers, > Erik Jan > > have a look that the github plugin project > https://github.com/edewit/cordova-plugin-hello/tree/swift > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/0cf383ff/attachment.html From daniel.bevenius at gmail.com Thu Aug 28 08:51:03 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 28 Aug 2014 14:51:03 +0200 Subject: [aerogear-dev] swift cordova plugin In-Reply-To: References: <6CDB0A05-6DA2-4FA6-9A8A-AB6FE064D4DA@redhat.com> Message-ID: Cool On 28 August 2014 14:46, Daniel Passos wrote: > Very nice! > > > On Thu, Aug 28, 2014 at 8:09 AM, Erik Jan de Wit > wrote: > >> Hi Swift lovers, >> >> In order to test if Swift could even be used to write cordova plugins and >> truly test the objective-c -> Swift interoperability. I?ve created a port >> of a very simple hello world plugin to Swfit to see if that could work. >> >> It seems that there is only one small hurdle the Bridging-Header is not >> automatically added to the compiler options and the runtime libs are not >> there. After changing these settings by hand one can use it. I?ve asked the >> cordova ML if there are any solutions to these problems. >> >> Cheers, >> Erik Jan >> >> have a look that the github plugin project >> https://github.com/edewit/cordova-plugin-hello/tree/swift >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/81216bfe/attachment.html From corinnekrych at gmail.com Thu Aug 28 08:53:50 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 28 Aug 2014 14:53:50 +0200 Subject: [aerogear-dev] swift cordova plugin In-Reply-To: References: <6CDB0A05-6DA2-4FA6-9A8A-AB6FE064D4DA@redhat.com> Message-ID: Ahh so all the magic is with @objc and bridging header Thanks for sharing ++ Corinne On 28 Aug 2014, at 14:51, Daniel Bevenius wrote: > Cool > > > On 28 August 2014 14:46, Daniel Passos wrote: > Very nice! > > > On Thu, Aug 28, 2014 at 8:09 AM, Erik Jan de Wit wrote: > Hi Swift lovers, > > In order to test if Swift could even be used to write cordova plugins and truly test the objective-c -> Swift interoperability. I?ve created a port of a very simple hello world plugin to Swfit to see if that could work. > > It seems that there is only one small hurdle the Bridging-Header is not automatically added to the compiler options and the runtime libs are not there. After changing these settings by hand one can use it. I?ve asked the cordova ML if there are any solutions to these problems. > > Cheers, > Erik Jan > > have a look that the github plugin project > https://github.com/edewit/cordova-plugin-hello/tree/swift > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Aug 28 09:18:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Aug 2014 15:18:09 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <1E4B9FA5-E620-4407-B6F5-21A2BB9FF1B7@redhat.com> References: <20140828083634.GC57031@abstractj.org> <1E4B9FA5-E620-4407-B6F5-21A2BB9FF1B7@redhat.com> Message-ID: the problem is... our 1.0.0 SDKs do not specify a version :-) so, they would than talk to the latest greatest, that does not work. We need to have that in mind, when planing this. On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist wrote: > +1 on Accept headers and also using the latest and greatest if no version > is specified/ > > i believe this is what github also does > > On Aug 28, 2014, at 4:36 AM, Bruno Oliveira wrote: > > On 2014-08-28, Matthias Wessendorf wrote: > > On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc > wrote: > > > > > On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > > If we go for the accept header and the consumer don't provide it, what > > do we do ? Return an error or use implicitly the latest version ? > Perhaps we can return the current version to not break any existing > clients. New clients will need to provide an explicit version. > > Why not but for how long do we return the "old" version by default ? (cf > my questions around deprecation) > > > yep - I am for that: looks like I forgot, and I think we had that on our > face2face: no version == 1.0.0 (old) > > > I vote for return the latest, instead of something old. And specify old > versions if you want to. > > > -M > > > > > On 28 August 2014 09:25, Sebastien Blanc wrote: > > Some questions : > > * If we go for the accept header and the consumer don't provide it, what > do we do ? Return an error or use implicitly the latest version ? > * What will be our deprecation policy ? Do we want keep maintaining all > the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 > we drop 1.0 ? > > About the implementation : > * I like the suggested CDI solution, if possible. > * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno > > Sebi > ps : I just read this blog post and it's really interesting : > http://apiux.com/2013/05/14/api-versioning/ > > > > On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > > +1 For using the Accept header to specify the version in the media type. > > > On 28 August 2014 07:50, Matthias Wessendorf wrote: > > Hello, > > for the 1.1.x (master) we are potentially doing some changes on the > Sender-API (see [1]). > > However, for backwards compatibility we need to think about API > versioning. > > For REST APIs there are (IMO) two options: > * accept header > * URIs > > On our Face2Face meeting we briefly talked about this and I think the > "accept header" solution was the one that had most fans. I think QMX added > that it is better for migration. One thing we were not clear on (I think): > What are HATEOS defined semantics? > > > Besides the what (headers vs. URI), I think we should think about > possible implementations, to switch different versions. > > Not sure, but wouldn't it be possible to inject an annotated > SenderService into the RESTful endpoint, based on header values ? > We could have a default impl (version 1.0.0) and an alternate one, > that is injected if the accept header indicate API version 1.1 > > Any thoughts ? > > -Matthias > > > [1] > http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/ff1807ed/attachment-0001.html From bruno at abstractj.org Thu Aug 28 10:03:47 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 28 Aug 2014 07:03:47 -0700 (PDT) Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: <1409234343233.eec9f5f8@Nodemailer> I think this is something to fix at our SDKs, and think about the legacy, that's the price to pay. The easy solution is to defaults to 1.0.0, but it doesn't seem correct. ? abstractj PGP: 0x84DC9914 On Thu, Aug 28, 2014 at 10:18 AM, Matthias Wessendorf wrote: > the problem is... our 1.0.0 SDKs do not specify a version :-) > so, they would than talk to the latest greatest, that does not work. > We need to have that in mind, when planing this. > On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist > wrote: >> +1 on Accept headers and also using the latest and greatest if no version >> is specified/ >> >> i believe this is what github also does >> >> On Aug 28, 2014, at 4:36 AM, Bruno Oliveira wrote: >> >> On 2014-08-28, Matthias Wessendorf wrote: >> >> On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc >> wrote: >> >> >> >> >> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >> If we go for the accept header and the consumer don't provide it, what >> >> do we do ? Return an error or use implicitly the latest version ? >> Perhaps we can return the current version to not break any existing >> clients. New clients will need to provide an explicit version. >> >> Why not but for how long do we return the "old" version by default ? (cf >> my questions around deprecation) >> >> >> yep - I am for that: looks like I forgot, and I think we had that on our >> face2face: no version == 1.0.0 (old) >> >> >> I vote for return the latest, instead of something old. And specify old >> versions if you want to. >> >> >> -M >> >> >> >> >> On 28 August 2014 09:25, Sebastien Blanc wrote: >> >> Some questions : >> >> * If we go for the accept header and the consumer don't provide it, what >> do we do ? Return an error or use implicitly the latest version ? >> * What will be our deprecation policy ? Do we want keep maintaining all >> the versions forever or let's say for 1.1 we still provide 1.0 and for 2.0 >> we drop 1.0 ? >> >> About the implementation : >> * I like the suggested CDI solution, if possible. >> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno >> >> Sebi >> ps : I just read this blog post and it's really interesting : >> http://apiux.com/2013/05/14/api-versioning/ >> >> >> >> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >> +1 For using the Accept header to specify the version in the media type. >> >> >> On 28 August 2014 07:50, Matthias Wessendorf wrote: >> >> Hello, >> >> for the 1.1.x (master) we are potentially doing some changes on the >> Sender-API (see [1]). >> >> However, for backwards compatibility we need to think about API >> versioning. >> >> For REST APIs there are (IMO) two options: >> * accept header >> * URIs >> >> On our Face2Face meeting we briefly talked about this and I think the >> "accept header" solution was the one that had most fans. I think QMX added >> that it is better for migration. One thing we were not clear on (I think): >> What are HATEOS defined semantics? >> >> >> Besides the what (headers vs. URI), I think we should think about >> possible implementations, to switch different versions. >> >> Not sure, but wouldn't it be possible to inject an annotated >> SenderService into the RESTful endpoint, based on header values ? >> We could have a default impl (version 1.0.0) and an alternate one, >> that is injected if the accept header indicate API version 1.1 >> >> Any thoughts ? >> >> -Matthias >> >> >> [1] >> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > -- > Matthias Wessendorf > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/790c8c2f/attachment.html From matzew at apache.org Thu Aug 28 10:15:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Aug 2014 16:15:53 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <1409234343233.eec9f5f8@Nodemailer> References: <1409234343233.eec9f5f8@Nodemailer> Message-ID: On Thu, Aug 28, 2014 at 4:03 PM, Bruno Oliveira wrote: > I think this is something to fix at our SDKs, like releasing 1.0.x (Server and SDKs), where the versioning is in? That's possible. And that way, we can say, why are you using 1.0.0, we released 1.0.1 with (some sort of) fixes -M > and think about the legacy, that's the price to pay. > > The easy solution is to defaults to 1.0.0, but it doesn't seem correct. > ? > abstractj > PGP: 0x84DC9914 > > > On Thu, Aug 28, 2014 at 10:18 AM, Matthias Wessendorf > wrote: > >> the problem is... our 1.0.0 SDKs do not specify a version :-) >> so, they would than talk to the latest greatest, that does not work. >> >> We need to have that in mind, when planing this. >> >> >> >> >> On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist >> wrote: >> >>> +1 on Accept headers and also using the latest and greatest if no >>> version is specified/ >>> >>> i believe this is what github also does >>> >>> On Aug 28, 2014, at 4:36 AM, Bruno Oliveira wrote: >>> >>> On 2014-08-28, Matthias Wessendorf wrote: >>> >>> On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>> If we go for the accept header and the consumer don't provide it, what >>> >>> do we do ? Return an error or use implicitly the latest version ? >>> Perhaps we can return the current version to not break any existing >>> clients. New clients will need to provide an explicit version. >>> >>> Why not but for how long do we return the "old" version by default ? (cf >>> my questions around deprecation) >>> >>> >>> yep - I am for that: looks like I forgot, and I think we had that on our >>> face2face: no version == 1.0.0 (old) >>> >>> >>> I vote for return the latest, instead of something old. And specify old >>> versions if you want to. >>> >>> >>> -M >>> >>> >>> >>> >>> On 28 August 2014 09:25, Sebastien Blanc wrote: >>> >>> Some questions : >>> >>> * If we go for the accept header and the consumer don't provide it, what >>> do we do ? Return an error or use implicitly the latest version ? >>> * What will be our deprecation policy ? Do we want keep maintaining all >>> the versions forever or let's say for 1.1 we still provide 1.0 and for >>> 2.0 >>> we drop 1.0 ? >>> >>> About the implementation : >>> * I like the suggested CDI solution, if possible. >>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno >>> >>> Sebi >>> ps : I just read this blog post and it's really interesting : >>> http://apiux.com/2013/05/14/api-versioning/ >>> >>> >>> >>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>> +1 For using the Accept header to specify the version in the media type. >>> >>> >>> On 28 August 2014 07:50, Matthias Wessendorf wrote: >>> >>> Hello, >>> >>> for the 1.1.x (master) we are potentially doing some changes on the >>> Sender-API (see [1]). >>> >>> However, for backwards compatibility we need to think about API >>> versioning. >>> >>> For REST APIs there are (IMO) two options: >>> * accept header >>> * URIs >>> >>> On our Face2Face meeting we briefly talked about this and I think the >>> "accept header" solution was the one that had most fans. I think QMX >>> added >>> that it is better for migration. One thing we were not clear on (I >>> think): >>> What are HATEOS defined semantics? >>> >>> >>> Besides the what (headers vs. URI), I think we should think about >>> possible implementations, to switch different versions. >>> >>> Not sure, but wouldn't it be possible to inject an annotated >>> SenderService into the RESTful endpoint, based on header values ? >>> We could have a default impl (version 1.0.0) and an alternate one, >>> that is injected if the accept header indicate API version 1.1 >>> >>> Any thoughts ? >>> >>> -Matthias >>> >>> >>> [1] >>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/d28337f2/attachment-0001.html From matzew at apache.org Thu Aug 28 10:21:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Aug 2014 16:21:02 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> Message-ID: On Thu, Aug 28, 2014 at 4:15 PM, Matthias Wessendorf wrote: > > > > On Thu, Aug 28, 2014 at 4:03 PM, Bruno Oliveira > wrote: > >> I think this is something to fix at our SDKs, > > > like releasing 1.0.x (Server and SDKs), where the versioning is in? > > That's possible. And that way, we can say, why are you using 1.0.0, we > released 1.0.1 with (some sort of) fixes > Not sure that really flies :-) >> The easy solution is to defaults to 1.0.0, but it doesn't seem correct. >> > "correct" is a perspective :-) Not said I do like it as the most awesome ever solution, just being practical here > ? >> abstractj >> PGP: 0x84DC9914 >> >> >> On Thu, Aug 28, 2014 at 10:18 AM, Matthias Wessendorf >> wrote: >> >>> the problem is... our 1.0.0 SDKs do not specify a version :-) >>> so, they would than talk to the latest greatest, that does not work. >>> >>> We need to have that in mind, when planing this. >>> >>> >>> >>> >>> On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist >>> wrote: >>> >>>> +1 on Accept headers and also using the latest and greatest if no >>>> version is specified/ >>>> >>>> i believe this is what github also does >>>> >>>> On Aug 28, 2014, at 4:36 AM, Bruno Oliveira >>>> wrote: >>>> >>>> On 2014-08-28, Matthias Wessendorf wrote: >>>> >>>> On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc >>>> wrote: >>>> >>>> >>>> >>>> >>>> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>> If we go for the accept header and the consumer don't provide it, what >>>> >>>> do we do ? Return an error or use implicitly the latest version ? >>>> Perhaps we can return the current version to not break any existing >>>> clients. New clients will need to provide an explicit version. >>>> >>>> Why not but for how long do we return the "old" version by default ? (cf >>>> my questions around deprecation) >>>> >>>> >>>> yep - I am for that: looks like I forgot, and I think we had that on our >>>> face2face: no version == 1.0.0 (old) >>>> >>>> >>>> I vote for return the latest, instead of something old. And specify old >>>> versions if you want to. >>>> >>>> >>>> -M >>>> >>>> >>>> >>>> >>>> On 28 August 2014 09:25, Sebastien Blanc wrote: >>>> >>>> Some questions : >>>> >>>> * If we go for the accept header and the consumer don't provide it, what >>>> do we do ? Return an error or use implicitly the latest version ? >>>> * What will be our deprecation policy ? Do we want keep maintaining all >>>> the versions forever or let's say for 1.1 we still provide 1.0 and for >>>> 2.0 >>>> we drop 1.0 ? >>>> >>>> About the implementation : >>>> * I like the suggested CDI solution, if possible. >>>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno >>>> >>>> Sebi >>>> ps : I just read this blog post and it's really interesting : >>>> http://apiux.com/2013/05/14/api-versioning/ >>>> >>>> >>>> >>>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>> +1 For using the Accept header to specify the version in the media type. >>>> >>>> >>>> On 28 August 2014 07:50, Matthias Wessendorf wrote: >>>> >>>> Hello, >>>> >>>> for the 1.1.x (master) we are potentially doing some changes on the >>>> Sender-API (see [1]). >>>> >>>> However, for backwards compatibility we need to think about API >>>> versioning. >>>> >>>> For REST APIs there are (IMO) two options: >>>> * accept header >>>> * URIs >>>> >>>> On our Face2Face meeting we briefly talked about this and I think the >>>> "accept header" solution was the one that had most fans. I think QMX >>>> added >>>> that it is better for migration. One thing we were not clear on (I >>>> think): >>>> What are HATEOS defined semantics? >>>> >>>> >>>> Besides the what (headers vs. URI), I think we should think about >>>> possible implementations, to switch different versions. >>>> >>>> Not sure, but wouldn't it be possible to inject an annotated >>>> SenderService into the RESTful endpoint, based on header values ? >>>> We could have a default impl (version 1.0.0) and an alternate one, >>>> that is injected if the accept header indicate API version 1.1 >>>> >>>> Any thoughts ? >>>> >>>> -Matthias >>>> >>>> >>>> [1] >>>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> >>>> abstractj >>>> PGP: 0x84DC9914 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/d98c0d17/attachment.html From corinnekrych at gmail.com Thu Aug 28 10:24:47 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 28 Aug 2014 16:24:47 +0200 Subject: [aerogear-dev] ios swift projects with playground sample? Message-ID: Hello Swifters Since Xcode bata5 you can import framework in playground [1]. What about if we replace our sample code in README by showing a code snippet in playground on how to use the library. Here?s a PR to show it in action [2]. To be able to do it you just need to create a workspace and build the different libraries, I?ve also updated README instruction. Give it a trial and share your thoughts. ++ Corinne [1] http://ihunter.svbtle.com/how-to-import-framework-in-playground [2] https://github.com/aerogear/aerogear-ios-http/pull/5 From bruno at abstractj.org Thu Aug 28 10:26:29 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 28 Aug 2014 11:26:29 -0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> Message-ID: <20140828142629.GA61471@abstractj.org> Answers inline (this is just my personal opinion) On 2014-08-28, Matthias Wessendorf wrote: > On Thu, Aug 28, 2014 at 4:03 PM, Bruno Oliveira wrote: > > > I think this is something to fix at our SDKs, > > > like releasing 1.0.x (Server and SDKs), where the versioning is in? For our releases tagged as 1.0.0, make it clear that UPS 1.0.0 IS required, also make it clear at our docs the reasons behind it. > > That's possible. And that way, we can say, why are you using 1.0.0, we > released 1.0.1 with (some sort of) fixes For further releases of UPS server like 1.0.x, make it clear at our documentation with something like "This release requires the SDKs 1.0.x or superior" and make it clear the reasons behind it. Is not a perfect solution but....trade-offs. > > -M > > > > and think about the legacy, that's the price to pay. > > > > The easy solution is to defaults to 1.0.0, but it doesn't seem correct. > > ? > > abstractj > > PGP: 0x84DC9914 > > > > > > On Thu, Aug 28, 2014 at 10:18 AM, Matthias Wessendorf > > wrote: > > > >> the problem is... our 1.0.0 SDKs do not specify a version :-) > >> so, they would than talk to the latest greatest, that does not work. > >> > >> We need to have that in mind, when planing this. > >> > >> > >> > >> > >> On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist > >> wrote: > >> > >>> +1 on Accept headers and also using the latest and greatest if no > >>> version is specified/ > >>> > >>> i believe this is what github also does > >>> > >>> On Aug 28, 2014, at 4:36 AM, Bruno Oliveira wrote: > >>> > >>> On 2014-08-28, Matthias Wessendorf wrote: > >>> > >>> On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc > >>> wrote: > >>> > >>> > >>> > >>> > >>> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < > >>> daniel.bevenius at gmail.com> wrote: > >>> > >>> If we go for the accept header and the consumer don't provide it, what > >>> > >>> do we do ? Return an error or use implicitly the latest version ? > >>> Perhaps we can return the current version to not break any existing > >>> clients. New clients will need to provide an explicit version. > >>> > >>> Why not but for how long do we return the "old" version by default ? (cf > >>> my questions around deprecation) > >>> > >>> > >>> yep - I am for that: looks like I forgot, and I think we had that on our > >>> face2face: no version == 1.0.0 (old) > >>> > >>> > >>> I vote for return the latest, instead of something old. And specify old > >>> versions if you want to. > >>> > >>> > >>> -M > >>> > >>> > >>> > >>> > >>> On 28 August 2014 09:25, Sebastien Blanc wrote: > >>> > >>> Some questions : > >>> > >>> * If we go for the accept header and the consumer don't provide it, what > >>> do we do ? Return an error or use implicitly the latest version ? > >>> * What will be our deprecation policy ? Do we want keep maintaining all > >>> the versions forever or let's say for 1.1 we still provide 1.0 and for > >>> 2.0 > >>> we drop 1.0 ? > >>> > >>> About the implementation : > >>> * I like the suggested CDI solution, if possible. > >>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno > >>> > >>> Sebi > >>> ps : I just read this blog post and it's really interesting : > >>> http://apiux.com/2013/05/14/api-versioning/ > >>> > >>> > >>> > >>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < > >>> daniel.bevenius at gmail.com> wrote: > >>> > >>> +1 For using the Accept header to specify the version in the media type. > >>> > >>> > >>> On 28 August 2014 07:50, Matthias Wessendorf wrote: > >>> > >>> Hello, > >>> > >>> for the 1.1.x (master) we are potentially doing some changes on the > >>> Sender-API (see [1]). > >>> > >>> However, for backwards compatibility we need to think about API > >>> versioning. > >>> > >>> For REST APIs there are (IMO) two options: > >>> * accept header > >>> * URIs > >>> > >>> On our Face2Face meeting we briefly talked about this and I think the > >>> "accept header" solution was the one that had most fans. I think QMX > >>> added > >>> that it is better for migration. One thing we were not clear on (I > >>> think): > >>> What are HATEOS defined semantics? > >>> > >>> > >>> Besides the what (headers vs. URI), I think we should think about > >>> possible implementations, to switch different versions. > >>> > >>> Not sure, but wouldn't it be possible to inject an annotated > >>> SenderService into the RESTful endpoint, based on header values ? > >>> We could have a default impl (version 1.0.0) and an alternate one, > >>> that is injected if the accept header indicate API version 1.1 > >>> > >>> Any thoughts ? > >>> > >>> -Matthias > >>> > >>> > >>> [1] > >>> http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html > >>> > >>> -- > >>> Matthias Wessendorf > >>> > >>> blog: http://matthiaswessendorf.wordpress.com/ > >>> sessions: http://www.slideshare.net/mwessendorf > >>> twitter: http://twitter.com/mwessendorf > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> > >>> -- > >>> Matthias Wessendorf > >>> > >>> blog: http://matthiaswessendorf.wordpress.com/ > >>> sessions: http://www.slideshare.net/mwessendorf > >>> twitter: http://twitter.com/mwessendorf > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Thu Aug 28 10:31:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 28 Aug 2014 16:31:02 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <20140828142629.GA61471@abstractj.org> References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: On Thu, Aug 28, 2014 at 4:26 PM, Bruno Oliveira wrote: > Answers inline (this is just my personal opinion) > > On 2014-08-28, Matthias Wessendorf wrote: > > On Thu, Aug 28, 2014 at 4:03 PM, Bruno Oliveira > wrote: > > > > > I think this is something to fix at our SDKs, > > > > > > like releasing 1.0.x (Server and SDKs), where the versioning is in? > > For our releases tagged as 1.0.0, make it clear that UPS 1.0.0 IS > required, also make it clear at our docs the reasons behind it. > > > > > That's possible. And that way, we can say, why are you using 1.0.0, we > > released 1.0.1 with (some sort of) fixes > > For further releases of UPS server like 1.0.x, make it clear at our > documentation with something like "This release requires the SDKs 1.0.x > or superior" and make it clear the reasons behind it. > yeah, that's reasonable - I think However not sure that flies :-) -M > > Is not a perfect solution but....trade-offs. > > > > -M > > > > > > > and think about the legacy, that's the price to pay. > > > > > > The easy solution is to defaults to 1.0.0, but it doesn't seem correct. > > > ? > > > abstractj > > > PGP: 0x84DC9914 > > > > > > > > > On Thu, Aug 28, 2014 at 10:18 AM, Matthias Wessendorf < > matzew at apache.org> > > > wrote: > > > > > >> the problem is... our 1.0.0 SDKs do not specify a version :-) > > >> so, they would than talk to the latest greatest, that does not work. > > >> > > >> We need to have that in mind, when planing this. > > >> > > >> > > >> > > >> > > >> On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist > > > >> wrote: > > >> > > >>> +1 on Accept headers and also using the latest and greatest if no > > >>> version is specified/ > > >>> > > >>> i believe this is what github also does > > >>> > > >>> On Aug 28, 2014, at 4:36 AM, Bruno Oliveira > wrote: > > >>> > > >>> On 2014-08-28, Matthias Wessendorf wrote: > > >>> > > >>> On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc < > scm.blanc at gmail.com> > > >>> wrote: > > >>> > > >>> > > >>> > > >>> > > >>> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < > > >>> daniel.bevenius at gmail.com> wrote: > > >>> > > >>> If we go for the accept header and the consumer don't provide it, > what > > >>> > > >>> do we do ? Return an error or use implicitly the latest version ? > > >>> Perhaps we can return the current version to not break any existing > > >>> clients. New clients will need to provide an explicit version. > > >>> > > >>> Why not but for how long do we return the "old" version by default ? > (cf > > >>> my questions around deprecation) > > >>> > > >>> > > >>> yep - I am for that: looks like I forgot, and I think we had that on > our > > >>> face2face: no version == 1.0.0 (old) > > >>> > > >>> > > >>> I vote for return the latest, instead of something old. And specify > old > > >>> versions if you want to. > > >>> > > >>> > > >>> -M > > >>> > > >>> > > >>> > > >>> > > >>> On 28 August 2014 09:25, Sebastien Blanc > wrote: > > >>> > > >>> Some questions : > > >>> > > >>> * If we go for the accept header and the consumer don't provide it, > what > > >>> do we do ? Return an error or use implicitly the latest version ? > > >>> * What will be our deprecation policy ? Do we want keep maintaining > all > > >>> the versions forever or let's say for 1.1 we still provide 1.0 and > for > > >>> 2.0 > > >>> we drop 1.0 ? > > >>> > > >>> About the implementation : > > >>> * I like the suggested CDI solution, if possible. > > >>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno > > >>> > > >>> Sebi > > >>> ps : I just read this blog post and it's really interesting : > > >>> http://apiux.com/2013/05/14/api-versioning/ > > >>> > > >>> > > >>> > > >>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < > > >>> daniel.bevenius at gmail.com> wrote: > > >>> > > >>> +1 For using the Accept header to specify the version in the media > type. > > >>> > > >>> > > >>> On 28 August 2014 07:50, Matthias Wessendorf > wrote: > > >>> > > >>> Hello, > > >>> > > >>> for the 1.1.x (master) we are potentially doing some changes on the > > >>> Sender-API (see [1]). > > >>> > > >>> However, for backwards compatibility we need to think about API > > >>> versioning. > > >>> > > >>> For REST APIs there are (IMO) two options: > > >>> * accept header > > >>> * URIs > > >>> > > >>> On our Face2Face meeting we briefly talked about this and I think the > > >>> "accept header" solution was the one that had most fans. I think QMX > > >>> added > > >>> that it is better for migration. One thing we were not clear on (I > > >>> think): > > >>> What are HATEOS defined semantics? > > >>> > > >>> > > >>> Besides the what (headers vs. URI), I think we should think about > > >>> possible implementations, to switch different versions. > > >>> > > >>> Not sure, but wouldn't it be possible to inject an annotated > > >>> SenderService into the RESTful endpoint, based on header values ? > > >>> We could have a default impl (version 1.0.0) and an alternate one, > > >>> that is injected if the accept header indicate API version 1.1 > > >>> > > >>> Any thoughts ? > > >>> > > >>> -Matthias > > >>> > > >>> > > >>> [1] > > >>> > http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html > > >>> > > >>> -- > > >>> Matthias Wessendorf > > >>> > > >>> blog: http://matthiaswessendorf.wordpress.com/ > > >>> sessions: http://www.slideshare.net/mwessendorf > > >>> twitter: http://twitter.com/mwessendorf > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Matthias Wessendorf > > >>> > > >>> blog: http://matthiaswessendorf.wordpress.com/ > > >>> sessions: http://www.slideshare.net/mwessendorf > > >>> twitter: http://twitter.com/mwessendorf > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> -- > > >>> > > >>> abstractj > > >>> PGP: 0x84DC9914 > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >> > > >> > > >> > > >> -- > > >> Matthias Wessendorf > > >> > > >> blog: http://matthiaswessendorf.wordpress.com/ > > >> sessions: http://www.slideshare.net/mwessendorf > > >> twitter: http://twitter.com/mwessendorf > > >> > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/a9712d98/attachment.html From scm.blanc at gmail.com Thu Aug 28 10:46:04 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 28 Aug 2014 16:46:04 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <20140828142629.GA61471@abstractj.org> References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: On Thu, Aug 28, 2014 at 4:26 PM, Bruno Oliveira wrote: > Answers inline (this is just my personal opinion) > > On 2014-08-28, Matthias Wessendorf wrote: > > On Thu, Aug 28, 2014 at 4:03 PM, Bruno Oliveira > wrote: > > > > > I think this is something to fix at our SDKs, > > > > > > like releasing 1.0.x (Server and SDKs), where the versioning is in? > > For our releases tagged as 1.0.0, make it clear that UPS 1.0.0 IS > required, also make it clear at our docs the reasons behind it. > > > > > That's possible. And that way, we can say, why are you using 1.0.0, we > > released 1.0.1 with (some sort of) fixes > > For further releases of UPS server like 1.0.x, make it clear at our > documentation with something like "This release requires the SDKs 1.0.x > or superior" and make it clear the reasons behind it. > > Is not a perfect solution but....trade-offs. > I would also prefer this approach > > > > -M > > > > > > > and think about the legacy, that's the price to pay. > > > > > > The easy solution is to defaults to 1.0.0, but it doesn't seem correct. > > > ? > > > abstractj > > > PGP: 0x84DC9914 > > > > > > > > > On Thu, Aug 28, 2014 at 10:18 AM, Matthias Wessendorf < > matzew at apache.org> > > > wrote: > > > > > >> the problem is... our 1.0.0 SDKs do not specify a version :-) > > >> so, they would than talk to the latest greatest, that does not work. > > >> > > >> We need to have that in mind, when planing this. > > >> > > >> > > >> > > >> > > >> On Thu, Aug 28, 2014 at 2:39 PM, Lucas Holmquist > > > >> wrote: > > >> > > >>> +1 on Accept headers and also using the latest and greatest if no > > >>> version is specified/ > > >>> > > >>> i believe this is what github also does > > >>> > > >>> On Aug 28, 2014, at 4:36 AM, Bruno Oliveira > wrote: > > >>> > > >>> On 2014-08-28, Matthias Wessendorf wrote: > > >>> > > >>> On Thu, Aug 28, 2014 at 10:14 AM, Sebastien Blanc < > scm.blanc at gmail.com> > > >>> wrote: > > >>> > > >>> > > >>> > > >>> > > >>> On Thu, Aug 28, 2014 at 9:29 AM, Daniel Bevenius < > > >>> daniel.bevenius at gmail.com> wrote: > > >>> > > >>> If we go for the accept header and the consumer don't provide it, > what > > >>> > > >>> do we do ? Return an error or use implicitly the latest version ? > > >>> Perhaps we can return the current version to not break any existing > > >>> clients. New clients will need to provide an explicit version. > > >>> > > >>> Why not but for how long do we return the "old" version by default ? > (cf > > >>> my questions around deprecation) > > >>> > > >>> > > >>> yep - I am for that: looks like I forgot, and I think we had that on > our > > >>> face2face: no version == 1.0.0 (old) > > >>> > > >>> > > >>> I vote for return the latest, instead of something old. And specify > old > > >>> versions if you want to. > > >>> > > >>> > > >>> -M > > >>> > > >>> > > >>> > > >>> > > >>> On 28 August 2014 09:25, Sebastien Blanc > wrote: > > >>> > > >>> Some questions : > > >>> > > >>> * If we go for the accept header and the consumer don't provide it, > what > > >>> do we do ? Return an error or use implicitly the latest version ? > > >>> * What will be our deprecation policy ? Do we want keep maintaining > all > > >>> the versions forever or let's say for 1.1 we still provide 1.0 and > for > > >>> 2.0 > > >>> we drop 1.0 ? > > >>> > > >>> About the implementation : > > >>> * I like the suggested CDI solution, if possible. > > >>> * Erik also mentionned OSGI and I'm -9999^99 to introduce that techno > > >>> > > >>> Sebi > > >>> ps : I just read this blog post and it's really interesting : > > >>> http://apiux.com/2013/05/14/api-versioning/ > > >>> > > >>> > > >>> > > >>> On Thu, Aug 28, 2014 at 8:07 AM, Daniel Bevenius < > > >>> daniel.bevenius at gmail.com> wrote: > > >>> > > >>> +1 For using the Accept header to specify the version in the media > type. > > >>> > > >>> > > >>> On 28 August 2014 07:50, Matthias Wessendorf > wrote: > > >>> > > >>> Hello, > > >>> > > >>> for the 1.1.x (master) we are potentially doing some changes on the > > >>> Sender-API (see [1]). > > >>> > > >>> However, for backwards compatibility we need to think about API > > >>> versioning. > > >>> > > >>> For REST APIs there are (IMO) two options: > > >>> * accept header > > >>> * URIs > > >>> > > >>> On our Face2Face meeting we briefly talked about this and I think the > > >>> "accept header" solution was the one that had most fans. I think QMX > > >>> added > > >>> that it is better for migration. One thing we were not clear on (I > > >>> think): > > >>> What are HATEOS defined semantics? > > >>> > > >>> > > >>> Besides the what (headers vs. URI), I think we should think about > > >>> possible implementations, to switch different versions. > > >>> > > >>> Not sure, but wouldn't it be possible to inject an annotated > > >>> SenderService into the RESTful endpoint, based on header values ? > > >>> We could have a default impl (version 1.0.0) and an alternate one, > > >>> that is injected if the accept header indicate API version 1.1 > > >>> > > >>> Any thoughts ? > > >>> > > >>> -Matthias > > >>> > > >>> > > >>> [1] > > >>> > http://lists.jboss.org/pipermail/aerogear-dev/2014-August/008881.html > > >>> > > >>> -- > > >>> Matthias Wessendorf > > >>> > > >>> blog: http://matthiaswessendorf.wordpress.com/ > > >>> sessions: http://www.slideshare.net/mwessendorf > > >>> twitter: http://twitter.com/mwessendorf > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Matthias Wessendorf > > >>> > > >>> blog: http://matthiaswessendorf.wordpress.com/ > > >>> sessions: http://www.slideshare.net/mwessendorf > > >>> twitter: http://twitter.com/mwessendorf > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> -- > > >>> > > >>> abstractj > > >>> PGP: 0x84DC9914 > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >> > > >> > > >> > > >> -- > > >> Matthias Wessendorf > > >> > > >> blog: http://matthiaswessendorf.wordpress.com/ > > >> sessions: http://www.slideshare.net/mwessendorf > > >> twitter: http://twitter.com/mwessendorf > > >> > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/7f21fa84/attachment-0001.html From daniel.bevenius at gmail.com Thu Aug 28 10:50:06 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 28 Aug 2014 16:50:06 +0200 Subject: [aerogear-dev] ios swift projects with playground sample? In-Reply-To: References: Message-ID: +1 I like this On 28 August 2014 16:24, Corinne Krych wrote: > Hello Swifters > > Since Xcode bata5 you can import framework in playground [1]. > What about if we replace our sample code in README by showing a code > snippet in playground on how to use the library. Here?s a PR to show it in > action [2]. > > To be able to do it you just need to create a workspace and build the > different libraries, I?ve also updated README instruction. Give it a trial > and share your thoughts. > > ++ > Corinne > [1] http://ihunter.svbtle.com/how-to-import-framework-in-playground > [2] https://github.com/aerogear/aerogear-ios-http/pull/5 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/5265671e/attachment.html From lholmqui at redhat.com Thu Aug 28 10:54:54 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 28 Aug 2014 10:54:54 -0400 Subject: [aerogear-dev] ios swift projects with playground sample? In-Reply-To: References: Message-ID: <5AAFCF10-E8F0-4143-BF70-39109CFC2A12@redhat.com> +1, yea this looks nice will be nice to see that sample code actually works!! On Aug 28, 2014, at 10:50 AM, Daniel Bevenius wrote: > +1 I like this > > > On 28 August 2014 16:24, Corinne Krych wrote: > Hello Swifters > > Since Xcode bata5 you can import framework in playground [1]. > What about if we replace our sample code in README by showing a code snippet in playground on how to use the library. Here?s a PR to show it in action [2]. > > To be able to do it you just need to create a workspace and build the different libraries, I?ve also updated README instruction. Give it a trial and share your thoughts. > > ++ > Corinne > [1] http://ihunter.svbtle.com/how-to-import-framework-in-playground > [2] https://github.com/aerogear/aerogear-ios-http/pull/5 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140828/76557c04/attachment.html From edewit at redhat.com Fri Aug 29 02:23:30 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 29 Aug 2014 08:23:30 +0200 Subject: [aerogear-dev] ios swift projects with playground sample? In-Reply-To: References: Message-ID: <361AA524-2F70-4548-9DA3-DD928627A3F1@redhat.com> +1 documentation is great working code is better! From matzew at apache.org Fri Aug 29 03:58:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 29 Aug 2014 09:58:51 +0200 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> Message-ID: Hi Vivek, FYI: https://github.com/aerogear/aerogear-unifiedpush-server/pull/369 once this above PR is merged, you should be able to import all devices with one request, using a JSON file -Matthias On Fri, Jul 18, 2014 at 3:41 PM, Matthias Wessendorf wrote: > > > > On Wed, Jul 2, 2014 at 4:40 PM, Vivek Pandey > wrote: > >> Hello Matthias, >> >> >> >> An ?importer? might help, but smaller changes in existing domain/service >> might help more. >> >> I ran a stress test on the installation endpoint yesterday, after merging >> Eric?s changes on source code of 0.10.x branch. >> >> I saw that even after using the merged code, the response worsened >> continuously. >> >> Looking closing, I saw that GenericVariantServiceImpl. addInstallation >> causes initialization of the now ?lazy? collection >> AbstractVariant.installations. >> >> >> >> I changed the model a bit, by adding variantID to Installation, and made >> it the owner of the variant-installation relationship. >> >> That changed the code in InstallationRegistrationEndpoint. registerInstallation >> from >> >> // store the installation: >> >> entity = clientInstallationService.addInstallation(entity); >> >> // add installation to the matching variant >> >> genericVariantService.addInstallation(variant, entity); >> >> >> >> to >> >> // store the installation: >> >> >> entity.setVariantID(variant); >> >> entity = >> clientInstallationService.addInstallation(entity); >> >> >> >> This fixed the problem for me and now I am getting constant time >> installation registration with dramatically better performance >> > > Hey Vivek!, > > as a FYI - I ran some perf. tests as well, and noticed a huge improvement > on the regitration as well, after Erik included (parts of) your patch > > >> >> >> Please let me know if you want me to add this to AGPUSH-661 >> >> >> >> Thanks >> >> Vivek >> >> >> >> *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] *On Behalf >> Of *Matthias Wessendorf >> *Sent:* Wednesday, July 02, 2014 6:26 PM >> *To:* AeroGear Developer Mailing List; vivek.pandey at pinelabs.com >> >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> >> >> Hello Vivek, >> >> >> >> On Mon, May 26, 2014 at 1:23 PM, Matthias Wessendorf >> wrote: >> >> >> >> >> >> On Mon, May 26, 2014 at 12:59 PM, Erik Jan de Wit >> wrote: >> >> Hi Vivek, >> >> >> >> We?ve fixed that >> https://github.com/aerogear/aerogear-unifiedpush-server/commit/1357c9e834286a9227a90e9ab618226aa54bbbf3 the >> collection is now lazy. But I?m sure other query optimisations can be made. >> >> >> >> +1 >> >> >> >> btw. Vivek, I added your mail to an existing ticket: >> >> https://issues.jboss.org/browse/AGPUSH-661 >> >> >> >> >> >> coming back from vacation and going over the JIRAs, I was wondering if an >> 'importer' helps? >> >> >> >> That would be a RESTful endpoint that accepts a JSON file, containing all >> the devices you want to register (for a given variant). >> >> >> >> That way it would be also a bit nicer on your side, to perform the import: >> >> * generate a "large" JSON file (instead of a ton of requests) >> >> * only one HTTP request >> >> * server accepts and will process it in the background >> >> >> >> I think that would be a nice migration tool. >> >> >> >> Let me know what you think! >> >> >> >> -Matthias >> >> >> >> >> >> -Matthias >> >> >> >> >> >> Cheers, >> >> Erik Jan >> >> >> >> On 26 May,2014, at 12:27 , Vivek Pandey >> wrote: >> >> >> >> Hi Matthias, >> >> >> >> It is good to know that activity in java-apns is picking up and also that >> you are looking at pushy. >> >> >> >> I did a few tests which added installations to UPS with a concurrency of >> 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war >> >> >> >> I noticed that response slowed down considerably after some time with >> high CPU usage and continued to get worse. After doing some profiling, I >> found that bulk of CPU cycles are being taken by >> org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread >> stack is attached. Also postgres continuously flagged >> >> >> >> select installati0_.variantID as variant10_0_0_, installati0_.id as >> id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, >> installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as >> deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, >> installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as >> osVersio7_3_1_, installati0_.platform as platform8_3_1_, >> installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl >> installati0_ where installati0_.variantID=$1 >> >> >> >> as the slow query. I am pretty sure that eager collection >> AbstractVariant.installations is the root cause of the problem. >> >> >> >> Please let me know if you need any more information. >> >> >> >> Thanks >> >> Vivek >> >> >> >> *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com >> ] *On Behalf Of *Matthias Wessendorf >> *Sent:* Wednesday, May 21, 2014 5:55 PM >> *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> >> >> Hello Vivek! >> >> >> >> On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey >> wrote: >> >> Hi Jay, >> >> >> >> Thanks for your reply. >> >> >> >> While we have not faced any issues in using UPS in our limited testing, I >> often see info stacktraces in ups logs >> >> >> >> 2014-05-16 10:19:20,032 INFO >> [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while >> waiting for error code: java.net.SocketException: Socket closed >> >> at java.net.SocketInputStream.socketRead0(Native Method) >> [rt.jar:1.7.0_51] >> >> at java.net.SocketInputStream.read(SocketInputStream.java:152) >> [rt.jar:1.7.0_51] >> >> at java.net.SocketInputStream.read(SocketInputStream.java:122) >> [rt.jar:1.7.0_51] >> >> ????? >> >> at >> com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) >> [apns-0.2.3.jar:] >> >> >> >> >> >> These stacktraces coupled with low dev activity of noop/java-apns project >> are disconcerting to me. >> >> >> >> the stack-trace is no harm - it's only happening w/ doing a monitoring of >> the thread (that's what we currently do, when setting up ApnsService - I >> thought about explicitly disable that) >> >> >> >> The activity of the underlying java-apns is very low, yes! However >> @froh42 is getting back: >> >> https://github.com/notnoop/java-apns/commits/master >> >> >> >> There will be a new release in the near future; @froh42 asked me if I >> could help with pushing the bits to maven central >> >> >> >> >> >> That said, I recently started looking at pushy: >> >> https://github.com/relayrides/pushy >> >> >> >> I also sent a PR that would allow us to feed pushy w/ our certificate >> from the database: >> >> https://github.com/relayrides/pushy/pull/87 >> >> >> >> Hope that helps >> >> -Matthias >> >> >> >> >> >> I am currently using UPS 0.10.2 war. >> >> >> >> Thanks, >> >> Vivek >> >> *From:* Jay Balunas [mailto:jbalunas at redhat.com] >> *Sent:* Tuesday, May 20, 2014 11:36 PM >> *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List >> *Cc:* Jay Balunas >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> >> >> Hi Vivek, >> >> >> >> It's awesome to hear that you have integrated the UPS into your backend >> systems and some of your mobile apps! >> >> >> >> We have a lot of confidence around the UPS, its functionality, and >> performance. Our team has been working hard on improvements and stability >> including our QE team. Also, as you may have seen we're planning a 1.0 >> release of the UPS this summer. >> >> >> >> However at this time we don't have specific references or success stories >> outside of what you can see in the community mailing lists - other users >> using it ;-) We're also about to kick off some performance and scale >> testing in the next couple of months. >> >> >> >> Have you run into any issues that drove these questions about production >> worthiness? If so please let us know and we'll certainly take a look. >> >> >> >> Hope this helps! >> >> >> >> Thanks, >> >> Jay Balunas >> >> >> >> On May 20, 2014, at 8:09 AM, Vivek Pandey >> wrote: >> >> >> >> Hello Aerogear dev team, >> >> >> >> We integrated UPS into our backend server which is serving various mobile >> apps. While the development and testing phase went well, my manager is >> questioning me about production worthiness about Aerogear. It would be >> great help if you could point me to references/success stories where UPS is >> being used in production environments and scaling well in medium to high >> loads. >> >> >> >> Thanks, >> >> Vivek >> >> >> >> >> >> >> ------------------------------ >> >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> ------------------------------ >> >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> ------------------------------ >> >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> >> _______________________________________________ >> >> >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> ------------------------------ >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/ad47513d/attachment-0001.html From matzew at apache.org Fri Aug 29 04:01:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 29 Aug 2014 10:01:25 +0200 Subject: [aerogear-dev] GCM limit with 1000 registrationIDs In-Reply-To: <1400679220199-7887.post@n5.nabble.com> References: <1400672454662-7879.post@n5.nabble.com> <1400679220199-7887.post@n5.nabble.com> Message-ID: Hi Antoine, FYI: https://github.com/aerogear/aerogear-unifiedpush-server/pull/369 once this above PR is merged, you should be able to import all devices with one request, using a JSON file -Matthias On Wed, May 21, 2014 at 3:33 PM, A577127 wrote: > Uh wrong translation I mean register tokens. We wrote a java sender that > registers lots of token (we wanted to register 1M tokens) with the REST api > http://aerogear.org/docs/specs/aerogear-push-rest/DeviceRegistration/ > > But it was very slow (~1/s), looks like the database slows the thing by > making big requests (huge joins ?). > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-GCM-limit-with-1000-registrationIDs-tp7858p7887.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/5fee235a/attachment.html From matzew at apache.org Fri Aug 29 04:06:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 29 Aug 2014 10:06:56 +0200 Subject: [aerogear-dev] UPS -> Windows 8 push notifications thoughts In-Reply-To: <1399290966123-7646.post@n5.nabble.com> References: <1399290966123-7646.post@n5.nabble.com> Message-ID: Hi Antoine, we added Windows to our roadmap for 1.1.x: https://issues.jboss.org/browse/AGPUSH-821 -Matthias On Mon, May 5, 2014 at 1:56 PM, A577127 wrote: > Hello, > > I'm looking for information about your future plans for implementing > Windows > 8 push notifications on the unified push server (if you've already thought > about it). I looked for topics on the mailing list but didn't find my > answers so I create this topic. > > Since Windows 8 uses XML data format, what are you plans to implement it on > the UPS in the future ? Current supported platforms all use JSON, allowing > to send a notification to everyone from one command. Either you'll lose > this > capability, either you'll have to "convert" JSON to XML, which is > problematic since Windows 8 has dozens of XML schemas (and some aren't > really compatible with Apple's one for example). > > Thanks, > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/UPS-Windows-8-push-notifications-thoughts-tp7646.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/20feef3d/attachment.html From tolisemm at gmail.com Fri Aug 29 04:30:12 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Fri, 29 Aug 2014 11:30:12 +0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: 2014-08-28 8:50 GMT+03:00 Matthias Wessendorf > > > On our Face2Face meeting we briefly talked about this and I think the > "accept header" solution was the one that had most fans. I think QMX added > that it is better for migration. One thing we were not clear on (I think): > What are HATEOS defined semantics? > What exactly do you mean by "HATEOAS defined semantics"; Is it in the roadmap to use a HATEOAS implementation (maybe Hal) or Json hyper schema in UPS rest? Thanks, Tolis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/f353c777/attachment.html From matzew at apache.org Fri Aug 29 04:39:00 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 29 Aug 2014 10:39:00 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: On Fri, Aug 29, 2014 at 10:30 AM, tolis emmanouilidis wrote: > 2014-08-28 8:50 GMT+03:00 Matthias Wessendorf > >> >> On our Face2Face meeting we briefly talked about this and I think the >> "accept header" solution was the one that had most fans. I think QMX added >> that it is better for migration. One thing we were not clear on (I think): >> What are HATEOS defined semantics? >> > > What exactly do you mean by "HATEOAS defined semantics"; Is it in the > roadmap to use a HATEOAS implementation (maybe Hal) or Json hyper schema in > UPS rest? > not sure, someone added that to the meeting notes :) > > Thanks, > Tolis > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/d574ed5b/attachment.html From edewit at redhat.com Fri Aug 29 04:43:51 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 29 Aug 2014 10:43:51 +0200 Subject: [aerogear-dev] UPS -> Windows 8 push notifications thoughts In-Reply-To: <1399290966123-7646.post@n5.nabble.com> References: <1399290966123-7646.post@n5.nabble.com> Message-ID: <16341108-359A-4833-B2FC-552E85899C6F@redhat.com> > Since Windows 8 uses XML data format, what are you plans to implement it on > the UPS in the future ? Current supported platforms all use JSON, allowing > to send a notification to everyone from one command. Either you'll lose this > capability, either you'll have to "convert" JSON to XML, which is > problematic since Windows 8 has dozens of XML schemas (and some aren't > really compatible with Apple's one for example). We are planning on converting json to xml and to be able to have still one message for all devices we try to at least have the main message the same and then add the other things that are windows specific, have a look at this gist: https://gist.github.com/edewit/305d76c31960aa6254a9 This is still a work in progress though. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/f232f203/attachment.html From tolisemm at gmail.com Fri Aug 29 04:51:03 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Fri, 29 Aug 2014 11:51:03 +0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: 2014-08-29 11:39 GMT+03:00 Matthias Wessendorf : > > > not sure, someone added that to the meeting notes :) > > ah, ok :) Just an idea, it would be nice to comply with the HATEOAS constraint or to create some kind of Json schema UPS. At least, in its simplest form you could just include the available UPS rest urls when someone creates a GET request to the main UPS url (e.g ../ag-push/rest). For example when I create a GET request to the GitHub API main url (https://api.github.com/) I receive the below Json and I'm able to create a dynamic REST client which reads the URLs from Json without any need to hardcode them in my app. It is also useful from a documentation perspective, since there is not need to read the APi docs. { "current_user_url": "https://api.github.com/user", "authorizations_url": "https://api.github.com/authorizations", "code_search_url": "https://api.github.com/search/code?q={query}{&page,per_page,sort,order}", "emails_url": "https://api.github.com/user/emails", "emojis_url": "https://api.github.com/emojis", "events_url": "https://api.github.com/events", "feeds_url": "https://api.github.com/feeds", "following_url": "https://api.github.com/user/following{/target}", "gists_url": "https://api.github.com/gists{/gist_id}", "hub_url": "https://api.github.com/hub", "issue_search_url": "https://api.github.com/search/issues?q={query}{&page,per_page,sort,order}", "issues_url": "https://api.github.com/issues", "keys_url": "https://api.github.com/user/keys", "notifications_url": "https://api.github.com/notifications", "organization_repositories_url": "https://api.github.com/orgs/{org}/repos{?type,page,per_page,sort}", "organization_url": "https://api.github.com/orgs/{org}", "public_gists_url": "https://api.github.com/gists/public", "rate_limit_url": "https://api.github.com/rate_limit", "repository_url": "https://api.github.com/repos/{owner}/{repo}", "repository_search_url": "https://api.github.com/search/repositories?q={query}{&page,per_page,sort,order}", "current_user_repositories_url": "https://api.github.com/user/repos{?type,page,per_page,sort}", "starred_url": "https://api.github.com/user/starred{/owner}{/repo}", "starred_gists_url": "https://api.github.com/gists/starred", "team_url": "https://api.github.com/teams", "user_url": "https://api.github.com/users/{user}", "user_organizations_url": "https://api.github.com/user/orgs", "user_repositories_url": "https://api.github.com/users/{user}/repos{?type,page,per_page,sort}", "user_search_url": "https://api.github.com/search/users?q={query}{&page,per_page,sort,order}" } -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/3723e7fe/attachment-0001.html From matzew at apache.org Fri Aug 29 05:30:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 29 Aug 2014 11:30:38 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: <20140731100539.GA24892@abstractj.org> References: <20140731100539.GA24892@abstractj.org> Message-ID: On Thu, Jul 31, 2014 at 12:05 PM, Bruno Oliveira wrote: > Do we have a roadmap and the release date for 0.7.0? The roadmap[1] is > not totally clear to me. > here we go: https://github.com/aerogear/aerogear.org/pull/382 -M > > > [1] - > http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ > > On 2014-07-29, Matthias Wessendorf wrote: > > Hi, > > > > looked at the change log of the Cordova Plugin and there were some fixes > > since the last 0.6.0 release. > > > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on > > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > > > Any thoughts? > > > > Thanks, > > Matthias > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/116bab4a/attachment.html From edewit at redhat.com Fri Aug 29 07:29:38 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 29 Aug 2014 13:29:38 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: Hi, Thinking a bit more about this (read trying out some stuff). The way we want to change the API is right now is ?just? the message format, how about we take a servlet filter that changes the json from the old version to the new? There is a lib [1] that takes a json and transforms it into another json. Other option is to have 2 jax-rs classes, but to make that work they will have to have 2 different paths. So you would have to ?redirect? / change the path in the servlet filter based on the accept header. Which feels like kinda of a hack to me. So WDYT any other suggestions? Cheers, Erik Jan [1] https://github.com/bazaarvoice/jolt -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/f1b50197/attachment.html From matzew at apache.org Fri Aug 29 07:47:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 29 Aug 2014 13:47:51 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: On Fri, Aug 29, 2014 at 1:29 PM, Erik Jan de Wit wrote: > Hi, > > Thinking a bit more about this (read trying out some stuff). The way we > want to change the API is right now is ?just? the message format, how about > we take a servlet filter that changes the json from the old version to the > new? > > There is a lib [1] that takes a json and transforms it into another json. > that sounds good to me > > Other option is to have 2 jax-rs classes, but to make that work they will > have to have 2 different paths. So you would have to ?redirect? / change > the path in the servlet filter based on the accept header. Which feels like > kinda of a hack to me. > While I like the above suggestion regarding the message format, couldn't we be still on the same path, and use some 'advanced' CDI injection mechanismn to inject a Version110SenderServiceImpl (or Version100ServiceImpl) ? Just curious > > So WDYT any other suggestions? > > Cheers, > Erik Jan > > [1] https://github.com/bazaarvoice/jolt > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/da14480a/attachment.html From scm.blanc at gmail.com Fri Aug 29 07:50:08 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 29 Aug 2014 13:50:08 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: On Fri, Aug 29, 2014 at 1:47 PM, Matthias Wessendorf wrote: > > > > On Fri, Aug 29, 2014 at 1:29 PM, Erik Jan de Wit > wrote: > >> Hi, >> >> Thinking a bit more about this (read trying out some stuff). The way we >> want to change the API is right now is ?just? the message format, how about >> we take a servlet filter that changes the json from the old version to the >> new? >> >> There is a lib [1] that takes a json and transforms it into another json. >> > > that sounds good to me > > >> >> Other option is to have 2 jax-rs classes, but to make that work they will >> have to have 2 different paths. So you would have to ?redirect? / change >> the path in the servlet filter based on the accept header. Which feels like >> kinda of a hack to me. >> > > While I like the above suggestion regarding the message format, couldn't > we be still on the same path, and use some 'advanced' CDI injection > mechanismn to inject a Version110SenderServiceImpl (or > Version100ServiceImpl) ? Just curious > I would prefer a servlet filter to handle that and keep just keep one SenderServiceImpl, seems less messy to me but just my 2 cents > > >> >> So WDYT any other suggestions? >> >> Cheers, >> Erik Jan >> >> [1] https://github.com/bazaarvoice/jolt >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/4a96935c/attachment.html From edewit at redhat.com Fri Aug 29 08:09:19 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 29 Aug 2014 14:09:19 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: > > > Other option is to have 2 jax-rs classes, but to make that work they will have to have 2 different paths. So you would have to ?redirect? / change the path in the servlet filter based on the accept header. Which feels like kinda of a hack to me. > > While I like the above suggestion regarding the message format, couldn't we be still on the same path, and use some 'advanced' CDI injection mechanismn to inject a Version110SenderServiceImpl (or Version100ServiceImpl) ? Just curious Right with CDI qualifiers you could select a specific version of the same implementation see SenderServiceImpl for an example of this it has all the PushNotificationSenders and selects them based on the variantType. And because the json in this particular Endpoint is serialised into a Map we don?t even have to have 2 different versions of the SenderServiceImpl or have CDI qualifiers we ?just? need to have a Strategy based on version that converts the Map into a Message object. I must say this is probably the most simple solution to this specific API change so I?m +1 on this one. WDYT -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/3be25808/attachment-0001.html From tolisemm at gmail.com Fri Aug 29 08:33:12 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Fri, 29 Aug 2014 15:33:12 +0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: 2014-08-29 15:09 GMT+03:00 Erik Jan de Wit : > > > >> >> Other option is to have 2 jax-rs classes, but to make that work they will >> have to have 2 different paths. So you would have to ?redirect? / change >> the path in the servlet filter based on the accept header. Which feels like >> kinda of a hack to me. >> > > While I like the above suggestion regarding the message format, couldn't > we be still on the same path, and use some 'advanced' CDI injection > mechanismn to inject a Version110SenderServiceImpl (or > Version100ServiceImpl) ? Just curious > > > Right with CDI qualifiers you could select a specific version of the same > implementation see SenderServiceImpl for an example of this it has all the > PushNotificationSenders and selects them based on the variantType. > > And because the json in this particular Endpoint is serialised into a > Map we don?t even have to have 2 different versions of the > SenderServiceImpl or have CDI qualifiers we ?just? need to have a Strategy > based on version that converts the Map into a Message object. > > I must say this is probably the most simple solution to this specific API > change so I?m +1 on this one. > > WDYT > Another option that might work out of the box would be to use the jax-rs @Consumes annotation e.g @Consumes({"application/vnd.aerogear.v101+json"}) on the service endpoints. So by making an abstract PushNotificationSenderEndpoint and and several PushNotificationSenderEndpointV101, PushNotificationSenderEndpointV102 with the right @Consumes annotation should work. I haven't tried it though > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/3adb7c9b/attachment.html From matzew at apache.org Fri Aug 29 08:45:32 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 29 Aug 2014 14:45:32 +0200 Subject: [aerogear-dev] Branches on UnifiedPush GH repo Message-ID: Hi, now that we have released the 1.0.0.Final, there are two 'important' branches: * master (current version is 1.1.0-SNAPSHOT) * 1.0.x (current version is 1.0.1-SNAPSHOT) This email is to clarify what goes in where, or tries to :-) I think it's quite simple. Every fix that goes into the "1.0.x branch" needs to go into the "master branch" as well. Once a PR has been merged to 1.0.x branch, it's the responsibility of the PR filer to rebase against (latest) master as well, to make sure the merge to master works without any trouble! While 1.0.x is really meant for bug fixes and improvements only, the new development is going on in master (for 1.1.0-SNAPSHOT, and later) and therefore fixes that are scheduled for 1.1.x only, should not go into the the 1.0.x branch. The scheudling is done via JIRA and almost all commits/merges should have JIRA tickets attached. Currently here are the 1.0.x related tickets: https://issues.jboss.org/browse/AGPUSH/fixforversion/12325080/ https://issues.jboss.org/browse/AGPUSH/fixforversion/12325448 As you can see, they all have the 1.1.x version label as well. This is important and ensures (critical) bug fixes to 1.0.x are also arriving on the master branch! The JIRAs that are scheduled for 1.1.0 are listed here: https://issues.jboss.org/browse/AGPUSH/fixforversion/12323762/ Of course, due to the backport requirement, some of these tickets contain 1.0.x labels on their Fix-Versions as well - but some are exclusively scheduled for 1.1.0, and therefore only go to master branch. Any thoughts ? -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/8beaecb4/attachment.html From qmx at qmx.me Fri Aug 29 08:47:15 2014 From: qmx at qmx.me (Douglas Campos) Date: Fri, 29 Aug 2014 09:47:15 -0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <20140828142629.GA61471@abstractj.org> References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: <20140829124715.GZ97717@darkstar.local> On Thu, Aug 28, 2014 at 11:26:29AM -0300, Bruno Oliveira wrote: > For further releases of UPS server like 1.0.x, make it clear at our > documentation with something like "This release requires the SDKs 1.0.x > or superior" and make it clear the reasons behind it. > > Is not a perfect solution but....trade-offs. +1 to this trade-off - seems reasonable -- qmx From qmx at qmx.me Fri Aug 29 08:47:53 2014 From: qmx at qmx.me (Douglas Campos) Date: Fri, 29 Aug 2014 09:47:53 -0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: Message-ID: <20140829124753.GA97717@darkstar.local> That's exactly what I meant when I said HATEOAS on the f2f ;) -- qmx From lholmqui at redhat.com Fri Aug 29 09:28:55 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 29 Aug 2014 09:28:55 -0400 Subject: [aerogear-dev] Branches on UnifiedPush GH repo In-Reply-To: References: Message-ID: good summary! On Aug 29, 2014, at 8:45 AM, Matthias Wessendorf wrote: > Hi, > > now that we have released the 1.0.0.Final, there are two 'important' branches: > > * master (current version is 1.1.0-SNAPSHOT) > * 1.0.x (current version is 1.0.1-SNAPSHOT) > > > This email is to clarify what goes in where, or tries to :-) > > I think it's quite simple. Every fix that goes into the "1.0.x branch" needs to go into the "master branch" as well. > > Once a PR has been merged to 1.0.x branch, it's the responsibility of the PR filer to rebase against (latest) master as well, to make sure the merge to master works without any trouble! > > While 1.0.x is really meant for bug fixes and improvements only, the new development is going on in master (for 1.1.0-SNAPSHOT, and later) and therefore fixes that are scheduled for 1.1.x only, should not go into the the 1.0.x branch. > > The scheudling is done via JIRA and almost all commits/merges should have JIRA tickets attached. > > Currently here are the 1.0.x related tickets: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325080/ > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325448 > > As you can see, they all have the 1.1.x version label as well. This is important and ensures (critical) bug fixes to 1.0.x are also arriving on the master branch! > > The JIRAs that are scheduled for 1.1.0 are listed here: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323762/ > > Of course, due to the backport requirement, some of these tickets contain 1.0.x labels on their Fix-Versions as well - but some are exclusively scheduled for 1.1.0, and therefore only go to master branch. > > Any thoughts ? > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/ff5f86f0/attachment.html From daniel.bevenius at gmail.com Fri Aug 29 09:29:59 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 29 Aug 2014 15:29:59 +0200 Subject: [aerogear-dev] Branches on UnifiedPush GH repo In-Reply-To: References: Message-ID: sounds good On 29 August 2014 15:28, Lucas Holmquist wrote: > good summary! > On Aug 29, 2014, at 8:45 AM, Matthias Wessendorf > wrote: > > Hi, > > now that we have released the 1.0.0.Final, there are two 'important' > branches: > > * master (current version is 1.1.0-SNAPSHOT) > * 1.0.x (current version is 1.0.1-SNAPSHOT) > > > This email is to clarify what goes in where, or tries to :-) > > I think it's quite simple. Every fix that goes into the "1.0.x branch" > needs to go into the "master branch" as well. > > Once a PR has been merged to 1.0.x branch, it's the responsibility of the > PR filer to rebase against (latest) master as well, to make sure the merge > to master works without any trouble! > > While 1.0.x is really meant for bug fixes and improvements only, the new > development is going on in master (for 1.1.0-SNAPSHOT, and later) and > therefore fixes that are scheduled for 1.1.x only, should not go into the > the 1.0.x branch. > > The scheudling is done via JIRA and almost all commits/merges should have > JIRA tickets attached. > > Currently here are the 1.0.x related tickets: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325080/ > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325448 > > As you can see, they all have the 1.1.x version label as well. This is > important and ensures (critical) bug fixes to 1.0.x are also arriving on > the master branch! > > The JIRAs that are scheduled for 1.1.0 are listed here: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323762/ > > Of course, due to the backport requirement, some of these tickets contain > 1.0.x labels on their Fix-Versions as well - but some are exclusively > scheduled for 1.1.0, and therefore only go to master branch. > > Any thoughts ? > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/13d7c701/attachment-0001.html From supittma at redhat.com Fri Aug 29 11:16:21 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 29 Aug 2014 11:16:21 -0400 Subject: [aerogear-dev] Branches on UnifiedPush GH repo In-Reply-To: References: Message-ID: <54009945.6010305@redhat.com> On 08/29/2014 08:45 AM, Matthias Wessendorf wrote: > Hi, > > now that we have released the 1.0.0.Final, there are two 'important' > branches: > > * master (current version is 1.1.0-SNAPSHOT) > * 1.0.x (current version is 1.0.1-SNAPSHOT) > > > This email is to clarify what goes in where, or tries to :-) > > I think it's quite simple. Every fix that goes into the "1.0.x branch" > needs to go into the "master branch" as well. > > Once a PR has been merged to 1.0.x branch, it's the responsibility of > the PR filer to rebase against (latest) master as well, to make sure > the merge to master works without any trouble! > > While 1.0.x is really meant for bug fixes and improvements only, the > new development is going on in master (for 1.1.0-SNAPSHOT, and later) > and therefore fixes that are scheduled for 1.1.x only, should not go > into the the 1.0.x branch. > > The scheudling is done via JIRA and almost all commits/merges should > have JIRA tickets attached. > > Currently here are the 1.0.x related tickets: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325080/ > https://issues.jboss.org/browse/AGPUSH/fixforversion/12325448 > > As you can see, they all have the 1.1.x version label as well. This is > important and ensures (critical) bug fixes to 1.0.x are also arriving > on the master branch! > > The JIRAs that are scheduled for 1.1.0 are listed here: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323762/ > > Of course, due to the backport requirement, some of these tickets > contain 1.0.x labels on their Fix-Versions as well - but some are > exclusively scheduled for 1.1.0, and therefore only go to master branch. > > Any thoughts ? +1 > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/64f1b7c4/attachment.html From daniel at passos.me Fri Aug 29 19:14:59 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 29 Aug 2014 20:14:59 -0300 Subject: [aerogear-dev] Travis problem to run aerogear-android-store tests Message-ID: Hi All, Summers and I are working in add travis-ci in all new agdroid modules. I don't know why, but on store we are having some problems. The build passed in Summers account[1], but failed in my account[2] and in my PR[3]. I don't know what is going on because the error is 'generic' I already asked for help in #travis but without success. Whatever help is very welcome PS: The build works locally [1] https://travis-ci.org/secondsun/aerogear-android-store/builds/33931123 [2] https://travis-ci.org/danielpassos/aerogear-android-store/builds/33930399 [3] https://travis-ci.org/aerogear/aerogear-android-store/builds/33947897 -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140829/616e398b/attachment.html