On Thu, Feb 19, 2015 at 9:15 PM, Nikhil Khandelwal <[email protected]> wrote:
> Responses inline. > > My initial thinking was to create a 'cordova package' command that did all > the steps that you mention below. I can see value in having this integrated > as part of 'cordova build' itself for Android. There are still some > questions on how this will for iOS and Windows. > > Thanks, > Nikhil > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Andrew > Grieve > Sent: Thursday, February 19, 2015 12:45 PM > To: dev > Subject: Re: Android packaging signed archive - Gradle vs Ant > > Sorry for the slow reply :(. > > I believe the environment variable docs have been updated in cordova-docs. > just not pushed to the website yet. > [NK] That's good to know > > The gradle support has certainly come a long way since the signing logic > was first added. There are two goals here, i think: > > 1. Allow signing of debug/release when building directly from > cordova/build script 2. Allow signing of debug/release when building via a > CLI project > > > For #1: > - Users could use a build-extras.gradle to set the values directly > - We could have the gradle script auto-detect the presence of a signing > .properties file > [NK] I like the idea of gradle script auto-detecting the .properties file > > For #2: > - I'm assuming for CLI we're going with having signing details in a .json > (seemed to have buy-in) > [NK] Yup! > - It's important that the .gradle file picks up the signing info without > any extra command-line hints, so that you can build via Android Studio. > [NK] Good point! My initial design does not account for this - but I can > tweak it to. > - build-extras.gradle is meant to be used only by end-users. However, we > can set properties via gradle.properties file, or have CLI edit the main > build.gradle file > > > So, how about we address #1 by: > - Users should use build-extras.gradle to specify signing info directly, > or via cdvReleaseSigningPropertiesFile > - Change build.gradle to auto-set cdvReleaseSigningPropertiesFile if a > file named "release-signing.properties" exists as a sibling (likewise for > debug) > [NK] I like this idea > > and address #2 by: > Have CLI extract signing info from .json and create > "release-signing.properties" in the project directory upon prepare. > [NK] Sounds good! > > In all of this: > - Let's keep support for the existing key names within the properties file > (since some early-adopters are already using it) > [NK] This adds more baggage to support and document. Do we have a sense of > how many early adopters might be impacted? Looks like we did switch from > using environment variables to gradle properties and did we hear feedback > when we did so? It would be nice to not have to support both key names. > Chrome Apps for Mobile and Ionic have both started using the 4.0.x branch. I think we'd still be fine to change the property names, but I figured it would be easy to support both names (var foo = obj.name1 || obj.name2). > - But let's also allow the ant-style key names > > > WDYT? > > > > > > > > > On Tue, Feb 17, 2015 at 3:38 PM, Nikhil Khandelwal <[email protected] > > > wrote: > > > PR here for the change: > > https://github.com/apache/cordova-android/pull/155 > > And the docs update: https://github.com/apache/cordova-docs/pull/267 > > > > Added Andrew, Ian to comment on the PR. > > > > Btw, the docs for Android 4.0 are out of date and they need a refresh > > - they still refer to environment variables that are not supported any > more. > > > > My understanding is that ant is being phased away, and gradle will be > > the default in 4.0. I think users are familiar with these properties > > in Ant and it makes sense to have the same names for Cordova-specific > > versions for Gradle. > > > > Thanks, > > Nikhil > > > > -----Original Message----- > > From: Joe Bowser [mailto:[email protected]] > > Sent: Tuesday, February 17, 2015 11:58 AM > > To: dev > > Subject: RE: Android packaging signed archive - Gradle vs Ant > > > > I'd ask Ian or Andrew about changing Gradle stuff. We're dropping Ant > > in 4.0, right? > > On Feb 17, 2015 11:52 AM, "Mefire O." <[email protected]> wrote: > > > > > +1 to reunification. > > > > > > Thanks, > > > Mefire > > > > > > -----Original Message----- > > > From: Victor Sosa [mailto:[email protected]] > > > Sent: Tuesday, February 17, 2015 11:06 AM > > > To: [email protected] > > > Subject: Re: Android packaging signed archive - Gradle vs Ant > > > > > > Don't know the history behind the names of the keys in those files, > > > but to me looks like unifying them is the way to go. Users won't get > > > confused when migrating from Ant to Gradle (not sure if "migrating" > > > is the best word) > > > > > > 2015-02-17 13:02 GMT-06:00 Nikhil Khandelwal <[email protected]>: > > > > > > > Gradle and Ant build systems both require a properties file to > > > > specify release signing parameters. However, the key names for > > > > Gradle are Cordova-specific and they are not the same as the one > > > > used > > in Ant: > > > > > > > > Gradle: > > > > storeFile=..\\..\\android.keystore > > > > storePassword=android > > > > keyAlias=nikhilkh > > > > keyPassword=password > > > > > > > > Ant: > > > > key.store=..\\..\\android.keystore > > > > key.alias=nikhilkh > > > > key.store.password=android > > > > key.alias.password=password > > > > > > > > I'm considering unifying the key names - changing the gradle ones > > > > to be the same as Ant. This will help in an easier implementation > > > > of this > > > JIRA: > > > > https://issues.apache.org/jira/browse/CB-8483 > > > > > > > > Let me know if you see issues with this. I will shortly send out a > > > > PR for this. > > > > > > > > Thanks, > > > > Nikhil > > > > > > > > > > > > > > > > -- > > > Victor Adrian Sosa Herrera > > > IBM Software Engineer > > > Guadalajara, Jalisco > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
