JIRA: default assignment
by Matthias Wessendorf
Hi,
when someone creates a JIRA against AG-WHAT-NOT, these tickets have a
default assignee.
IMO this is bad.
That feels like: Someone did assign it to himself in order to work on it.
Which is not really true :)
Also, for growing a community: If a ticket (for e.g. low-hanging fruits) is
NOT assigned someone new will be more-likely go ahead and work on it, when
it is NOT assigned to someone.
So... I'd really vote for changing the "default assignee" to "not assigned"
Thoughts ?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
13 years
parent pom?
by Douglas Campos
While reviewing summers' PR I've found myself doing that tedious work of
fixing license headers again - what do y'all think part of our default
tools (like maven-license-plugin) on an aerogear parent pom (which
inherits from jboss parent pom, of course)
Thoughts?
--
qmx
13 years
Android AAR Project format
by Summers Pittman
Y'all,
pilhuhn asked on Twitter if we were planning to support the new aar
package format in AeroGear's Android library. Matzew suggested to take
it to the mailing list so I will run with it for now.
First an introduction. Aar is Google's new binary package format for
Android libraries. It is what their Gradle plugin looks for when it
fetches libraries. For those of you who havn't experienced the joy of
using Android Library Projects with Android Application projects this
fixes a whole host of maintainability and usability problems. Matzew
can probably explain the n00b experience better, but you should be
fluent in angry, angry German.
Now for the challenges. We use Maven to build AGDroid and the
maven-android-plugin does not yet support aar. Also in some Googling
last week I could find 0 documentation for the file format. Right now
the only way to make an aar build is to export an Eclipse Android
project and import it into Android Studio and let it build the aar for
you. This can then be packaged into maven central but is really labor
intensive.
Also the only thing which supports using aar is Android Studio /
Google's Gradle build stuff. Other than being on the cutting cutting
edge (and having a nice project feather in our cap) I don't really see
what this gets us right now.
With that said I would like to put energy toward this.
For now I propose we start building an aar as part of the release process.
Eventually I would like to lend a hand to the android-maven-plugin
project so they can export aars.
Right now I do NOT think we should look at porting the AGDroid source
project from maven to Android Studio.
Thoughts?
Summers
13 years
Push Server Admin UI packaging
by Lucas Holmquist
Currently i've started to develop the push server admin ui in a repo here:https://github.com/lholmquist/aerogear-unified-push-server-admin-ui ( be sure to look at the ember repo ;) )
my question is how should we package it with the push server. Should we keep developing the UI in a separate branch and then update the servers "web" directory with the "dist" directory( currently i'm using grunt to copy the non dist directory to the web directory of the server during development ) when we do a "release" of the admin UI,
or do we want to include all the unminified stuff in the "web" directory of the server.
-- There are 2 options here:
---- just develop in the push server repo
---- develop in a separate repo and then copy unminified stuff over
I kind of like the develop in a separate repo and copy over the dist directory for "releases" but in a read me or something, tell the developer how to modify the console if the want to
thoughts?
13 years
Few suggestions about push quickstarts
by Bruno Oliveira
Good morning, today I was looking at the quickstart demo for push and
would like to make some considerations and see what do you guys think.
In this way we can file jiras to move forward.
- The quickstart make use of AeroGear Controller. IMO we should move to
Resteasy
- Code formatting, do we have a template for it? I don't want to mess up
with the project.
- Something that brought to my attention, after discuss with Passos some
issues on Android is when you send: curl -v -b cookies.txt -c
cookies.txt -H "Accept: application/json" -H "Content-type:
application/json" -X POST -d '{"loginName": "john", "password":"123"}'
http://localhost:8080/prodoctor/login
The HTTP response is:
{"id":"8a7d9bfd-6adc-475a-9b90-407efb6bcae5","enabled":true,"createdDate":1372349593981,"expirationDate":null,"partition":null,"loginName":"john","firstName":null,"lastName":null,"email":null,"status":"PTO","password":"123","location":"New
York"}
Attributes like expirationDate, partition and mailing password should
never be sent back. For more details please take a look at how aerogear
controller demo handle it
https://github.com/aerogear/aerogear-controller-demo/blob/master/src/main....
Behind the scenes PicketLink already encrypts the passwords on AGSec,
but I can't do so much if they're sent back through the network. Thoughts?
--
abstractj
13 years
Repo Names (was: Re: Push "all inclusive" demo)
by Matthias Wessendorf
Hi,
this is not really a quick start :) So I am asking for new names.
Once have have decided on "better" repo names for this, I'll create a JIRA
so that the repos will be renamed to better reflect what they actually
are...
Thoughts?
-Matthias
>
> On Jun 11, 2013, at 10:45 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
> Hey !
> We would like to provide, in a quite short delay (coming 2 weeks) a demo
> showing all the different bits of the "push" world , meaning :
> client | push server | JEE Backend App
>
> We already have the push server (aerogear-unified-push-server) : so we
> need a client (iOS and maybe also Android) and a simple JEE backend
> application. The backend app will mostly be scaffolded and will use the
> aerogear-unified-push-java-client to send messages to the Push Server.
>
> Then of course, we need to think about an idea of the application itself.
> It needs to stay really simple, show how we can send selectively and
> should be a bit "business" related.
>
> So, I came up with an idea this morning that we can discuss here, of
> course if you have any other idea don't hesitate to share it.
>
> Push Demo <https://gist.github.com/sebastienblanc/5755548#introduction>
> Introduction
>
> Prodoctor is a company in the health care industry, selling a
> revolutionary tensiometer. Their clients are doctors. Prodoctor has several
> sales agents all over the United States. At the headquarters, they have
> their "first line" sales department doing cold calls all along the day.
> As soon they have a concrete lead, they use their Prodoctor Admin app to
> filter out available sales Agents available in the lead area. They can then
> send them a push notification.
>
> The sales agent receives the notification on their mobile device that a
> new lead is available. The agent will handle the lead by "accepting" the
> notification informing the other agents that the lead has been processed.
> <https://gist.github.com/sebastienblanc/5755548#the-client-app>The
> client app
>
> 1. The client consist of a list of leads : a lead can be "open" or "in
> process", leads "in process" of other sales are not visible.
>
>
> - optional : when the client tap a lead it appears on a map
>
>
> 1. The client has a status that he can set: STANDBY | WITH_CLIENT |PTO
> 2. The client has a location
> 3. The client has an alias
>
> <https://gist.github.com/sebastienblanc/5755548#prodoctor-admin-client>Prodoctor
> Admin client
>
> 1. The admin client can create a new lead :
>
>
> - A lead consist of a name and a location
>
>
> 1. The admin client can query for Sales Agents based on :
>
>
> - Status
> - Location
>
>
> 1.
>
> The admin client can assign a lead to a selection (1..n) of sales
> agents, this will send out the notifications.
> 2.
>
> The admin client manage the Sales Agents DB.
>
> _______________________________________________
>
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
13 years
AG Security 1.1.1 released
by Bruno Oliveira
Good morning, this e-mail is more to give you a heads up than an
announcement. The major changes into this release were based on unified
push needs, I also updated Picketlink released yesterday
(http://lists.jboss.org/pipermail/security-dev/2013-June/001341.html)
and today our demos.
You might be asking to yourself: when abstractj released 1.1.0? It was
with hawk, but I found some issues between Hawk and CDI and had to
rollback, for 1.2.0 I'll figure out what's happening.
Thanks.
Changelog
- AeroGear Security
* Update README
* Preparing to release AeroGear Security 1.1.1
* Releasing AeroGear Security 1.1.0
* Merge branch 'AGSEC-49'
* Inclusion of Hawk support
* Refactoring packages
* Merge branch 'AGSEC-70'
* Add endpoint authorization support via annotations
- AeroGear Security Picketlink
* Preparing to release 1.1.0
* Merge branch 'AGSEC-76'
* Update to PicketLink beta5
--
abstractj
JBoss, a division of Red Hat
13 years
[RAD/PUSH] Push Tooling
by Sebastien Blanc
Hi all,
With all the stuff going around the unified push, we started to look how to
make the things easier for the developer to integrate "push" capabilities
into his existing backend application.
After playing around and discussing with a few people, we came to the
conclusion that these things are common, whatever your backend apps looks
like :
- You need the Java Sender Artifact
- You need a Valid Unified Push Server URL
- You need a valid Push Application ID
- You need a valid Master Password to be able to interact with the unified
Push Server
That seems to be the perfect case for a Forge Plugin : on any JEE
application, you could apply the "Aerogear Push Plugin" that will do the
current things :
- Pulls down the Java Sender Artifacts into your dependencies
- Make available an Modle/JPA Config object with CRUD facilities on : Push
server URL / Push Application ID / Master password.
This config object could be editable through :
- Forge command line (i.e "aerogear-push set push-url "mypusherver.com")
- Through simple scaffolded User Interface
The idea is really to give people a "boost" when they want to enable "push"
on their existing apps : i.e aerogear-push init >> pulls down the
dependency , add the config object etc ...
Please comment on that, IMO this is really something that would reduce the
step for someone who wants his apps to be "Push" aware.
Seb
13 years
