RE: [DISCUSS] Tools Release
Hi Steven, CB-9589: - CB-9589 added more warnings and added conversion step to fetch.js - CB-9589 auto convert old plugin ids to new npm ids seems like an important change for users to understand. I.e. what exactly will happen when a user adds a plugin using an 'old', reverse domain name plugin id. This is one way it could work, but it is likely wrong. Would you fix it to be correct and add to the release notes and/or release blog? The are two subcases: - The id is not in the map: - We try to fetch the plugin from cordova.io (including any version specifier) - If that fails, we try to fetch the plugin from NPM (including any version specifier) - The id is in the map: - We try to fetch the plugin from cordova.io (including any version specifier) - If that fails, we convert the id and then try to fetch the plugin from NPM (including any version specifier) Thanks, Leo -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Friday, October 30, 2015 5:33 PM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Tools Release Updated release notes: Lib@5.4.0: https://github.com/apache/cordova-lib/blob/master/cordova-lib/RELEASENOTES.md CLI@5.4.0: https://github.com/apache/cordova-cli/blob/master/RELEASENOTES.md Plugman@1.0.5: https://github.com/apache/cordova-plugman/blob/master/RELEASENOTES.md JS@4.1.2: https://github.com/apache/cordova-js/blob/master/RELEASENOTES.md I'll send out draft of the blog once it is ready. On Fri, Oct 30, 2015 at 8:58 AM, Nikhil Khandelwal wrote: > Great. Good quick fix. Let's get this out soon. Node.js 5.0 just got > released and it uses npm@3+ by default. Currently, cordova create fails > with npm@3. Let's release soon to address that. > > -Nikhil > > -Original Message- > From: Shazron [mailto:shaz...@gmail.com] > Sent: Thursday, October 29, 2015 1:52 PM > To: dev@cordova.apache.org > Subject: Re: [DISCUSS] Tools Release > > Breakage: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-9902&data=01%7c01%7cnikhilkh%40microsoft.com%7cb3fabc4510a84924082708d2e0a2f56d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=l5roCBV0kQT%2b%2fylFBwBrd5I9IhnpfVcvIRjSss0KaQ0%3d > Sent a PR: > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fapache%2fcordova-lib%2fpull%2f335&data=01%7c01%7cnikhilkh%40microsoft.com%7cb3fabc4510a84924082708d2e0a2f56d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=6n3jtKymyZyqnu7WGJDyZD2phxtNuHFwsVokZ5d94l4%3d > > On Thu, Oct 29, 2015 at 12:46 PM, Carlos Santana > wrote: > > Thanks Alex and Tim ! > > > > - Carlos > > @csantanapr > > > >> On Oct 29, 2015, at 2:50 PM, Tim Barham > wrote: > >> > >> There was still a problem with the tests in cordova-lib. Alex's fix has > just been merged and tests are now green. > >> > >> -Original Message- > >> From: Carlos Santana [mailto:csantan...@gmail.com] > >> Sent: Wednesday, October 28, 2015 7:49 PM > >> To: dev@cordova.apache.org > >> Subject: Re: [DISCUSS] Tools Release > >> > >> What's the latest status on this? cordova-android master being fixed to > make it green again? > >> > >>> On Wed, Oct 28, 2015 at 7:28 AM Vladimir Kotikov (Akvelon) < > v-vlk...@microsoft.com> wrote: > >>> > >>> This is fixed in > >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgit > >>> hu > >>> b.com%2fapache%2fcordova-android%2fcommit%2f78fa7374d97ad9ed85c5c857 > >>> a7 > >>> 7a8f3830d600f9.&data=01%7c01%7cTBARHAM%40064d.mgd.microsoft.com%7c4f > >>> 38 > >>> f6ba36884c66bc2b08d2e00b8584%7c72f988bf86f141af91ab2d7cd011db47%7c1& > >>> sd ata=K7eLyX5rvUBrS1NAp7rpMyXX9aAIOMYvNe6rv4JmfJ4%3d > >>> However tests are still failing locally, but this seems to be a > >>> problem with tests, not LIB/Android. Alex Sorokin is looking into this. > >>> > >>> - > >>> Best regards, Vladimir > >>> > >>> -Original Message- > >>> From: Tim Barham [mailto:tim.bar...@microsoft.com] > >>> Sent: Tuesday, October 27, 2015 8:36 PM > >>> To: dev@cordova.apache.org > >>> Subject: RE: [DISCUSS] Tools Release > >>> > >>> This appears to be a cordova-android issue (I followed the steps in > >>> that test and filed > >>> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-9880&data=01%7c01%7cv-vlkoti%40064d.mgd.microsoft.com%7c0244e3527d6b45a4881308d2def52abb%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3fDroGSY1qWwUtl6JusJiD6JgJR6wJw8iITxXGovBdU%3d > ). > >>> Although I agree we should fix the cordova-android issue and get > >>> cordova-lib green before proceeding. > >>> > >>> -Original Message- > >>> From: Steven Gill [mailto:stevengil...@gmail.com] > >>> Sent: Tuesday, October 27, 2015 10:33 AM > >>> To: dev@cordova.apache.org > >>> Subject: Re: [DISCUSS] Tools Release > >>> > >>> Held up currently with > >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fiss > >>> ue > >>> s.apache.org%2fjira%2fbrowse%2fCB-9872
RE: [iOS] proposed major whitelist change
I'm not completely certain of how the whitelist plugin is supposed to work after this discussion. To get the legacy whitelist plugin out of the way, if there are no entries, then the network web access is blocked, right? Which is why the pre-5.0 default 'HelloCordova' app added That maintains compatibility with the 4.x whitelist support. On to the new whitelist plugin, what I was suggesting and what I believe Shazron agreed with is that if there are no entries, then network requests are wide open and security is handled via CSP. Ian answered that this is the same for Android, which would be good! What concerns me is that the documentation says this: "Without anytags, only requests to file:// URLs are allowed. However, the default Cordova application includesby default." and 'HelloCordova' indeed has that line. So, is the whitelist plugin network request list "*" with no entries, or "*" because of the entry added to the default project? Thanks, Leo -Original Message- From: Carlos Santana [mailto:csantan...@gmail.com] Sent: Wednesday, July 22, 2015 3:37 PM To: dev@cordova.apache.org Subject: Re: [iOS] proposed major whitelist change +1 CSP wins, otherwise we give false sense of security if not done consistently On Mon, Jul 20, 2015 at 9:32 PM Ian Clelland wrote: > +1 to CSP as the "right way to do it". > > This all sounds very similar to what we ended up doing with the Android > whitelist plugins: Default is (ugh) *, and the strong recommendation is to > use CSP to actually filter requests from the WebView. > > On Mon, Jul 20, 2015 at 7:24 PM, Shazron wrote: > > > Ah I forgot about the legacy whitelist plugin -- we can't remove the > > whitelist totally then, but as you said "default > > the new whitelist plugin to a 'wildcard' network request list until the > > user adds any entries". > > > > That will preserve backwards compat. > > > > On Mon, Jul 20, 2015 at 4:18 PM, Treggiari, Leo > > > wrote: > > > > > I assume this is for the new whitelist plugin as opposed to the legacy > > > whitelist plugin which will continue to use the current tags. > > > > > > Another alternative, but not necessarily better, would be to default > > > the new whitelist plugin to a 'wildcard' network request list until the > > > user adds any entries. When they add an entry the default wildcard > > > entry is replaced. > > > > > > Leo > > > > > > -Original Message- > > > From: Shazron [mailto:shaz...@gmail.com] > > > Sent: Monday, July 20, 2015 3:45 PM > > > To: dev@cordova.apache.org > > > Subject: Re: [iOS] proposed major whitelist change > > > > > > 1. "If a user is using CSP can we tell them to specify a single '*' > entry > > > for the network request whitelist (a.k.a. tags)?" > > > We could. But comes back to my point, why recommend *two* ways, it's > just > > > confusing -- especially if we recommend CSP and require an > > > wildcard. What I'm proposing is a permanent, unchangeable access > wildcard > > > effectively. > > > > > > 2. "If they are not using CSP, in spite of our recommendation, do the > > > tags provide an alternative, though inferior solution?" > > > Yes, is definitely inferior. > > > > > > > > > On Mon, Jul 20, 2015 at 3:36 PM, Treggiari, Leo < > leo.treggi...@intel.com > > > > > > wrote: > > > > > > > I'm not certain that this makes sense, but anyway... > > > > > > > > If a user is using CSP can we tell them to specify a single '*' entry > > for > > > > the network request whitelist (a.k.a. tags)? > > > > If they are not using CSP, in spite of our recommendation, do the > > > > tags provide an alternative, though inferior solution? > > > > > > > > And, is this different for the Android platform which already > supports > > > the > > > > new whitelist plugin? > > > > > > > > Thanks, > > > > Leo > > > > > > > > -Original Message- > > > > From: Shazron [mailto:shaz...@gmail.com] > > > > Sent: Monday, July 20, 2015 3:24 PM > > > > To: dev@cordova.apache.org > > > > Subject: [iOS] proposed major whitelist change > > > > > > > > https://github.com/apache/cordova-plugin-whitelist > > > > > > > > Previously, the initial imple
RE: [iOS] proposed major whitelist change
I assume this is for the new whitelist plugin as opposed to the legacy whitelist plugin which will continue to use the current tags. Another alternative, but not necessarily better, would be to default the new whitelist plugin to a 'wildcard' network request list until the user adds any entries. When they add an entry the default wildcard entry is replaced. Leo -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, July 20, 2015 3:45 PM To: dev@cordova.apache.org Subject: Re: [iOS] proposed major whitelist change 1. "If a user is using CSP can we tell them to specify a single '*' entry for the network request whitelist (a.k.a. tags)?" We could. But comes back to my point, why recommend *two* ways, it's just confusing -- especially if we recommend CSP and require an wildcard. What I'm proposing is a permanent, unchangeable access wildcard effectively. 2. "If they are not using CSP, in spite of our recommendation, do the tags provide an alternative, though inferior solution?" Yes, is definitely inferior. On Mon, Jul 20, 2015 at 3:36 PM, Treggiari, Leo wrote: > I'm not certain that this makes sense, but anyway... > > If a user is using CSP can we tell them to specify a single '*' entry for > the network request whitelist (a.k.a. tags)? > If they are not using CSP, in spite of our recommendation, do the > tags provide an alternative, though inferior solution? > > And, is this different for the Android platform which already supports the > new whitelist plugin? > > Thanks, > Leo > > -Original Message- > From: Shazron [mailto:shaz...@gmail.com] > Sent: Monday, July 20, 2015 3:24 PM > To: dev@cordova.apache.org > Subject: [iOS] proposed major whitelist change > > https://github.com/apache/cordova-plugin-whitelist > > Previously, the initial implementation for the plugin for iOS didn't > support the tag, but that proved problematic since not supporting > it meant all *native* code network connections were effectively > blacklisted. > > I added the support back in, but this will end up confusing the user even > more. Right now we are recommending that the user support CSP, but that > only works in the context of the WebView (whether UIWebView or WKWebView) - > ie xhr, images, etc. > > If the user specified a CSP src for access to a domain in their .html, but > did not specify an tag for that domain, the connection will fail > (since the native code whitelist filters all network connections). So this > in effect doubles the number of declarations needed -- a CSP policy needs > to have its mirror in the tag. You can see where this can get > confusing. > > We could have a dynamic CSP parser in native code to dynamically "generate" > access tags but that will add on more complexity (but this would be best > workaround). > > I propose that we get rid of the native code whitelist (effectively > allowing all connections) and rely on CSP only. I'm not sure that having a > native code whitelist can really be truly secure, with the dynamic nature > of Objective-C this is just a façade anyway. > > In any case, native code whitelisting will only work on UIWebView, there is > no way our current whitelisting system will work on WKWebView at all -- > more fodder for us to abandon our whitelisting system. > > The whitelisting should really be handled lower level by the system, and > indeed this is coming in iOS 9 with Application Transport Security (ATS): > > https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/index.html#//apple_ref/doc/uid/TP40016240 > > The ATS whitelisting is through new tags in Info.plist, and we will have to > map our existing whitelist tags to ATS when the time comes. >
RE: [iOS] proposed major whitelist change
I'm not certain that this makes sense, but anyway... If a user is using CSP can we tell them to specify a single '*' entry for the network request whitelist (a.k.a. tags)? If they are not using CSP, in spite of our recommendation, do the tags provide an alternative, though inferior solution? And, is this different for the Android platform which already supports the new whitelist plugin? Thanks, Leo -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, July 20, 2015 3:24 PM To: dev@cordova.apache.org Subject: [iOS] proposed major whitelist change https://github.com/apache/cordova-plugin-whitelist Previously, the initial implementation for the plugin for iOS didn't support the tag, but that proved problematic since not supporting it meant all *native* code network connections were effectively blacklisted. I added the support back in, but this will end up confusing the user even more. Right now we are recommending that the user support CSP, but that only works in the context of the WebView (whether UIWebView or WKWebView) - ie xhr, images, etc. If the user specified a CSP src for access to a domain in their .html, but did not specify an tag for that domain, the connection will fail (since the native code whitelist filters all network connections). So this in effect doubles the number of declarations needed -- a CSP policy needs to have its mirror in the tag. You can see where this can get confusing. We could have a dynamic CSP parser in native code to dynamically "generate" access tags but that will add on more complexity (but this would be best workaround). I propose that we get rid of the native code whitelist (effectively allowing all connections) and rely on CSP only. I'm not sure that having a native code whitelist can really be truly secure, with the dynamic nature of Objective-C this is just a façade anyway. In any case, native code whitelisting will only work on UIWebView, there is no way our current whitelisting system will work on WKWebView at all -- more fodder for us to abandon our whitelisting system. The whitelisting should really be handled lower level by the system, and indeed this is coming in iOS 9 with Application Transport Security (ATS): https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/index.html#//apple_ref/doc/uid/TP40016240 The ATS whitelisting is through new tags in Info.plist, and we will have to map our existing whitelist tags to ATS when the time comes.
RE: Proposal: Expose check_reqs at the CLI level
platform level > command. This could be a good first phase, and should also give us an > idea about how developers use this command. > > As a part of Phase 2, anyone from the community should be able to > build on a cordova level check reqs, and possibly extend it to > checking reqs when no project is present. > > > -Original Message- > From: Josh Soref [mailto:jso...@blackberry.com] > Sent: Wednesday, April 15, 2015 8:53 AM > To: dev@cordova.apache.org > Subject: RE: Proposal: Expose check_reqs at the CLI level > > We already support: > > `cordova build android` > > There's no need for the extra `platform` verb.. > > But, > `cordova build android --nobuild` isn't any more intuitive than w/ the > extra "platform". > > > And yes, as I noted, and others have noted, we used to run check_reqs > in add, we're not going back to doing that. > > A `cordova doctor` or `cordova requirements` verb seems fine. > > I'm also fine `cordova doctor PLATFORM` instead of `cordova platform > doctor PLATFORM`, > > As for when someone is likely to want to ask "what requirements do I > need for a platform", it's fairly arbitrary. > > Someone who is given a project might know that they don't have the > environment for a platform, they aren't likely to want to go down a > "build" rabbit hole, so, I'm -1 on hiding it anywhere near build. > > It's perfectly reasonable from my perspective for someone to want to > run `cordova requirements PLATFORM` without a project at all. > Imagine someone is getting started, they "install cordova", and know > they want to develop for PLATFORM, they could reasonably want to set > up their requirements for that platform before trying to create a > project... > > I don't know if anyone's check_reqs scripts actually requires a > project, I actually think they don't, so it's probably sufficient to > run them straight from the platform origin instead of from a created project. > > One notable thing: check_reqs isn't a .js file yet, as an API, it's > "check_reqs" (*nix) and "check_reqs" + something from %PATHEXT% > (Windows) > > > -Original Message- > > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of > > Andrew Grieve > > Sent: Wednesday, April 15, 2015 11:00 AM > > To: dev > > Subject: Re: Proposal: Expose check_reqs at the CLI level > > > > We've worked to make iOS add'able from Windows, so I do think it's a > > good idea to *not* run check_reqs from add (we used to but removed it). > > > > We already run it on build, so potentially we already have this command: > > "cordova platform build android --nobuild" > > > > > > > > On Tue, Apr 14, 2015 at 9:51 PM, Treggiari, Leo > > > > wrote: > > > > > My opinions. > > > > > > Q1. Just say that platform is not added, so cannot check requirements. > > > > > > I don't think it is important to support the platform-not-added case. > > > > > > Q2. Should the requirements be checked when a platform is added, > > > or > > when > > > it is built ? > > > > > > 'platform add' should work even when the requirements are not met. > > > If requirements used to be checked on 'platform add', then I > > > suspect they were removed > to > > > support > > > the scenario of using the same Cordova project on multiple host > platforms. > > > E.g. a team with some developers on Windows and some on Mac. As a > user > > of > > > Cordova CLI on Windows, I want it to be OK to have the project I'm > working > > > on have the > > > iOS platform added and I only get errors if I try to do something > > > (build, > > > emulate) > > > which requires the native SDK. > > > > > > Leo > > > > > > -Original Message- > > > From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] > > > Sent: Tuesday, April 14, 2015 6:04 PM > > > To: dev@cordova.apache.org > > > Subject: RE: Proposal: Expose check_reqs at the CLI level > > > > > > I think you raise an interesting point on the behavior of > > > check_reqs for platform that are not yet added. > > > > > > The options, as you mention are > > > > > > Question 1 > > > 1 - Add the platform, run check_reqs script, remove the platform > > >
RE: Android 4.0 Blog Post
Thanks all for the information and suggestions on whitelisting. Very helpful! Leo -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Wednesday, April 15, 2015 11:51 AM To: dev Subject: Re: Android 4.0 Blog Post You can customize the tags per-platform via network" > > if you want to ensure your app only talks to domains you specify then: > > 1. do not include 3rd party scripts (or if you do make sure you trust them > and maybe keep an eye out for document.write!) > 2. use ssl for all your http traffic > 3. only talk to external services through a proxy you run (and auth) > > > > On Wed, Apr 15, 2015 at 1:14 PM, Ian Clelland > wrote: > > > On Wed, Apr 15, 2015 at 1:47 PM, Treggiari, Leo > > > wrote: > > > > > If anyone has the time to educate me, then please pardon my ignorance. > > > > > > Then you're suggesting that if I'm writing a cross-platform app, I > stick > > > with > > > the legacy whitelist plugin until all of the platforms I care about > > support > > > new whitelisting? Or they already do support the new whitelisting? > > > > > > > Most platforms *do not* support the new whitelisting. As of right now, > it's > > Android 4.0.0, and iOS (4.0.x development branch). > > > > If you're building a cross-platform app, there are a couple of options, > but > > they all come down to the fact that you need to use the old syntax for > any > > platforms other than Android. > > > > > > 1. Install the legacy plugin, and use the same syntax for everything > > (easiest) > > > > 2. Install the new whitelist plugin, and have separate config.xml files > for > > each platform. This may or may not be feasible, depending on your build > > system. You'll probably have to swap the config file out between builds > of > > different platforms (I can't remember off-hand if there's any syntax in > > config.xml to have platform-dependent sections, but that would make this > > easier.) > > > > 3. Install the new whitelist plugin, and use *both* syntaxes in > config.xml. > > The new plugin uses tags for network requests, but not for > > navigation, so you'd have to include tags as well, if > > you have more than a single-page-app. You can include both kinds of tags, > > though, and the platforms will happily just pick out the ones they > > understand. > > > > > > > Thanks, > > > Leo > > > > > > -Original Message- > > > From: Joe Bowser [mailto:bows...@gmail.com] > > > Sent: Wednesday, April 15, 2015 10:42 AM > > > To: dev@cordova.apache.org > > > Subject: Re: Android 4.0 Blog Post > > > > > > Isn't this why the Legacy Whitelist plugin exists? > > > > > > On Wed, Apr 15, 2015 at 10:40 AM Treggiari, Leo < > leo.treggi...@intel.com > > > > > > wrote: > > > > > > > I have a question. With the new whitelist support in Android, does > > that > > > > mean if I'm writing a cross-platform app, do I need to deal with > > > > whitelisting differently in Android and other platforms (at least > until > > > the > > > > other platforms 'catch up')? If not, thanks. If so, what would be > the > > > > best way to handle the differences - perhaps using the merges > > > functionality? > > > > > > > > Thanks, > > > > Leo > > > > > > > > -Original Message- > > > > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of > > Andrew > > > > Grieve > > > > Sent: Wednesday, April 15, 2015 10:18 AM > > > > To: dev > > > > Subject: Android 4.0 Blog Post > > > > > > > > The 4.0 release is posted to npm, and I've updated the blog post to > > work > > > > without the need for a tools release: > > > > > > > > I'd like to publish the blog post without waiting for a CLI release: > > > > - I've updated the post to use plugins-from-git so it works without > new > > > CLI > > > > - I've mentioned those can just wait for tools if they like > > > > - This should give us some early adopter feedback in case there's a > > need > > > > for a 4.0.1 > > > > > > > > > > > > > > > > > > https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md > > > > > > > > Any objections? > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > >
RE: Android 4.0 Blog Post
If anyone has the time to educate me, then please pardon my ignorance. Then you're suggesting that if I'm writing a cross-platform app, I stick with the legacy whitelist plugin until all of the platforms I care about support new whitelisting? Or they already do support the new whitelisting? Thanks, Leo -Original Message- From: Joe Bowser [mailto:bows...@gmail.com] Sent: Wednesday, April 15, 2015 10:42 AM To: dev@cordova.apache.org Subject: Re: Android 4.0 Blog Post Isn't this why the Legacy Whitelist plugin exists? On Wed, Apr 15, 2015 at 10:40 AM Treggiari, Leo wrote: > I have a question. With the new whitelist support in Android, does that > mean if I'm writing a cross-platform app, do I need to deal with > whitelisting differently in Android and other platforms (at least until the > other platforms 'catch up')? If not, thanks. If so, what would be the > best way to handle the differences - perhaps using the merges functionality? > > Thanks, > Leo > > -Original Message- > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew > Grieve > Sent: Wednesday, April 15, 2015 10:18 AM > To: dev > Subject: Android 4.0 Blog Post > > The 4.0 release is posted to npm, and I've updated the blog post to work > without the need for a tools release: > > I'd like to publish the blog post without waiting for a CLI release: > - I've updated the post to use plugins-from-git so it works without new CLI > - I've mentioned those can just wait for tools if they like > - This should give us some early adopter feedback in case there's a need > for a 4.0.1 > > > https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md > > Any objections? > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org >
RE: Android 4.0 Blog Post
I have a question. With the new whitelist support in Android, does that mean if I'm writing a cross-platform app, do I need to deal with whitelisting differently in Android and other platforms (at least until the other platforms 'catch up')? If not, thanks. If so, what would be the best way to handle the differences - perhaps using the merges functionality? Thanks, Leo -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Wednesday, April 15, 2015 10:18 AM To: dev Subject: Android 4.0 Blog Post The 4.0 release is posted to npm, and I've updated the blog post to work without the need for a tools release: I'd like to publish the blog post without waiting for a CLI release: - I've updated the post to use plugins-from-git so it works without new CLI - I've mentioned those can just wait for tools if they like - This should give us some early adopter feedback in case there's a need for a 4.0.1 https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md Any objections? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Proposal: Expose check_reqs at the CLI level
My opinions.
Q1. Just say that platform is not added, so cannot check requirements.
I don't think it is important to support the platform-not-added case.
Q2. Should the requirements be checked when a platform is added, or when it is
built ?
'platform add' should work even when the requirements are not met. If
requirements
used to be checked on 'platform add', then I suspect they were removed to
support
the scenario of using the same Cordova project on multiple host platforms.
E.g. a team with some developers on Windows and some on Mac. As a user of
Cordova CLI on Windows, I want it to be OK to have the project I'm working on
have the
iOS platform added and I only get errors if I try to do something (build,
emulate)
which requires the native SDK.
Leo
-Original Message-
From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
Sent: Tuesday, April 14, 2015 6:04 PM
To: dev@cordova.apache.org
Subject: RE: Proposal: Expose check_reqs at the CLI level
I think you raise an interesting point on the behavior of check_reqs for
platform that are not yet added.
The options, as you mention are
Question 1
1 - Add the platform, run check_reqs script, remove the platform and report
results.
1.5 - Just download the check_reqs script (or use it from the cached platform
directory) without adding the platform, and run that.
2 - Just say that platform is not added, so cannot check requirements.
Question 2: It also comes to the case of - when would a user want to run the
requirement check
- before starting a cordova project ?
- before adding a platform ?
- should the requirements be checked when a platform is added, or when it is
built ?
The answer to the above questions will help us understand if a top level
req_check is required or not. We should also look at what check_reqs do today -
the do not tell you ALL the missing pieces for building an SDK.
It would be good to hear what the others in the community think about these
answers.
-Original Message-
From: Josh Soref [mailto:jso...@blackberry.com]
Sent: Tuesday, April 14, 2015 9:55 AM
To: dev@cordova.apache.org
Subject: RE: Proposal: Expose check_reqs at the CLI level
Fwiw, for the case of a platform that isn't in a project yet, I'd envision:
`cordova platform doctor not-yet-installed`
to do effectively:
```sh
(
PLATFORM=not-yet-installed
(cordova platform add $PLATFORM 2>&1) > /dev/null &&
cordova platform doctor $PLATFORM;
(cordova platform remove $PLATFORM 2>&1)
)
```
i.e. add the platform (or create a temporary project, and add the platform
to the temporary project), and then run platform doctor, and then remove the
platform (and if it was in a temporary project, delete the temporary
project...).
I don't really want to expos a 'check_reqs' verb via CLI.
If we really really want to, we could have `cordova platform requirements
[PLATFORM...]` as a verb, that's ok.
If someone wants to call `check_reqs` directly, they're welcome to do so,
but it's an incredibly ugly thing and doesn't belong in a public facing
interface.
> -Original Message-
> From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
> Sent: Tuesday, April 14, 2015 10:19 AM
> To: dev@cordova.apache.org
> Subject: Re: Proposal: Expose check_reqs at the CLI level
>
> Carlos, you are right, check_reqs should be in the platform repo, CLI will
> just proxy the call to the platforms.
>
> On 4/13/15, 10:29 PM, "Carlos Santana" wrote:
>
> >+1 if check_reqs are kept in the platform repos, currently check_reqs is
a
> >platform concerned
> >if it's available from CLI it will be just a proxy to the platform
> >check_reqs.
> >
> >if don't keep it in the platform repo, and add this logic to cli repo, we
> >will need to maintained a list of reqs for each platform, for each
version
> >of each platform.
> >
> >This is the reason why it was removed from cli and just is present in the
> >platform repo/code
> >
> >
> >
> >On Mon, Apr 13, 2015 at 5:13 PM, Josh Soref
> wrote:
> >
> >> I'm +1 for `cordova doctor` and `cordova platform doctor
> >>{platformname}`.
> >>
> >> The former should apply to all current platforms, the latter should
> >>support
> >> doctoring for available but not added platforms -- if said platform
were
> >> specified.
> >> And we should note in the documentation or `cordova doctor` that it may
> >>do
> >> other checks -- e.g. linting the config.xml, warning about CSP,
possibly
> >> mentioning when a plugin is out of date -- just to indicate to people
> >>that
> >> the behavior may evolve.
> >>
> >> Not that this is more or less fixing a regression that we introduced
> >>when
> >> we
> >> made `cordova platform add` not call check_reqs.
> >>
> >> > -Original Message-
> >> > From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com]
> >> > Sent: Monday, April 13, 2015 2:53 PM
> >> > To: dev@cordova.apache.org
> >> > Subject: Proposal: Expose check_reqs at the CLI level
> >> >
> >> > Hi,
> >> >
> >>
RE: Proposal: Expose check_reqs at the CLI level
+1 It sounds like a very good thing to do. Leo -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Monday, April 13, 2015 12:24 PM To: dev@cordova.apache.org Subject: Re: Proposal: Expose check_reqs at the CLI level Everyone's +1's count! It's the -1's that may be scrutinized @purplecabbage risingj.com On Mon, Apr 13, 2015 at 12:11 PM, Dmitry Blotsky wrote: > +1 for me too, even though my +1 points don't matter :) > > I've actually run into this issue when writing documentation for setting > up slaves for medic. My short documentation is here: > https://github.com/apache/cordova-medic/blob/master/SLAVES.md, but it is > best for it to refer to the official Cordova docs instead. > > Should we make a JIRA task for better docs and automated platform > dependency detection? > > Kindly, > Dmitry > > -Original Message- > From: Shazron [mailto:shaz...@gmail.com] > Sent: Monday, April 13, 2015 11:56 AM > To: dev@cordova.apache.org > Subject: Re: Proposal: Expose check_reqs at the CLI level > > +1 > This will be great for users > > On Mon, Apr 13, 2015 at 11:53 AM, Parashuram N (MS OPEN TECH) < > panar...@microsoft.com> wrote: > > Hi, > > > > One of the main problems a lot of developers seem to have is the issue > to setting up their machines for building various platforms. This came out > from the Stack overflow survey, and the number of questions on stack > overflow, twitter. Etc. > > > > I thought it would be helpful to have a check_reqs command exposed at > > the CLI level. This is similar to `brew doctor` or `appium doctor`. > > The idea is > > > > > > 1. Have a way for the user to see if they have all dependencies > (like JAVA_HOME or ANDROID_HOME) set up? This happens at build time, but > moving it out to a CLI level command where you can run cordova check_reqs > (or something similar) would be useful to the users. > > > > 2. Today, the build command shows one error at a time. The > check_reqs could run all the checks, and show a summary of the issues so > that the user can fix them all, instead of fixing one, running build, > fixing again, etc. > > > > What does the community think of this idea ? Can we implement a > prototype and see if this is useful to our developers ? > > Note that this does not change or break existing functionality - it just > exposes the already existing check_reqs in the CLI. Build will continue to > call check_reqs. > > > > Please vote on this proposal, or raise any concerns you may have. > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
RE: Discussions on vote threads
I'll tell you why I didn't raise my question until now. Sorry it was on the vote thread, but it was the first time that I was able to see the information that I needed to understand exactly (at least better) what was going to happen with whitelisting. Actually, the title of the message (that is was a vote thread) never made it to my forefront consciousness. This is a process suggestion and I hope you take it in the spirit of trying to make the process better and the project releases better. Maybe *my* problem is exactly just that and no one else is having the same problem. I have a hard time figuring out to any level of detail what is being changed/added in any release. Sometimes there are written proposals that go into some level of detail. Then there are e-mail discussions and/or comments made to a document. But not often do I see the original proposal updated with final decisions before a release occurs. So how many people know what is actually happening in a release at more than the level that, e.g., whitelisting is changing and there are some new plugins. If I wrote the code I'd know. If I reviewed the code, I’d probably know. If I tried to piece together the likely changes by following all discussions and comments, I might know. I did not write or review the code and I try at keeping up with the discussions but it still leaves me with questions. Even after a release, I often find it difficult to find a description (spec or documentation) about exactly how something is supposed to work. So here is a rough suggestion about how I think things could improve. I'm just a downstream consumer and so I don't expect my opinions to carry much weight compared to you who have created and maintained Cordova over years. Imagine there was a complete spec to the visible functionality in Cordova, including plugins, CLI commands, configuration files, etc. Certainly a lot exists but I have found myself in the situation where I can find no documentation about some option or some 'corner case'. If you think the project already has this, great - step 1 is done. When a proposal is made to change the visible functionality, the differences to the existing spec are documented in a proposal spec and then reviewed by this mailing list. Discussions take place like they do today, but at some point the proposer decides the discussions have died down and then updates the proposal spec. Maybe there is some further discussion based upon the update or not. However, with the update(s) to the proposal spec everyone should be able to understand what is expected when the proposed functionality is released and should raise any issues or questions before vote time comes. With the release, the information in the proposal spec can be merged into the complete public spec. So that's my excuse regarding why my questions and issues are often "last minute". Other than of course, "my cat ate my e-mail!" Leo -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Thursday, April 09, 2015 1:01 PM To: dev Subject: Re: Discussions on vote threads That's a good point. Perhaps we should update our template to say "minium or 48 hours, and at least 24 hours after the last non-vote comment" On Thu, Apr 9, 2015 at 3:58 PM, Joe Bowser wrote: > There's nothing wrong with the practice except that a vote thread with > comments means that we probably shouldn't proceed and should discuss it > more. Too much discussion on vote thread means we don't have any sort of > consensus and should work that out first. > > On Thu, Apr 9, 2015, 12:52 PM Andrew Grieve wrote: > > > Have become very common for us. Probably because the release VOTE is the > > thing that actually gets people motivated to take a good look. > > > > Thought it'd be good for us to discuss this practice. > > > > My thoughts: > > - I think it still makes sense to DISCUSS before starting a release > > - I think it's perfectly reasonable to go through several RCs as things > > come up during testing (RCs are easy) > > - I think it helps to have the blog post ready before a vote (I made this > > change to the platforms release process this time around) > > - I don't have any problem with VOTE threads that are full of discussion. > > What's the concern? > > >
RE: [DISCUSS] Cordova-Android 4.0.0 Release
You may have seen this before (deja-vu). If this is not the correct place for this, sorry that my focus is not on following a strict release process but rather releasing a good product. Having read the proposed whitelist release notes, I have the following additional question: Based upon my understanding, which must be wrong! The 4.0.0 Android Release will require the cordova-plugin-whitelist in order to get a whitelist implemented correctly. Given its name (dash-style) it is only available as an node component. The is no released CLI that knows how to fetch from npm? Or does 4.3, even though I don't see it in the release notes? Even so, there are many previous CLI releases which will not work? It would be good for the release notes to explain the situation. Leo -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Wednesday, April 08, 2015 7:08 PM To: Andrew Grieve Cc: dev; Homer, Tony Subject: Re: [DISCUSS] Cordova-Android 4.0.0 Release CB-8684 is now merged and I've updated the targetSdk (and made a couple other changes). I'll start the release process in the morning as long as there no objections. On Tue, Apr 7, 2015 at 2:20 PM, Andrew Grieve wrote: > I'll start on it once CB-8684 lands (Tony - assuming you'll have this done > shortly and would prefer it lands?) > > On Tue, Apr 7, 2015 at 1:33 PM, Jesse wrote: > >> Sweet! >> >> @purplecabbage >> risingj.com >> >> On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve >> wrote: >> >> > Let's do it! >> > >> > On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser wrote: >> > >> > > So, I think we should put off the embedder's guide until after the >> > > release. A lot of it has changed, and since we're still technically >> > > obligated to support the 3.x release tree for six months, that should >> buy >> > > us some time to figure out how that is going to work. Getting >> Cordova to >> > > work with a vanilla Android Studio project is a non-trivial task. >> > > >> > > Given that everything else appears to be done, should we start voting >> on >> > an >> > > RC for this? What do people think? >> > > >> > > >> > > >> > > On Thu, Mar 19, 2015 at 10:31 AM Andrew Grieve >> > > wrote: >> > > >> > > > Here's issues: >> > > > https://issues.apache.org/jira/browse/CB-8715 (docs) >> > > > https://issues.apache.org/jira/browse/CB-8716 (whitelist) >> > > > https://issues.apache.org/jira/browse/CB-8717 (write >> RELEASENOTES.md) >> > > > >> > > > On Tue, Mar 17, 2015 at 10:15 AM, Carlos Santana < >> csantan...@gmail.com >> > > >> > > > wrote: >> > > > >> > > > > I would say let's start RC testing and voting, But not pin the >> > version >> > > in >> > > > > Cordova CLI until the tasks that Andrew mentioned are done. >> > > > > Andrew can you create the JIRA Items for the tasks that need to be >> > > done. >> > > > I >> > > > > thought there was a discussion about creating JIRA Items to help >> > track >> > > > and >> > > > > know what's left for release something. >> > > > > >> > > > > - upgrade guide, >> > > > > - publishing whitelist plugins, >> > > > > - and making it so that the default project template includes >> > > > > > name="cordova-plugin-whitelist" />) >> > > > > >> > > > > >> > > > > On Mon, Mar 16, 2015 at 11:21 PM, Ian Clelland < >> > iclell...@chromium.org >> > > > >> > > > > wrote: >> > > > > >> > > > > > We'll probably need at least an RC for the whitelist plugin, if >> > not a >> > > > > vote, >> > > > > > to be able to vote on this. >> > > > > > >> > > > > > Or can we just include instructions like "Use >> > > > > > cordova-plugin-whitelist@f70b1bc for testing" while we start >> the >> > > > > official >> > > > > > release process for the plugins? >> > > > > > >> > > > > > On Mon, Mar 16, 2015 at 11:17 PM, Ian Clelland < >> > > iclell...@chromium.org >> > > > > >> > > > > > wrote: >> > > > > > >> > > > > > > +1 -- Let's get this out the door :) >> > > > > > > I'll see what I can get done to move it in that direction. >> > > > > > > >> > > > > > > On Mon, Mar 16, 2015 at 7:51 PM, Andrew Grieve < >> > > agri...@chromium.org >> > > > > >> > > > > > > wrote: >> > > > > > > >> > > > > > >> Everything's ready afaik (minus upgrade guide, publishing >> > > whitelist >> > > > > > >> plugins, and making it so that the default project template >> > > includes >> > > > > > >> ). Maybe let's do >> a RC >> > > > while >> > > > > > we >> > > > > > >> wait on these things being finished up? >> > > > > > >> >> > > > > > >> If anyone wants to take on any of these tasks, that would be >> > > > awesome. >> > > > > > >> >> > > > > > >> On Mon, Mar 16, 2015 at 4:57 PM, Shazron >> > > wrote: >> > > > > > >> >> > > > > > >> > +1 for vote thread, let's get this thing out so people >> (that >> > are >> > > > not >> > > > > > >> > us) can test... >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > On Mon, Mar 16, 2015 at 1:41 PM, Joe Bowser < >> > bows...@gmail.com> >> > > > > > wrote: >> > > > > > >> >
RE: [Vote] 4.0.0 Android Release
Did the DISCUSS thread have a pointer to the release notes about whitelist support? Sorry that I missed that. Leo -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Thursday, April 09, 2015 11:00 AM To: dev@cordova.apache.org Subject: Re: [Vote] 4.0.0 Android Release Why is this on the Vote thread? please take it to the Discuss thread. On Thursday, April 9, 2015, Treggiari, Leo wrote: > Another question, based upon my understanding, which must be wrong! > > The 4.0.0 Android Release will require the cordova-plugin-whitelist in > order > to get a whitelist implemented correctly. > > Given its name (dash-style) it is only available as an node component. > > The is no released CLI that knows how to fetch from npm? > Or does 4.3, even though I don't see it in the release notes? > Even so, there are many previous CLI releases which will not work? > > It would be good for the release notes to explain the situation. > > Leo > > -Original Message- > From: Treggiari, Leo [mailto:leo.treggi...@intel.com ] > Sent: Thursday, April 09, 2015 10:27 AM > To: dev@cordova.apache.org > Subject: RE: [Vote] 4.0.0 Android Release > > Do the whitelist changes mean that current access origin entries in a > config.xml file will be ignored the next time that a developer builds > their project? If so, that will certainly surprise some developers. > > Or does this just impact newly created projects? > > Thanks, > Leo > > -Original Message- > From: mmo...@google.com [mailto:mmo...@google.com > ] On Behalf Of Michal Mocny > Sent: Thursday, April 09, 2015 9:54 AM > To: dev > Subject: Re: [Vote] 4.0.0 Android Release > > PR for Blogpost changes, hopefully making it a bit more obvious what the > whitelist changes are: > https://github.com/cordova/apache-blog-posts/pull/35 > > Possibly we want to link to a more in-depth guide and remove some of my > notes (i.e. specifically what needs adding, which config.xml should look > like). > > Question: some of the plugin links are to github, some to npm. Should we > document how to add these plugins using the new npm plugin name format? > > On Thu, Apr 9, 2015 at 12:15 PM, Andrew Grieve > wrote: > > > Please review and vote on this 4.0.0 Android Release. > > > > Release issue: https://issues.apache.org/jira/browse/CB-8833 > > > > Repos ready to be released have been published to dist/dev: > > https://dist.apache.org/repos/dist/dev/cordova/CB-8833 > > > > The package was published from its corresponding git tag: > > cordova-android: 4.0.0 (f224b1f2d4) > > > > Note that you can test it out via: > > > > cordova platform add https://github.com/apache/cordova-android#4.0.0 > > > > Blog post to review is here: > > > > > > > > > https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md > > > > Upon a successful vote I will upload the archive to dist/, publish it to > > NPM, and post the corresponding blog post. > > > > Voting guidelines: > > > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md > > > > Voting will go on for a minimum of 48 hours. > > > > I vote +1: > > * Ran coho audit-license-headers over the relevant repos > > * Ran coho check-license to ensure all dependencies and subdependencies > > have Apache-compatible licenses > > * Ran mobilespec and only expected failures were happening > > * Verified contents of archive > > > B�CB� > � [��X��ܚX�K K[XZ[ > � ]�][��X��ܚX�P �ܙ ݘK�\ X� K�ܙ�B��܈ Y ] [ۘ[ ��[X[� � K[XZ[ > � ]�Z [ �ܙ ݘK�\ X� K�ܙ�B >
RE: [Vote] 4.0.0 Android Release
Another question, based upon my understanding, which must be wrong! The 4.0.0 Android Release will require the cordova-plugin-whitelist in order to get a whitelist implemented correctly. Given its name (dash-style) it is only available as an node component. The is no released CLI that knows how to fetch from npm? Or does 4.3, even though I don't see it in the release notes? Even so, there are many previous CLI releases which will not work? It would be good for the release notes to explain the situation. Leo -Original Message- From: Treggiari, Leo [mailto:leo.treggi...@intel.com] Sent: Thursday, April 09, 2015 10:27 AM To: dev@cordova.apache.org Subject: RE: [Vote] 4.0.0 Android Release Do the whitelist changes mean that current access origin entries in a config.xml file will be ignored the next time that a developer builds their project? If so, that will certainly surprise some developers. Or does this just impact newly created projects? Thanks, Leo -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, April 09, 2015 9:54 AM To: dev Subject: Re: [Vote] 4.0.0 Android Release PR for Blogpost changes, hopefully making it a bit more obvious what the whitelist changes are: https://github.com/cordova/apache-blog-posts/pull/35 Possibly we want to link to a more in-depth guide and remove some of my notes (i.e. specifically what needs adding, which config.xml should look like). Question: some of the plugin links are to github, some to npm. Should we document how to add these plugins using the new npm plugin name format? On Thu, Apr 9, 2015 at 12:15 PM, Andrew Grieve wrote: > Please review and vote on this 4.0.0 Android Release. > > Release issue: https://issues.apache.org/jira/browse/CB-8833 > > Repos ready to be released have been published to dist/dev: > https://dist.apache.org/repos/dist/dev/cordova/CB-8833 > > The package was published from its corresponding git tag: > cordova-android: 4.0.0 (f224b1f2d4) > > Note that you can test it out via: > > cordova platform add https://github.com/apache/cordova-android#4.0.0 > > Blog post to review is here: > > > > https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md > > Upon a successful vote I will upload the archive to dist/, publish it to > NPM, and post the corresponding blog post. > > Voting guidelines: > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md > > Voting will go on for a minimum of 48 hours. > > I vote +1: > * Ran coho audit-license-headers over the relevant repos > * Ran coho check-license to ensure all dependencies and subdependencies > have Apache-compatible licenses > * Ran mobilespec and only expected failures were happening > * Verified contents of archive > B�CB�� [��X��ܚX�KK[XZ[ �]�][��X��ܚX�P�ܙݘK�\X�K�ܙ�B��܈Y][ۘ[��[X[� �K[XZ[ �]�Z[ �ܙݘK�\X�K�ܙ�B
RE: [Vote] 4.0.0 Android Release
Do the whitelist changes mean that current access origin entries in a config.xml file will be ignored the next time that a developer builds their project? If so, that will certainly surprise some developers. Or does this just impact newly created projects? Thanks, Leo -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, April 09, 2015 9:54 AM To: dev Subject: Re: [Vote] 4.0.0 Android Release PR for Blogpost changes, hopefully making it a bit more obvious what the whitelist changes are: https://github.com/cordova/apache-blog-posts/pull/35 Possibly we want to link to a more in-depth guide and remove some of my notes (i.e. specifically what needs adding, which config.xml should look like). Question: some of the plugin links are to github, some to npm. Should we document how to add these plugins using the new npm plugin name format? On Thu, Apr 9, 2015 at 12:15 PM, Andrew Grieve wrote: > Please review and vote on this 4.0.0 Android Release. > > Release issue: https://issues.apache.org/jira/browse/CB-8833 > > Repos ready to be released have been published to dist/dev: > https://dist.apache.org/repos/dist/dev/cordova/CB-8833 > > The package was published from its corresponding git tag: > cordova-android: 4.0.0 (f224b1f2d4) > > Note that you can test it out via: > > cordova platform add https://github.com/apache/cordova-android#4.0.0 > > Blog post to review is here: > > > > https://github.com/cordova/apache-blog-posts/blob/master/2015-04-10-cordova-android-4.0.0.md > > Upon a successful vote I will upload the archive to dist/, publish it to > NPM, and post the corresponding blog post. > > Voting guidelines: > https://github.com/apache/cordova-coho/blob/master/docs/release-voting.md > > Voting will go on for a minimum of 48 hours. > > I vote +1: > * Ran coho audit-license-headers over the relevant repos > * Ran coho check-license to ensure all dependencies and subdependencies > have Apache-compatible licenses > * Ran mobilespec and only expected failures were happening > * Verified contents of archive >
Does Cordova have a problem making developers happy?
The data below is from a StackOverflow Developer Survey (http://stackoverflow.com/research/developer-survey-2015). Most Dreaded technologies: Salesforce 73.2% Visual Basic72.0% Wordpress 68.2% Matlab 65.6% Sharepoint 62.8% LAMP62.2% Perl59.2% Cordova 58.8% ** Coffeescript 54.7% Other57.3% % of devs who are developing with the language or tech but have not expressed interest in continuing to do so. Any ideas on what the problem is? Here are some possible answers. I'm not suggesting that any of these are true, but rather looking for feedback from those who have heard developers express frustration with Cordova: *There is no problem - unclear question led to the answer *The problem is really about creating native apps in JavaScript + HTML5 *Cordova CLI has a quality problem (learnability | usability | reliability) o Too hard to set up development environment o The command CLI is too complicated o Not enough learning material (documentation, articles, books) o Too many bugs o Changes too frequently Leo
RE: Question about plugin/platform --save: src vs version?
> It looks like single attribute is preferred, so instead of trying to find
> a word that can mean "source and version", we should settle on version and
> change it for plugin.
If there are multiple pieces of information 'encoded' in a single attribute,
then I suggest that multiple attributes are better. I'm thinking it's easier
to mash multiple pieces of information back together if necessary, than to
split them, making sure all possible 'special characters' are accounted for.
Being consistent with the plugin saved metadata, as long as the information is
equivalent, would be better.
If you want one name, how about 'origin'.
Leo
-Original Message-
From: Jesse [mailto:purplecabb...@gmail.com]
Sent: Tuesday, March 31, 2015 11:47 AM
To: dev@cordova.apache.org
Subject: Re: Question about plugin/platform --save: src vs version?
Yes, words are hard.
re:
> Jesse - are you suggesting that rather than having a name and a ?version
> attribute, we instead store them in a single attribute, something like
the
> following?
>
Yes, but I had only thought of it in a plugin context.
afaik: these are all the ways we can use 'cordova plugin add'
//1. Install by unique name, registry is used to lookup
cordova plugin add plugin-name
//2. Install by unique name, registry is used to lookup, specific version
cordova plugin add plugin-name@version
//3. Install from local folder
cordova plugin add local-path
//4. Install from a repo
cordova plugin add someURI.git
//5. Install from a repo with a specific branch, tag or commit
cordova plugin add someURI.git#r0.2.0
//6. Install from a repo in a specific subdirectory
cordova plugin add someURI.git#:/my/sub/dir
I have no idea what the right terminology would be to encompass all of this.
Presumably also, if we receive an argument as in #1, we should also store
the version number as if we were called like #2
@purplecabbage
risingj.com
On Tue, Mar 31, 2015 at 10:59 AM, Gorkem Ercan
wrote:
>
>
> On 31 Mar 2015, at 8:44, Tim Barham wrote:
>
> So... I agree that:
>>
>> a) if we don't find it in the specified location, we should fail, and
>> b) storing the version is really superfluous when a source location is
>> specified (since we're gonna grab whatever is at the specified location
>> regardless of version).
>>
>> And particularly since one of our goals with this was to move towards
>> being more npm'ish - 'npm install' doesn't save the version when you
>> specify a source location. For example:
>>
>> "dependencies": {
>> "semver": "https://github.com/npm/node-semver/tarball/master";
>> }
>>
>> Jesse - are you suggesting that rather than having a name and a ?version
>> attribute, we instead store them in a single attribute, something like the
>> following?
>>
>>
>> http://myplatforms/cordova-windows.tgz"; />
>>
>> (I'm not actually suggesting "param" BTW - just something for the sake of
>> example)
>>
>> That's a possibility, though it makes it harder to quickly look up
>> something by name (that is, simply find the element that has a 'name'
>> attribute that matches). So I'd prefer to keep the name ad the other bit in
>> separate attributes, but use the same attribute name whether we're storing
>> version or source. That, we go with:
>>
>> https://github.com/apache/cordova-windows/
>> tarball/master" />
>>
>>
>> But where "xxx" is something other than "version" or "src" (something
>> that works for both types of value). Any suggestions? Only thing that comes
>> to my mind right now is "at" (because of the "@"):
>>
>> https://github.com/apache/
>> cordova-windows/tarball/master" />
>>
>>
>> Any better ideas?
>>
>
> Ahh.. the stages of config.xml discussions. Starts with "rename things"
> continues to "rename more" and usually ends with "let's change to JSON" :)
>
> It looks like single attribute is preferred, so instead of trying to find
> a word that can mean "source and version", we should settle on version and
> change it for plugin.
>
>
>
>> Thanks!
>>
>> Tim
>>
>>
>> From: Jesse [purplecabb...@gmail.com]
>> Sent: Tuesday, March 31, 2015 3:53 PM
>> To: dev@cordova.apache.org
>> Subject: Re: Question about plugin/platform --save: src vs version?
>>
>> I agree with Andrew, fail loudly if we cannot find it.
>> And, jam all this into 1 attribute which may or may not have a version (
>> or
>> a tag? )
>> Essentially just store whatever the parameter to 'cordova plugin add' was.
>>
>>
>>
>>
>>
>>
>> @purplecabbage
>> risingj.com
>>
>> On Mon, Mar 30, 2015 at 5:36 PM, Andrew Grieve
>> wrote:
>>
>> I don't think we'd want to try a fallback in this case. Better to fail
>>> loudly if the plugin can't be found where it's expected to be.
>>>
>>> I think since NPM uses only a single field (although theirs isn't
>>> labeled),
>>> we should do likewise. Don't feel strongly about it though.
>>>
>>> On Mon, Mar 30, 2015 at 4:04 PM, Edna Y Morales
>>> wrote:
>>>
>>> It could make sense to store both
RE: Plugins to NPM (Phase 1)
Hi Steve, My final questions (until my next final question... ;-) ) Until the CPR becomes read-only, will the Cordova project plugin releases update both CPR and npm or only npm? I guess they would be the same except for the id? Or has CPR already seen its final update for Cordova project plugins? In your reply you mentioned: > Right now, our mapping just spits out a message to use the new name for > users. It doesn't actually convert the id to the new name, though we will > probably start doing the conversion automatically at some point. I had been assuming for the initial support that if the mapper found a match, it would go to npm - either first and dropback to CPR or CPR then npm. Here's why I ask. In the Intel XDK we want to support both CLI 4.x and CLI 5.x (in the same IDE) until CPR is retired. That presents a few challenges of course, but wrt to the name change, I would like to be able to use the old names both with CLI 4.x and CLI 5.x until we have a release that no longer supports CLI 4.x. For example, the current version of the camera plugin is 0.3.5. With the initial npm release there will be a cordova-plugin-camera version 1.0? If I ask the CLI 5.x for org.apache.cordova.camera@1.0, will that work? Thanks, Leo -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Thursday, March 26, 2015 5:40 PM To: dev@cordova.apache.org Subject: Re: Plugins to NPM (Phase 1) On Wed, Mar 25, 2015 at 2:36 PM, Horn, Julian C wrote: > I'd like to add some more questions to what Leo asked. > > Can anyone explain how the hundreds of plugins that are published in git > repos are supposed to transition to CLI 5 (and beyond)? It seems like the > answer is that they don't change anything. What if they want to (or > already do) publish via the registry? It seems like you can win if you > keep the id unchanged and add yourself to the mapping table. But if that's > true, then why are we renaming the core plugins? > If you don't change the id, you don't need to be added to the mapping table. It will just work once we start checking npm first if it is published as the same id on npm. We decided to rename our core plugins due to improved readability and fitting in better with the npm ecosystem. > > I don't think repo-resident plugins need to update any tags > that refer to core plugins. That is, you can continue to ask for > "org.apache.cordova.file". If you use CLI 5, then the rename logic will > get you the corresponding plugin from npm. Or is there some reason why you > will eventually have to change your tags to use the new > names. Of course you better not change a tag in your > repo-resident plugin before October 1, because that will break projects > that use your plugin but aren't yet using CLI 5. > Right now, our mapping just spits out a message to use the new name for users. It doesn't actually convert the id to the new name, though we will probably start doing the conversion automatically at some point. The tag is an interesting usecase. Not sure what the best solution is. For core plugins, we are doing a major version jump and we are probably going to have a requirement that they require a newer version of the CLI to work. (using the engine tag). Third party developers could do something similar. All of this would be a part of the effort to get developers to update their tools. > I haven't been able to come up with any strategy for changing the id of a > repo-resident plugin without great pain. It's basically equivalent to > discontinuing your plugin and creating a new one in its place. So it seems > to me that if I have any users I would probably want to stick with my > existing id and repo URL, even if it meant that I couldn't publish my > plugin in npm format. Is that a viable strategy, or is there a long term > plan that EVERY plugin must eventually publish via npm? > We will still support installing via git or locally. So npm won't be a requirement. To clarify, org.your.project.id is valid for npm. You are welcomed to use the existing id as package-name when publishing to npm. > > One final question. Suppose I have a CLI 4.x project and I want to > transition to CLI 5. Do I have to start over at "cordova create project"? > Depends on what changes land in 5. But currently, it is the same as updating has been since CLI 3.x. * Update cordova-cli via npm install -g cordova-cli@5.0.0. * Update your project platforms if you desire. cordova platform rm android; cordova platform add android@newVERSION. As far as I know, we don't have any changes coming into the CLI that prevent older platform versions from working. Hopefully we can keep this going. Great questions. Appreciate it. > > Julian > > -Original Message
RE: Plugins to NPM (Phase 1)
Thanks for the information Steve. That helps with our planning. I have a couple of follow-ups. > We don't necessarily have to do a major bump > for the CLI. We could easily save the major jump until we switch npm > fetching as default (approx July 1) Re: the major bump. This seems like a "delayed" breaking change. That is, when CPR is removed, all prior CLI releases will be "crippled" to a significant degree since no reference will be able to be resolved. Re: ~July 1: Would you verify my understanding? For a reference which is not in the mapping table, from ~Apr to ~July 1, CPR will be tried first and if that fails then npm. From ~July 1 to ~Oct 1, npm will be tried first and if that fails then the CPR. After ~Oct 1, only npm. Thanks, Leo -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, March 25, 2015 11:13 AM To: dev@cordova.apache.org Subject: Re: Plugins to NPM (Phase 1) Thanks for answering tony. More comments below. On Tue, Mar 24, 2015 at 12:45 PM, Homer, Tony wrote: > I¹ll try to answer some of Leo¹s questions, but it would be great if > someone else (Steve?) could comment. > > First, though, I¹ll ask a question of my own. > Is there a doc or JIRA task for tracking all of the activity related to > moving plugins to NPM? > There was the Google Doc that was created last hangout for tracking > the proposal, but it doesn¹t list JIRAs and hasn¹t been updated since > January. > I found CB-8529, CB-8538 and CB-8551 but they are not linked to a master > task JIRA. > This is not a jab at Steve at all, I¹m just wondering if there is or > should be a reference for this set of tasks (other than staying caught up > with reading the list)? > Good point. I have created a master issue at https://issues.apache.org/jira/browse/CB-8743 > On to Leo¹s questions- > > Will the release be named Cordova 5.0? > Unknown at this time? It seems like this will require a co-ordinated > release of CLI, Tools and > Plugins, with major version bumps for all. > We haven't discussed this yet. We don't necessarily have to do a major bump for the CLI. We could easily save the major jump until we switch npm fetching as default (approx July 1) > > Will it trigger a major revision bump? > Yes. > For plugins, yes. All of the core plugins will be getting a major version bump shortly. > > What is the current estimate for the release? > > I would say ³when it¹s done² but it would be great to get a more specific > answer. > I¹m not sure if that¹s possible? > Aiming for April 1st. > > If release of Phase 1 occurs on April 1 does this mean that the CPR > becomes read-only on July 1 and is > deleted on Oct 1? I think the real driver was that there is an external hosting issue with > CPR after Oct. 1. > The 3 month period was adopted so provide a transition window, but there > is a hard stop on or around Oct. 1. > Steve had mentioned this somewhere but I can¹t find it now. > - CPR becomes read-only July 1st (if we release April 1st) - Tools fetch from NPM by default on July 1st (currently checks CPR first, npm as fallback) - We will try to keep CPR open as read-only for as long as possible. Nodejitsu people told us they could give us the 6 months but we will see if we can stretch it. A day will come when we will have to shut down CPR though. > > - On Oct 1, all previous releases of Cordova CLI (< 5.0) will immediately > be "broken"? > Yes, that is my understanding, although in reading back over the > discussion I don¹t see where it is explicitly addressed. > I was assuming that this is intended in part as a forcing function. > Yes. We could look into setting up some redirect service to keep old versions working. But for now, we are saying users will have to upgrade. > > Tony > > > On 3/20/15, 11:05 AM, "Treggiari, Leo" wrote: > > >I have a few questions about Phase 1 (and beyond) as I plan how to > >migrate the Intel XDK and existing user projects through this change. > > > >- Will the release be named Cordova 5.0? This seems worthy of a major > >bump for the CLI in addition to the plugins. > > > >- What is the current estimate for the release? I assume soon. > > > >- For the purpose of my questions, I'll assume the release occurs on > >April 1. This means that the CPR becomes read-only on July 1 and is > >deleted on Oct 1? > > > >- On Oct 1, all previous releases of Cordova CLI (< 5.0) will > >immediately be "broken"? That is, they cannot add new plugins, they > >cannot "restore" plugins, etc. "Local" and "git repo" plugins continue > >to work, but my assumption is that the va
RE: [DISCUSS] Whitelist & Legacy Whitelist Plugins Release @1.0.0
Is there a timing issue here? How can a plugin be published to npm when there is no tools release that will fetch from npm? Leo -Original Message- From: iclell...@google.com [mailto:iclell...@google.com] On Behalf Of Ian Clelland Sent: Tuesday, March 24, 2015 6:42 AM To: dev@cordova.apache.org Subject: Re: [DISCUSS] Whitelist & Legacy Whitelist Plugins Release @1.0.0 We should definitely do that -- and I think we should release them simultaneously with cordova-app-hello-world, since it now references cordova-plugin-whitelist by that name (I had to install it from local git repo, but it still wasn't a perfectly smooth experience). On Mon, Mar 23, 2015 at 7:18 PM, Steven Gill wrote: > I'd like to start a vote thread for both plugins. I'm thinking they will > only be published to npm and dist (no CPR). > > Thoughts? > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Update: Plugins to NPM (Phase 1)
I have a few questions about Phase 1 (and beyond) as I plan how to migrate the Intel XDK and existing user projects through this change. - Will the release be named Cordova 5.0? This seems worthy of a major bump for the CLI in addition to the plugins. - What is the current estimate for the release? I assume soon. - For the purpose of my questions, I'll assume the release occurs on April 1. This means that the CPR becomes read-only on July 1 and is deleted on Oct 1? - On Oct 1, all previous releases of Cordova CLI (< 5.0) will immediately be "broken"? That is, they cannot add new plugins, they cannot "restore" plugins, etc. "Local" and "git repo" plugins continue to work, but my assumption is that the vast majority of plugins come from CPR (soon to be npm). Thanks, Leo -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Monday, March 09, 2015 5:20 PM To: dev@cordova.apache.org Cc: sosah.vic...@gmail.com Subject: Update: Plugins to NPM (Phase 1) Our master branch has plugin fetching from npm set as the fallback now. It will go directly to npm if the plugin-id entered isn't reverse domain name style. Cordova-lib also warns users to use the package-name instead of plugin-id when adding plugins that we have renamed and are in https://github.com/stevengill/cordova-registry-mapper Plugins TODO: - README: Move doc/en/index.md into README.md. Delete doc/en/index.md. Add links in README.md that point to github page of translated docs for plugin. (ex. https://github.com/apache/cordova-plugin-device/blob/master/doc/es/index.md). I'd love to hear from someone (Victor?) working on docs translations about how this change will impact them. - Rename plugin-ids to new plugin names in plugin.xml. Anything we should be aware of before we do this? (Ex. rename org.apache.cordova.device to cordova-plugin-device in plugin.xml) - Add peer dependencies to plugins that depend on other plugins (file, media-capture, etc) - Paramedic support for every plugin - Major version bump for all core plugins - Update plugins release process to use package.json version as main version and have it update plugin.xml's version. Will do this when we do next release Migration TODO: - Create blog post talking about migration to npm for community - include how we are renaming, suggest they do so if they want to. Will suggest they follow the pattern cordova-plugin-* - mention https://github.com/stevengill/cordova-registry-mapper for warning purposes - include potential lifespan of CPR (publishing and read only) - Discuss plugman createpackage.json command - Discuss keyword: 'ecosystem:cordova' Thoughts? Missing anything? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Schedule for npm transition
I have another question which I don't remember being discussed. Will older versions of the core plugins be published in NPM? I ask because existing user projects may reference previous versions of plugins and may want to be able to continue to fetch them for quite some time. This is separate from the 'mapper' functionality. E.g. will a user be able to request cordova-plugin-camera@0.3.4? Note that I see that the current version is 0.3.5, and I don't actually know how old 0.3.4 is. These versioned references can come from a number of places including (as Andrew pointed out and with one addition from me): 1. within plugin.xml. 2. within config.xml (for cordova plugin restore). 3. within config.xml (or some other source of metadata) for a 'cloud' Cordova build system. Thanks, Leo -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Wednesday, February 11, 2015 3:48 PM To: dev@cordova.apache.org Subject: Re: Schedule for npm transition I agree with Steve to move forward with this. The package name rationale was already discussed during the hangout, and we all agreed. On Wed, Feb 11, 2015 at 3:43 PM, Steven Gill wrote: > Mapper: https://github.com/stevengill/cordova-registry-mapper > > Mapper would be a dependency of cordova-lib. We would use it during cordova > plugin add/rm to map old id's to new name. > > We can look at extending CPR readonly phase but I fear we may have to deal > with migrating it to a different provider if want to extend its life. I am > not looking forward to dealing with that. > > In terms of package-name/package-id, we have been discussing it for weeks. > I am not a fan of the flip flopping on this issue and it is seriously > holding up us moving forward with this. Michal did a great job explaining > how the mapper could be integrated to handle the workflows. > > > > On Wed, Feb 11, 2015 at 3:20 PM, Gorkem Ercan > wrote: > >> >> >> On 11 Feb 2015, at 15:50, Michal Mocny wrote: >> >> Leo, restore will still work. The only information stored in the saves >>> list is a set of plugin ids (and versions?). Restoring will go through >>> the >>> steps Steve outlines above, and either download from CPR or be mapped >>> automatically to the npm equivalent. After the deprecation cutoff, >>> plugins >>> that aren't in the mapper may fail to restore -- so we could improve the >>> >> >> Any ideas what that mapper will look like? part of CLI, online service? >> >> >> >> rollout plan by starting to warn users adding plugins that still fetch >>> from >>> CPR. >>> >>> -Michal >>> >>> On Wed, Feb 11, 2015 at 2:58 PM, Treggiari, Leo >>> wrote: >>> >>> The proposal contains suggestions, alternatives and comments. >>>> >>>> >>>>> https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3 >>>> OXmP-9DpYkcmfs/edit?usp=sharing >>>> >>>> When will there be a final version that is the official plan? >>>> >>>> One other question: Soon we will have optional 'save' of plugin metadata >>>> in config.xml. When CPR is turned off, there will be saved metadata >>>> which >>>> is no longer valid - i.e. a restore will fail. This is because the >>>> 'name' >>>> used to fetch a plugin (cordova-plugin-device) as well as the location >>>> will >>>> change. Is there anything that can be done to mitigate that? Is the >>>> name >>>> change really necessary - why can't we stick with the current names? >>>> >>>> Thanks, >>>> Leo >>>> >>>> -Original Message- >>>> From: Steven Gill [mailto:stevengil...@gmail.com] >>>> Sent: Wednesday, February 11, 2015 11:40 AM >>>> To: dev@cordova.apache.org >>>> Subject: Re: Schedule for npm transition >>>> >>>> Correct! For the first 3 months, all requests will hit CPR first, if CPR >>>> fails, we will try to fetch from npm. >>>> >>>> If users run "cordova plugin add cordova-plugin-device", it would hit >>>> CPR, >>>> fail, go to npm, succeed. >>>> >>>> If we use the mapper module, "cordova plugin add >>>> org.apache.cordova.device" would be converted to cordova-plugin-device, >>>> hit >>>> CPR, fail, go to npm, succeed. >>>> >>>> After 3 months, "cordova plugin add cordova-plugin-device"
RE: Schedule for npm transition
The proposal contains suggestions, alternatives and comments. > https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing When will there be a final version that is the official plan? One other question: Soon we will have optional 'save' of plugin metadata in config.xml. When CPR is turned off, there will be saved metadata which is no longer valid - i.e. a restore will fail. This is because the 'name' used to fetch a plugin (cordova-plugin-device) as well as the location will change. Is there anything that can be done to mitigate that? Is the name change really necessary - why can't we stick with the current names? Thanks, Leo -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, February 11, 2015 11:40 AM To: dev@cordova.apache.org Subject: Re: Schedule for npm transition Correct! For the first 3 months, all requests will hit CPR first, if CPR fails, we will try to fetch from npm. If users run "cordova plugin add cordova-plugin-device", it would hit CPR, fail, go to npm, succeed. If we use the mapper module, "cordova plugin add org.apache.cordova.device" would be converted to cordova-plugin-device, hit CPR, fail, go to npm, succeed. After 3 months, "cordova plugin add cordova-plugin-device" would hit npm first and succeed. We want to use these 3 months to get our developers to update their tools and use the new names for plugins to install. On Wed, Feb 11, 2015 at 10:36 AM, Michal Mocny wrote: > Steve, npm fetch default only affects plugins that use same name in both > places, right? > > If we create cordova-plugin-device today, and tell users to start using > cordova plugin add cordova-plugin-device, then we will get much user > feedback on npm fetching far before May 18th, right? > > On Wed, Feb 11, 2015 at 1:09 PM, Steven Gill > wrote: > > > We don't have one yet but we should pick dates soon. > > > > How about: > > > > CPR Switch to read only: Monday, May 18th > > NPM fetch becomes default: Monday, May 18th > > CPR offline: Monday, August 17th > > > > Based on the following proposal: > > > > > https://docs.google.com/document/d/12WAXJa6jfY3BnNHGieK9QOqvZ6cl3OXmP-9DpYkcmfs/edit?usp=sharing > > > > - Need to start educating plugin developers to publish to npm as well as > > CPR for next three months. (blog post) > > - Need to educate users to install plugins via new names (if > package-name > > is different than id). Our core plugins are being renamed from > > org.apache.cordova.device to cordova-plugin-device > > - Inform devs who are working with registry directly to pull plugins from > > npm instead of CPR. After 3 months, CPR plugins will start to become out > of > > date compared to npm versions. > > > > Our next plugins release (after the one currently ongoing) will be > > published to npm as well as cpr. > > > > > > > > On Wed, Feb 11, 2015 at 9:10 AM, Gorkem Ercan > > wrote: > > > > > > > > Is there a determined calendar for the npm move of the plugins? > > > I think the scheduling of the transition is crucial for those who are > > > using the plugin registry directly. > > > -- > > > Gorkem > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > > > For additional commands, e-mail: dev-h...@cordova.apache.org > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: platforms/plugins save and restore from config.xml
I agree with always saving and automatically re-fetching sources and platforms when needed. With regards to the other conversation going on re: automatic add of a platform, I think the CLI should automatically do things when it is reasonably unambiguous what the user wants - e.g. if they explicitly say build for iOS then CLI adds the platform if it is needed. If you are on Windows and you say build for iOS, you get an error, which you would even if CLI had allowed you to add the platform - e.g. for a cross platform, multi-developer scenario. If save/restore are 'optional', then as others have pointed out, other problems cannot be solved unless the user has used the save and restore command/options. I don't want my IDE to be saying: "didn't I tell you that you need to use the save/restore command options if you want to do any operations outside of the IDE!". Leo -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Tuesday, January 13, 2015 6:57 AM To: Gorkem Ercan Cc: dev; Andrew Grieve; Michael Brooks Subject: Re: platforms/plugins save and restore from config.xml Saving all the time certainly would make this simpler. If we save all of the time, we can also make uninstall a part of prepare. E.g. If users edits their config.xml and removes a , then prepare can detect that and plugman uninstall it before building. If we don't always save, then editing your config.xml wouldn't be that meaningful unless you delete & recreate platforms every time. On Mon, Jan 12, 2015 at 10:29 PM, Gorkem Ercan wrote: > > > On 12 Jan 2015, at 22:09, Andrew Grieve wrote: > > Related to this, but maybe can be discussed outside of the doc just fine: >> >> https://issues.apache.org/jira/browse/CB-4275 >> >> Right now when we add a new platform, we do a for-each on directories >> within plugins/ and add them as well. This causes all plugins to wind up >> as >> top-level plugins even when they are dependent plugins on existing >> platforms. >> >> Having plugins listed in config.xml, I think it would make sense to change >> this logic to plugin add based on plugins within config.xml rather than >> directories that exist within plugins. We could potentially still add all >> of them if no plugins are listed in config.xml for backwards compat. >> >> > Related to that, I was looking at CB-8278[1] this bug not only causes the > variables to be lost also it causes the top-level plugin info to vanish as > well. > We could also fix this problem easier too if we are saving plugins to > config.xml all the time. Which means no save command or --save. > > [1] https://issues.apache.org/jira/browse/CB-8278 > > > >> >> On Mon, Jan 12, 2015 at 9:19 PM, Andrew Grieve >> wrote: >> >> Thanks for putting the doc together. Added some comments to it. >>> >>> On Mon, Jan 12, 2015 at 5:39 PM, Mefire O. >>> wrote: >>> >>> Google docs link : https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5 Jnc7FU41V3-jFc/edit Thanks, Mefire -Original Message- From: Mefire O. [mailto:ommen...@microsoft.com] Sent: Monday, January 12, 2015 2:12 PM To: dev@cordova.apache.org Cc: Michael Brooks Subject: RE: platforms/plugins save and restore from config.xml Here's what I propose, let me know what you think : 'cordova platform add' * No -save flag, No 'autosave' setting in project_dir/.cordova/config.json 1. 'cordova platform add android' => restores the android platform from config.xml. If config.xml doesn't have any android engine, falls back to using the pinned CLI version. * With -save flag or 'autosave' setting in project_dir/.cordova/config.json 1. 'cordova platform add https://github.com/apache/cordova-android.git -save' => clones the git repo and adds the android platform to the project, then updates config.xml and point its version to the specified git-url. 2. 'cordova platform add android@ https://github.com/apache/cordova-android.git -save' => clones the git repo and adds the android platform to the project, then updates config.xml and point its version to the specified git-url. 3. 'cordova platform add C:/path/to/android/platform -save' => adds the android platform to the project, then updates config.xml and point its version to the specified folder location. * --Save flag is used in CLI-based workflows, and 'autosave' (project_dir/.cordova/config.json) is used in IDE-based workflows. 'cordova save platforms' In its current behavior, 'cordova save platforms' retrieves all the platforms currently installed on the project, and saves them to config.xml. However, unlike 'cordova save plugins', it does not save the source of the platform (i.e: git-url, folder location), it on
RE: platforms/plugins save and restore from config.xml
I had asked some questions about save and restore a while back, but have not been following the progress in detail - so ignore me if you feel it is appropriate. One of my biggest questions was why would these commands be an option? What I'm looking for, as soon as possible, is that Cordova 'project' metadata is stored logically and consistently so that the CLI and multiple IDEs could simultaneously work on the same project and know about what each other have done wrt. adding/removing plugins/platforms/etc. Does removing experimental advance that goal or does it, as Michal says, put obstacles in the path of getting there by requiring long term support of an incomplete and possibly confusing (more options?) solution? Leo -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Friday, January 09, 2015 10:35 AM To: dev Subject: Re: platforms/plugins save and restore from config.xml -1 on removing experimental. I love the concept behind this feature, and I applaud Gorkem for actually working on pushing it forward, but I'm still concerned the current design is not perfect. Just today we were discussing storing the list of plugins into a package.json if plugins move to npm. The current implementation still saves all installed plugins including dependencies and not just what was explicitly added. If we add this outside experimental, and document & broadcast it, we will have to support it going forward. That will certainly influence future cli designs. -Michal On Fri, Jan 9, 2015 at 12:08 PM, Gorkem Ercan wrote: > > > On 9 Jan 2015, at 10:41, Andrew Grieve wrote: > > Questions: Would ever not want to use --save? Why not just always update >> config.xml with what plugins you have? >> >> Eclipse Thym always updates the plugin & platform information to > config.xml, and no one complained about it so far. > > Likewise, would you ever not want to have --shrinkwrap? I think you'd >> always want the plugin/platform version listed in there. >> >> > I do not set the shrinkwrap for plugins usually, because without > shrinkwrap, the latest version is restored. I usually prefer the latest > with the stable plugins, such as the core plugins. > As a reference, Eclipse Thym does not shrinkwrap by default but has a > preference you can turn on. > > With platforms shrinkwrap as default makes sense. > > On Fri, Jan 9, 2015 at 1:46 AM, Mefire O. wrote: >> >> Also, I have Pull Requests that implements the --save flag as mentioned >>> earlier : >>> >>> - https://github.com/apache/cordova-cli/pull/203 >>> - https://github.com/apache/cordova-lib/pull/144 >>> >>> >>> Thanks, >>> Mefire >>> >>> -Original Message- >>> From: Mefire O. [mailto:ommen...@microsoft.com] >>> Sent: Thursday, January 8, 2015 10:27 PM >>> To: Cordova Dev >>> Subject: RE: platforms/plugins save and restore from config.xml >>> >>> +1 on removing the --experimental flag after fixing the 'variables not >>> being saved' bug. >>> >>> Thanks, >>> Mefire >>> >>> -Original Message- >>> From: Josh Soref [mailto:jso...@blackberry.com] >>> Sent: Thursday, January 8, 2015 8:49 PM >>> To: Cordova Dev >>> Subject: Re: platforms/plugins save and restore from config.xml >>> >>> Until adding plugins saves the variables provided, we really shouldn't / >>> can't make this non experimental. >>> >>> Sent from my BlackBerry 10 smartphone. >>> >>> >>> > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Questions re: plugin variables
I'm having a hard time understanding exactly how plugin variables work. It's probably a level of detail that only plugin developers and tool developers need to be concerned about. I'd appreciate it if someone can give me the answers. 1. "variables can be indicated by a dollar-sign followed by a series of capital letters, digits, or underscores." "To make the variable mandatory, the tag needs to contain a tag." Does this mean that there are optional and required variables - i.e? - A variable reference is defined by a lexical element which begins with a $ and is followed only by capital letters, digits, or underscores? - A variable is made mandatory by the presence of a tag which uses the same name with the $ removed? - Can this tag be anywhere in the plugin.xml file, or must it be the direct child of the element or a element? - Can the variable references be anywhere or only within strings? 2. Where and when are the variables replaced by their value? - plugin.xml is the only place that the variable value is used and only for replacing the variable references? - When in Cordova CLI do the values get applied - during "add", during "prepare"? 3. What happens if you combine dependencies with variables. For example, suppose A depends on B, and B requires a variable X. How do you supply the value? Thanks, Leo
RE: cordova xxx add - is there a problem?
> I think you would like for each developer to be able to be able to work on > any project regardless of locally available sdks, correct? Yes. Thanks. From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Monday, November 03, 2014 1:30 PM To: Treggiari, Leo Cc: Michal Mocny; dev Subject: Re: cordova xxx add - is there a problem? Okay, gotcha. I think you would like for each developer to be able to be able to work on any project regardless of locally available sdks, correct? E.g. if you on windows and some project supports ios, you should still be able to work on the wp/android parts, or use an iOS cloud build. That makes sense. Andrew mentioned earlier that we have actually started landing patches in this direction. Specifically, the "add" scripts should fail gracefully if the sdk is not available, in a way that is easy to recover from once the sdks are added (including cloning the repo on another machine). I don't think moving things to prepare-time is required for this, though it could be an option if needed. -Michal On Mon, Nov 3, 2014 at 3:38 PM, Treggiari, Leo mailto:leo.treggi...@intel.com>> wrote: Hi Michal, Thanks for the information and considering this. The workflow that I want is somewhat different than what you have inferred from my previous mail. I do want “add” to set the metadata AND fetch the plugin sources / platform implementation. I think it is fair that if someone only wants to set the metadata, that they use a command line option, or some other method, for that. What I don’t want “add” to do is anything that requires the platform SDKs. I want that to happen with “prepare” and commands that occur post-prepare. If “prepare” works incrementally based upon the project metadata and knowledge of what it has done before, or if “prepare” always redoes everything, then it should work if “add” does not call “prepare”, right? If “prepare” assumes that “add” has done any more than set the metadata and fetch the sources, then a change would be necessary. Here’s an example scenario – two developers working on the same project: •One uses CLI and develops on Mac for iOS and/or Android •One uses an IDE and develops on Windows for Windows Phone and/or Android One user creates the project. Either can add plugins and platforms. The remainder of the workflow is specific to the tools each user is using, but they don’t get into each other’s way when they share the ‘project’ in git – i.e. the project sources and the project metadata. Really we just need to iron out and land what Gorkem started. Does that sound fair? Yes, but wouldn’t it be better to change “add” to not call “prepare”. You suggested a "--skip-prepare" or "--save-only" type flag for the add commands. This would work as long as developers remembered to us it when necessary. Thanks, Leo From: mmo...@google.com<mailto:mmo...@google.com> [mailto:mmo...@google.com<mailto:mmo...@google.com>] On Behalf Of Michal Mocny Sent: Monday, November 03, 2014 12:10 PM To: dev Cc: Treggiari, Leo Subject: Re: cordova xxx add - is there a problem? Prepare runs hooks, updates the platform config.xml's (using platform defaults + plugin.xml's + app config.xml), and updates the www/ assets, including re-adding plugin js-modules. In practice this takes about as long as copying all the files around. However, pre/post prepare hooks are the most common place for application developers to inject more complex conditional actions. Chrome Apps for Mobile, for example, will automatically install platforms / plugins if they aren't already installed as part of pre-prepare. Anyway, its starting to sound like we wont actually need to change the cli interface to address your needs: IDE's can just edit the config.xml directly to insert dependant platforms/plugins (with gorkems work) without actually adding those asserts locally if that isn't important (i.e. for remote cloud build). If you are working at the command line, I don't see much value in supporting "add" without actually fetching the assets. Really we just need to iron out and land what Gorkem started. Does that sound fair? -Michal On Mon, Nov 3, 2014 at 1:45 PM, Treggiari, Leo mailto:leo.treggi...@intel.com>> wrote: I hate to see lots of new commands and/or options added. They are OK if code is calling the commands (e.g. an IDE), but not so good for users. Certainly having a well-defined and documented place for the metadata re: plugins and platforms is an important step forward. How smart is "prepare"? Does it work incrementally based upon the changes since the last time it was invoked, or is does it do all preparation every time? I ask from a performance perspective with respect to moving work from "add" to "prepare", because it seems like "prepa
RE: cordova xxx add - is there a problem?
Hi Michal, Thanks for the information and considering this. The workflow that I want is somewhat different than what you have inferred from my previous mail. I do want “add” to set the metadata AND fetch the plugin sources / platform implementation. I think it is fair that if someone only wants to set the metadata, that they use a command line option, or some other method, for that. What I don’t want “add” to do is anything that requires the platform SDKs. I want that to happen with “prepare” and commands that occur post-prepare. If “prepare” works incrementally based upon the project metadata and knowledge of what it has done before, or if “prepare” always redoes everything, then it should work if “add” does not call “prepare”, right? If “prepare” assumes that “add” has done any more than set the metadata and fetch the sources, then a change would be necessary. Here’s an example scenario – two developers working on the same project: ·One uses CLI and develops on Mac for iOS and/or Android ·One uses an IDE and develops on Windows for Windows Phone and/or Android One user creates the project. Either can add plugins and platforms. The remainder of the workflow is specific to the tools each user is using, but they don’t get into each other’s way when they share the ‘project’ in git – i.e. the project sources and the project metadata. Really we just need to iron out and land what Gorkem started. Does that sound fair? Yes, but wouldn’t it be better to change “add” to not call “prepare”. You suggested a "--skip-prepare" or "--save-only" type flag for the add commands. This would work as long as developers remembered to us it when necessary. Thanks, Leo From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Monday, November 03, 2014 12:10 PM To: dev Cc: Treggiari, Leo Subject: Re: cordova xxx add - is there a problem? Prepare runs hooks, updates the platform config.xml's (using platform defaults + plugin.xml's + app config.xml), and updates the www/ assets, including re-adding plugin js-modules. In practice this takes about as long as copying all the files around. However, pre/post prepare hooks are the most common place for application developers to inject more complex conditional actions. Chrome Apps for Mobile, for example, will automatically install platforms / plugins if they aren't already installed as part of pre-prepare. Anyway, its starting to sound like we wont actually need to change the cli interface to address your needs: IDE's can just edit the config.xml directly to insert dependant platforms/plugins (with gorkems work) without actually adding those asserts locally if that isn't important (i.e. for remote cloud build). If you are working at the command line, I don't see much value in supporting "add" without actually fetching the assets. Really we just need to iron out and land what Gorkem started. Does that sound fair? -Michal On Mon, Nov 3, 2014 at 1:45 PM, Treggiari, Leo mailto:leo.treggi...@intel.com>> wrote: I hate to see lots of new commands and/or options added. They are OK if code is calling the commands (e.g. an IDE), but not so good for users. Certainly having a well-defined and documented place for the metadata re: plugins and platforms is an important step forward. How smart is "prepare"? Does it work incrementally based upon the changes since the last time it was invoked, or is does it do all preparation every time? I ask from a performance perspective with respect to moving work from "add" to "prepare", because it seems like "prepare" is called much more often than "add". Regarding fetching the sources and local vs. remote builds, It's not just where the build takes place that determines whether a client wants the sources. The sources can be used for other things besides building, including code-assist in an editor, emulation, companion apps, etc. Leo -Original Message- From: mmo...@google.com<mailto:mmo...@google.com> [mailto:mmo...@google.com<mailto:mmo...@google.com>] On Behalf Of Michal Mocny Sent: Monday, November 03, 2014 10:25 AM To: dev Cc: Treggiari, Leo Subject: Re: cordova xxx add - is there a problem? I'm not sure that we should change the "cordova plugin/platform add" cli command to not actually make the changes to platforms/ or plugins/, but since both commands run "cordova prepare", we could move the logic to the prepare step and then add a "--skip-prepare" or "--save-only" type flag for the add commands? Alternatively, we could do something like what phonegap-cli does and have a "cordova remote plugin add" to differentiate local installs from mere metadata updates. Either way, seems this is related to Gorkems work to add platform / plugin deps to confi
RE: cordova xxx add - is there a problem?
I hate to see lots of new commands and/or options added. They are OK if code is calling the commands (e.g. an IDE), but not so good for users. Certainly having a well-defined and documented place for the metadata re: plugins and platforms is an important step forward. How smart is "prepare"? Does it work incrementally based upon the changes since the last time it was invoked, or is does it do all preparation every time? I ask from a performance perspective with respect to moving work from "add" to "prepare", because it seems like "prepare" is called much more often than "add". Regarding fetching the sources and local vs. remote builds, It's not just where the build takes place that determines whether a client wants the sources. The sources can be used for other things besides building, including code-assist in an editor, emulation, companion apps, etc. Leo -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Monday, November 03, 2014 10:25 AM To: dev Cc: Treggiari, Leo Subject: Re: cordova xxx add - is there a problem? I'm not sure that we should change the "cordova plugin/platform add" cli command to not actually make the changes to platforms/ or plugins/, but since both commands run "cordova prepare", we could move the logic to the prepare step and then add a "--skip-prepare" or "--save-only" type flag for the add commands? Alternatively, we could do something like what phonegap-cli does and have a "cordova remote plugin add" to differentiate local installs from mere metadata updates. Either way, seems this is related to Gorkems work to add platform / plugin deps to config.xml (though, the current implementation as it exists is insufficient). -Michal On Fri, Oct 31, 2014 at 1:48 PM, Frederico Galvão < frederico.gal...@pontoget.com.br> wrote: > Well, afaik 'cordova plugin add <>' only does 'cordova prepare' after the > plugin stuff is done, and 'cordova prepare' works even without native SDKs. > > 2014-10-30 23:43 GMT-02:00 Andrew Grieve : > > > There've been some changes to CLI in the last month that fix Android > > requiring an SDK to run create & plugin add. Likewise, a fix just went in > > this week (last week?) that fixes the slash problem for xcode project > files > > on windows. > > > > That said, I like your idea of not modifying platforms/ outside of > prepare > > / build. > > > > On Thu, Oct 30, 2014 at 10:48 AM, Treggiari, Leo < > leo.treggi...@intel.com> > > wrote: > > > > > Is there an issue with the semantics of "plugin add" and "platform > add"? > > > > > > This is just a high level query to see if this is something worth > > > discussing in more detail. I don't know exactly what each Cordova CLI > > > command does. My knowledge is based upon reading documentation (which > is > > > sometimes wrong as noted in recent e-mails) and experimentation. > > > > > > What does "add" do? > > > > > > > > > 1. For "plugin add" fetches the plugin sources. For "platform > add" > > > fetches the platform implementation if necessary. > > > > > > 2. Stores some metadata somewhere indicating that the plugin or > > > platform was added? What and where this metadata is stored should be > > > better documented. > > > > > > 3. For "plugin add", processes plugin variables, if specified, > which > > > modifies the plugin sources. > > > > > > 4. Creates/modifies the native platform "project" (e.g. a Visual > > > Studio, Eclipse, or Xcode, etc. project) to make the appropriate > changes. > > > > > > If "plugin add" or "platform add" do more than this, I'd appreciate > > being > > > educated. > > > > > > My question is, should "add" stop at step #2 and leave the rest to the > > > prepare step? > > > > > > Here's why: > > > > > > *We see there is an issue with multiple developers on the same > > > project on different platforms. E.g. when one developer is on Windows > > > working on the Windows and Android versions of the project and another > is > > > on Mac working on the iOS version of the project. If the shared > project > > > wants to add all three platforms (which it does...) then Cordova CLI > has > > > problems. Basically because not much else than the "create" co
cordova xxx add - is there a problem?
Is there an issue with the semantics of "plugin add" and "platform add"? This is just a high level query to see if this is something worth discussing in more detail. I don't know exactly what each Cordova CLI command does. My knowledge is based upon reading documentation (which is sometimes wrong as noted in recent e-mails) and experimentation. What does "add" do? 1. For "plugin add" fetches the plugin sources. For "platform add" fetches the platform implementation if necessary. 2. Stores some metadata somewhere indicating that the plugin or platform was added? What and where this metadata is stored should be better documented. 3. For "plugin add", processes plugin variables, if specified, which modifies the plugin sources. 4. Creates/modifies the native platform "project" (e.g. a Visual Studio, Eclipse, or Xcode, etc. project) to make the appropriate changes. If "plugin add" or "platform add" do more than this, I'd appreciate being educated. My question is, should "add" stop at step #2 and leave the rest to the prepare step? Here's why: *We see there is an issue with multiple developers on the same project on different platforms. E.g. when one developer is on Windows working on the Windows and Android versions of the project and another is on Mac working on the iOS version of the project. If the shared project wants to add all three platforms (which it does...) then Cordova CLI has problems. Basically because not much else than the "create" command works without having native SDKs installed. Would many issues be solved if the "add" command did not require the presence of native SDKs, but rather "prepare" did? *There seems to be an issue with the co-existence of Cordova CLI and IDEs, and in particular with IDEs that want to build in the cloud without the requirement of native SDKs. It would be ideal if multiple users on the same project could use different tools - e.g. one use the command line and one use the IDE. The basic "definition" of a Cordova CLI project, i.e. the part that needs to be shared, is the list of platforms and plugins and the settings in the top level config.xml. If the basic definition of the project could be created/edited from both the CLI and various IDEs, then the rest of the development workflow (prepare, build, emulate, etc.) could be implemented in different ways, but the project definition could still be shared. P.S. the "remove" command has similar semantics. Thanks, Leo
Plugin documentation
In our Intel XDK plugin selection UI, we have a link to the documentation with each plugin. In our current release the URL looks like this: http://cordova.apache.org/docs/en/3.3.0/cordova_camera_camera.md.html I can't find that style of documentation for releases later than 3.3. I can find plugin documentation in cordova.io, e.g. http://plugins.cordova.io/#/package/org.apache.cordova.camera Has the cordova.apache.org/docs "style" of documentation been "retired", or did it move somewhere else? Thanks, Leo
RE: Independent platform release summary
Thanks for the answers and they make sense to me. Just a couple of follow-ons
– see [LEO] below.
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Friday, October 10, 2014 9:54 AM
To: Treggiari, Leo
Cc: Michal Mocny; Marcel Kinard; dev
Subject: Re: Independent platform release summary
On Thu, Oct 9, 2014 at 3:22 PM, Treggiari, Leo
mailto:leo.treggi...@intel.com>> wrote:
I’ll have to admit that this seems a bit weird. That is, independent versions
of the CLI and platforms, with a “Cordova release” named “something” – e.g. a
date?
"The Cordova Release" can be labelled with the CLI version number. That number
just doesn't make sense to apply to all platforms, and is harmful to some of
our goals.
Imagine a user wants to know whether the new whitelist entry in config.xml is
supported in the versions of CLI and platforms that they have – assuming they
understand the distinction between the CLI and platforms to begin with. They
use some command to list the versions of the “things” (CLI and platforms) they
have installed. They go to the individual documentation of the “things” and
try to figure it out
Okay, great question. Heres how I think that would play out:
First, we add this new config.xml feature to the CLI. We document this in the
CLI documentation, and should be obvious which CLI versions to support this
feature.
[LEO] Will this happen before the “big change”? It would be nice if it did.
If this feature also required platform changes:
- Ideally, we implement the CLI change in a way that just warns when the
platform is too old, and no-ops if so. This is actually historically common
(minus the warnings!).
- If that isn't possible, and the change will actually break existing
platforms, that means the CLI has to do a MAJOR revision bump.
- Platforms have tags to say they expect a particular CLI version >=
x.y.z and < (x+1).0.0, and so updates to CLI that are MAJOR require updates to
all platforms.
- You can downgrade your CLI, perhaps only locally using local node_module
installs, should you want to avoid this situation in an old project.
The way the Cordova documentation works today is nice with the combo box where
I can select a Cordova version – 3.6.0, 3.5.0, ... What would the combo box
contain in the new versioning scheme and how many entries would there be? Are
the answers “dates” and “lots of dates”? Or would there be no Cordova version
documentation other than an explanation of how to get the list of “things” you
currently have and where to find the documentation on them.
As discussed, we would split CLI/platform docs and version alongside releases
(like plugins). In this case, you would probably be reading the CLI docs for
config.xml settings, and can follow a link to platform-specific extensions.
To “pin” or not to “pin”
Note that, to me, the pinning choice defines what happens when I use “cordova
{plugin | platform} add foo” with no specific version specified.
Right.
I’ve understood, so far at least, that plugins are not pinned (an add always
fetches something) and platforms are pinned to a CLI version (an add tells the
CLI that I will be using that platform (already installed) for this project).
Everything I have read which includes 1 book and the on-line project
documentation, suggest that, even if not stating it explicitly. E.g. plugins
talk about “fetching” and platforms don’t. There is a way to fetch a specific
version of platform support. That’s good and if I do that it is up to me to
understand the compatibility of the specific version I requested.
Is this true? If so then the npm cordova behavior seems weird. That is, if I
“npm install cordova” I get a set of pinned platforms. If I “npm update
cordova”, I get a new CLI and nothing else – i.e. not the platforms that were
pinned to that version of the CLI?
Few questions here..
Yes, plugins are not pinned in any way, they always install latest.
Yes, platforms are pinned, in that there is a pre-selected default version that
will be installed which is tied to the CLI version.
Yes, there are ways to explicitly override the default version of platform /
plugin that gets installed.
Yes, when you update CLI on npm, you "pinnings" change, but no platforms are
actually upgraded anywhere. You don't even download the platforms at this
point, it just affects the next time you "platform add" somewhere.
[LEO] I get the last distinction (npm update) now and didn’t before. That
makes sense, but would be better if it were well documented. Maybe it is and I
just didn’t see it.
Should the plugin and platform ‘pin’ behavior be the same?
Personally, I think so, but this is something we can decide later. Right now
there are already a lot of changes, and pinning has been what we've done
historically. There was a long thread about this and there were some good
reasons mentioned there for why
RE: Independent platform release summary
ject: Re: Independent platform release summary > > > >> > > > > > >> > >I think vladimir fixed the bug. We just need to release now. > > > >> > > > > > >> > >Only thing holding back the release now is consensus on the > version > > > >> > >of the cli. It seemed like most people were leaning toward > 10.0.0. > > > >> > >Should I move forward with that? I would just have to branch + > pin > > > >> > >deps > > > >> > > > > > >> > >Leo the documentation version dropdown box would be tied to cli > > > >>version. > > > >> > >It still makes sense to copy over platform documentation into > > > >> > >platform repos and maybe copy it into docs during generation > time. > > > >> > > > > > >> > >As for plugin pinning, plugins have more to do with platforms. I > > > >> wouldn't > > > >> > >say they aren't tied to the cli at all. I understand your point > > > >>though. > > > >> > >So far, we haven't had any plugins that won't work with previous > > > >> versions > > > >> > >(As far as I know). We should really fix the engine stuff for > > > >> > >plugins so we can keep track of what platforms they work for. I'd > > > >> > >like us to give warnings to users to update their plugins if > newer > > > >>versions are out. > > > >> > >Cordova info should also dump what versions of plugins you have > > > >> installed > > > >> > >if it doesn't already. In combination with cordova --save & > cordova > > > >> > >--restore, we should be able to recommend a workflow that is > easily > > > >> > >reproducible on any machine. > > > >> > > > > > >> > >On Thu, Oct 9, 2014 at 1:44 PM, Chuck Lantz < > cla...@microsoft.com> > > > >> wrote: > > > >> > > > > > >> > >> Okay - so - there's a pretty nasty CLI blocker bug right now. > > > >> > >> Plugins with dependencies don't install (this affects all > > > >> > >> platforms). In my opinion, we need to get a CLI release out > > > >> > >> really soon. Are we closed on this topic, or do we need to > look > > > >> > >> at doing the old process to get this out the door while we are > > > >>still talking? > > > >> > >> > > > >> > >> There are also a series of other bugs in the currently tagged > > > >>"3.6.4" > > > >> > >> platforms for Android, Windows, and Windows Phone 8. These can > > > >> > >> be handled independently, but the CLI bug can't. > > > >> > >> > > > >> > >> https://issues.apache.org/jira/browse/CB-7670 > > > >> > >> > > > >> > >> -Chuck > > > >> > >> > > > >> > >> -Original Message- > > > >> > >> From: Treggiari, Leo [mailto:leo.treggi...@intel.com] > > > >> > >> Sent: Thursday, October 9, 2014 12:23 PM > > > >> > >> To: Michal Mocny > > > >> > >> Cc: Marcel Kinard; dev > > > >> > >> Subject: RE: Independent platform release summary > > > >> > >> > > > >> > >> I'll have to admit that this seems a bit weird. That is, > > > >> > >> independent versions of the CLI and platforms, with a "Cordova > > > >> > >> release" named "something" - e.g. a date? > > > >> > >> > > > >> > >> Imagine a user wants to know whether the new whitelist entry in > > > >> > >> config.xml is supported in the versions of CLI and platforms > that > > > >> > >> they have - assuming they understand the distinction between > the > > > >> > >> CLI and platforms to begin with. They use some command to list > > > >> > >> the versions of the "things" (CLI and > > > >> > >> platforms) they have installed. They go to the individual > > > >> > >> documentation of the "thing
RE: Independent platform release summary
I’ll have to admit that this seems a bit weird. That is, independent versions
of the CLI and platforms, with a “Cordova release” named “something” – e.g. a
date?
Imagine a user wants to know whether the new whitelist entry in config.xml is
supported in the versions of CLI and platforms that they have – assuming they
understand the distinction between the CLI and platforms to begin with. They
use some command to list the versions of the “things” (CLI and platforms) they
have installed. They go to the individual documentation of the “things” and
try to figure it out.
The way the Cordova documentation works today is nice with the combo box where
I can select a Cordova version – 3.6.0, 3.5.0, ... What would the combo box
contain in the new versioning scheme and how many entries would there be? Are
the answers “dates” and “lots of dates”? Or would there be no Cordova version
documentation other than an explanation of how to get the list of “things” you
currently have and where to find the documentation on them.
To “pin” or not to “pin.
Note that, to me, the pinning choice defines what happens when I use “cordova
{plugin | platform} add foo” with no specific version specified.
I’ve understood, so far at least, that plugins are not pinned (an add always
fetches something) and platforms are pinned to a CLI version (an add tells the
CLI that I will be using that platform (already installed) for this project).
Everything I have read which includes 1 book and the on-line project
documentation, suggest that, even if not stating it explicitly. E.g. plugins
talk about “fetching” and platforms don’t. There is a way to fetch a specific
version of platform support. That’s good and if I do that it is up to me to
understand the compatibility of the specific version I requested.
Is this true? If so then the npm cordova behavior seems weird. That is, if I
“npm install cordova” I get a set of pinned platforms. If I “npm update
cordova”, I get a new CLI and nothing else – i.e. not the platforms that were
pinned to that version of the CLI?
Should the plugin and platform ‘pin’ behavior be the same?
Should both be pinned? Some may find this alternative “blasphemous” but the
core plugin versions tested with a version of the CLI could be pinned to the
version of the CLI.
Should both not be pinned? It would be more consistent and if users are OK
with plugins being unpinned, why not platforms?
But maybe plugins and platforms are different. Plugins are purely run-time
code. Platforms are primarily tooling with some run-time code. Does that
difference make the current pinning behavior the best choice.
Maybe, but personally I would prefer both to be pinned – i.e. I install a
version of Cordova, and until I update it, every time I add a platform or
‘core’ plugin, I get the same thing.
Leo
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Wednesday, October 08, 2014 1:47 PM
To: Treggiari, Leo
Cc: Michal Mocny; Marcel Kinard; dev
Subject: Re: Independent platform release summary
With this direction, there is no single number. Users should not functionally
care about CLI version, so there will just be the platform versions that
matter, really.
Downstreams can of course put labels on combinations of versions, so "PhoneGap
4" may be Android 4, iOS 3.8, and etc.
On Wed, Oct 8, 2014 at 4:39 PM, Treggiari, Leo
mailto:leo.treggi...@intel.com>> wrote:
> Did I miss anything?
I don't think we closed on this (I had to leave the meeting a little early) but
a remaining question is how to version what we (and users) call "Cordova".
Assuming a "Cordova" version is a point in time collection of the latest CLI
version + platform versions + plugin versions. Is the Cordova version semver
(using what algorithm with respect to its contained components) or is that what
you meant by ""latest as of Oct 2014" or something".
Thanks,
Leo
-Original Message-
From: mmo...@google.com<mailto:mmo...@google.com>
[mailto:mmo...@google.com<mailto:mmo...@google.com>] On Behalf Of Michal Mocny
Sent: Wednesday, October 08, 2014 1:13 PM
To: Michal Mocny
Cc: Marcel Kinard; dev
Subject: Re: Independent platform release summary
Thanks everyone for participation in what was a long and grueling
discussion.
Summary of current proposal:
- Cad-ver is dead.
- Everything moves Sem-ver, with platforms continuing from current versions
and diverging over time.
- CLI potentially gets a significant version bump to showcase this reset
(to 5.0 or 10.0, not yet settled)
- Pinning default platform versions *will* continue for the time being, but
it will be trivial to override the default.
- Platforms will have CLI tag equivalent (unclear yet if as node
peerDependency or otherwise) so devs will know when they need to
upgrade/downgrade CLI for non-default platform versions.
- After a platform update, ev
RE: Independent platform release summary
> Did I miss anything? I don't think we closed on this (I had to leave the meeting a little early) but a remaining question is how to version what we (and users) call "Cordova". Assuming a "Cordova" version is a point in time collection of the latest CLI version + platform versions + plugin versions. Is the Cordova version semver (using what algorithm with respect to its contained components) or is that what you meant by ""latest as of Oct 2014" or something". Thanks, Leo -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Wednesday, October 08, 2014 1:13 PM To: Michal Mocny Cc: Marcel Kinard; dev Subject: Re: Independent platform release summary Thanks everyone for participation in what was a long and grueling discussion. Summary of current proposal: - Cad-ver is dead. - Everything moves Sem-ver, with platforms continuing from current versions and diverging over time. - CLI potentially gets a significant version bump to showcase this reset (to 5.0 or 10.0, not yet settled) - Pinning default platform versions *will* continue for the time being, but it will be trivial to override the default. - Platforms will have CLI tag equivalent (unclear yet if as node peerDependency or otherwise) so devs will know when they need to upgrade/downgrade CLI for non-default platform versions. - After a platform update, eventually CLI will release to "pin" the new default, and bump its PATCH/MINOR version (unless CLI had a functional update at same time that requires a larger bump). - After you update CLI, your existing projects don't change & platform upgrades remain explicit, but you will now get warnings if your installed platforms are older than the CLI pinned versions. - Event MAJOR changes to platforms are not MAJOR updates to the CLI, unless there is an actual breaking change to the CLI tool (i.e. new CLI will no longer work with the currently installed platform). - Platform and CLI docs have to split out and be released & versioned alongside each (like plugins). Cross references from one to the other will only be needed in a few places. Note: The CLI-Platform compatibility story is functionally no different than we have today. If you upgrade your CLI and there is a breaking change, you will have to re-create your projects or downgrade CLI again. Now we plan to be more explicit about it and offer warnings. Note: There is no concept of a "fancy-pants" release other than to say "latest as of Oct 2014" or something. Platforms don't have a single common set of functionality, so CadVer was somewhat misleading already in that sense. We could introduce a concept of "API Level" for exec bridge or something for use by plugins, but not sure that has value. What wasn't covered that came to mind after the fact: - When there is an update available for CLI, should we give a warning to update? (this is useful, but isn't common for npm modules. I think we already do this from plugman when you try to publish plugins?). Did I miss anything? -Michal On Wed, Oct 8, 2014 at 12:35 PM, Michal Mocny wrote: > External Public link for those that just want to watch/chat: > https://plus.google.com/events/cm4l0vifcig920qkhpn5stqiet4 > > Hangout link to join the conversation: > https://plus.google.com/hangouts/_/hoaevent/AP36tYcNwXEyet4Xv_23HiTl4IK0jsM4NlmGy5kbLsPIW3SnOsUEIQ?authuser=0&hl=en > > See you in 30 minutes. > > On Wed, Oct 8, 2014 at 12:33 PM, Michal Mocny wrote: > >> +dev list again >> >> Not everyone could make 1pm, not everyone could make 2pm. While I don't >> think we need a full 2 hours, I'm hoping to start late and end early -- >> proving opportunity people to pop in at either time and chime in. >> >> On Wed, Oct 8, 2014 at 12:18 PM, Marcel Kinard >> wrote: >> >>> Is the expected duration 1 hour or 2 hours? >>> >>> On Oct 8, 2014, at 10:56 AM, Michal Mocny wrote: >>> >>> > So it looks like Today 1-3 EST or Friday 1-3 EST are the best times. >>> I'm >>> > going to start the ball rolling to do this TODAY, but if that proves >>> too >>> > short notices we'll move it to Friday. >>> > >>> > I'll email out links to hangout at 12:30 or so, and I'm hoping Steven >>> can >>> > make it before 2pm since he's been most active with releases recently. >>> > >>> > -Michal >>> >>> >> >
RE: Independent platform release summary
From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, October 07, 2014 11:25 AM To: Treggiari, Leo Cc: Michal Mocny; Marcel Kinard; dev Subject: Re: Independent platform release summary > I don't think its a goal for us developers, but I understand that it has been > a goal for end users (resistance to change, averse to risk, been bitten with > bad upgrades in the past..) To me it is more about how much risk I want to take on at this point in time. For example, I may be fine with updating to latest and greatest at the beginning of a major release of my app. However, when I doing final testing, coming up on a deadline, I want minimal changes. Leo On Tue, Oct 7, 2014 at 2:20 PM, Treggiari, Leo mailto:leo.treggi...@intel.com>> wrote: > - enable users to easily obtain the latest-and-greatest > - clearly communicate to users what they have, so they can easily > understand how what they currently have differs from the latest-and-greatest I think there is another user goal, which may not be so easy to achieve. That is, the ability to easily understand how to take the Cordova release that I have, and do a selective update to get fixes that I need. I.e. I don't want the "latest and greatest", I want the minimal change that fixes the problems I have to fix. Does that have to be a goal? I don't think its a goal for us developers, but I understand that it has been a goal for end users (resistance to change, averse to risk, been bitten with bad upgrades in the past..) but I believe the way to strive to solve that is to simplify upgrades, not make it easier to ignore them. Leo -Original Message- From: mmo...@google.com<mailto:mmo...@google.com> [mailto:mmo...@google.com<mailto:mmo...@google.com>] On Behalf Of Michal Mocny Sent: Tuesday, October 07, 2014 11:14 AM To: Marcel Kinard Cc: dev Subject: Re: Independent platform release summary Marcel, I added the goal for "latest-and-greatest" which is a good idea. I think your other goals are already covered with what's there. Again, I wanted to be brief. "Do not confuse developers" goal hopefully covers your points about communication and information (and going into detail is imposing specific strategies to reach that goal). -Michal On Tue, Oct 7, 2014 at 2:09 PM, Marcel Kinard mailto:cmarc...@gmail.com>> wrote: > Yes, creating a doc is a great next step to solving this. Thanks for doing > that. > > Now that there is a doc to read, I think the goals are wrong. I suggest > the following: > > - enable releases to happen at a faster pace and lower cost > - enable users to easily obtain the latest-and-greatest > - clearly communicate to users what they have, so they can easily > understand how what they currently have differs from the latest-and-greatest > - (keep the hypotheticals as-is, since they make helpful specific stories) > > If folks agree, I can make that change in the doc. > > If we don't start with the right goals, then the rest of the conversation > is moot. > > On Oct 7, 2014, at 11:51 AM, Michal Mocny > mailto:mmo...@chromium.org>> wrote: > > > Created a doc to summarize. Trying to keep it concise and free of > > opinions/conclusions, only context & goals. > > > > > https://docs.google.com/document/d/1VqAVo2AA5vZ7LRmq_9jJ6oa7Nyr2OrjLCfEkBhO-X8U/edit?usp=sharing > > > - > To unsubscribe, e-mail: > dev-unsubscr...@cordova.apache.org<mailto:dev-unsubscr...@cordova.apache.org> > For additional commands, e-mail: > dev-h...@cordova.apache.org<mailto:dev-h...@cordova.apache.org> > >
RE: Independent platform release summary
> - enable users to easily obtain the latest-and-greatest > - clearly communicate to users what they have, so they can easily > understand how what they currently have differs from the latest-and-greatest I think there is another user goal, which may not be so easy to achieve. That is, the ability to easily understand how to take the Cordova release that I have, and do a selective update to get fixes that I need. I.e. I don't want the "latest and greatest", I want the minimal change that fixes the problems I have to fix. Leo -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, October 07, 2014 11:14 AM To: Marcel Kinard Cc: dev Subject: Re: Independent platform release summary Marcel, I added the goal for "latest-and-greatest" which is a good idea. I think your other goals are already covered with what's there. Again, I wanted to be brief. "Do not confuse developers" goal hopefully covers your points about communication and information (and going into detail is imposing specific strategies to reach that goal). -Michal On Tue, Oct 7, 2014 at 2:09 PM, Marcel Kinard wrote: > Yes, creating a doc is a great next step to solving this. Thanks for doing > that. > > Now that there is a doc to read, I think the goals are wrong. I suggest > the following: > > - enable releases to happen at a faster pace and lower cost > - enable users to easily obtain the latest-and-greatest > - clearly communicate to users what they have, so they can easily > understand how what they currently have differs from the latest-and-greatest > - (keep the hypotheticals as-is, since they make helpful specific stories) > > If folks agree, I can make that change in the doc. > > If we don't start with the right goals, then the rest of the conversation > is moot. > > On Oct 7, 2014, at 11:51 AM, Michal Mocny wrote: > > > Created a doc to summarize. Trying to keep it concise and free of > > opinions/conclusions, only context & goals. > > > > > https://docs.google.com/document/d/1VqAVo2AA5vZ7LRmq_9jJ6oa7Nyr2OrjLCfEkBhO-X8U/edit?usp=sharing > > > - > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
RE: Independent platform release summary
per version confusion. > > The Cordova site seems in need of a kind of > Cordova/Platform/CLI/CorePlugin "version dependency matrix" which > officially documents what-works-with-what (e.g. what has passed the > official testing). Perhaps it would look something like the API support > matrix at > http://cordova.apache.org/docs/en/3.6.0/guide_support_index.md.html#Platform%20Support > . > > It might not be easy to do, but if the combined wit of Cordova committers > is unable to clearly document versioning dependencies then what hope is > there for end users to understand it? > > Peter > > -Original Message- > From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew > Grieve > Sent: Sunday, 5 October 2014 5:05 AM > To: Treggiari, Leo > Cc: Brian LeRoux; Andrew Grieve; dev@cordova.apache.org; Marcel Kinard > Subject: Re: Independent platform release summary > > To the best of my knowledge, the version numbers of platforms do not > signify that platforms have the same functionality. Version numbers for > plugins also don't really do this - many plugins have different > capabilities on different platforms even at the same version number. > > For example, whitelists mean different things on different platforms. > Another example is that different platforms added support for ArrayBuffers > over the exec() bridge at different times. Historically - platform version > numbers just mean that they were all released at the same time. > > For the most part, platforms keep changing to keep up with OS changes, but > almost never are there features that are added across all platforms at the > same time. > > > > > On Fri, Oct 3, 2014 at 10:10 PM, Treggiari, Leo > wrote: > > > Here’s my concern regarding versions of things in Cordova. As a > > developer I would use Cordova to write portable applications. Sure, > > maybe some developers use Cordova for other reasons, but, to me at > > least, that seems to be the primary “draw”. > > > > > > > > When writing a portable application, I want it to be as easy as > > possible to know that what I want to use is supported everywhere I > > want to deploy my app. > > > > > > > > Plugins have independent versions. That makes sense. As a developer > > I can see what the API of plugin ‘FOO’ version ‘x.y.z’ is, and then > > look at a table to see where it is supported. That answers my > > questions about APIs and how I can use them in a portable manner. > > > > > > > > I want the same to be true of ‘platform’ and Cordova CLI versions as > > much as possible. Maybe it is true already, but all of these > > independent releases and different platform version numbers make me > > nervous. For example, If a platform releases version 3.6.0, does that > > mean that it supports the same set of features that other platforms > > that release 3.6.0 do? The major.minor.patch versioning scheme makes a > great deal of sense. > > However, imagine all platforms started at version 3.0 with the same > > set of features. Then 4 separate platforms each added 5 different > > features in an upward compatible manner and so they are now all at > > version 3.5.0. How does that help our users figure out how they can > > write a portable application? > > > > > > > > Maybe there is a clear definition of what platform version numbers > > mean and I’m just not aware of it. Maybe a CLI release is not just a > > collection of the latest platform releases and I’m just not aware of > > it. It makes sense that platforms can release asynchronously, but > > does the versioning scheme help the user figure out what is going on > > and when and where they can expect common functionality across platforms? > > > > > > > > Leo > > > > > > > > *From:* brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] *On > > Behalf Of *Brian LeRoux > > *Sent:* Friday, October 03, 2014 5:29 PM > > *To:* Andrew Grieve > > *Cc:* dev@cordova.apache.org; Marcel Kinard; Treggiari, Leo > > > > *Subject:* Re: Independent platform release summary > > > > > > > > I meant pinning all platforms to the cli (so an update to any of the > > platforms pushes everything up one). Anyhow this is way hard to reason > > about. So its an improvement how again? > > > > On Oct 3, 2014 4:55 PM, "Andrew Grieve" wrote: > > > > Is pinning not what's driving this version number discussion? > > > > > > > > Projects are generally made up of more plugins than platforms, but we
RE: Independent platform release summary
Hi Andrew, Thanks for reading and responding. I guess time will tell whether users stumble over this or not. Leo From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Monday, October 06, 2014 12:12 PM To: Treggiari, Leo Cc: Andrew Grieve; Brian LeRoux; dev@cordova.apache.org; Marcel Kinard Subject: Re: Independent platform release summary Leo - that was a very well thought out summary of the state of things! I agree that from a user perspective, it would be easier to understand and reason about things if platform versions corresponded to things that platforms support in a x-platform sense. I think in practice it's just not feasible to co-ordinate platforms in this way. E.g. Android wants to add support for feature X, but iOS is busy trying to make iOS 8 work. Should Android disable the feature until it rises to the top of the priority list for all other platforms? The answer, in my opinion, is that we just need to document "feature X works on Android as of FOO, iOS as of BAR" On Sat, Oct 4, 2014 at 4:05 PM, Treggiari, Leo mailto:leo.treggi...@intel.com>> wrote: >To the best of my knowledge, the version numbers of platforms do not signify >that platforms have the >same functionality. Version numbers for plugins also >don't really do this - many plugins have different >capabilities on different >platforms even at the same version number. If you tell me that is true then I certainly believe you. My question is, is this a good thing? I.e. Is it the best way to help developers who want to write portable hybrid applications or is it just the way things evolved? I just went to http://cordova.apache.org/. It has a button for “Download Cordova version 3.6.0”. What mental model should I be using to understand what I am going to get? The page also gives me a pointer to the documentation - http://cordova.apache.org/docs/en/3.6.0/. Note that I’m focusing on the Cross-platform (CLI) workflow. I currently don’t see why I should care about the Platform-centered workflow. Why? Because my own gut, and what I have heard from speakers at conferences, tells me that if I’m writing for a single platform, I should stick to the native programming environment. Just an aside to explain where I’m coming from. Some of my statements below could be wrong and please correct me when they are. Plugins implement the native device functionality. You point out that they can have different capabilities on different platforms. I understand that this must be the case – i.e. if one platform has a capability that others don’t, there is no logical reason to make that functionality unavailable until all platforms can support it. However, if my goal is a portable application, I hope this is the exception and not the rule. As long as the documentation clearly points out the platform differences, that’s OK. This is from the first page of the Cordova documentation: “Ideally, the JavaScript APIs to that native code are consistent across multiple device platforms.” All I can say is 1+. What functionality does a Cordova CLI “platform” provide? •Cordova “Applications execute within wrappers targeted to each platform”. This is clearly platform specific, but to the app developer this should be “invisible”. •Build with a platform SDK which supports a specific set of platform versions. The build functionality should be ‘opaque’ as long as the developer has the correct prerequisites correctly installed. It is clearly platform specific as to which version(s) of the platform (OS) a Cordova platform supports. •Supports the functionality specified in config.xml: “The config.xml file contains important metadata needed to generate and distribute the application.” The config.xml specification defines cross-platform configuration options. I suggest that these cross-platform options defined by a Cordova version (e.g. 3.6) should be supported by all platforms that release a 3.6.x version.Config.xml seems to identify the functionality “contract” for a platform version, over and above the wrappers and build functionality which are just assumed to work. This may already be the case. Just like with plugin-in APIs, platforms may have platform specific functionality. Again this is OK and should be well documented. Again, when functionality can be abstracted using a common paradigm, that helps developers create portable applications more easily. •Support an embedded WebView: This seems platform specific at this time and that is OK. Maybe it will evolve over time into more portable functionality. What functionality does Cordova CLI itself provide? It defines a workflow that pulls together plugins and platforms and drives the development process for a portable hybrid application. •Support for platform specific code – merges •Support for developer spec
RE: Independent platform release summary
>To the best of my knowledge, the version numbers of platforms do not signify >that platforms have the >same functionality. Version numbers for plugins also >don't really do this - many plugins have different >capabilities on different >platforms even at the same version number. If you tell me that is true then I certainly believe you. My question is, is this a good thing? I.e. Is it the best way to help developers who want to write portable hybrid applications or is it just the way things evolved? I just went to http://cordova.apache.org/. It has a button for “Download Cordova version 3.6.0”. What mental model should I be using to understand what I am going to get? The page also gives me a pointer to the documentation - http://cordova.apache.org/docs/en/3.6.0/. Note that I’m focusing on the Cross-platform (CLI) workflow. I currently don’t see why I should care about the Platform-centered workflow. Why? Because my own gut, and what I have heard from speakers at conferences, tells me that if I’m writing for a single platform, I should stick to the native programming environment. Just an aside to explain where I’m coming from. Some of my statements below could be wrong and please correct me when they are. Plugins implement the native device functionality. You point out that they can have different capabilities on different platforms. I understand that this must be the case – i.e. if one platform has a capability that others don’t, there is no logical reason to make that functionality unavailable until all platforms can support it. However, if my goal is a portable application, I hope this is the exception and not the rule. As long as the documentation clearly points out the platform differences, that’s OK. This is from the first page of the Cordova documentation: “Ideally, the JavaScript APIs to that native code are consistent across multiple device platforms.” All I can say is 1+. What functionality does a Cordova CLI “platform” provide? ·Cordova “Applications execute within wrappers targeted to each platform”. This is clearly platform specific, but to the app developer this should be “invisible”. ·Build with a platform SDK which supports a specific set of platform versions. The build functionality should be ‘opaque’ as long as the developer has the correct prerequisites correctly installed. It is clearly platform specific as to which version(s) of the platform (OS) a Cordova platform supports. ·Supports the functionality specified in config.xml: “The config.xml file contains important metadata needed to generate and distribute the application.” The config.xml specification defines cross-platform configuration options. I suggest that these cross-platform options defined by a Cordova version (e.g. 3.6) should be supported by all platforms that release a 3.6.x version.Config.xml seems to identify the functionality “contract” for a platform version, over and above the wrappers and build functionality which are just assumed to work. This may already be the case. Just like with plugin-in APIs, platforms may have platform specific functionality. Again this is OK and should be well documented. Again, when functionality can be abstracted using a common paradigm, that helps developers create portable applications more easily. ·Support an embedded WebView: This seems platform specific at this time and that is OK. Maybe it will evolve over time into more portable functionality. What functionality does Cordova CLI itself provide? It defines a workflow that pulls together plugins and platforms and drives the development process for a portable hybrid application. ·Support for platform specific code – merges ·Support for developer specific workflow additions - hooks So, should a change in the Cordova CLI version mean a change in the workflow functionality? Platforms and/or Cordova CLI have a connection to the plugin.xml specification, correct? That is, if a new capability is added to plugin.xml, then a newer version of something is required to process it. What else have I missed which drives functionality/version changes (leaving out ‘patch’ versions)? Leo From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Saturday, October 04, 2014 11:05 AM To: Treggiari, Leo Cc: Brian LeRoux; Andrew Grieve; dev@cordova.apache.org; Marcel Kinard Subject: Re: Independent platform release summary To the best of my knowledge, the version numbers of platforms do not signify that platforms have the same functionality. Version numbers for plugins also don't really do this - many plugins have different capabilities on different platforms even at the same version number. For example, whitelists mean different things on different platforms. Another example is that different platforms added support for ArrayBuffers over the exec
RE: Independent platform release summary
Here’s my concern regarding versions of things in Cordova. As a developer I would use Cordova to write portable applications. Sure, maybe some developers use Cordova for other reasons, but, to me at least, that seems to be the primary “draw”. When writing a portable application, I want it to be as easy as possible to know that what I want to use is supported everywhere I want to deploy my app. Plugins have independent versions. That makes sense. As a developer I can see what the API of plugin ‘FOO’ version ‘x.y.z’ is, and then look at a table to see where it is supported. That answers my questions about APIs and how I can use them in a portable manner. I want the same to be true of ‘platform’ and Cordova CLI versions as much as possible. Maybe it is true already, but all of these independent releases and different platform version numbers make me nervous. For example, If a platform releases version 3.6.0, does that mean that it supports the same set of features that other platforms that release 3.6.0 do? The major.minor.patch versioning scheme makes a great deal of sense. However, imagine all platforms started at version 3.0 with the same set of features. Then 4 separate platforms each added 5 different features in an upward compatible manner and so they are now all at version 3.5.0. How does that help our users figure out how they can write a portable application? Maybe there is a clear definition of what platform version numbers mean and I’m just not aware of it. Maybe a CLI release is not just a collection of the latest platform releases and I’m just not aware of it. It makes sense that platforms can release asynchronously, but does the versioning scheme help the user figure out what is going on and when and where they can expect common functionality across platforms? Leo From: brian.ler...@gmail.com [mailto:brian.ler...@gmail.com] On Behalf Of Brian LeRoux Sent: Friday, October 03, 2014 5:29 PM To: Andrew Grieve Cc: dev@cordova.apache.org; Marcel Kinard; Treggiari, Leo Subject: Re: Independent platform release summary I meant pinning all platforms to the cli (so an update to any of the platforms pushes everything up one). Anyhow this is way hard to reason about. So its an improvement how again? On Oct 3, 2014 4:55 PM, "Andrew Grieve" mailto:agri...@chromium.org>> wrote: Is pinning not what's driving this version number discussion? Projects are generally made up of more plugins than platforms, but we don't bump the CLI each time plugins are released. Maybe the simplest thing to do is just have the CLI version not be influenced by platform versions at all. Ideally, we'll finish up the work to write the platform versions in config.xml, and then users won't accidentally update their platform versions without explicitly doing so in their config.xml (or some equivalent CLI command that updates it). On Fri, Oct 3, 2014 at 6:02 PM, Brian LeRoux mailto:b...@brian.io>> wrote: Maybe pinning platforms and the CLI wasn't so bad after all. On Oct 3, 2014 2:34 PM, "Treggiari, Leo" mailto:leo.treggi...@intel.com>> wrote: > I agree that this is, and will be, confusing. It was confusing today in > our own discussions in our own team (who are, in general, fairly Cordova > savvy) to be talking about the Android store issue related to "Cordova > 3.5.1". E.g. what did it mean to be talking about "Cordova 3.5.1", and > what would a user need to do to get the fix? What I took away was that a > user would need Cordova CLI 3.5.0-0.2.7. However, I wouldn't be surprised > if you told me that was wrong... > > Anyway, a completely different (and possibly immediately dismissible) > idea. What if a Cordova CLI version number was the same as the highest > version number of the platforms supported by that Cordova CLI version. > E.g. if the latest highest platform version was Android 3.5.1, then the > Cordova CLI version would be 3.5.1. The supported other-platform version > might be lower - e.g. Windows 3.4.2 (totally made up version number...). > > That doesn't instantly solve all problems. What if the next platform > release after Android 3.5.1 was Windows 3.4.3? Cordova CLI can't remain at > the highest version number. So would Cordova CLI become 3.5.2 or 3.5.1-1? > Should the Windows release be 3.5.2? Are there a specific set of features > associated with a specific platform major version number? It seems that a > platform release named 3.x.y is expected to have a certain set of features > implemented. Is a platform release named 3.4.x expected to have a certain > set of features and a platform named 3.5.x expected to have those features > plus some additional feature? > > In general, what can a user expect these version numbers to mean. E.g. if > I as an app developer want to use a
RE: Independent platform release summary
I agree that this is, and will be, confusing. It was confusing today in our own discussions in our own team (who are, in general, fairly Cordova savvy) to be talking about the Android store issue related to "Cordova 3.5.1". E.g. what did it mean to be talking about "Cordova 3.5.1", and what would a user need to do to get the fix? What I took away was that a user would need Cordova CLI 3.5.0-0.2.7. However, I wouldn't be surprised if you told me that was wrong... Anyway, a completely different (and possibly immediately dismissible) idea. What if a Cordova CLI version number was the same as the highest version number of the platforms supported by that Cordova CLI version. E.g. if the latest highest platform version was Android 3.5.1, then the Cordova CLI version would be 3.5.1. The supported other-platform version might be lower - e.g. Windows 3.4.2 (totally made up version number...). That doesn't instantly solve all problems. What if the next platform release after Android 3.5.1 was Windows 3.4.3? Cordova CLI can't remain at the highest version number. So would Cordova CLI become 3.5.2 or 3.5.1-1? Should the Windows release be 3.5.2? Are there a specific set of features associated with a specific platform major version number? It seems that a platform release named 3.x.y is expected to have a certain set of features implemented. Is a platform release named 3.4.x expected to have a certain set of features and a platform named 3.5.x expected to have those features plus some additional feature? In general, what can a user expect these version numbers to mean. E.g. if I as an app developer want to use a particular recently added feature on multiple platforms, how do I determine which versions of which platforms support the feature and which Cordova CLI version gives me what I want? Sorry, but it is confusing... Leo -Original Message- From: Marcel Kinard [mailto:cmarc...@gmail.com] Sent: Friday, October 03, 2014 1:56 PM To: dev@cordova.apache.org Subject: Re: Independent platform release summary If a bump to major indicates an API change, how is that visible to users? Do users look at the CLI version as "the version of Cordova", or are we expecting users to look at the version of every Cordova component to understand where majors got bumped? While I agree the latter is more correct technically, I think users have been and are currently assuming the former. It would take some education to switch that. On Oct 2, 2014, at 7:51 PM, Andrew Grieve wrote: > I don't think it's necessary to bump CLI major when platforms bump major. > Platforms and CLI are linked only superficially anyways. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
RE: Directory Structure - CLI directory config proposal
Sounds like there is a 3rd use case for a configurable directory structure?: 1 - Allow the user to define the directory structure and have all tools honor it. Maybe because it allows them to more easily use additional tools with Cordova CLI. 2 - A tool needs to impose a particular directory structure but wants to be able to use Cordova functionality without modifying it. 3 - Cordova CLI wants to change THEIR directory structure. I haven't personally experienced the pain of #3 but I can well imagine it. If the Cordova CLI team can't promise to never change the directory structure again, then this is a good reason! Leo -Original Message- From: Victor Sosa [mailto:sosah.vic...@gmail.com] Sent: Thursday, August 28, 2014 9:42 AM To: dev@cordova.apache.org Subject: Re: Directory Structure - CLI directory config proposal >Are users actually using IBM >Worklight IDE interchangeably with cordova-cli tool? I'd like to take this question to show off the Cordova tools we've built in RAD (sorry for being so pretentious) http://www.ibm.com/developerworks/rational/library/hybrid-mobile-applications-rational-application-developer/index.html Quick summary about the directory within the IDE: We respect it as it is so it can be loaded onto other IDEs as well. You can tell how hard it is to maintain a project structure that constantly changes. If there could be a way to standardize the filesystem structure, that will help IDEs a lot 2014-08-28 11:31 GMT-05:00 Carlos Santana : > >Are users actually using IBM > >Worklight IDE interchangeably with cordova-cli tool? If so, could the > >answer just be to ship a worklight-cli? > > We already have a worklight-cli [1], but current implementation assumes a > proprietary directory structure for hybrid apps. > > Going forward I would like to see our IBM platform adopt the cordova cli > directory structure since a lot of tools already using it, and allow > Worklight customers to use any cordova base tool like ionic, cca, phonegap, > etc.. and just add the worklight plugin into it and continue using their > tool of choice. > > If there are tooling features specific to worklight I will add thru plugin > hooks or enhance the worklight-cli to also support the cordova project > structure > > [1]: > > http://www-01.ibm.com/support/knowledgecenter/api/content/SSZH4A_6.2.0/com.ibm.worklight.dev.doc/dev/c_wl_cli_features.html?locale=en > > > > > On Wed, Aug 27, 2014 at 8:10 PM, Treggiari, Leo > wrote: > > > > This would mean that you are either 100% cordova-cli directory > structure > > > compatible, and thus (potentially, at least) tool-interchangeable, or > > your > > > have a different structure and are not interchangeable. > > > > > > Does that not map to user expectations? > > > > Interesting question. So there seems to be two possible use cases for > the > > configurable directory structure: > > > > 1. Allow the user to define the directory structure and have all tools > > honor it. I found your earlier example interesting as well: > > > > > I'd like to see this happen. > > > > > > > > > > Specifically, I would like to see support for a directory structure > > like > > > > > this: > > > > > > > > > > MyApp/ > > > > > cordova_components/ > > > > > platforms/ > > > > > plugins/ > > > > > bower_components/... > > > > > node_modules/... > > > > > ...Rest of contents of MyApp are basically www/ > > Maybe configurable directories help support this? I would hope so. If > > not, then maybe they aren't that useful from a user's perspective. > > This is part of a larger discussion that I would like to see discussed at > > some point. That is, when you want to combine different tooling > > technologies into the hybrid app development workflow, which tool is in > > charge of what? It seems as if Cordova-cli / cordova-lib must be in > charge > > of the plugin selection and the build. To be in charge of the build it > > needs to know everything that has to do with the build - metadata > targeted > > for platform specific manifest files, icons, splash screens, all of the > > plugin code, all of the application's JavaScript code, all of the > > JavaScript libraries being used by the app (I guess these just look like > > application JavaScript code now, and maybe that is how it should be), any > > other native binaries, etc. Another tool could be used for managing > > "components" - e.g. bower/npm. Another tool for generating applications > >
RE: Directory Structure - CLI directory config proposal
> This would mean that you are either 100% cordova-cli directory structure > compatible, and thus (potentially, at least) tool-interchangeable, or your > have a different structure and are not interchangeable. > > Does that not map to user expectations? Interesting question. So there seems to be two possible use cases for the configurable directory structure: 1. Allow the user to define the directory structure and have all tools honor it. I found your earlier example interesting as well: > > > I'd like to see this happen. > > > > > > Specifically, I would like to see support for a directory structure like > > > this: > > > > > > MyApp/ > > > cordova_components/ > > > platforms/ > > > plugins/ > > > bower_components/... > > > node_modules/... > > > ...Rest of contents of MyApp are basically www/ Maybe configurable directories help support this? I would hope so. If not, then maybe they aren't that useful from a user's perspective. This is part of a larger discussion that I would like to see discussed at some point. That is, when you want to combine different tooling technologies into the hybrid app development workflow, which tool is in charge of what? It seems as if Cordova-cli / cordova-lib must be in charge of the plugin selection and the build. To be in charge of the build it needs to know everything that has to do with the build - metadata targeted for platform specific manifest files, icons, splash screens, all of the plugin code, all of the application's JavaScript code, all of the JavaScript libraries being used by the app (I guess these just look like application JavaScript code now, and maybe that is how it should be), any other native binaries, etc. Another tool could be used for managing "components" - e.g. bower/npm. Another tool for generating applications (boilerplate, workflow tasks, etc.) - e.g. yo. Another tool for application emulation - e.g. Ripple. What do these tools need to know about each other to work well together? These tools tend to have their own metadata. Do some tools need to know about each other's metadata? An IDE tends to want to tie these all together and would like to have well-defined metadata and no duplication of information - e.g. what metadata holds the true list of plugins used by this app? I certainly don't know the answers here. 2. A tool needs to impose a particular directory structure but wants to be able to use Cordova functionality without modifying it. Maybe your suggestion is sufficient for that: > If cordova-lib just stopped containing hardcoded paths, and all modules > required paths as inputs, then cordova-cli would have one pre-defined > expected directory structure (not configurable), exactly as it is now. But > if you want to build a downstream IDE/tool with a different structure, you > just pass those values when making calls to cordova-lib. Leo -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Wednesday, August 27, 2014 2:02 PM To: dev Subject: Re: Directory Structure - CLI directory config proposal Hmm, maybe we don't actually need these to be configurable. If cordova-lib just stopped containing hardcoded paths, and all modules required paths as inputs, then cordova-cli would have one pre-defined expected directory structure (not configurable), exactly as it is now. But if you want to build a downstream IDE/tool with a different structure, you just pass those values when making calls to cordova-lib. This would mean that you are either 100% cordova-cli directory structure compatible, and thus (potentially, at least) tool-interchangeable, or your have a different structure and are not interchangeable. Does that not map to user expectations? Are users actually using IBM Worklight IDE interchangeably with cordova-cli tool? If so, could the answer just be to ship a worklight-cli? -Michal On Tue, Aug 26, 2014 at 2:55 PM, Treggiari, Leo wrote: > I was reacting to this in your e-mail: > > > The user may choose to check in the user specific config if the entire > team decides to use that as a project structure. They would not check the > user-config in cases where individual users use different IDEs. > > There should be one directory structure defined for the project. That > metadata is under source code control as well as the sources that are > actually using that directory structure. Ideally, Cordova CLI and all IDEs > use the checked in directory structure. If an IDE can't handle that, then > it would need to change the metadata, and rearrange the project sources, > and, of course, not check in those modifications. So the use of multiple > IDEs and Cordova CLI will work when they all respect t
RE: Directory Structure - CLI directory config proposal
I was reacting to this in your e-mail: > The user may choose to check in the user specific config if the entire team > decides to use that as a project structure. They would not check the > user-config in cases where individual users use different IDEs. There should be one directory structure defined for the project. That metadata is under source code control as well as the sources that are actually using that directory structure. Ideally, Cordova CLI and all IDEs use the checked in directory structure. If an IDE can't handle that, then it would need to change the metadata, and rearrange the project sources, and, of course, not check in those modifications. So the use of multiple IDEs and Cordova CLI will work when they all respect the directory metadata, specifically for the directories that are under source code control. An IDE could do whatever it wants in temporary/working directories. > I could volunteer to take the first stab at that API that cordova-lib > suggests. Does that sound good ? Definitely! Thanks, Leo -Original Message- From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panar...@microsoft.com] Sent: Tuesday, August 26, 2014 11:40 AM To: dev@cordova.apache.org Subject: RE: Directory Structure - CLI directory config proposal It is the latter. The idea is that there is a default directory structure that shall be defined by Cordova CLI, and the IDE can modify it, call tasks like prepare or compile directly from cordova-lib. The IDE could do clever things like copy only modified files, use symlinks, etc. From the hangouts discussion, it was agree that cordova-lib would expose APIs that shall be used by build systems, IDEs and the CLI. We need to finalize on that API. I could volunteer to take the first stab at that API that cordova-lib suggests. Does that sound good ? -Original Message----- From: Treggiari, Leo [mailto:leo.treggi...@intel.com] Sent: Thursday, August 21, 2014 6:45 AM To: dev@cordova.apache.org Subject: RE: Directory Structure - CLI directory config proposal Is the flexible directory structure being proposed so that the CLI can "conform" to a directory structure defined by the IDE, or so that a user can define the directory structure and both the CLI and the IDE use it? I'm an IDE developer, but I don't have a lot a sympathy for the former. The latter is useful. I don't understand why an IDE should think IT defines the directory structure, just like the CLI did prior to this proposal. Leo -Original Message- From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panar...@microsoft.com] Sent: Wednesday, August 20, 2014 10:17 PM To: dev@cordova.apache.org Subject: RE: Directory Structure - CLI directory config proposal Should the platform/plugin save/restore take care of the ability to restore platforms? That way, though the platforms folder is discernable, we do not have to necessarily delete it. The goal of able to re-create a project solely based on the checked-in information still stays. The user may choose to check in the user specific config if the entire team decides to use that as a project structure. They would not check the user-config in cases where individual users use different IDEs. -Original Message- From: Marcel Kinard [mailto:cmarc...@gmail.com] Sent: Tuesday, August 19, 2014 12:50 PM To: dev@cordova.apache.org Subject: Re: Directory Structure - CLI directory config proposal I don't want to dramatically increase the scope of this thread, but I'm wondering if this is the opportunity to get the platforms dir to be 100% generated and discardable between app builds. The goal being that then there is a clean line of what devs should check into SCM and what is in their .gitignore file. It also feels like there should be a slight difference between user-specific config that doesn't go into a team SCM (my copy of cordova-android is in /home/marcelk/customized), and project-specific config that does go into a team SCM (the layout of this meta config that describes where the project dirs are). And yes, it should be 100% compatible with today's directory structure.
RE: Directory Structure - CLI directory config proposal
Is the flexible directory structure being proposed so that the CLI can "conform" to a directory structure defined by the IDE, or so that a user can define the directory structure and both the CLI and the IDE use it? I'm an IDE developer, but I don't have a lot a sympathy for the former. The latter is useful. I don't understand why an IDE should think IT defines the directory structure, just like the CLI did prior to this proposal. Leo -Original Message- From: Parashuram Narasimhan (MS OPEN TECH) [mailto:panar...@microsoft.com] Sent: Wednesday, August 20, 2014 10:17 PM To: dev@cordova.apache.org Subject: RE: Directory Structure - CLI directory config proposal Should the platform/plugin save/restore take care of the ability to restore platforms? That way, though the platforms folder is discernable, we do not have to necessarily delete it. The goal of able to re-create a project solely based on the checked-in information still stays. The user may choose to check in the user specific config if the entire team decides to use that as a project structure. They would not check the user-config in cases where individual users use different IDEs. -Original Message- From: Marcel Kinard [mailto:cmarc...@gmail.com] Sent: Tuesday, August 19, 2014 12:50 PM To: dev@cordova.apache.org Subject: Re: Directory Structure - CLI directory config proposal I don't want to dramatically increase the scope of this thread, but I'm wondering if this is the opportunity to get the platforms dir to be 100% generated and discardable between app builds. The goal being that then there is a clean line of what devs should check into SCM and what is in their .gitignore file. It also feels like there should be a slight difference between user-specific config that doesn't go into a team SCM (my copy of cordova-android is in /home/marcelk/customized), and project-specific config that does go into a team SCM (the layout of this meta config that describes where the project dirs are). And yes, it should be 100% compatible with today's directory structure.
RE: cordova plugin save
I have a few follow-on questions / comments: > Run-time Platform-specific config: > - Automatically created on prepare from a combination of initial application > template and many project properties > - Currently, this is the cordova "platform" config.xml, but also the various > platform metadata files like AndroidManifest.xml and App.plist etc So, part of the job of config.xml is to hold other application definition metadata. In particular, one set of properties is used during preparation to generate the platform specific manifest files. Is this set of config.xml properties ever used directly by a platform at installation or loading, or is it just used during preparation? > Build-time Platform-generic App config: > - Settings *every* developer would agree with. > - Goes into VC, required to build the project. > - Currently, this is /config.xml However, the fact that Cordova CLI does not store the list of platforms and plugins in config.xml, makes it quite incomplete. Project config: - Settings local to a given developers machine / project instance. - Currently, this is /.cordova/config.json - Can also have a global version that applies to all projects, but the content is the same as per-project, conceptually the same. - and ~/.cordova/config.json - [I've been calling "Project config" the "Workspace config". I think both terms are overloaded and confusing. Perhaps we should just call it the "Local config"?] Sounds good. > I think the point of this thread was to figure out if the list of > platform/plugins to restore from should go. With the above descriptions, > here are my 2c: I’m still at a higher level question which is why save/restore at all? It seems like it would be better if the ‘plugin/platform add/remove’ commands maintained their lists in config.xml. There’s no need for a ‘save’ command then. ‘restore’ could be interesting if it can’t be done automatically – i.e. if Cordova CLI knows the list of plugins from config.xml, then it could automatically fetch them if they are missing from the plugins directory. As an IDE developer, my overall goal would be to make it such that Cordova CLI and an IDE could be used seamlessly on the same application. E.g. support a user who likes to use both at different times, and teams where some users want to use the CLI and other users want to use an IDE. Leo From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, August 14, 2014 5:53 AM To: dev Cc: Treggiari, Leo Subject: Re: cordova plugin save Summarizing / simplifying since this thread has run away: Run-time Platform-specific config: - Automatically created on prepare from a combination of initial application template and many project properties - Currently, this is the cordova "platform" config.xml, but also the various platform metadata files like AndroidManifest.xml and App.plist etc Build-time Platform-generic App config: - Settings *every* developer would agree with. - Goes into VC, required to build the project. - Currently, this is /config.xml Project config: - Settings local to a given developers machine / project instance. - Currently, this is /.cordova/config.json - Can also have a global version that applies to all projects, but the content is the same as per-project, conceptually the same. - and ~/.cordova/config.json - [I've been calling "Project config" the "Workspace config". I think both terms are overloaded and confusing. Perhaps we should just call it the "Local config"?] I think the point of this thread was to figure out if the list of platform/plugins to restore from should go. With the above descriptions, here are my 2c: - The list of plugin id / url and optional version go into the App config. Every developer I believe will agree with the list itself being a requirement to build the app. - Local settings such as searchpaths go in the local config, since I may have cloned my repos differently than you have. - I should be able to override the list of version requirements easily, these are just suggestions to help simplify sharing, not rules. - Ditto for platforms. Does that make sense? If we don't like the current app/local config, lets bring that up in a different thread! -Michal On Thu, Aug 14, 2014 at 4:15 AM, Gorkem Ercan mailto:gorkem.er...@gmail.com>> wrote: The goal with the save/restore work is to make it as convenient as possible to share cordova projects, so Chuck was right on the money. We also have an accompanying "save/restore platforms" command. Once the work is complete CLI should be able to restore plugins and platforms folders of a shared project with the plugins installed and platforms that was worked on. I actually think of config.xml as an app metadata file. Another of my
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 (.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 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,
Re: cordova plugin save
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 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 > 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. >> >>
cordova plugin save
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
