Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of purplecabbage@gmail.com
 designates 209.85.218.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <9379b384227a4ff2a474ec5cbfb79c76@BLUPR03MB065.namprd03.prod.outlook.com>
References: 
 <CANDRhHD45TvHJq4289kqF7ufhBpxFH=siVUWCY=iJijOSTnQ2Q@mail.gmail.com>
	<CABiQX1VpGDUYgEQVXujcrnVczd2uMeGSOy7XACoMBavDqRt9-w@mail.gmail.com>
	<D0586855.4BEB1%jsoref@blackberry.com>
	<7a4401fb930347aa952b456b85e5fc97@DM2PR03MB366.namprd03.prod.outlook.com>
	<CAFNH95QQxZOwj7fix7zxaobYKKhbQqVewbobqp1LemW-N95KEg@mail.gmail.com>
	<etPan.54346ccb.66334873.3de@HooperX.local>
	<CAE6O_-bUjMTuZN5krJYD61tJWNCebtdDkwfpbe-_gX4s1hdWHQ@mail.gmail.com>
	<CABiQX1V8vp-8whLuVTEePRbGKuCx5mE0uJmrgPo5D0QYiE_EHw@mail.gmail.com>
	<d4fdccc8f42048c58aeb92f0ec4bd0ad@BLUPR03MB151.namprd03.prod.outlook.com>
	<CAFNH95RKOTAy4Pw9THA_A9=0Rf5BD8JQ3EL3BHH5poK38RF06A@mail.gmail.com>
	<9379b384227a4ff2a474ec5cbfb79c76@BLUPR03MB065.namprd03.prod.outlook.com>
Date: Thu, 9 Oct 2014 11:17:02 -0700
Message-ID: 
 <CAKP6k2tRkzNoum=eL1_qXsxJf0T518kMC46Go=7TU0qibT_wTw@mail.gmail.com>
Subject: Re: Build signed archives using CLI
From: Jesse <purplecabbage@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b339ebd69669005050170cb

--047d7b339ebd69669005050170cb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I am liking all of this.
Are we ready to move this to an editable plaintext doc to collaborate on?

I agree that we should take advantage of as much 'by-convention' as we can,
meaning things like `cordova package ios` defaults to a code sign identity
of 'iPhone Developer' and signs based on app-bundle-id, ...

If it does not make sense as a convention, then I too would like to see as
much as possible done through config.xml as Fredrico points out, and agree
on picking the most consistent names possible.

I would prefer that we do not prompt, and simply fail fast, given that
tools will typically be consuming the cli.  Or we should at least provide a
--noPrompt option. Anything prompt-able should be config.xml-able


@purplecabbage
risingj.com

On Thu, Oct 9, 2014 at 10:48 AM, Chuck Lantz <clantz@microsoft.com> wrote:

> One option here could be to build off of the idea of the "res" folder tha=
t
> is in the current samples for splashscreens and icons and introduce
> something like "res/native".  Files placed here would be put into the
> native project folders "before_prepare" and would be further enhanced by
> the plugin and build infrastructure.  This would allow you to place
> customized native assets that are unique to your project in a place that
> you can check in and would be unaffected by an upgrade.
>
> Andrew's environment variable idea could also provide an alternate means
> to specify platform specific values (what Soak mentions in the { }).
>
> -Chuck
>
> -----Original Message-----
> From: Frederico Galv=C3=A3o [mailto:frederico.galvao@pontoget.com.br]
> Sent: Thursday, October 9, 2014 10:33 AM
> Cc: dev@cordova.apache.org
> Subject: Re: Build signed archives using CLI
>
> I agree with pretty much everything mentioned, but as far as I know
> cordova is trying it's best to not depend on anything to be in
> /platforms/<TARGET_PLATFORM>/. Having said that, the package command shou=
ld
> always expect things to be in config.xml or something like that.
>
> Also, the closer we are in naming things to what they are already known a=
s
> in the native platform, the better.
>
> 2014-10-08 20:03 GMT-03:00 Subhag Oak <Subhag.Oak@microsoft.com>:
>
> > Hey Cordova community,
> >
> >
> >
> > I am Subhag Oak, senior program manager on the Visual Studio team
> > working on VS tools for Multi device hybrid apps. In line with the
> > discussion of having a generic Cordova =E2=80=98packaging=E2=80=99 comm=
and for all
> > platforms, here is one
> > proposal:
> >
> >
> >
> > As we all know, packaging an application for deployment requires extra
> > steps that are specific to the native platforms.  A new generic
> > Cordova CLI =E2=80=98package=E2=80=99 command can perform these platfor=
m specific
> > actions to generate a final signed package ready for deployment:
> >
> > cordova package [platform] [--packageConfiguration] {--
> > =E2=80=93-sign[location]
> > -- =E2=80=93-embed[location] -- --signIdentity[location]}, where all th=
e
> > parameters within { } are platform specific overrides.
> >
> >
> >
> > If no platform is specified, the command will build packages for all
> > platforms added.
> >
> >
> >
> > The values for =E2=80=93packageConfiguration are interpreted by the res=
pective
> > platforms. For Android and Windows, the value can be debug or release,
> > with release being the default value.  For iOS, the possible values
> > are development, adhoc or store with development being the default
> > value. The
> > -- --sign, -- -- embed  and -- --signIdentity are optional iOS
> > specific signing arguments for specifying the location of code-signing
> > certificate, the provisioning profile or the code signing identity
> > (certificates along with public and private keys) respectively.
> >
> >
> >
> > e.g:
> >
> > =C2=B7         =E2=80=98cordova package iOS=E2=80=99 would generate a s=
igned ipa with
> > development profile, using code signing identity defined in
> build.xcconfig:
> >
> > // to list all installed iOS identities, run:
> >
> > // security find-identity |  sed -n 's/.*\("[^"]*"\).*/\1/p' | grep
> > 'iPhone'
> >
> > // generic 'iPhone Developer' (no quotes) will match the right
> > Identity with the right Provisioning // Profile plus Certificate,
> > based on the app bundle id
> >
> > CODE_SIGN_IDENTITY =3D iPhone Developer
> >
> >
> >
> > =C2=B7         =E2=80=98cordova package android=E2=80=99 would generate=
 a release signed using
