Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CAMSbhBiZQVbRLEqaJoPm8L-j2Ve1FcXSV7qOCnHzvw3Bx3t5-A@mail.gmail.com>
References: 
 <BLUPR03MB134406867C80188791FB8B3C3C40@BLUPR03MB134.namprd03.prod.outlook.com>
 <CAMSbhBiZQVbRLEqaJoPm8L-j2Ve1FcXSV7qOCnHzvw3Bx3t5-A@mail.gmail.com>
From: Michal Mocny <mmocny@chromium.org>
Date: Tue, 19 May 2015 11:55:49 -0400
Message-ID: 
 <CAEeF2TcaL3D9sKKX_dnWkrHHahuSAhgmE+v2cYs5dcxB9Ac9yg@mail.gmail.com>
Subject: Re: build.json file
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=bcaec5485aba6247760516715992

--bcaec5485aba6247760516715992
Content-Type: text/plain; charset=UTF-8

2 cents: A pattern I was introduced to recently was simply to use:

<name>.SECRET.json

For any sensitive settings for any file, and:

<name>.SAMPLE.json

To provide dummy data for any SECRET files as a source of documentation.

Then, in your .gitignore, you can just ignore **/*.SECRET.*, and write a
single helper method for reading any config files which knows to merge in
SECRET files.

Has worked well for projects I've used recently.

-Michal

On Mon, May 18, 2015 at 3:39 PM, Steven Gill <stevengill97@gmail.com> wrote:

> I am generally hesitant to add more config files to cordova projects. I
> would rather see us converge to package.json as the de facto config file
> over config.xml in the future.
>
> Aside from that, I do see the value in having a build.json file which
> contains sensitive information (certs, passwords, signing identity) and
> doesn't get packaged up with the app or checked in to git repos. So this
> looks good to me. Also like the ideas for the future.
>
> -Steve
>
> On Mon, May 18, 2015 at 10:25 AM, Nikhil Khandelwal <
> nikhilkh@microsoft.com>
> wrote:
>
> > I want to bring this to the attention of everyone that I have added a
> > build.json for specifying signing parameters for different platforms as
> > part of cordova build. Here are the design principles I used:
> >
> > -          build.json should be used over config.xml for specifying build
> > time behavior (as opposed to runtime). In the case of signing, it did not
> > make sense to have paths to certs, passwords, signing identity info etc.
> to
> > be part of config.xml and be packaged with the app itself.
> >
> > -          build.json file has the following schema:
> > {
> >                      "<platformName>" : {
> >                                 "debug" : {
> >                                                 "<propertyName>" :
> > "<propertyValue>"
> >                                 },
> >                                 "release" : {
> >                                                 "<propertyName>" :
> > "<propertyValue>"
> >                                 },
> >                 }
> >
> > -          So far all properties that can be specified using build.json
> > can be specified using command line args. Command line args take
> precedence
> > if it's specified at both places.
> >
> > -          By convention, a file named 'build.json' on the project root
> > alongside 'config.xml' will be passed to platform CLI scripts with its
> > location using the '--buildConfig' argument. There is a PR for this here:
> > https://github.com/apache/cordova-lib/pull/215
> >
> > Ideas for future:
> >
> > -          Cordova CLI will allow to specify a custom build.json
> >
> > -          Add docs for this talking about build.json
> >
> > -          Unify parsing logic for build.json & command line args across
> > platforms in a shared module.
> >
> > -          Move some of the config.xml properties to build.json since
> they
> > belong better there.
> >
> > Let me know if you have any questions, ideas or concerns related to this.
> >
> > Thanks,
> > Nikhil
> >
> >
> >
>

--bcaec5485aba6247760516715992--