Added logic to look for "debug-signing.properties" and "release-signing.properties".
Also made it accept ant-style keys, although I hope most will move to the gradle style. On Mon, Feb 23, 2015 at 10:26 AM, Andrew Grieve <[email protected]> wrote: > > > 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] >> > >
