I'd like to discuss how to handle maintenance branches. Sorry if this has
already been discussed, I think Kris posted something about this but I was
not able to find it.
For example, now that we are about to release 1.0.0 we will tag that
release. After that should we create a 1.0.1 branch for patches/bugfixes
and then continue with new features in master?
Since we are in a waiting state at the moment, which could happen again,
should we perhaps create a branch named 1.0.0, which we can use until the
release and then tag it and remove that branch. After that any issues would
be fixed in the 1.0.1 branch.
Does this sound correct?
I want to create wrappers around aerogear-js to be able to use the Aerogear from Erria. What this task comes down to is to create a java api that calls the aerogear-js api. But then I rembered seeing an example in a presentation that you kept the apis the same on all platforms. So my work is already done I just have to look at the api defined in android. The only problem is there are some differences, for instance DataManager on the js side it can be created by passing some config object, but on the android side there is a need for an IdGenerator and a StoreFactory. So what do you guys think should I stick closer to the js api and really try to create a minimal wrapper that is close to that, or should I stick with the android api and maybe use parts of Errai to implement a bridge?
Just wanted to inform you that I've added a functional test for the
Aerogear-Controller-Demo in the GitHub repo 
I created a parent POM which contains 2 modules, the first module is the
aerogear-controller-demo and the second one is the
aerogear-controller-demo-ftest. The aerogear-controller-demo version is
the latest one until the moment I'm writing this e-mail. The only change
which has been done in the aerogear-controller-demo is that the staging
repository was added inside the POM xml since I didn't want to modify my
maven settings.xml. But we can change it..
The functional test project contains 2 profiles:
By default the first profile is active.
Inside the AerogearControllerDemoTestCase there is a TODO task which
states: 'TODO: uncomment when
https://issues.jboss.org/browse/AEROGEAR-1005 is fixed'. The relevant
commented code tests the above JIRA issue.
Any comment, enhancement, improvement is highly appreciated :)
I noticed that some of the method and class names in AeroGear Android
around Paging are sub obtimal.
I would like to, before 1.0 is cut, make the following changes
PageConfig.setPageHeaderParser -> PageConfig.setParameterProvider
PageResultExtractor -> ParameterProvider
ParameterProvider -> gets merged into Parameter Provider
All implementations are updated