My two cents - there are three things here: 1. App metadata 2. Project metadata 3. Workspace metadata
$project/.cordova/config.json is probably the closest thing to an IDE project file. The closest thing to workspace level settings is $home/.cordova/config.json. Given config.xml's roots, it's more of an app metadata file like AndroidManifest.xml or package.appxmanifest.xml. Its contents should describe the app intendant of IDE or build system (as far as that is possible). So, regarding, "The newly proposed metadata for specifying project directory structure would be part of this metadata," I don't think config.xml is the right place for that. It's build system config - which I believe belongs in config.json. Plugins in many ways equate to capabilities or intents which is why that makes sense to exist in config.xml. The platforms that the app is designed to target also by extension appear to make sense (though admittedly less cleanly since there isn't a native platform equivalent). On the plugin operations - Question is whether that would annoy developers that prefer to edit by hand (vs IDE use). The idea behind save/restore is to make it easier to share a project and reduce the amount of redundant code that you'd check in to a source repo. (You could omit the plugins and platforms folders from source control and then "restore".) -Chuck -----Original Message----- From: Michal Mocny [mailto:mmo...@google.com] Sent: Wednesday, August 13, 2014 3:27 PM To: Treggiari, Leo Cc: dev@cordova.apache.org Subject: Re: cordova plugin save On Wed, Aug 13, 2014 at 6:07 PM, Treggiari, Leo <leo.treggi...@intel.com> wrote: > Hi Michal, > > > > Thanks for your answers. They were quite helpful. I have a few > follow-ups. > > > > With your answers, and references, and I found > https://wiki.apache.org/cordova/ConfigurationFiles, > > I have a better understanding of the existing metadata files. > > > > However there seem to be quite a few of them and I’m not yet sure > about where different types of information should go. > > > > https://wiki.apache.org/cordova/ConfigurationFiles goes into the > answers I’m looking for, except it just seems to be documenting the > current situation. > > - What types of metadata are there? > > - Where is each type saved? > > - Who owns each type and can change it? > I think we are figuring this out ourselves. There are differing opinions. Thanks for speaking up and voicing yours. > > > Here are my thoughts: > > > > - “App” (or “Project”) metadata defines everything about the “app” > that should be shared by all developers who want to develop/build the > app. In the case of Cordova CLI, this is primarily a “build recipe”. > I.e. with this metadata (plus given proper “workspace” (or > “environment”) setup), anyone can build the same app. Tooling (e.g. > Cordova CLI) or IDEs would normally be used to maintain some/all of > this metadata. For example, Cordova CLI may handle the plugins and > platforms but document how to add icons and splash screens to the app > using this metadata file. An IDE might manage all of that inside the > IDE itself. The newly proposed metadata for specifying project directory > structure would be part of this metadata. > Personally, this is exactly my mental model as well. But its > > > - “Workspace” (or “Environment” or “Project specific user settings”) > metadata describe the settings that a user (or tools on the user’s > behalf) have to make to set up an environment for developing/building the app. > E.g. the location of native SDKs. > Ditto. > > > In general, different tooling/IDEs could have different rules > regarding who creates these metadata files and who is allowed to edit them > and how. > > > > Is app config.xml intended to be the “App” metadata file? > Yes. Though it should be noted that most everyone would rather there was a different file for this. config.xml is based on a deprecated proposal for app metadata (widget spec). There are several new app manifest formats roaming around, most based on json. However, I think we will likely use what we already have for the foreseeable future since we're already spending way too much time on tooling and changing this is not worthwhile bang-for-buck. > Is .cordova/config.json intended to be the “Workspace” metadata file? > I think so. I'm less sure about how everyone feels about this file, but its likely that we will stick with what we have. Its also possible that IDE's/downstream tooling can just use some internal settings representation since most the the config.json values can be passed in to the CLI through the command line or node interface. > > > > - Aside from the initial create script that sets name etc, the > > > plugin/platform save command is the first tooling command to edit > > the > file > > > directly (I think?). > > > > I don’t understand why ‘cordova plugin/platform add/remove’ would not > modify app config.xml, but now ‘cordova plugin/platform save’ would. > Or is that really the distinction between the 2? And how does that > list of plugins interact with what the user may have added themselves to > config.xml? > I think this was Andrew's point and Gorkems original intention. We agree that `plugin add/remove` should update the list. The save/restore was just a non-intrusive way to experiment for now. > > > Thanks, > All good questions raised, with few definitive answers. It sounds like you're all caught up to the rest of us, though! > Leo > > > > > A few answers: > > > - There is no spec, since this is an "experimental" feature we > > aren't > > > ourselves sure yet how it will look when complete. That was the > > point > of > > > recent threads. > > > - The file belongs to the app / user, not to the workspace / tooling. > > > - Aside from the initial create script that sets name etc, the > > > plugin/platform save command is the first tooling command to edit > > the > file > > > directly (I think?). > > > - You can read more here: > > > https://cordova.apache.org/docs/en/edge/config_ref_index.md.html > > > - The top level "app" config.xml is not platform specific, but you > > can > have > > > platform specific settings in there by using the <platform> tag > > > - It is specific to cordova CLI. Each platform has another, > > different > > > config.xml (we usually call it the "platform" config.xml) which is > created > > > during cordova prepare, and thats what edited with non cli workflow. > > > - Phonegap workflow (also chrome cordova (cca) and likely others) is > > > compatible with cordova config.xml, but those often also add > > extensions > to > > > the options > > > - "project-level" (I call this "workspace") metadata should *not* go > > into > > > app config.xml. We already have another file, .cordova/config.json > > for > > > those. However, the list of plugins that your app needs is arguably > > not > a > > > property of a workspace, but truly a property of your application. > > Ditto > > > for platforms (to a lesser extent). > > > > > > I'm not so sure what the proposal is for removing plugins/ > > directory, I > > > don't think there is anything concrete for that, it was just > > ramblings of > > > various contributors ;) > > > > > > -Michal > > > > > > > > > On Wed, Aug 13, 2014 at 2:41 PM, Treggiari, Leo > > <leo.treggi...@intel.com > > > > > wrote: > > > > > >> I'm new to this mailing list. I work on the Intel(r) XDK which is > another > > >> IDE which supports the creation of hybrid apps using Cordova plugins. > > >> > > >> I'm having trouble figuring out what the proposed 'cordova plugin save' > > >> command does. Is there an up-to-date 'spec' that explains the > >> goals of > the > > >> command and the implementation? > > >> > > >> A couple of things that I have read in the mailing list concern me. > > >> > > >> There is mention of saving information in config.xml. The usage of > > >> config.xml is somewhat of a mystery to me: > > >> - Who owns the file? Does the user own and edit it? Do certain > Cordova > > >> CLI commands edit it? What are the valid entries? > > >> - Is it treated differently by different platform builds - e.g. iOS vs. > > >> Android? Is it treated differently by Cordova CLI vs. other > >> Cordova > IDEs > > >> which directly use Cordova CLI or not - e.g. PhoneGap build? > > >> - If Cordova CLI wants to store 'project-level' metadata, is this > >> a > good > > >> place to put it? If the answer to the first question above is not > >> well > > >> defined, or the answer to the second question is that different 'things' > > >> are using it differently, then config.xml may not be a good place > >> to be > > >> putting new metadata. > > >> > > >> There is a mention of plugin "restoring" and making the plugins > directory > > >> optional. This relates to the issue of plugin 'versions'. Now, > >> when a > > >> user executes 'cordova plugin add', plugin sources are fetched and > >> the > > >> version of the plugin that was added is fixed until the user > >> explicitly > > >> removes and re-adds it. Is 'cordova plugin save' & 'restore' > suggesting a > > >> new version management model? E.g. if I add a plugin without a > >> specific > > >> version suffix and 'restore' it later, I may not get the same > >> version, > > >> right? > > >> > > >> If there is a 'spec', I should be able to answer these questions myself. > > >> > > >> Thanks, > > >> Leo Treggiari > > >
