Yeah I guess what I'm getting at is it is more of an app descriptor. It describes things about the app that are immutable across the native underlying projects used to build the app, different IDEs, or project structures. If there was a way to import and export Cordova apps across any number of IDEs or products and services (PhoneGap Build, WorkLight, Intel, Telerik, etc) there are a set of things about the app that wouldn't change. A transformed version of config.xml lands in underlying native projects in the platforms folder as well.
Another example, lets say that Gulp becomes the build system instead of the CLI (not saying that will happen - just jumping to an extreme). We need a place to keep the things that would not change. Speaking for VS, I would never put typescript compilation settings, build configs, and other IDE settings that pertain to the app project in config.xml. That's specific to the VS world and belongs in the VS project. Similarly I would not force a project structure on another IDE let alone someone hand editing config.xml in sublime text. Most likely will not change from the CLI structure anyway. Now, how that is presented to the developer is a completely different story. Whether config.xml is the right long term place for what I describe is another topic entirely. It's pretty engrained. I do think it will be important to easily separate the concepts, however. On the other questions - hop on that thread. I didn't make the PR so I can only speak to the code verses the exact intent. :) The issue is that there is no single definitive list of plugins or platforms to install today (plugins pull in dependencies for specific platforms so the contents of the plugins folder is actually not the definitive list). That's what it was trying to fix. ________________________________ From: Treggiari, Leo<mailto:leo.treggi...@intel.com> Sent: 8/13/2014 6:48 PM To: Chuck Lantz<mailto:cla...@microsoft.com>; dev@cordova.apache.org<mailto:dev@cordova.apache.org> Cc: Treggiari, Leo<mailto:leo.treggi...@intel.com> Subject: RE: cordova plugin save Hi Chuck, Thanks for adding the other 'app metadata file' (like AndroidManifest.xml or package.appxmanifest.xml.) to the conversation. It's important to consider that as well. Those are somewhat different because they contain information that is not built into the app executable, but rather handled by an installer or loader. Does that make those settings somehow different to the app developer? I'm not sure. But I'm sure you're right that items in the existing set of metadata files affect all of the app executable, the accompanying app 'manifest' file, and the accompanying cordova.js file. To start, I'm not sure that it makes sense to add any new metadata to the app config.xml file. I'm not sure that, because of its history, it fits cleanly into any metadata category we might want to define. Maybe a new file is needed. Others than I are better suited to judge that since I don't have the Cordova history. However, I don't agree with some of the categorizations you've made. I don't see why the list of plugins your app uses is a different kind of metadata than the directories where you would find portable sources, plugins, merge sources, etc. Both are required to fully define how to build the app based upon a set of sources pulled from a repository. Thinking in terms of a Visual Studio example, wouldn't both be defined in a single project file? More files just leads to more things to maintain and accidentally overlook. > 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".) So is that the primary use case for the new commands? I didn't realize that from the discussion I had read, but now I understand. I thought it was specifically recommended to not put the platforms folder under source code control. So, the savings could come with the plugins folder. There are, at least, a couple of issues/questions with this that have already been mentioned (just adding them here to keep them in one place...): - Where does 'save' find the definitive list of plugins that it should save? There may be some plugins specified in config.xml and there are other metadata (<platform>.json) files that believe they know the list. - What does it save and where? Does it save the argument that was passed to 'corodva platform add xxx'? Does it save the id, (and possibly additional information) from the sources that were actually fetched? - Can 'restore' be guaranteed to fetch the same exact sources that were in the project that was 'save'd? Does it need to? Thanks, Leo -----Original Message----- From: Chuck Lantz [mailto:cla...@microsoft.com] Sent: Wednesday, August 13, 2014 3:58 PM To: dev@cordova.apache.org; Treggiari, Leo Subject: RE: cordova plugin save 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 > > >
