Hi everyone, me and Jira are eager to solve this issue (https://issues.jboss.org/browse/AEROGEAR-365). Sande sent some updates to our readme attached at this JIRA, but I'm not sure about the reasons to update that.
I'm leaning towards a wontfix for this. Wdyt?
"The measure of a man is what he does with power" - Plato
Volenti Nihil Difficile
I was reviewing aerogear-android-todo, and noticed some issues
1) Why there is no history on the project? (and consequently, ownership history - passos contributed code hasn't got attribution)
- even in cases of big rewrites and start-overs, it's nice to keep the commits, as the history of the incremental changes say a lot about the rationale/train of thought that lead to the final solution
2) Why aren't we following the maven project layout, as suggested by the archetype we are using?
3) Why the API and the example app are intermixed?
- Ideally these should be separate repositories, like the iOS version
setting up my dev environment and trying to install the TODO app from the aerogear repo , I came across to a little problem. Although the instructions say to do "maven clean install" to produce the ear, *and then* start JBoss, what I experience is a build-failure on TODO-EAR if the AS is not already started prior to the build.
I think we need to update the doc to explicitly say start JBoss AS prior to do "maven clean install" or disable "auto-deploy" on build. Need to check the jboss-as maven plugin..
The more I build out the different pieces of aerogear.js, I realize that giving access to and promoting the use of direct options for jQuery.ajax defeats the purpose of the abstraction. The user could just use jQuery.ajax. I think to simplify the APIs, I am going to remove the access to those options and just provide the specific options I think would be useful for the user to have access to.
Any thoughts or objections?