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? 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. - "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. 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? Is .cordova/config.json intended to be the "Workspace" metadata file? > - 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? Thanks, 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<mailto: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
