Thats awesome, looking forward to it!
On Thu, Sep 12, 2013 at 10:22 AM, Jeffrey Heifetz <jheif...@blackberry.com>wrote: > Yup I'm on the same page with you Michal, and I believe Braden as well. > I'm sorry I should have said so earlier, we resolved this on irc. I have a > basic implementation here https://github.com/apache/cordova-cli/pull/39 > but I'm still testing it. > > On 13-09-12 12:36 PM, "Michal Mocny" <mmo...@chromium.org> wrote: > > >Trying to clarify the misunderstanding... > > > >Jeffrey, if I understand your email, your understanding of point (4) of > >bradens flow is that the app.xml is *being* munged, whereas we meant that > >its the app.xml config that is *doing* the munging to the platform config. > > I think that means we both agree that app.xml should never be modified, > >and it was just a miscommunication. Am I right with that understanding? > > > >Also, in your proposal you have plugins munging/preparing *after* app.xml > >does its munging. I assume you did not do intentionally, that you had just > >not considered the order important. If it was intentional, why? We were > >thinking app.xml should be last and thus have the most "importance". > > > > > >On Wed, Sep 11, 2013 at 11:38 AM, Braden Shepherdson > ><bra...@chromium.org>wrote: > > > >> I think we've gotten a bit confused. Let me try to describe again the > >>way I > >> was envisioning things. > >> > >> 1. If defaults.xml exists, replace platform config.xml with it. > >> 2. Use plugman to add each plugin's <config-file> changes onto the > >>platform > >> config.xml. > >> 3. Add in the values from the app config.xml: <name>, <author> etc., > >>which > >> it currently does, plus the proposed new <config-file> tags. > >> 4. Somewhere in there, call plugman prepare to update the JS modules. > >>This > >> doesn't change or depend on config.xml at all. > >> > >> NB: I don't suggest anywhere that we edit the user's top-level, app > >> config.xml. This is just a process for building the platform config.xml, > >> and making it a pure build artifact. > >> > >> I also suggest that the "last word"; the file whose changes are added > >>last, > >> is the app config.xml. This allows the user the power to override any > >> default or setting from a plugin. > >> > >> Braden > >> > >> > >> On Wed, Sep 11, 2013 at 2:16 PM, Jeffrey Heifetz > >><jheif...@blackberry.com > >> >wrote: > >> > >> > I'd like to clarify the changes to prepare before I continue the > >> > implementation. > >> > > >> > The current prepare flow works like this > >> > 1. Call parser.update_project. This includes calling > >> > parser.update_from_config which updates the platform config and > >>resources > >> > based on app config (but only handles specific tags). It also updates > >>the > >> > platform www based on app www, staging and overrides. > >> > 2. Call plugman prepare (sets up JS-modules) > >> > 3. Plugin config-munge (where each plugin config changes are > >> > iterated > >> > through) > >> > > >> > Braden's proposed flow (in his own words) > >> > 1. Delete the old platform config.xml. > >> > 2. Copy the defaults.xml to config.xml. > >> > 3. Re-run the Plugman config munging for every plugin, > >>modifying > >> > the > >> > fresh platform config.xml. (The order here is deliberately > >> > undefined; > >> > plugins should already not be relying on this.) > >> > 4. Run the config munging for the app’s config.xml as well. > >> > Where I believe #4 means the plugin config-munge. > >> > > >> > I'd like to propose the new flow to be the following > >> > > >> > 1. If defaults.xml exists, replace platform congig.xml with it > >> > 2. Run a generic clobbers from app.xml to platform.xml that > >>will > >> > include > >> > processing the proposed <platform> tags. > >> > 3. Run plugman config munge on the platform config.xml (I > >>believe > >> > this should only add net new elements) > >> > > >> > 4. Call a modified parser.update_project that no longer makes > >> > changes to > >> > the platform config.xml > >> > > >> > I believe that this is complimentary with the approach Braden > >>suggested > >> > with one major change. I did not include plugin config munging on the > >>app > >> > config.xml. This is because I feel that by doing so we make the app > >> > config.xml the same half build artifact half user edited mess we're > >> trying > >> > to solve. If the list disagrees with me I will of course implement it > >>the > >> > way Braden proposed it though. > >> > > >> > > >> > > >> > On 13-09-10 1:58 PM, "Jeffrey Heifetz" <jheif...@blackberry.com> > >>wrote: > >> > > >> > >Issue Created - https://issues.apache.org/jira/browse/CB-4774 > >> > > > >> > >On 13-09-10 9:30 AM, "Tommy-Carlos Williams" <to...@devgeeks.org> > >> wrote: > >> > > > >> > >>Then colour me excited! > >> > >> > >> > >>+1 > >> > >> > >> > >> > >> > >>On 10/09/2013, at 11:27 PM, Andrew Grieve <agri...@chromium.org> > >> wrote: > >> > >> > >> > >>> On Mon, Sep 9, 2013 at 7:37 PM, Tommy-Carlos Williams > >> > >>><to...@devgeeks.org>wrote: > >> > >>> > >> > >>>> I have been following this thread with a combination of interest > >>and > >> > >>>> trepidation. > >> > >>>> > >> > >>>> Interest: > >> > >>>> > >> > >>>> Anything that works towards ./platforms being a build artefact I > >>am > >> > >>>>all > >> > >>>> for. In our app, ./platforms is already a build artefact. We used > >> > >>>>hooks to > >> > >>>> achieve this (updating config files, copying icon / splash > >>assets, > >> > >>>>etc). > >> > >>>> > >> > >>>> Just a quick questionŠ I know that ./platforms/../config.xml > >>(even > >> > >>>>after a > >> > >>>> `cordova build Š`) still has the old defaults for name, author, > >>id > >> > >>>>etcŠ but > >> > >>>> it doesn't seem to make any difference. We don't modify > >> > >>>> ./platforms/../config.xml as it seemed like the modifications to > >> > >>>> ./www/config.xml (and our custom hook modifications to say > >> > >>>> ./platforms/android/AndroidManifest.xml) were sufficient. > >> > >>>> > >> > >>>> What am I missing wrt there being differences between these > >>files? > >> > >>>> > >> > >>>> Trepidation: > >> > >>>> > >> > >>>> Users are just starting to get a handle on how the CLI works > >>(though > >> > >>>>there > >> > >>>> are still some ongoing issues that I see fairly regularly, like > >> > >>>>thinking > >> > >>>> they still need to use Plugman directly even with CLI created > >> > >>>>projects). > >> > >>>> Just worried more workflow changes yet again are going to turn > >> people > >> > >>>>off > >> > >>>> the CLI entirely. I may be a bit "twice shy", so if it's not > >>going > >> to > >> > >>>> impact users much (except for making things much better) feel > >>free > >> to > >> > >>>>set > >> > >>>> me straight. hehe. > >> > >>>> > >> > >>>> - tommy > >> > >>>> > >> > >>> Some clarifications: > >> > >>> - Change doesn't change workflow at all > >> > >>> - Change will allow user's edits to their root config.xml actually > >> work > >> > >>>in > >> > >>> all cases > >> > >>> > >> > >>> Win! > >> > >>> > >> > >>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> > >> > >>>> On 10/09/2013, at 2:57 AM, Michal Mocny <mmo...@chromium.org> > >> wrote: > >> > >>>> > >> > >>>>> Aside from moving some files around and changing the order of > >> > >>>>>operations > >> > >>>> a > >> > >>>>> bit, the biggest change will be adding support for <platform> > >>and > >> > >>>>> <config-file> to app.xml. By the way, thats still called > >> config.xml, > >> > >>>>>do > >> > >>>> we > >> > >>>>> want to rename it to app.xml for 3.1? > >> > >>>>> > >> > >>>>> > >> > >>>>> On Mon, Sep 9, 2013 at 12:47 PM, Braden Shepherdson > >> > >>>>><bra...@chromium.org > >> > >>>>> wrote: > >> > >>>>> > >> > >>>>>> I should certainly be able to. I'm digging into a major > >> refactoring > >> > >>>>>>of > >> > >>>>>> Plugman right now, though, so I'll probably want to finish > >>that. > >> If > >> > >>>>>>it's > >> > >>>>>> taking too long, though, then I'll switch gears and get this in > >> > >>>>>>before > >> > >>>> we > >> > >>>>>> cut 3.1. > >> > >>>>>> > >> > >>>>>> Braden > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> On Mon, Sep 9, 2013 at 11:48 AM, Michal Mocny < > >> mmo...@chromium.org> > >> > >>>> wrote: > >> > >>>>>> > >> > >>>>>>> Braden, are you going to be able to take this on this week? I > >> > >>>>>>>think it > >> > >>>>>>> would make the upgrade from 3.0 much easier. > >> > >>>>>>> > >> > >>>>>>> -Michal > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> On Mon, Sep 9, 2013 at 9:48 AM, Michal Mocny < > >> mmo...@chromium.org> > >> > >>>> wrote: > >> > >>>>>>> > >> > >>>>>>>> If you would use a different helloworld app template (which > >>is > >> now > >> > >>>>>>>> possible to specify in both CLI and old workflow), then the > >> > >>>>>>> pre-generatred > >> > >>>>>>>> platform config.xml template would likely be the wrong one, > >>and > >> > >>>>>>>>thus > >> > >>>>>>> this > >> > >>>>>>>> bundling for self documentation would be a disservice. > >> > >>>>>>>> > >> > >>>>>>>> I don't see very much value in documentation for bundling the > >> > >>>> config.xml > >> > >>>>>>>> inside the platform template (when do we suspect users look > >>at > >> > >>>>>>>>that > >> > >>>>>>> file, > >> > >>>>>>>> as apposed to whats actually generated inside their > >>project?). > >> > >>>>>>>>Users > >> > >>>>>>> can > >> > >>>>>>>> read what is generated after adding a platform for their > >> specific > >> > >>>>>>>>app > >> > >>>>>>> using > >> > >>>>>>>> their chosen flow. > >> > >>>>>>>> > >> > >>>>>>>> I think that since bin/create can mush defaults.xml with > >>app.xml > >> > >>>>>>>>for > >> > >>>>>>> both > >> > >>>>>>>> flows, it should. > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> On Mon, Sep 9, 2013 at 9:21 AM, Ian Clelland > >> > >>>>>>>><iclell...@chromium.org > >> > >>>>>>>> wrote: > >> > >>>>>>>> > >> > >>>>>>>>> On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson < > >> > >>>>>>> bra...@chromium.org > >> > >>>>>>>>>> wrote: > >> > >>>>>>>>> > >> > >>>>>>>>>> The defaults.xml is only part of the CLI workflow, yes. It > >>has > >> > >>>>>>>>>>no > >> > >>>>>>>>> relevance > >> > >>>>>>>>>> if you're not using CLI. BUT there is a complete > >>config.xml in > >> > >>>>>>>>>>the > >> > >>>>>>>>>> bin/create template, and it can of course have the same > >>values > >> > >>>>>>>>>>as > >> > >>>> you > >> > >>>>>>>>> would > >> > >>>>>>>>>> get from an unchanged CLI project (defaults.xml + app.xml). > >> The > >> > >>>>>>>>>> configuration values you get from the templates should be > >>the > >> > >>>>>>>>>>same > >> > >>>> in > >> > >>>>>>>>> both > >> > >>>>>>>>>> cases, I agree completely. > >> > >>>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> Yes, I think it's definitely achievable to have the complete > >> > >>>>>>>>>template > >> > >>>>>>>>> config.xml be exactly what you would get (modulo whitespace > >>/ > >> > >>>> comments > >> > >>>>>>> / > >> > >>>>>>>>> etc) from installing the same sample app on the same > >>platform > >> > >>>>>>>>>with > >> > >>>> CLI. > >> > >>>>>>>>> > >> > >>>>>>>>> If we can maintain that standard, then the various files > >>become > >> > >>>> almost > >> > >>>>>>>>> self-documenting; its easy to look at the final config.xml > >>file > >> > >>>>>>>>>in > >> > >>>> the > >> > >>>>>>>>> template to see how the pieces should fit together, and work > >> out > >> > >>>> where > >> > >>>>>>>>> each > >> > >>>>>>>>> of the tags originally came from. > >> > >>>>>>>>> > >> > >>>>>>>>> It might be worth trying to generate the template config.xml > >> > >>>>>>>>>*using* > >> > >>>>>>> cli, > >> > >>>>>>>>> just to maintain the correspondence between them. > >> > >>>>>>>>> > >> > >>>>>>>>> Ian > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>>> Braden > >> > >>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>>> On Sun, Sep 8, 2013 at 5:28 AM, James Jong > >> > >>>>>>>>>><wjamesj...@gmail.com> > >> > >>>>>>>>> wrote: > >> > >>>>>>>>>> > >> > >>>>>>>>>>> Andrew - what I was thinking was pretty much what Michal > >> wrote > >> > >>>>>>> below. > >> > >>>>>>>>>>> Perhaps it was my interpretation of the original note but > >>I > >> > >>>>>>> thought > >> > >>>>>>>>>>> defaults was to be applied only in the CLI workflow. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> -James Jong > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> On Sep 7, 2013, at 1:05 PM, Michal Mocny < > >> mmo...@chromium.org> > >> > >>>>>>> wrote: > >> > >>>>>>>>>>> > >> > >>>>>>>>>>>> With this proposal as it stands, I think that is already > >> true > >> > >>>>>>>>>>>>(at > >> > >>>>>>>>> least > >> > >>>>>>>>>>> for > >> > >>>>>>>>>>>> the initial contents, obviously user can make edits > >>later). > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> Ie, defaults.xml + app.xml = initial config.xml for both > >> > >>>>>>>>>>>>cases, > >> > >>>>>>>>> which > >> > >>>>>>>>>> use > >> > >>>>>>>>>>>> the same helloworld template's app.xml. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> If there are specific differences to the default values > >>that > >> > >>>>>>>>>>>>we > >> > >>>>>>>>> want, > >> > >>>>>>>>>> we > >> > >>>>>>>>>>>> maybe will want to use a different app.xml for each, but > >> > >>>>>>>>> defaults.xml > >> > >>>>>>>>>>>> should be tied to a platform-version not to a workflow. > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> -Michal > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> On Sat, Sep 7, 2013 at 7:56 AM, Andrew Grieve < > >> > >>>>>>> agri...@chromium.org > >> > >>>>>>>>>> > >> > >>>>>>>>>>> wrote: > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>>> James - that's a nice goal, but I don't think it's > >> feasible. > >> > >>>>>>>>>>>>>Did > >> > >>>>>>>>> you > >> > >>>>>>>>>>> have a > >> > >>>>>>>>>>>>> way to do that in mind? > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> On Fri, Sep 6, 2013 at 10:31 PM, James Jong < > >> > >>>>>>> wjamesj...@gmail.com> > >> > >>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> I would like to see the defaults be applied in all > >>cases. > >> > >>>>>>>>>>>>>>For > >> > >>>>>>>>>>>>>> consistency, less confusion, and easier documentation. > >> If > >> > >>>>>>>>>>>>>>we > >> > >>>>>>> add > >> > >>>>>>>>> or > >> > >>>>>>>>>>>>> change > >> > >>>>>>>>>>>>>> the defaults in a release, both workflows should get > >>it. > >> In > >> > >>>>>>>>>>>>>>my > >> > >>>>>>>>> mind, > >> > >>>>>>>>>>> the > >> > >>>>>>>>>>>>>> CLI platform config.xml should be equivalent to the > >> > >>>>>>>>>>>>>>bin/create > >> > >>>>>>>>> one. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> -James Jong > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> On Sep 6, 2013, at 11:06 AM, Michal Mocny > >> > >>>>>>>>>>>>>><mmo...@chromium.org > >> > >>>>>>>> > >> > >>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> I thought we were adding support for the last bit (ie, > >> app > >> > >>>>>>>>> generic > >> > >>>>>>>>>> not > >> > >>>>>>>>>>>>>>> platform specific preferences) to "app.xml" which the > >> > >>>>>>> helloworld > >> > >>>>>>>>>>>>> template > >> > >>>>>>>>>>>>>>> should ship with and bin/create should apply. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> -Michal > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> On Fri, Sep 6, 2013 at 10:52 AM, Ian Clelland < > >> > >>>>>>>>>> iclell...@chromium.org > >> > >>>>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> The template version needs to be a complete config > >>file > >> > >>>>>>>>>>>>>>>>for > >> > >>>>>>> the > >> > >>>>>>>>>>> sample > >> > >>>>>>>>>>>>>> app, > >> > >>>>>>>>>>>>>>>> though. You should be able to run bin/create and then > >> > >>>>>>>>>>>>>>>>build > >> > >>>>>>> the > >> > >>>>>>>>>>> Hello, > >> > >>>>>>>>>>>>>>>> Cordova app immediately. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> defaults.xml is supposed to be stripped right down to > >> just > >> > >>>>>>> the > >> > >>>>>>>>>>>>>>>> platform-specific options which, in theory, shouldn't > >> need > >> > >>>>>>> to be > >> > >>>>>>>>>>>>>> specified > >> > >>>>>>>>>>>>>>>> by every app. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> At least that's how it works in my head :) The > >> distinction > >> > >>>>>>> may > >> > >>>>>>>>> be > >> > >>>>>>>>>>> less > >> > >>>>>>>>>>>>>>>> important than I'm imagining. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> Ian > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> On Fri, Sep 6, 2013 at 9:08 AM, Michal Mocny < > >> > >>>>>>>>> mmo...@chromium.org> > >> > >>>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> If the content or format of defaults.xml and the > >> initial > >> > >>>>>>>>>> config.xml > >> > >>>>>>>>>>>>>> will > >> > >>>>>>>>>>>>>>>> be > >> > >>>>>>>>>>>>>>>>> different then we should ship both -- but I don't > >>think > >> > >>>>>>>>>>>>>>>>>they > >> > >>>>>>>>> will > >> > >>>>>>>>>>> be, > >> > >>>>>>>>>>>>>> so > >> > >>>>>>>>>>>>>>>> I > >> > >>>>>>>>>>>>>>>>> think we just ship the template with a defaults > >>file. > >> > >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> -Michal > >> > >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> On Thu, Sep 5, 2013 at 11:19 PM, Ian Clelland < > >> > >>>>>>>>>>>>> iclell...@chromium.org > >> > >>>>>>>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> On Thu, Sep 5, 2013 at 5:16 PM, James Jong < > >> > >>>>>>>>> wjamesj...@gmail.com > >> > >>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> defaults.xml - Is that only used by CLI? And not > >> used > >> > >>>>>>>>>>>>>>>>>>>by > >> > >>>>>>>>>>>>> bin/create > >> > >>>>>>>>>>>>>>>>>>> scripts? > >> > >>>>>>>>>>>>>>>>>>> It was bit unclear to me from the description > >>since > >> > >>>>>>>>>>>>>>>>>>>both > >> > >>>>>>> were > >> > >>>>>>>>>>>>>>>> mentioned > >> > >>>>>>>>>>>>>>>>>>> regarding the 2 xml files. > >> > >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> Yes, that's the idea. If you're using the > >>bin/create > >> > >>>>>>> scripts, > >> > >>>>>>>>>> then > >> > >>>>>>>>>>>>>>>> there > >> > >>>>>>>>>>>>>>>>> is > >> > >>>>>>>>>>>>>>>>>> a complete "config.xml" file in the template that > >>will > >> > >>>>>>>>>>>>>>>>>>be > >> > >>>>>>> used > >> > >>>>>>>>>> for > >> > >>>>>>>>>>>>>> your > >> > >>>>>>>>>>>>>>>>> new > >> > >>>>>>>>>>>>>>>>>> app. This is for strict backwards compatibility > >>with > >> > >>>>>>> anyone's > >> > >>>>>>>>>>>>> workflow > >> > >>>>>>>>>>>>>>>>> that > >> > >>>>>>>>>>>>>>>>>> doesn't currently include CLI. > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> If you are using CLI, then we will construct a new > >> > >>>>>>> config.xml > >> > >>>>>>>>>> file > >> > >>>>>>>>>>>>> for > >> > >>>>>>>>>>>>>>>>> you > >> > >>>>>>>>>>>>>>>>>> instead, from three sources: defaults.xml, which > >> > >>>>>>>>>>>>>>>>>>specifies > >> > >>>>>>>>> all of > >> > >>>>>>>>>>>>> the > >> > >>>>>>>>>>>>>>>>>> platform defaults; the various plugin.xml files, > >>and > >> > >>>>>>>>>>>>>>>>>>your > >> > >>>>>>>>> app's > >> > >>>>>>>>>>>>>>>>> config.xml > >> > >>>>>>>>>>>>>>>>>> file. The end-result should be the same, but you > >>have > >> a > >> > >>>>>>> clear > >> > >>>>>>>>>> place > >> > >>>>>>>>>>>>> to > >> > >>>>>>>>>>>>>>>>>> override the defaults for your app that lives > >>outside > >> of > >> > >>>>>>> your > >> > >>>>>>>>>>>>>> platforms > >> > >>>>>>>>>>>>>>>>>> directory, and the cordova team has a clear place > >>to > >> set > >> > >>>>>>> those > >> > >>>>>>>>>> same > >> > >>>>>>>>>>>>>>>>>> defaults. > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> Ian > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> The new CLI prepare flow makes sense to me. > >> > >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> -James Jong > >> > >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> On Sep 5, 2013, at 2:21 PM, Michal Mocny < > >> > >>>>>>>>> mmo...@chromium.org> > >> > >>>>>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>> We briefly discussed JSON and the two thoughts > >>were: > >> > >>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>> (1) We like it, but really what does it buy us? > >> > >>>>>>>>>>>>>>>>>>>> (2) This change is at the moment 100% compatible > >> with > >> > >>>>>>>>>>>>>>>>>>>>all > >> > >>>>>>>>>> current > >> > >>>>>>>>>>>>>>>>>>> workflows > >> > >>>>>>>>>>>>>>>>>>>> (including upgrades from 3.0->3.1), and we think > >> > >>>>>>>>>>>>>>>>>>>>that's > >> > >>>>>>>>>> important > >> > >>>>>>>>>>>>>>>> for > >> > >>>>>>>>>>>>>>>>>>>> headache-less adoption. JSON would obviously not > >> be. > >> > >>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>> Regarding where to store the defaults, we had > >> thought > >> > >>>>>>>>>>>>>>>>>>>>it > >> > >>>>>>>>> would > >> > >>>>>>>>>> be > >> > >>>>>>>>>>>>> a > >> > >>>>>>>>>>>>>>>>>> file > >> > >>>>>>>>>>>>>>>>>>>> bundled with the platform, perhaps in > >>bin/templates? > >> > >>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>> -Michal > >> > >>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>> On Thu, Sep 5, 2013 at 12:38 PM, Brian LeRoux < > >> > >>>>>>> b...@brian.io> > >> > >>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>> The logic flow is much safer in this method. > >>Where > >> do > >> > >>>>>>> you > >> > >>>>>>>>>> think > >> > >>>>>>>>>>>>>>>>>>> default.xml > >> > >>>>>>>>>>>>>>>>>>>>> should live? (Maybe it doesn't have to exist and > >> > >>>>>>> defaults > >> > >>>>>>>>> can > >> > >>>>>>>>>>>>> just > >> > >>>>>>>>>>>>>>>>> be > >> > >>>>>>>>>>>>>>>>>>> vars > >> > >>>>>>>>>>>>>>>>>>>>> in the logic that does the processing?) > >> > >>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>> Is this our opportunity to move to JSON? > >> > >>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>> On Thu, Sep 5, 2013 at 8:21 AM, Braden > >>Shepherdson > >> < > >> > >>>>>>>>>>>>>>>>>> bra...@chromium.org > >> > >>>>>>>>>>>>>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> config.xml as a build artifact for less > >>suffering > >> > and > >> > >>>>>>>>> easier > >> > >>>>>>>>>>>>>>>>> upgrades > >> > >>>>>>>>>>>>>>>>>>>>>> Terminology > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> ³platform config.xml² refers to the > >> > platform-specific > >> > >>>>>>>>>>>>>>>> config.xml > >> > >>>>>>>>>>>>>>>>>>>>> files, > >> > >>>>>>>>>>>>>>>>>>>>>> eg. platforms/android/res/xml/config.xml. This > >>is > >> > the > >> > >>>>>>>>> final > >> > >>>>>>>>>>>>>>>> file > >> > >>>>>>>>>>>>>>>>>> read > >> > >>>>>>>>>>>>>>>>>>>>> by > >> > >>>>>>>>>>>>>>>>>>>>>> Cordova at runtime. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> ³app config.xml² refers to the top-level > >> config.xml > >> > >>>>>>> found > >> > >>>>>>>>> in > >> > >>>>>>>>>>>>>>>>>>>>>> www/config.xml. > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Why the current situation is suffering > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Chiefly, the platforms/foo/.../config.xml files > >> are > >> > >>>>>>> both > >> > >>>>>>>>> the > >> > >>>>>>>>>>>>>>>>> input > >> > >>>>>>>>>>>>>>>>>>> and > >> > >>>>>>>>>>>>>>>>>>>>>> output of munging by Plugman and the user. This > >> > sucks. > >> > >>>>>>> It > >> > >>>>>>>>>> makes > >> > >>>>>>>>>>>>>>>>>>>>>> automatic upgrades difficult because everybody > >> has a > >> > >>>>>>>>>> customized > >> > >>>>>>>>>>>>>>>>>>>>>> config.xml > >> > >>>>>>>>>>>>>>>>>>>>>> file in their platforms. It also makes plugin > >>rm > >> > harder > >> > >>>>>>>>> and > >> > >>>>>>>>>>>>>>>> less > >> > >>>>>>>>>>>>>>>>>>>>> robust > >> > >>>>>>>>>>>>>>>>>>>>>> in > >> > >>>>>>>>>>>>>>>>>>>>>> CLI than it needs to be. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Currently only some tags in the app config.xml > >>are > >> > >>>>>>>>> actually > >> > >>>>>>>>>>>>>>>>>> honoured. > >> > >>>>>>>>>>>>>>>>>>>>>> Others are ignored, and this has tripped up our > >> > users. > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Goals > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> bin/create workflow is unchanged. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Final content of the platform config.xml file > >>is > >> > >>>>>>>>> unchanged, > >> > >>>>>>>>>>>>>>>>> though > >> > >>>>>>>>>>>>>>>>>>> the > >> > >>>>>>>>>>>>>>>>>>>>>> method of building it in the CLI can change. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> CLI workflow is unchanged, in terms of what a > >>user > >> > >>>>>>> types. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> platform config.xml stops being both input and > >> > output > >> > >>>>>>>>> under > >> > >>>>>>>>>>>>>>>> CLI. > >> > >>>>>>>>>>>>>>>>>> Less > >> > >>>>>>>>>>>>>>>>>>>>>> munging, and easier upgrades. In short, > >>platform > >> > >>>>>>>>> config.xml > >> > >>>>>>>>>>>>>>>> files > >> > >>>>>>>>>>>>>>>>>>>>> become > >> > >>>>>>>>>>>>>>>>>>>>>> build artifacts. > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> What we propose to do about it > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> First, adjust the platform template (used by > >> > >>>>>>> bin/create) > >> > >>>>>>>>> to > >> > >>>>>>>>>>>>>>>>> contain > >> > >>>>>>>>>>>>>>>>>>>>> two > >> > >>>>>>>>>>>>>>>>>>>>>> files: > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> defaults.xml, which is versioned, immutable, > >>and > >> > >>>>>>> tucked > >> > >>>>>>>>>> away > >> > >>>>>>>>>>>>>>>>>>>>>> somewhere (only CLI accesses it) and contains > >> only > >> > >>>>>>> the > >> > >>>>>>>>>>>>>>>>>>>>>> Cordova-specified > >> > >>>>>>>>>>>>>>>>>>>>>> platform defaults, such as the preferences, > >>any > >> > >>>>>>> default > >> > >>>>>>>>>>>>>>>>>>>>>> whitelist entries, > >> > >>>>>>>>>>>>>>>>>>>>>> etc. It does NOT contain any <author>, <name> > >>or > >> > >>>>>>> other > >> > >>>>>>>>>> such > >> > >>>>>>>>>>>>>>>>>> tags. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> platform config.xml, which is the same as it > >> > >>>>>>> currently > >> > >>>>>>>>>> is, a > >> > >>>>>>>>>>>>>>>>>>>>> complete > >> > >>>>>>>>>>>>>>>>>>>>>> config.xml for the HelloWorld app. This means > >> > >>>>>>> behavior > >> > >>>>>>>>> is > >> > >>>>>>>>>>>>>>>>>>> unchanged > >> > >>>>>>>>>>>>>>>>>>>>>> for people who are not using CLI. Plugman > >>still > >> > >>>>>>> munges > >> > >>>>>>>>>> this > >> > >>>>>>>>>>>>>>>>> file > >> > >>>>>>>>>>>>>>>>>>>>> and > >> > >>>>>>>>>>>>>>>>>>>>>> outputs back to it, same as now. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Second, adjust the CLI¹s cordova create > >>template > >> so > >> > >>>>>>> that > >> > >>>>>>>>> its > >> > >>>>>>>>>>>>>>>>>>> top-level > >> > >>>>>>>>>>>>>>>>>>>>>> app config.xml contains <name>, <author>, > >> <content>, > >> > >>>>>>> etc. > >> > >>>>>>>>> - > >> > >>>>>>>>>>>>>>>> tags > >> > >>>>>>>>>>>>>>>>>> the > >> > >>>>>>>>>>>>>>>>>>>>>> user is likely to edit. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Third, modify the CLI so that the new cordova > >> > prepare > >> > >>>>>>> flow > >> > >>>>>>>>>> is: > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Delete the old platform config.xml. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Copy the defaults.xml to config.xml. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Re-run the Plugman config munging for every > >> plugin, > >> > >>>>>>>>>>>>>>>> modifying > >> > >>>>>>>>>>>>>>>>>> the > >> > >>>>>>>>>>>>>>>>>>>>>> fresh platform config.xml. (The order here is > >> > >>>>>>>>> deliberately > >> > >>>>>>>>>>>>>>>>>>>>> undefined; > >> > >>>>>>>>>>>>>>>>>>>>>> plugins should already not be relying on > >>this.) > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Run the config munging for the app¹s > >>config.xml > >> as > >> > >>>>>>>>> well. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> This results in a freshly built, > >>build-artifact > >> > >>>>>>>>> platform > >> > >>>>>>>>>>>>>>>>>>>>> config.xml. > >> > >>>>>>>>>>>>>>>>>>>>>> Users should not be editing it; their > >>top-level > >> app > >> > >>>>>>>>>>>>>>>> config.xml > >> > >>>>>>>>>>>>>>>>>>>>>> has the last > >> > >>>>>>>>>>>>>>>>>>>>>> word and will override any settings the > >>defaults > >> or > >> > >>>>>>>>>> plugins > >> > >>>>>>>>>>>>>>>>>> might > >> > >>>>>>>>>>>>>>>>>>>>>> make. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Note that this means we shouldn¹t be > >> needlessly > >> > >>>>>>>>> setting > >> > >>>>>>>>>>>>>>>>>>> defaults > >> > >>>>>>>>>>>>>>>>>>>>>> in the app config.xml, since this might > >> prevent > >> > >>>>>>>>>> plugins > >> > >>>>>>>>>>>>>>>>> from > >> > >>>>>>>>>>>>>>>>>>>>>> changing > >> > >>>>>>>>>>>>>>>>>>>>>> things that need changing. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Fourth, extend the app config.xml format so > >>that > >> it > >> > can > >> > >>>>>>>>> have > >> > >>>>>>>>>>>>>>>>>>>>>> <platform>tags, like a plugin.xml. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> Into this it can put platform-specific things > >> like > >> > >>>>>>>>>>>>>>>>>> splashscreens, > >> > >>>>>>>>>>>>>>>>>>>>>> preferences and other things, rather than > >>mixing > >> > >>>>>>> these > >> > >>>>>>>>>>>>>>>>> together > >> > >>>>>>>>>>>>>>>>>> in > >> > >>>>>>>>>>>>>>>>>>>>>> the > >> > >>>>>>>>>>>>>>>>>>>>>> config. > >> > >>>>>>>>>>>>>>>>>>>>>> - > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>>> In particular, it can have <config-file> tags > >>in > >> > the > >> > >>>>>>>>> usual > >> > >>>>>>>>>>>>>>>>>> format > >> > >>>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>> > >> > >>>> > >> > >> > >> > > > >> > > > >> > >--------------------------------------------------------------------- > >> > >This transmission (including any attachments) may contain > >>confidential > >> > >information, privileged material (including material protected by the > >> > >solicitor-client or other applicable privileges), or constitute > >> > >non-public information. Any use of this information by anyone other > >>than > >> > >the intended recipient is prohibited. If you have received this > >> > >transmission in error, please immediately reply to the sender and > >>delete > >> > >this information from your system. Use, dissemination, distribution, > >>or > >> > >reproduction of this transmission by unintended recipients is not > >> > >authorized and may be unlawful. > >> > > >> > > >> > --------------------------------------------------------------------- > >> > This transmission (including any attachments) may contain confidential > >> > information, privileged material (including material protected by the > >> > solicitor-client or other applicable privileges), or constitute > >> non-public > >> > information. Any use of this information by anyone other than the > >> intended > >> > recipient is prohibited. If you have received this transmission in > >>error, > >> > please immediately reply to the sender and delete this information > >>from > >> > your system. Use, dissemination, distribution, or reproduction of this > >> > transmission by unintended recipients is not authorized and may be > >> unlawful. > >> > > >> > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from > your system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. >