> > the packaging assets (keystore, alias and password) defined in the
> > ant.properties files using the ANT build. This would be using
> > gradle.propoerties once cordova changes to gradle build like the one
> > Andrew mentions below.
> >
> >
> >
> > =C2=B7         =E2=80=98Cordova package windows=E2=80=99 would generate=
 a signed APPX package.
> > This will use the following tools in the Windows SDK:
> >
> > =E2=80=A2                    An unsigned packaged Windows Store app, fo=
r example,
> > an .APPX file created by using the app packager (MakeAppx.exe) tool
> >
> > =E2=80=A2                    A valid code signing certificate, for exam=
ple, a
> > Personal Information Exchange (.pfx) file created with the
> > MakeCert.exe and Pvk2Pfx.exe tools
> >
> > =E2=80=A2                    SignTool, which is part of the Windows SDK
> >
> >
> >
> > Here is how the package command should work. The proposal is to make
> > the =E2=80=98package=E2=80=99 command work on convention (similar to th=
e Cordova build
> > command) rather than config settings. The command would look out for
> > packaging assets in the =E2=80=9Cplatform\ [native-platform]=E2=80=9D f=
older.
> >
> >
> >
> > For android, the contents of the ant.properties (keystore, password,
> > alias and alias password) would be used for packaging. If any of these
> > properties is missing in ant.properties [or gradle.properties for
> > gradle build] or if the file is missing, the command would prompt the
> > user for these value at the command prompt. If the values provided are
> > invalid, the command would fail.
> >
> >
> >
> > For iOS, the contents of build.xcconfig specify the code-sign
> > certificate and the provisioning profile to be used. The default
> > build.xcconfig file is setup to handle different information by build
> > profile based on the configuration defined in the command.
> > Build.xcconfig can also support signing identities that tie the
> > code-sign certificate with the provisioning profile.
> >
> >
> >
> > Tools like VS and other IDEs, which use cordova CLI, may need an
> > explicit way to specify certs/profile for packaging for iOS (since the
> > build needs to happen on MAC agent) instead of the assets being
> > defined in the build.xcconfig. One way to allow this is by using
> > optional platform specific arguments to the package command like:
> >
> > Cordova package iOS --development --sign =E2=80=9Cd:\cert\mycert.cer=E2=
=80=9D --embed
> > =E2=80=9Cd:\cert\devprovision.mobileprovisioning=E2=80=9D
> >
> > This command will run the xcrun command to generate a signed IPA with
> > development provisioning profile.
> >
> >
> >
> > I would love to hear your comments, insights and feedback on this
> proposal.
> >
> >
> >
> > Subhag Oak  |  Senior Program Manager
> >
> > Visual Studio, Client Tools
> >
> > soak@microsoft.com
> >
> > 425 707 5598 office
> >
> >
> >
> > -----Original Message-----
> > From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of
> > Andrew Grieve
> > Sent: Wednesday, October 8, 2014 4:40 AM
> > To: Shazron
> > Cc: tommy-carlos williams; dev@cordova.apache.org
> > Subject: Re: Build signed archives using CLI
> >
> >
> >
> > For Android Gradle, what's in (and experimental) right now:
> >
> >
> >
> > Environment variable "RELEASE_SIGNING_PROPERTIES_FILE" points to a
> > .properties file that contains:
> >
> >
> >
> > storeFile=3Drelative/path/to/keystore.p12
> >
> > storePassword=3DSECRET1
> >
> > storeType=3Dpkcs12
> >
> > keyAlias=3DDebugSigningKey
> >
> > keyPassword=3DSECRET2
> >
> >
> >
> >
> >
> > Topics to discuss:
> >
> >
> >
> > 1) Combine platform info into one file, or leave separate?
> >
> > - Leaning towards together
> >
> > 2) have config.xml point to signing info?
> >
> > - I think no, since signing info you often want to not check in / keep
> > secure
> >
> >
> >
> >
> >
> > Strawman:
> >
> > If a file "cordova-keys.json" exists as a sibling to www/, then use
> > it. It should look like:
> >
> > {
> >
> >   "android": {
> >
> >     "storeFile": "relative/path.p12"
> >
> >      ...
> >
> >   },
> >
> >   "ios": {
> >
> >   },
> >
> >   ...
> >
> > }
> >
> >
> >
> >
> >
> > Android signs debug builds as well (not sure if other platforms do
> > this too?), so maybe also allow
> >
> >   "android-release" as an alias for "android", and
> >
> >   "android-debug"
> >
> >
> >
> >
> >
> > On Tue, Oct 7, 2014 at 6:52 PM, Shazron <shazron@gmail.com<mailto:
> > shazron@gmail.com>> wrote:
> >
> >
> >
> > > I did open an issue for this two years ago:
> >
> > > https://issues.apache.org/jira/browse/CB-1369
> >
> > > and we did discuss this as well 2 yrs ago:
> >
> > > http://apache.markmail.org/thread/xxlmjjzgnctvsqnm
> >
> > >
> >
> > > Seems to be of great value - so let's get going on this ;) The CLI
> > > has
> >
> > > (I think) matured more since then to allow this
> >
> > >
> >
> > >
> >
> > > On Tue, Oct 7, 2014 at 3:44 PM, tommy-carlos williams
> >
> > > <tommy@devgeeks.org<mailto:tommy@devgeeks.org>>
> >
> > > wrote:
> >
> > >
> >
> > > > Frederico=E2=80=99s workflow is the same as ours. I would love to s=
ee
> >
> > > > something happen To improve this, the less time I spend in Xcode,
> >
> > > > the happier I am
> >
> > > ;)
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > On 7 October 2014 at 8:48:40, Frederico Galv=C3=A3o (
> >
> > > > frederico.galvao@pontoget.com.br<mailto:
> > frederico.galvao@pontoget.com.br>) wrote:
> >
> > > >
> >
> > > > I can already get the ultimate .apk through "cordova build android
> >
> > > > --release", but I already have the required .properties properly
> >
> > > configured
> >
> > > > in my platform/android folder, specifying the path and name to my
> >
> > > > keystores. The "cordova build android --release" already gives me
> >
> > > > the signed and ready .apk, all I have to do is upload it to
> > play.google.com.
> >
> > > >
> >
> > > > I have never, however, used cordova's CLI to build the final
> >
> > > > artifact for iOS (IPA) for iTunes. All I do is run "cordova
> >
> > > > prepare", and use xCode
> >
> > > from
> >
> > > > then on to build, package, sign, and upload.
> >
> > > >
> >
> > > > 2014-10-06 16:52 GMT-03:00 Parashuram Narasimhan (MS OPEN TECH) <
> >
> > > > panarasi@microsoft.com<mailto:panarasi@microsoft.com>>:
> >
> > > >
> >
> > > > > How about a "cordova package" command, that would be for
> > > > > packaging
> >
> > > > > the
> >
> > > > app
> >
> > > > > for the store? Note that different platforms may have different
> >
> > > > > requirements for certs, signing etc. So it may make sense to
> >
> > > > > promote
> >
> > > this
> >
> > > > > to a different command and let each command take care of
> > > > > packaging
> >
> > > > > the
> >
> > > > app
> >
> > > > > for the store. This command will also mean that developers don=E2=
=80=99t
> >
> > > > > have
> >
> > > to
> >
> > > > go
> >
> > > > > over to the native projects when they finally want to publish
> >
> > > > > their
> >
> > > apps
> >
> > > > to
> >
> > > > > the store.
> >
> > > > >
> >
> > > > > -----Original Message-----
> >
> > > > > From: Josh Soref [mailto:jsoref@blackberry.com]
> >
> > > > > Sent: Monday, October 6, 2014 12:46 PM
> >
> > > > > To: dev
> >
> > > > > Subject: Re: Build signed archives using CLI
> >
> > > > >
> >
> > > > > if you do:
> >
> > > > > Cordova build --release,
> >
> > > > > The blackberry10 platform will generate a signed image...
> >
> > > > >
> >
> > > > > On 10/6/14, 3:18 PM, "Andrew Grieve" <agrieve@chromium.org<mailto=
:
> > agrieve@chromium.org>> wrote:
> >
> > > > >
> >
> > > > > >AFAIK, I don't think there's any technical roadblocks. Just
> > > > > >need
> >
> > > > > >a proposal for how it should look, and then a patch & docs to
> > > > > >add
> > it!
> >
> > > > > >
> >
> > > > > >For Android's hot-off-the-press gradle support, you can set an
> >
> > > > > >environment variable that points to a .properties file for
> >
> > > > > >signing builds. This shows one way to go about it, but I'm not
> > > > > >in
> >
> > > > > >love with
> >
> > > the
> >
> > > > > .properties idea.
> >
> > > > > >
> >
> > > > > >On Mon, Oct 6, 2014 at 2:48 PM, Victor Sosa
> >
> > > > > ><sosah.victor@gmail.com<mailto:sosah.victor@gmail.com>>
> >
> > > > > >wrote:
> >
> > > > > >
> >
> > > > > >> Hi community.
> >
> > > > > >>
> >
> > > > > >> Been looking at this topic and wondering why the build
> > > > > >> command
> >
> > > > > >>does not create signed archives. Digging a little bit found a
> >
> > > > > >>lot of differences in the platforms to create these archives.
> >
> > > > > >>
> >
> > > > > >> For instance, in Android you need to 1. Export your APK in
> >
> > > > > >> release mode (--release flag) 2. Sign your APK (you already
> >
> > > > > >> need a RSA key)
> >
> > > > > >>
> >
> > > > > >> In iOS, you need to:
> >
> > > > > >> 1. Export your APP using --device flag (--release seems to
> >
> > > > > >> export
> >
> > > for
> >
> > > > > >>emulator only) 2. Either use XCode (UI-based) and sign the
> >
> > > > > >>archive or use xcrun (headless
> >
> > > > > >> process)
> >
> > > > > >>
> >
> > > > > >> Besides these differences, what is preventing Cordova from
> >
> > > > > >> providing a generic one-way to build these signed,
> > ready-to-publish archives?
> >
> > > > > >>
> >
> > > > > >> Perhaps I'm missing something here...? I really appreciate
> > > > > >> your
> >
> > > > > >>insights on this topic
> >
> > > > > >>
> >
> > > > > >> Thanks!
> >
> > > > > >>
> >
> > > > > >> --
> >
> > > > > >> Victor Adrian Sosa Herrera
> >
> > > > > >> IBM Software Engineer
> >
> > > > > >> Guadalajara, Jalisco
> >
> > > > > >>
> >
> > > > >
> >
> > > > >
> >
> > > > > ----------------------------------------------------------------
> > > > > --
> >
> > > > > --- To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > <mailto:dev-unsubscribe@cordova.apache.org>
> >
> > > > > For additional commands, e-mail: dev-help@cordova.apache.org
> <mailto:
> > dev-help@cordova.apache.org>
> >
> > > > >
> >
> > > >
> >
> > > >
> >
> > > >
> >
> > > > --
> >
> > > >
> >
> > > > *Frederico Galv=C3=A3o*
> >
> > > >
> >
> > > > Diretor de Tecnologia
> >
> > > >
> >
> > > > PontoGet Inova=C3=A7=C3=A3o Web
> >
> > > >
> >
> > > >
> >
> > > > ( +55(62) 8131-5720
> >
> > > >
> >
> > > > * www.pontoget.com.br<http://www.pontoget.com.br> <
> > http://www.pontoget.com/>
> >
> > > >
> >
> > >
> >
>
>
>
> --
>
> *Frederico Galv=C3=A3o*
>
> Diretor de Tecnologia
>
> PontoGet Inova=C3=A7=C3=A3o Web
>
>
> ( +55(62) 8131-5720
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>

--047d7b339ebd69669005050170cb--