Aerogear 2506 - Spike #210
Conversation
| dependencies { | ||
| implementation project(path: ":core") | ||
| implementation project(path: ":auth") | ||
| implementation project(path: ":push") |
There was a problem hiding this comment.
if the app is move to a different repo, how the references here would look like?
There was a problem hiding this comment.
The app should use the production-profile.gradle file as standard as it references a release version of the SDK, it is only for development would we use the development-profile.gradle once it has been cloned into the SDK.
There was a problem hiding this comment.
right, gotcha. So there should be a script to copy the app from its own repo to the SDK's repo (or symlink). Is that what you have in mind?
There was a problem hiding this comment.
Initially no, I was thinking of manually cloning the showcase into the SDK for testing locally, but it would make a lot more sense that if we are following this approach to write a script to clone and copy the showcase for us, and set the gradle property profile to development
There was a problem hiding this comment.
I would say that the script should be there to make the setup for development as easy as possible.
There was a problem hiding this comment.
Cool, Ill get on that now, and will sync up with @TommyJ1994 later on testing it with the new showcase app
|
Really like this change. This will allow us to have smooth transition to separate showcase app without affecting contributions. To make this mergeable I will suggest to:
@ciaranRoche World class work! Very well done! |
|
@wei-lee @TommyJ1994 @wtrocki I have included two scripts in latest commit, I also updated the description and added an intended usage to the PR above explaining the workflow. |
| mkdir example | ||
| git clone git@github.com:aerogear/android-showcase-template.git | ||
| cd android-showcase-template | ||
| cp -a app/. ../example |
There was a problem hiding this comment.
can we use a symlink here?
There was a problem hiding this comment.
Good idea, once we get the content of the showcase app moved over we can test a symlink over a full copy
There was a problem hiding this comment.
I think the overall flow described here sounds good. Let's start moving the content to the showcase app repo, verify that it will work using the released sdks, and also work with the flow described here.
Once that's done, we can remove the example app here, and update the README file to add instructions on how to do the development work.
|
@ciaranRoche Is that still in progress? :> |
ciaranRoche
changed the title
|
@wtrocki Just needs to be tested against the new showcase app, this was only a spike to see if it could work so the changes need to be tested and then can be closed and or merged. |
|
Thanks for update. I think that current Android showcase works with development versions of the SDK so this changes is really needed. @secondsun Any comments here before we merge this? |
|
@wtrocki It would seem to me that it would be a lot less work to create a development dependency set in the showcase app that defines dependencies to the SDK based on a path variable contained in the showcase. For "default" releases the showcase app could download from jcenter/mavencentral as normal. |
|
@secondsun This is how we are doing things in js and also on ios. FYI @danielpassos |
| } | ||
|
|
||
| dependencies { | ||
| implementation project(path: ":core") |
There was a problem hiding this comment.
Shouldn't it use also published packages?
|
@wtrocki That makes sense. It is basically what this PR does just in a weird way. I'll ask @ciaranRoche about it today |
|
However work here is still valuable to apply the same patterns to showcase app. Closing PR. |
Motivation
JIRA: https://issues.jboss.org/browse/AEROGEAR-2506
Currently, we have an example application as part of our SDK along with a separate security template app. The idea of this Spike is to consolidate these two apps together with minimum disruption to the current development flow.
Description
A suggested approach was to use mavenLocal, this seems unfeasible as a developer would be required to run
./gradlew installand rebuild the project to test every change made.A solution I found was to include separate gradle profile files in the showcase app. One profile would link dependencies to a release version of the SDK whereas the other profile would follow the conventions we already have in the example app.
Intended Usage
Run the following command from the SDK root directory:
This script creates an
exampledirectory, clones the showcase app, and copies the contents of the showcase'sappdirectory into theexampledirectory. Since we have the gradle propertyprofileset to development in the SDK the workflow is now the same as it was before, we can make changes to the example app to test features in the SDK.In order to commit changes to the showcase app, run the following command in the SDK root directory:
This will copy changes from the
exampledir toappdir in the showcase template. If we simply navigate toandroid-showcase-templateand rungit statuswe can see all uncommitted changes to the repo, and from here create a PR against the development branch of theshowcase-templateapp.This method should work well if we follow the conventions from the cordova showcase application which were discussed here.
Additional Information
The approach taken, adds two gradle profiles to the showcase application. The gradle.build file in the showcase app then depends on the gradle property
profileby setting theprofileto production the showcase app will look to a release of the SDK, where as ifprofileis set to development the showcase app will look for a local version of the SDK.Intended usage will only involve setting up your development environment one,
exampleandandroid-showcase-applicationwill be added to the.gitignoreand will not be tracked for contributions to the SDK. Contributions to the showcase app can be made by running the copy script and then navigating to the showcase dir and creating the PR against the showcase app