Re: build.json file
2 cents: A pattern I was introduced to recently was simply to use:
name.SECRET.json
For any sensitive settings for any file, and:
name.SAMPLE.json
To provide dummy data for any SECRET files as a source of documentation.
Then, in your .gitignore, you can just ignore **/*.SECRET.*, and write a
single helper method for reading any config files which knows to merge in
SECRET files.
Has worked well for projects I've used recently.
-Michal
On Mon, May 18, 2015 at 3:39 PM, Steven Gill stevengil...@gmail.com wrote:
I am generally hesitant to add more config files to cordova projects. I
would rather see us converge to package.json as the de facto config file
over config.xml in the future.
Aside from that, I do see the value in having a build.json file which
contains sensitive information (certs, passwords, signing identity) and
doesn't get packaged up with the app or checked in to git repos. So this
looks good to me. Also like the ideas for the future.
-Steve
On Mon, May 18, 2015 at 10:25 AM, Nikhil Khandelwal
nikhi...@microsoft.com
wrote:
I want to bring this to the attention of everyone that I have added a
build.json for specifying signing parameters for different platforms as
part of cordova build. Here are the design principles I used:
- build.json should be used over config.xml for specifying build
time behavior (as opposed to runtime). In the case of signing, it did not
make sense to have paths to certs, passwords, signing identity info etc.
to
be part of config.xml and be packaged with the app itself.
- build.json file has the following schema:
{
platformName : {
debug : {
propertyName :
propertyValue
},
release : {
propertyName :
propertyValue
},
}
- So far all properties that can be specified using build.json
can be specified using command line args. Command line args take
precedence
if it's specified at both places.
- By convention, a file named 'build.json' on the project root
alongside 'config.xml' will be passed to platform CLI scripts with its
location using the '--buildConfig' argument. There is a PR for this here:
https://github.com/apache/cordova-lib/pull/215
Ideas for future:
- Cordova CLI will allow to specify a custom build.json
- Add docs for this talking about build.json
- Unify parsing logic for build.json command line args across
platforms in a shared module.
- Move some of the config.xml properties to build.json since
they
belong better there.
Let me know if you have any questions, ideas or concerns related to this.
Thanks,
Nikhil
Re: Dearly Departed
:D On Mon, May 18, 2015 at 7:01 PM, Jesse purplecabb...@gmail.com wrote: To the committers who have recently been reassigned, and will be committing less over the next while, please release any jira issues you have assigned to yourselves, and if possible/relevant, add some comments to help whoever comes after you. TIA Cheers, Jesse @purplecabbage risingj.com
Re: Behavior of --copy-from
The *intention* of copy-from / link-to is to import either (a) a web project, or (b) another cordova project. We used to check for (b) I think by the existence of a config.xml and www/ (note: double check config.xml is required). If that check passes, we copy those two nested contents only (I think) directly into the root of your new project. If the check failed, we would copy the entire folder into the www/ of the new project. There's some bug since you should get a valid cordova project no matter what the contents of the import (with caveats of importing invalid config.xml or bad apps). -Michal On Tue, May 19, 2015 at 7:12 AM, Raymond Camden raymondcam...@gmail.com wrote: I definitely can't recreate the end up with a folder that isn't a project but --copy-from does seem to ignore files it doesn't recognize. I filed a bug for it. On Tue, May 19, 2015 at 6:07 AM, Raymond Camden raymondcam...@gmail.com wrote: No, what seems to happen to me is: If I copy-from a directory that has a www folder in it, then it is treated as the *root* of the new project and a proper Cordova folder is not created. If I copy-from a dir that does NOT have a www folder in it, it is treated as the www folder of a new project. Nope, I lie. Ok, so this is weirder than I imagined. I made a new folder called testwithwww. It has a file called something.txt and a folder called www with an index.html. I sourced a new project with it. My www folder copied fine, but something.txt was completely ignored. It did, however, make a proper Cordova project. So this is a bit different from what I saw earlier where my first test created something that wasn't a project, but it definitely failed to copy a file over. On Tue, May 19, 2015 at 2:18 AM, Dmitry Blotsky dblot...@microsoft.com wrote: Hi Raymond, The semantics of “--copy-from” are: copy the passed path in place of the new project's “www” directory, which “cordova create” seems to obey. Is that not what happened in your case? However, the failure to copy over paths that start with “.” looks like a bug to me. Unless someone says otherwise, feel totally free file a bug in JIRA. Kindly, Dmitry On May 17, 2015, at 7:56 AM, Raymond Camden raymondcam...@gmail.com mailto:raymondcam...@gmail.com wrote: Well shoot - as a follow up - if I make a new Cordova project, lets call it testsource2, and then copy .settings to it, and then follow up by making a new project that uses copy-from pointing to testsource2, the CLI isn't copying the .settings directory. That is a bug for sure, right? On Sun, May 17, 2015 at 9:51 AM, Raymond Camden raymondcam...@gmail.commailto:raymondcam...@gmail.com wrote: I thought I remember seeing a thread on this, but GMail is being a bit cranky about how I search today. I had thought that if you used --copy-from and the directory you used included www itself, then the folders would be copied over to a new project and merged in with normal default items. I just tested with a folder that had 2 items: A .settings directory and a www directory. While the CLI reported no issues, it did not create a proper Cordova project. It literally just copied .settings and www, but didn't do anything else to create a proper Cordova project. So I'm guessing that the expectation is that if you do not use a folder meant to be www, then your source directory should contain everything required for a proper Cordova project. But that's not forward-proof though. Imagine if Cordova 6 changes the project structure a bit so that a Foo folder is required, then I wouldn't be able to use my source dir w/o changing it. (Which, ok, probably won't happen.) So is this expected? Is this ok with others? Should I file a ER perhaps to make --copy-from in this situation add the rest of the project assets? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.commailto:raymondcam...@gmail.com Blog : www.raymondcamden.comhttp://www.raymondcamden.com Twitter: raymondcamden -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.commailto:raymondcam...@gmail.com Blog : www.raymondcamden.comhttp://www.raymondcamden.com/ Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.orgmailto: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.orgmailto: dev-h...@cordova.apache.org -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog :
Re: Behavior of --copy-from
Just checked: https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/create.js#L179 Seems config.xml isn't required. We import the nested www/ if it exists, and same for config.xml merges and hooks. I would not expect any files/folders outside of www to be copied, dotfiles or not. If this isn't desired behaviour, we need a feature request. On Tue, May 19, 2015 at 12:01 PM, Michal Mocny mmo...@chromium.org wrote: The *intention* of copy-from / link-to is to import either (a) a web project, or (b) another cordova project. We used to check for (b) I think by the existence of a config.xml and www/ (note: double check config.xml is required). If that check passes, we copy those two nested contents only (I think) directly into the root of your new project. If the check failed, we would copy the entire folder into the www/ of the new project. There's some bug since you should get a valid cordova project no matter what the contents of the import (with caveats of importing invalid config.xml or bad apps). -Michal On Tue, May 19, 2015 at 7:12 AM, Raymond Camden raymondcam...@gmail.com wrote: I definitely can't recreate the end up with a folder that isn't a project but --copy-from does seem to ignore files it doesn't recognize. I filed a bug for it. On Tue, May 19, 2015 at 6:07 AM, Raymond Camden raymondcam...@gmail.com wrote: No, what seems to happen to me is: If I copy-from a directory that has a www folder in it, then it is treated as the *root* of the new project and a proper Cordova folder is not created. If I copy-from a dir that does NOT have a www folder in it, it is treated as the www folder of a new project. Nope, I lie. Ok, so this is weirder than I imagined. I made a new folder called testwithwww. It has a file called something.txt and a folder called www with an index.html. I sourced a new project with it. My www folder copied fine, but something.txt was completely ignored. It did, however, make a proper Cordova project. So this is a bit different from what I saw earlier where my first test created something that wasn't a project, but it definitely failed to copy a file over. On Tue, May 19, 2015 at 2:18 AM, Dmitry Blotsky dblot...@microsoft.com wrote: Hi Raymond, The semantics of “--copy-from” are: copy the passed path in place of the new project's “www” directory, which “cordova create” seems to obey. Is that not what happened in your case? However, the failure to copy over paths that start with “.” looks like a bug to me. Unless someone says otherwise, feel totally free file a bug in JIRA. Kindly, Dmitry On May 17, 2015, at 7:56 AM, Raymond Camden raymondcam...@gmail.com mailto:raymondcam...@gmail.com wrote: Well shoot - as a follow up - if I make a new Cordova project, lets call it testsource2, and then copy .settings to it, and then follow up by making a new project that uses copy-from pointing to testsource2, the CLI isn't copying the .settings directory. That is a bug for sure, right? On Sun, May 17, 2015 at 9:51 AM, Raymond Camden raymondcam...@gmail.commailto:raymondcam...@gmail.com wrote: I thought I remember seeing a thread on this, but GMail is being a bit cranky about how I search today. I had thought that if you used --copy-from and the directory you used included www itself, then the folders would be copied over to a new project and merged in with normal default items. I just tested with a folder that had 2 items: A .settings directory and a www directory. While the CLI reported no issues, it did not create a proper Cordova project. It literally just copied .settings and www, but didn't do anything else to create a proper Cordova project. So I'm guessing that the expectation is that if you do not use a folder meant to be www, then your source directory should contain everything required for a proper Cordova project. But that's not forward-proof though. Imagine if Cordova 6 changes the project structure a bit so that a Foo folder is required, then I wouldn't be able to use my source dir w/o changing it. (Which, ok, probably won't happen.) So is this expected? Is this ok with others? Should I file a ER perhaps to make --copy-from in this situation add the rest of the project assets? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.commailto:raymondcam...@gmail.com Blog : www.raymondcamden.comhttp://www.raymondcamden.com Twitter: raymondcamden -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.commailto:raymondcam...@gmail.com Blog : www.raymondcamden.comhttp://www.raymondcamden.com/ Twitter: raymondcamden
Re: Behavior of --copy-from
And for yet more context, I think this is because we did not want to import plugins / platforms, and so did not just cp -R the whole thing, but perhaps thats a better strategy. Up to you now :) -Michal On Tue, May 19, 2015 at 12:07 PM, Michal Mocny mmo...@chromium.org wrote: Just checked: https://github.com/apache/cordova-lib/blob/master/cordova-lib/src/cordova/create.js#L179 Seems config.xml isn't required. We import the nested www/ if it exists, and same for config.xml merges and hooks. I would not expect any files/folders outside of www to be copied, dotfiles or not. If this isn't desired behaviour, we need a feature request. On Tue, May 19, 2015 at 12:01 PM, Michal Mocny mmo...@chromium.org wrote: The *intention* of copy-from / link-to is to import either (a) a web project, or (b) another cordova project. We used to check for (b) I think by the existence of a config.xml and www/ (note: double check config.xml is required). If that check passes, we copy those two nested contents only (I think) directly into the root of your new project. If the check failed, we would copy the entire folder into the www/ of the new project. There's some bug since you should get a valid cordova project no matter what the contents of the import (with caveats of importing invalid config.xml or bad apps). -Michal On Tue, May 19, 2015 at 7:12 AM, Raymond Camden raymondcam...@gmail.com wrote: I definitely can't recreate the end up with a folder that isn't a project but --copy-from does seem to ignore files it doesn't recognize. I filed a bug for it. On Tue, May 19, 2015 at 6:07 AM, Raymond Camden raymondcam...@gmail.com wrote: No, what seems to happen to me is: If I copy-from a directory that has a www folder in it, then it is treated as the *root* of the new project and a proper Cordova folder is not created. If I copy-from a dir that does NOT have a www folder in it, it is treated as the www folder of a new project. Nope, I lie. Ok, so this is weirder than I imagined. I made a new folder called testwithwww. It has a file called something.txt and a folder called www with an index.html. I sourced a new project with it. My www folder copied fine, but something.txt was completely ignored. It did, however, make a proper Cordova project. So this is a bit different from what I saw earlier where my first test created something that wasn't a project, but it definitely failed to copy a file over. On Tue, May 19, 2015 at 2:18 AM, Dmitry Blotsky dblot...@microsoft.com wrote: Hi Raymond, The semantics of “--copy-from” are: copy the passed path in place of the new project's “www” directory, which “cordova create” seems to obey. Is that not what happened in your case? However, the failure to copy over paths that start with “.” looks like a bug to me. Unless someone says otherwise, feel totally free file a bug in JIRA. Kindly, Dmitry On May 17, 2015, at 7:56 AM, Raymond Camden raymondcam...@gmail.com mailto:raymondcam...@gmail.com wrote: Well shoot - as a follow up - if I make a new Cordova project, lets call it testsource2, and then copy .settings to it, and then follow up by making a new project that uses copy-from pointing to testsource2, the CLI isn't copying the .settings directory. That is a bug for sure, right? On Sun, May 17, 2015 at 9:51 AM, Raymond Camden raymondcam...@gmail.commailto:raymondcam...@gmail.com wrote: I thought I remember seeing a thread on this, but GMail is being a bit cranky about how I search today. I had thought that if you used --copy-from and the directory you used included www itself, then the folders would be copied over to a new project and merged in with normal default items. I just tested with a folder that had 2 items: A .settings directory and a www directory. While the CLI reported no issues, it did not create a proper Cordova project. It literally just copied .settings and www, but didn't do anything else to create a proper Cordova project. So I'm guessing that the expectation is that if you do not use a folder meant to be www, then your source directory should contain everything required for a proper Cordova project. But that's not forward-proof though. Imagine if Cordova 6 changes the project structure a bit so that a Foo folder is required, then I wouldn't be able to use my source dir w/o changing it. (Which, ok, probably won't happen.) So is this expected? Is this ok with others? Should I file a ER perhaps to make --copy-from in this situation add the rest of the project assets? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.commailto:raymondcam...@gmail.com Blog : www.raymondcamden.comhttp://www.raymondcamden.com Twitter: raymondcamden
Re: before you go! (Andrew Michal)
I wouldn't expect to be able to convert existing hardware beacons to this new format. However, you can literally create your own beacon by running a node script on a BT capable laptop: https://github.com/google/uribeacon/tree/master/beacons/nodejs -- Fun fact: Don Coleman contributed this, small world! Many other examples of uribeacon advertisers and scanners on that repo. Also, Andrew is moving to a different project, its just me who gets to do cool things ;) On Tue, May 5, 2015 at 5:51 PM, Lisa Seacat DeLuca ldel...@us.ibm.com wrote: I'd also like to clime in that I've been put on another project that still uses Cordova but I'm not part of our open source team anymore. So I've been following what has been going on with Cordova but haven't been as active as I'd like to be. Michal~ you gave me a good distraction reading up on the physical web all afternoon. I'm a little jealous I'm not playing with them. Might have to contribute to the open source project. Do you know if it's possible to convert a beacon like an estimote beacon into a uribeacon? Lisa @LisaSeacat www.LisaSeacat.com
FYI - Moving to new team, seeing me less around here
I've moved to a new team here at Google (Physical Web: https://google.github.io/physical-web/). This means I will likely be speaking up less often going forward, though I'll still be keeping an eye on these lists for the foreseeable future. And I'm itching to write some cordova plugins for the Physical Web... -Michal
Re: [ANNOUNCEMENT] Cordova Tools (CLI 5.0.0) + Plugins (renamed) have been released
Happy Santa? On Wed, Apr 22, 2015 at 11:25 AM, Andrew Grieve agri...@chromium.org wrote: WOOOHOOOHOHOOO!! On Wed, Apr 22, 2015 at 11:04 AM, Raymond Camden raymondcam...@gmail.com wrote: Ah - a shift reload fixed it. Is the caching a bit high for the page? On Wed, Apr 22, 2015 at 7:15 AM, Carlos Santana csantan...@gmail.com wrote: Hi Ray Home page http://cordova.apache.org shows the last 3 blog posts with corresponding Read More that takes you directly to post. 21 Apr 2015 » Tools Release: April 21, 2015 http://cordova.apache.org/news/2015/04/21/tools-release.html 21 Apr 2015 » Plugins Release and Moving plugins to npm: April 21, 2015 http://cordova.apache.org/announcements/2015/04/21/plugins-release-and-move-to-npm.html 15 Apr 2015 » Apache Cordova Android 4.0.0 http://cordova.apache.org/announcements/2015/04/15/cordova-android-4.0.0.html If you see this now, maybe it was a caching problem, and now is resolved. On Wed, Apr 22, 2015 at 12:53 AM, Shazron shaz...@gmail.com wrote: It should be, I see it? On Tue, Apr 21, 2015 at 8:12 PM, Raymond Camden raymondcam...@gmail.com wrote: Query - the blog listing on the home page isn't updated. Is that a known issue? On Tue, Apr 21, 2015 at 5:46 PM, Steven Gill stevengil...@gmail.com wrote: Tools and plugins have been released. Includes fetching from npm and renamed plugins. Plugins: http://cordova.apache.org/announcements/2015/04/21/plugins-release-and-move-to-npm.html Tools: http://cordova.apache.org/news/2015/04/21/tools-release.html Tweets: https://twitter.com/apachecordova/status/590676867046383616 https://twitter.com/apachecordova/status/590677169745068034 https://twitter.com/apachecordova/status/590677437454929920 -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - 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 -- Carlos Santana csantan...@gmail.com -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Scoped package names for npm?
Okay fair enough. I was hoping that with the lack of tools release to stable, we can rename without affecting end users *right now*, but not *soon*. If we never want to use scopes, fair enough. If we ever do, it will only get more difficult. -Michal On Tue, Apr 21, 2015 at 11:04 AM, Andrew Grieve agri...@chromium.org wrote: Given the state of some of our plugins, dropping the distinguishing namespace might be a good thing :P On Tue, Apr 21, 2015 at 8:45 AM, Horn, Julian C julian.c.h...@intel.com wrote: I am also against another rename. These name changes are very costly and disruptive. There is code in several places that assumes that you can enumerate the plugins selected by a project by enumerating the subdirectories of plugins. If you allow a plugin root folder to be more than a single directory, like @cordova/plugin-device then you break that code. Also, please remember that when you rename a plugins, you require people to update every dependency tag that refers to that plugin, unless you want to rely on the rename machinery forever. Julian -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Monday, April 20, 2015 9:42 PM To: dev@cordova.apache.org Subject: Re: Scoped package names for npm? I also like scoped packages but am against another rename. Haha. I know organizations are coming soon so we will be able to create the Cordova organization and I believe scope packages that way. Add PMC members to the organization to be able to publish instead of relying on a Cordova npm user account. Lets wait and see how it goes. On Apr 20, 2015 2:29 PM, Jesse purplecabb...@gmail.com wrote: re: the scoped package id, I like it, but not sure we want to change them again ... and how much of our existing world will it break. Can we install an '@' id currently on all platforms? It will result in a www/plugins/@cordova/plugin-device/ folder right now, won't it? re: other questions Personally, I would rather see only committers able to publish to our scope (assuming we go that way), just like we wanted to prevent non committers from using org.apache.cordova namespace. I considered 'cordova plugin add device' awhile back, I was going to do it directly in plugman, but I decided against it. Currently it would mean a 3rd attempt to find the plugin over http; 1) cpr, 2) npm, 3)munge name and go back to npm By this time, I think I would just ask the user what they really want. We could also do this via cordova-registry-mapper aliases. @purplecabbage risingj.com On Mon, Apr 20, 2015 at 2:13 PM, Parashuram N (MS OPEN TECH) panar...@microsoft.com wrote: Scopes are like namespaces. In the reverse domain name world, org.apache.cordova was considered a namespace, right ? We did not want non core packages to publish to that namespace, so does the same argument apply ? Alternatively, we can think of scope as packages that apply to a particular environment - for example, all cordova packages would be @cordova scope. -Original Message- From: Michal Mocny [mailto:mmo...@google.com] Sent: Monday, April 20, 2015 2:03 PM To: dev Subject: Re: Scoped package names for npm? Other questions to answer: - Can 3rd-parties publish to this scope? - Do we want them to? - Do we want to default to @cordova scope if none is provided, such that you could do `cordova plugin add device`? -Michal On Mon, Apr 20, 2015 at 5:00 PM, Michal Mocny mmo...@google.com wrote: https://docs.npmjs.com/getting-started/scoped-packages Should we be @cordova/plugin-device instead of cordova-plugin-device? -Michal - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Scoped package names for npm?
https://docs.npmjs.com/getting-started/scoped-packages Should we be @cordova/plugin-device instead of cordova-plugin-device? -Michal
Re: Scoped package names for npm?
Other questions to answer: - Can 3rd-parties publish to this scope? - Do we want them to? - Do we want to default to @cordova scope if none is provided, such that you could do `cordova plugin add device`? -Michal On Mon, Apr 20, 2015 at 5:00 PM, Michal Mocny mmo...@google.com wrote: https://docs.npmjs.com/getting-started/scoped-packages Should we be @cordova/plugin-device instead of cordova-plugin-device? -Michal
Re: Experimenting with API for cordova tooling
Great enthusiasm! Mark is currently at ApacheCon and then taking a few vacation days, so I'm not sure if he will answer this quickly. Figured I'd chime in for now. I think that exactly as you say, the PlatformProject work was started by Mark as a way to separate the divide between platforms and lib. This experiment I think came out of discussions on how best to move out the platform parsers (search ML for Move platform parsers from CLI to platforms started by Steven Gill). I also emphasize earlier points that these are experiments and are totally open for re-design. I don't have concrete steps to propose for going forward, but sounds like you already have some good ideas. Another topic that came out of discussion at Hangout was to create a cleaner cordova-lib-core, still leaving it within the cordova-lib repo. High-level strawman suggests this core would not do various input parsing or make any assumptions about project directory structure, but would have a very strict and simple interface, which various higher levels use to do with it what they will. -Michal On Wed, Apr 15, 2015 at 12:33 PM, Rob Paveza rob.pav...@microsoft.com wrote: This is a cool project. I'm curious, how much work do you think it'd be to refactor the cordova CLI to interact with the projects via the PlatformProject interface? We've been talking about how we could pull some of the cordova-lib platform-specific dependencies out and put them into the platforms (one example that comes to mind is having platform-specific parameters on plugin), so that platform-specific code lives in the platform implementation rather than cordova-lib. Having each platform derive from PlatformProject seems like an excellent first step, since (at least between -lib and -windows) once -lib hands off the project to the platform code, it's just go time. What do you think the next steps are in terms of your API shape and plans? Where do you see needing help most, where can I pitch in to get your project going more? -Original Message- From: Mark Koudritsky [mailto:kam...@google.com] Sent: Friday, April 10, 2015 12:50 PM To: dev@cordova.apache.org Subject: Experimenting with API for cordova tooling From today's hangout discussion, here are the links to our experiments with using cordova tooling via API rather than CLI. It is loosely based on my older experiments here https://github.com/kamrik/CordovaGulpTemplate But his time there is a separate wrapper that exposes a more object oriented API and reaches deeper into cordova-lib. It introduces a central object called PlatformProject that represents a single platform. The wrapper is here: https://github.com/kamrik/CordovaPlatformProject Please consider it experimental and feel free to fork and play with it. A demo app that uses this wrapper https://github.com/kamrik/cordova-api-example The ServiceWorker-to-Cordova script that uses the same wrapper https://github.com/MobileChromeApps/sw2cdv I'll also be giving a presentation about this at ApacheCon next week, draft slides are here http://kamrik.org/PlatformProjectSlides
Re: proposal for cordova cli
..we already have this? cordova build android ... BUILD SUCCESSFUL Total time: 6 seconds Built the following apk(s): Perhaps some platforms don't? Perhaps older build scripts don't? -Michal On Wed, Apr 15, 2015 at 3:53 PM, Willy Aguirre marti1...@gmail.com wrote: Hi, I would like to add time after build BUILD SUCCESSFUL 12:39:44 - Total time: 17 seconds Built the following apk(s): Regards! -- Willy Aguirre | @willrre Blog: http://osgux.tumblr.com/ Mozilla Rep: https://reps.mozilla.org/u/Willy/ Mozilla Hispano - Willyaguirre https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre
Re: proposal for cordova cli
I'm with Ian.. I don't think every user of cordova wants output in the form
you desire, so you will be much better off wrapping the output with a
script that does exactly what you need.
-Michal
On Wed, Apr 15, 2015 at 4:58 PM, Willy Aguirre marti1...@gmail.com wrote:
is more easy something like this: 15/04/2015 - Total time: 12 seconds
BUILD SUCCESSFUL
Total time: 12 seconds
Built the following apk(s):
G:\SIICEX-Rutas-Phonegap\siicex-rutas\platforms\android\ant-build\CordovaApp-debug.apk
The current date is: 15/04/2015
Enter the new date: (dd-mm-yy) ?
Can I send a PR about this change ?
2015-04-15 15:35 GMT-05:00 Ian Clelland iclell...@chromium.org:
This is a general issue with command line tools, but can be solved in a
consistent way. I'll usually do something like this:
cordova build android date
As output, I see:
...
BUILD SUCCESSFUL
Total time: 31.314 secs
Built the following apk(s):
/Users/iclelland/test/platforms/android/build/outputs/apk/android-debug.apk
Wed Apr 15 16:33:30 EDT 2015
Does that work for you?
On Wed, Apr 15, 2015 at 4:21 PM, Willy Aguirre marti1...@gmail.com
wrote:
I have:
cordova -version
4.2.0
I am working with android platform but I need to know when it built
{12:39:44 - }
2015-04-15 15:12 GMT-05:00 Michal Mocny mmo...@chromium.org:
..we already have this?
cordova build android
...
BUILD SUCCESSFUL
Total time: 6 seconds
Built the following apk(s):
Perhaps some platforms don't? Perhaps older build scripts don't?
-Michal
On Wed, Apr 15, 2015 at 3:53 PM, Willy Aguirre marti1...@gmail.com
wrote:
Hi, I would like to add time after build
BUILD SUCCESSFUL
12:39:44 - Total time: 17 seconds
Built the following apk(s):
Regards!
--
Willy Aguirre | @willrre
Blog: http://osgux.tumblr.com/
Mozilla Rep: https://reps.mozilla.org/u/Willy/
Mozilla Hispano - Willyaguirre
https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre
--
Willy Aguirre | @willrre
Blog: http://osgux.tumblr.com/
Mozilla Rep: https://reps.mozilla.org/u/Willy/
Mozilla Hispano - Willyaguirre
https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre
--
Willy Aguirre | @willrre
Blog: http://osgux.tumblr.com/
Mozilla Rep: https://reps.mozilla.org/u/Willy/
Mozilla Hispano - Willyaguirre
https://www.mozilla-hispano.org/documentacion/Usuario:Willyaguirre
Re: Tools for Cordova Commits Presentation Slides
I think we should implement a smiley adding email triggering system hosted by apache. I don't have time to work on this, but it could be implemented using... :D On Mon, Apr 13, 2015 at 5:36 PM, Shazron shaz...@gmail.com wrote: Yeah http 403. Andrew, if you don't mind maybe post a file link? Or slideshare or something :) -- how am I doing On Mon, Apr 13, 2015 at 2:31 PM, Homer, Tony tony.ho...@intel.com wrote: First, thanks for sharing this! Second, I tried to download so I could read offline, but I guess the permissions don¹t allow it? It seemed to silently fail. If that is intended, no problem. Thanks again, reading online now. Tony On 4/13/15, 4:58 PM, Jesse purplecabb...@gmail.com wrote: And I almost forgot the last bit I learnt from your slides ... ;) smileys! @purplecabbage risingj.com On Mon, Apr 13, 2015 at 1:53 PM, Jesse purplecabb...@gmail.com wrote: I got a little confused by slide #54/55 My name is circled, but I didn't merge that pull request, I commented on the next one #172 ... of course, if I had your narration, I would have been fine. Thanks for sharing this! Were the talks recorded? @purplecabbage risingj.com On Mon, Apr 13, 2015 at 1:31 PM, Michal Mocny mmo...@chromium.org wrote: Great lessons learned! On Mon, Apr 13, 2015 at 4:29 PM, Murat Sutunc mura...@microsoft.com wrote: Looks pretty good to me! -Original Message- From: agri...@google.com [mailto:agri...@google.com] On Behalf Of Andrew Grieve Sent: Monday, April 13, 2015 1:14 PM To: dev Subject: Tools for Cordova Commits Presentation Slides Created the slides to be readable without me talking over them in hopes to be a form of documentation for the project :) Mainly: - how to use some of coho, - how to do a pull request - picture guides to visual debugging for node, android, ios http://goo.gl/ciGnaR - 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: [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 agri...@chromium.org 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
Re: [Vote] 4.0.0 Android Release
Also, not directly related to this release, but cordova-plugin-crosswalk-webview README.md instructions list Platform workflow first, then CLI workflow. Should we swap that? Users will go there for install instructions.. I think the platform scripts workflow should perhaps just link out to a separate doc even.. -Michal On Thu, Apr 9, 2015 at 12:54 PM, Michal Mocny mmo...@chromium.org wrote: 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 agri...@chromium.org 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
Re: [Vote] 4.0.0 Android Release
Certainly doesn't block! Heres a PR for the plugin docs: https://github.com/MobileChromeApps/cordova-crosswalk-engine/pull/21 On Thu, Apr 9, 2015 at 1:00 PM, Joe Bowser bows...@gmail.com wrote: This should probably go to discuss, and I'm not sure blocks the release. Sorry to clutter the vote thead, I'll vote once I'm done testing. On Thu, Apr 9, 2015 at 9:57 AM Michal Mocny mmo...@chromium.org wrote: Also, not directly related to this release, but cordova-plugin-crosswalk-webview README.md instructions list Platform workflow first, then CLI workflow. Should we swap that? Users will go there for install instructions.. I think the platform scripts workflow should perhaps just link out to a separate doc even.. -Michal On Thu, Apr 9, 2015 at 12:54 PM, Michal Mocny mmo...@chromium.org wrote: 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 agri...@chromium.org 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
Re: [DISCUSS] Cordova-Android 4.0.0 Release
Splashscreens was mentioned, icons was not. I don't think there is an icons change? On Thu, Apr 9, 2015 at 1:17 PM, Joe Bowser bows...@gmail.com wrote: So, wasn't there a change regarding icons and spashscreens being moved? I have no idea if we want to add that, or if adding that should happen after the release? On Wed, Apr 8, 2015 at 7:09 PM Andrew Grieve agri...@chromium.org wrote: 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 agri...@chromium.org 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 purplecabb...@gmail.com wrote: Sweet! @purplecabbage risingj.com On Tue, Apr 7, 2015 at 8:35 AM, Andrew Grieve agri...@chromium.org wrote: Let's do it! On Mon, Apr 6, 2015 at 7:33 PM, Joe Bowser bows...@gmail.com 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 agri...@chromium.org 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 plugin 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 plugin name=cordova-plugin-whitelist /). 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 shaz...@gmail.com 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: OK, this is a three month old thread, and we're waiting on a discussion before we release something? I really think we should go to a vote thread now that we have a legacy whitelist plugin and a new style whitelist plugin. We shouldn't keep constantly delaying this release because of what's happening on other platforms, especially since we already pluginized the whitelist. Can we please release soon? On Thu, Mar 12, 2015 at 2:20 PM Nikhil Khandelwal nikhi...@microsoft.com wrote: I know we discussed a couple of approaches implementing the default whitelist
Re: [DISCUSS] Cordova TOOLS release - 4.3.1
+1 to 5.0.0. Will Android bump to 4.0 mean cli major rev? I think it would just be a minor, no? -Michal On Mon, Apr 6, 2015 at 5:45 PM, Steven Gill stevengil...@gmail.com wrote: I'm thinking we should make this release cordova 5.0.0. It will be the first release with fetching from npm and encouraging developers do use the new plugin names. I think a plugins release should go out alongside it. It would be really nice if we could get android 4.0.0 released and pinned before it too but I won't hold my breath on this. On Mon, Apr 6, 2015 at 2:07 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: This is a good one to take in before release, since it changes config.xml schema: https://github.com/apache/cordova-lib/pull/202. It needs to be code reviewed. Thanks, Nikhil -Original Message- From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] Sent: Monday, April 6, 2015 1:36 PM To: dev@cordova.apache.org Subject: [DISCUSS] Cordova TOOLS release - 4.3.1 Hi, In the recent days, a couple of platforms have released. We are also voting on Windows platform release. There have also been a couple of bug fixes in the CLI/Lib. Does it make sense to do a tools release ? Wanted to start a discuss thread on doing a TOOLS release. Are there other PRs that people want to get into this release ? - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Cordova Monthly Hangouts - April Edition
Sounds good. Thanks for organizing. Agenda Doc: https://docs.google.com/document/d/18aXzqqf6CAjg6hI0z78q5W1DcHNAz4t2GiCxfgVc2Uc/edit#heading=h.umrueh6zb4gg On Mon, Apr 6, 2015 at 5:23 PM, Parashuram N (MS OPEN TECH) panar...@microsoft.com wrote: Closing this poll - looks like Apr 10 (Friday) 1:00 pm EST has the max possible folks. Let us schedule the hangout for April 10, at 1:00 pm EST. Can someone help with creating the Agenda document ? We will be sharing the hangouts link closer to the poll. -Original Message- From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] Sent: Friday, April 3, 2015 9:46 AM To: dev@cordova.apache.org Subject: RE: Cordova Monthly Hangouts - April Edition Bumping this thread up one last time. Will close the results for the hangout, and send out a date later today PST. -Original Message- From: Parashuram N (MS OPEN TECH) [mailto:panar...@microsoft.com] Sent: Thursday, April 2, 2015 3:04 PM To: dev@cordova.apache.org Subject: Cordova Monthly Hangouts - April Edition Wanted to bump up the thread about Cordova hangouts. We have 10 responses so far. I plan to close the poll early tomorrow morning so that we have enough time to schedule the hangout and folks can make it. If you have not yet responded to the time, please add your preference here http://doodle.com/kydhnyzzwge92hsu - 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: Platform guides update
CLI + Android Studio are not mutually exclusive, provided you follow certain workflows. I always use CLI, but sometimes also use XCode / Android Studio / Eclipse. You do need to adhere to some rules in order to not shoot yourself in the foot, which are usually hard to describe to users. I believe the situation has gotten easier with platform project - top-level www/plugin symlink support, but I haven't personally played with that much. -Michal On Tue, Apr 7, 2015 at 3:57 PM, Raymond Camden raymondcam...@gmail.com wrote: Ok - so for the user *not* writing a plugin, but just doing general Cordova building, the CLI is still the best way, right? And the docs make that clear I hope? (Or the proposed changes I should say.) On Tue, Apr 7, 2015 at 2:52 PM, Andrew Grieve agri...@chromium.org wrote: Perhaps the quote is out of context (I'm too lazy to check), but it's certainly the recommended option for debugging native code. On Tue, Apr 7, 2015 at 3:47 PM, Raymond Camden raymondcam...@gmail.com wrote: Replace Eclipse example w/ Android Studio as officially recommended option/tool Do we really recommend this over CLI + your favorite editor ? On Tue, Apr 7, 2015 at 2:35 PM, Jesse purplecabb...@gmail.com wrote: +1000 @purplecabbage risingj.com On Tue, Apr 7, 2015 at 12:31 PM, Andrew Grieve agri...@chromium.org wrote: These changes all sound great! On Tue, Apr 7, 2015 at 3:01 PM, Sergey Grebnov (Akvelon) v-seg...@microsoft.com wrote: Hi guys, I see that some docs are outdated or not actual anymore so I want to improve this. Please let me know if someone already working on this or going to take a look. I've listed below some things I want to update, could you please review them before I stared working on this (additional suggestions and ideas are very welcome) iOS: 1. Xcode 4.x-5.x 2. Add information about ios-sim required to deploy app from command line 3. Add information how to list available deploy targets and run app on specific target/device Android: 1. Add changes in favor of replacing Ant w/ Gradle a. Remove Ant from requirements b. Replace Eclipse example w/ Android Studio as officially recommended option/tool 2. Add more details about particular Android packages/components required to be installed. Android 5.0.1 (API 21) platform SDK Android SDK Build-tools version 19.1.0 or higher Android Support Repository (Extras) 3. Add information how to list available deploy targets and run app on specific target/device Windows: 1. Remove 'To develop apps for Windows 8.0 only:' 2. Hardware requirements to run Windows Phone emulator (Client Hyper-V and Second Level Address Translation (SLAT)) 3. Add information how to list available deploy targets and run app on specific target/device Thx! Sergey - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: hooks docs
I can't find docs on that website, but there are docs in the cordova-cli repo and are linked from the main top-level README.md. Additionally, any cordova project created will have a default hooks/README.md which explains how they work. Then there are plugin hooks which are documented in plugman, and linked to from various places. Seems we should just create a link from docs.cordova.io? (And re-read existing docs for accuracy?) On Wed, Mar 25, 2015 at 5:32 PM, Raymond Camden raymondcam...@gmail.com wrote: Before I file an issue I want to make sure I'm just not missing something right in front of me. Are the docs for hooks missing from docs.cordova.io? If I'm seeing right, there's no core doc for hooks or mention of the support to configure them in config.xml as well. (I see the docs in the hooks folder so there's one place folks can get them.) -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: hooks docs
I fixed the broken link, but we need a JIRA for the missing docs. Thanks Ray! On Wed, Mar 25, 2015 at 9:04 PM, Raymond Camden raymondcam...@gmail.com wrote: I'll file a JIRA ticket for this - in a bit. On Wed, Mar 25, 2015 at 4:54 PM, Michal Mocny mmo...@chromium.org wrote: Here are some links: default hooks: https://github.com/apache/cordova-app-hello-world/tree/master/hooks cli hooks section: https://github.com/apache/cordova-cli/#hooks and https://github.com/apache/cordova-cli/#hooks-1 Seems the link from the main README is actually dead ever since I moved the hooks/ from cordova-lib to the default app, so thanks for the poke! On Wed, Mar 25, 2015 at 5:51 PM, Michal Mocny mmo...@chromium.org wrote: I can't find docs on that website, but there are docs in the cordova-cli repo and are linked from the main top-level README.md. Additionally, any cordova project created will have a default hooks/README.md which explains how they work. Then there are plugin hooks which are documented in plugman, and linked to from various places. Seems we should just create a link from docs.cordova.io? (And re-read existing docs for accuracy?) On Wed, Mar 25, 2015 at 5:32 PM, Raymond Camden raymondcam...@gmail.com wrote: Before I file an issue I want to make sure I'm just not missing something right in front of me. Are the docs for hooks missing from docs.cordova.io? If I'm seeing right, there's no core doc for hooks or mention of the support to configure them in config.xml as well. (I see the docs in the hooks folder so there's one place folks can get them.) -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden
Re: 'cordova plugin save' should also save plugin versions
Another +1 to do-as-npm-does. Both because of existing developer expectations, and because the trend is to move towards npm-isms and it would be a disservice down the road to change the behaviour. Any fork from what npm does should have a strong reason, and not just a prefer-it-this-way, imho. -Michal On Tue, Mar 24, 2015 at 5:20 PM, Steven Gill stevengil...@gmail.com wrote: Definitely agree with alignment with npm's save! :D On Tue, Mar 24, 2015 at 1:46 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I'm in favor of alignment of 'plugin save' behavior with npm's as we expect developers to already familiar with that and in future, we plan to move to npm. I liked Andrew's idea of adding a specific version with allowing minor version upgrades to be automatic. As for shrink wrapping, for npm this means locking down the version numbers of all modules and their dependencies: https://docs.npmjs.com/cli/shrinkwrap . It does not look our --shrinkwrap option does that. -Nikhil -Original Message- From: So, Byoungro [mailto:byoungro...@intel.com] Sent: Tuesday, March 24, 2015 12:40 PM To: dev@cordova.apache.org Subject: Re: 'cordova plugin save' should also save plugin versions +1 for making the shrinkwrap as the default for the save. This makes sure the users will restore the same version they saved before. Byoungro So SSG / DPD / Mobile Computing and Compilers Intel Corporation On 3/24/15, 12:31 PM, Gorkem Ercan gorkem.er...@gmail.com wrote: I think the problem here is shrinkwrap behaviour is the expected because platforms behave that way. I guess we could just make shrinkwrap default and change the flag to --noshrinkwrap. -- Gorkem On 24 Mar 2015, at 13:58, Andrew Grieve wrote: On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: They are related but not same. CB-8594 asks to save the plugin version information during cordova plugin add --save. Right now we do not save version unless the command is cordova plugin add --save --shrinkwrap. This behaviour allows plugins to be restored to the latest possible version available if they are not explicitly shrinkwrapped. How about doing what npm does, and always save the version, but save it as ^1.0.3, so that you still get updates, but not major version changes? As for CB-8733, cordova plugin save command can not save the version information even if it had wanted to because fetch.json is missing that information. It is a bug. -- Gorkem On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden raymondcam...@gmail.com wrote: Is that a dupe of https://issues.apache.org/jira/browse/CB-8594? On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales eymor...@us.ibm.com wrote: Currently, version info is not saved for plugins in the fetch.json. That needs to be added so that plugin version can be saved in the config.xml. It should follow what 'cordova platform save' does. I created a jira item for this: https://issues.apache.org/jira/browse/CB-8733 and opened a pull request: https://github.com/apache/cordova-lib/pull/189. If someone could review it and provide any feedback. Thanks, Edna Morales -- = === === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden --- -- 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 - 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: Cordova Monthly Hangouts
Another topic is discussion of package.json based cli workflow, aka leveraging more npm-ness in our tools. -Michal On Tue, Mar 24, 2015 at 1:59 PM, Andrew Grieve agri...@chromium.org wrote: +1! On Tue, Mar 24, 2015 at 1:23 PM, Jesse purplecabb...@gmail.com wrote: +1 asap, thanks Parash! We are much more coherent when we meet. On Mar 24, 2015, at 10:02 AM, Parashuram N (MS OPEN TECH) panar...@microsoft.com wrote: Hi, I was wondering if folks would be interested in doing a hangout to quickly resolve some of the outstanding issues that we have been talking on the mailing list. I think we could talk about the following * Androind 4.0 release * Medic/ParaMedic/Mobile Spec - progress and next steps * Finalize Save/Restore discussions * ApacheCon ? I can volunteer to help set this up if we think there are items that we would like to discuss and close on. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Simulating Cordova plugins and device capabilities
This is exceptionally cool (and thanks for doing a video demonstration, great way to get the point across)! I also agree with all your points, and really support this approach. Specifically: +1 browser platform will be used for both prod and debugging, so cannot have always-on emulation. +1 to have emulation hooks inside cordova browser platform and cordova plugins' browser versions, but have them no-op by default. +1 to support any downstream emulation embedders, and perhaps have a very lightweight cordova project (though perhaps not necessary beyond a simple testing app). +1 to suggest Ripple become an embedder. I'll also note that Microsoft is one of the primary supporters of Ripple recently, so if they think this is a good direction, that is a strong signal to me. Intel is a second strong supporter or ripple (anyone else?), and I think they were on board with this direction as well (to build on top of browser platform). -Michal On Tue, Mar 24, 2015 at 3:55 PM, Jesse purplecabb...@gmail.com wrote: Thank you Tim for the brief explanation! ;) I agree with all your summary points. Some more questions: What value does Ripple if the basic functionality becomes part of a generic simulation interface? Ripple currently will simulate screen sizes based on device choice. Chrome dev tools support picking different device viewports also. Where should something like this live? Is this feature valuable enough to warrant this lengthy discussion? I have no idea how useful this will actually be. As someone who has released apps for most of our supported platforms I have never needed ripple of any other simulation, short of stubbing cordova-exec and working out all my UI/UX in a browser. Is there some way we can measure the need? Given that this does not appear to impact cordova, just supplement it, you should probably just go for it. Fixing cordova-serve and getting cordova-browser to use it are already in discussions, so moving forward with another module 'cordova-platform-sim'? sounds good to me. Cheers, Jesse @purplecabbage risingj.com On Mon, Mar 23, 2015 at 7:08 AM, Tim Barham tim.bar...@microsoft.com wrote: Hey Jesse - thanks for the feedback! First I'd like to address why we think this belongs in Cordova rather than Ripple: *. The functionality described is closely tied to how Cordova works, and we feel is a capability that should be built into Cordova - specifically, that Cordova provide the hooks necessary for any arbitrary simulation host to connect to. *. We don't see this as being a Ripple replacement, per se. Rather, is this model, Ripple would become one of any number of simulation hosts built on top of this. Cordova might include a very basic simulation host out of the box, while Ripple would remain a much richer, but separate, project built on top of the same functionality. Why do we see the need for this when we already have Ripple? Reasons include: * We want to make it easy to embed a simulation host in other environments. Ripple is just one example.. Also within an IDE, or within a browser's dev tools, or whatever. * As mentioned below, we want to separate the simulation UI from the app itself to simplify the debugging experience. * We want to make it easily extensible - specifically allow plugins to define their simulation UI and have it work in any simulation host. Regarding the browser vs Ripple thread - yeah, I remember it :). We were following it at the time, and it definitely influenced what we are proposing. Some points on this: * We don't think it should be browser vs Ripple... We think it should be Ripple on top of browser :) ... but most importantly we don't limit this to Ripple. May simulation hosts proliferate! * If I recall there was also discussion about whether the browser platform is primarily a debugging tool or a real production delivery platform. Our firm belief is that it is both. We can easily provide the hooks (the 'app host' and 'server' pieces) so a rich debugging environment like Ripple can be built on top of it (and, of course, also open the door to other simulation hosts) without taking anything away from it being a real delivery platform. So, in summary, this is how I'm thinking about it: * The browser platform continues to be a production delivery platform. It doesn't provide any UI for simulating plugins. Plugins should always just do the real thing, and never provide mock data or anything like that. * The browser platform, when run from the Cordova CLI, is modified to launch from a server. Something we'd want to do regardless. * That server provides the hooks a simulation host needs to do its thing (but, most likely, those hooks would only be available if the application was launched in a mode to expect plugin simulation). * The simulation host itself is completely separate from the browser platform.
Re: 'cordova plugin save' should also save plugin versions
..Also with the move to put plugins in npm, I think we would be directly using npm's resolution of the version? On Tue, Mar 24, 2015 at 8:48 PM, Andrew Grieve agri...@chromium.org wrote: On Tue, Mar 24, 2015 at 7:48 PM, Gorkem Ercan gorkem.er...@gmail.com wrote: On 24 Mar 2015, at 18:38, Tim Barham wrote: +1 from me too (always save version, and allow automatic minor version upgrades). I like Andrew's idea, my only concern is implementing only a portion of the semver syntax. I personally would assume full semver support after seeing ^1.2.3 notation on config.xml I think we do already support all semver? Just tried: cordova plugin add cordova-plugin-okhttp@1 3 and it worked fine. Gorkem - I'm currently doing some work in this area - I'm happy to make this change while I'm there. Sure, go ahead. I would not be able to get to it until next week. From: Steven Gill [stevengil...@gmail.com] Sent: Wednesday, March 25, 2015 7:20 AM To: dev@cordova.apache.org Subject: Re: 'cordova plugin save' should also save plugin versions Definitely agree with alignment with npm's save! :D On Tue, Mar 24, 2015 at 1:46 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I'm in favor of alignment of 'plugin save' behavior with npm's as we expect developers to already familiar with that and in future, we plan to move to npm. I liked Andrew's idea of adding a specific version with allowing minor version upgrades to be automatic. As for shrink wrapping, for npm this means locking down the version numbers of all modules and their dependencies: https://docs.npmjs.com/cli/shrinkwrap . It does not look our --shrinkwrap option does that. -Nikhil -Original Message- From: So, Byoungro [mailto:byoungro...@intel.com] Sent: Tuesday, March 24, 2015 12:40 PM To: dev@cordova.apache.org Subject: Re: 'cordova plugin save' should also save plugin versions +1 for making the shrinkwrap as the default for the save. This makes sure the users will restore the same version they saved before. Byoungro So SSG / DPD / Mobile Computing and Compilers Intel Corporation On 3/24/15, 12:31 PM, Gorkem Ercan gorkem.er...@gmail.com wrote: I think the problem here is shrinkwrap behaviour is the expected because platforms behave that way. I guess we could just make shrinkwrap default and change the flag to --noshrinkwrap. -- Gorkem On 24 Mar 2015, at 13:58, Andrew Grieve wrote: On Tue, Mar 24, 2015 at 11:49 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: They are related but not same. CB-8594 asks to save the plugin version information during cordova plugin add --save. Right now we do not save version unless the command is cordova plugin add --save --shrinkwrap. This behaviour allows plugins to be restored to the latest possible version available if they are not explicitly shrinkwrapped. How about doing what npm does, and always save the version, but save it as ^1.0.3, so that you still get updates, but not major version changes? As for CB-8733, cordova plugin save command can not save the version information even if it had wanted to because fetch.json is missing that information. It is a bug. -- Gorkem On Tue, Mar 24, 2015 at 11:29 AM, Raymond Camden raymondcam...@gmail.com wrote: Is that a dupe of https://issues.apache.org/jira/browse/CB-8594? On Tue, Mar 24, 2015 at 10:19 AM, Edna Y Morales eymor...@us.ibm.com wrote: Currently, version info is not saved for plugins in the fetch.json. That needs to be added so that plugin version can be saved in the config.xml. It should follow what 'cordova platform save' does. I created a jira item for this: https://issues.apache.org/jira/browse/CB-8733 and opened a pull request: https://github.com/apache/cordova-lib/pull/189. If someone could review it and provide any feedback. Thanks, Edna Morales -- = === === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden --- -- 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 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [Android] Proposal: Deprecate/No-Op Battery Plugin
Raymond, I think that was Joe's point in the original email. He is saying we should finally do something about it :P On Tue, Mar 24, 2015 at 10:47 PM, Raymond Camden raymondcam...@gmail.com wrote: On Tue, Mar 24, 2015 at 9:37 PM, Joe Bowser bows...@gmail.com wrote: If you use the Battery plugin on Android, it will drain your battery. It's been a known issue for almost a year, and there's been this issue in JIRA: https://issues.apache.org/jira/browse/CB-6838 I'd like to think I'm a pretty involved user - not a contributor - and I use Jira to file issues. But I don't think I've ever gone through and tried to read every single issue. Maybe because I assumed that an issue like this would be kinda critical and actually documented. Does no one else seriously think this is a Big Freaking Deal? No, because someone has to actually update the docs to do that, and they'd be subject to the Apache release process. And everyone here is perfectly ok with this? With the vast majority of users using a plugin that may be detrimental to their apps, and by proxy, detrimental to Cordova (and PhoneGap) as a whole... because we can't get a ONE sentence (what Joe said above) posted to the doc? I've rewritten this last paragraph a few times now because I don't want to be rude. I love this project, but as a user, this is maddening. Obviously I must be wrong about this being a big deal. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [Android] Proposal: Deprecate/No-Op Battery Plugin
..and regarding the release process, thats not the reason this wasn't done. We release plugins in a bulk process and its not much work to add an update to this one. Just no one made the documentation updates to master yet. On Wed, Mar 25, 2015 at 12:02 AM, Michal Mocny mmo...@chromium.org wrote: Raymond, I think that was Joe's point in the original email. He is saying we should finally do something about it :P On Tue, Mar 24, 2015 at 10:47 PM, Raymond Camden raymondcam...@gmail.com wrote: On Tue, Mar 24, 2015 at 9:37 PM, Joe Bowser bows...@gmail.com wrote: If you use the Battery plugin on Android, it will drain your battery. It's been a known issue for almost a year, and there's been this issue in JIRA: https://issues.apache.org/jira/browse/CB-6838 I'd like to think I'm a pretty involved user - not a contributor - and I use Jira to file issues. But I don't think I've ever gone through and tried to read every single issue. Maybe because I assumed that an issue like this would be kinda critical and actually documented. Does no one else seriously think this is a Big Freaking Deal? No, because someone has to actually update the docs to do that, and they'd be subject to the Apache release process. And everyone here is perfectly ok with this? With the vast majority of users using a plugin that may be detrimental to their apps, and by proxy, detrimental to Cordova (and PhoneGap) as a whole... because we can't get a ONE sentence (what Joe said above) posted to the doc? I've rewritten this last paragraph a few times now because I don't want to be rude. I love this project, but as a user, this is maddening. Obviously I must be wrong about this being a big deal. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Deprecation of Config and the embedded use case (4.0.x related)
Carlos, thats great, then perhaps you could give 4.0 embedded webview a shot to confirm that it is still adequately supported for your customers? I think this thread has been too much talk and not enough trying it out in practice. Everyone agrees the use case is important, what's left is to confirm we got it right. -Michal On Mon, Mar 16, 2015 at 8:58 PM, Carlos Santana csantan...@gmail.com wrote: I just want to add that Joe is not alone on thinking that are developers with this use case. For us we have customers that start with Native Android alone, and then later want to add a Cordova Web View to a portion of their App. And they want an easy way to add a Cordova Web View. For 4.x, I would assume that the developer can choose to make this embedded Cordova Web View CrossWalk based. On Wed, Mar 11, 2015 at 10:24 AM, Joe Bowser bows...@gmail.com wrote: That's why we have tests! I just changed the activity and saw that we have one failure. I'm not sure why this test in particular is failing, since there's too many assertions in one method, so I'll have to try and debug it today. The thing is that if we're deprecating something and replacing it with something else, we should write tests for it. Releasing a 4.0.x and changing how we embed a WebView by changing class names but not fixing up the deprecation is bizzare. On Wed, Mar 11, 2015 at 7:15 AM Andrew Grieve agri...@chromium.org wrote: I wanted to make sure that I didn't break the old way of doing things. On Tue, Mar 10, 2015 at 2:24 PM, Joe Bowser bows...@gmail.com wrote: The main issue is that this isn't documented anywhere, and this is necessary for people to use a Third Party WebView. Also, why didn't you bother updating the test with the new API? On Mon, Mar 9, 2015 at 5:19 PM Andrew Grieve agri...@chromium.org wrote: Here's an example: ConfigXmlParser parser = new ConfigXmlParser(); parser.parse(activity); webView.init(cordova, parser.getPluginEntries(), parser.getPreferences()); Feel free to iterate if you think the API is too obtuse, but I think it's good to allow a file-less mode, and to allow different WebViews to have different settings. On Mon, Mar 9, 2015 at 8:08 PM, Joe Bowser bows...@gmail.com wrote: Do you have an example of how this would work? This seems to be a lot more complex than it needs to be. On Mon, Mar 9, 2015 at 5:05 PM Andrew Grieve agri...@chromium.org wrote: It's so that you can have multiple CordovaWebViews that use different configs within one application. It's also so that you don't have to have a config.xml if you prefer to build up your config in code instead. I don't think loadConfig() is deprecated. It has a @SuppressWarnings(deprecation), which just silences a warning about it setting the config of the Config class (which is done for backwards compatibility). On Mon, Mar 9, 2015 at 3:54 PM, Joe Bowser bows...@gmail.com wrote: OK, this actually makes using the WebView as a component a lot harder, since you now have to have this loadConfig method which you also marked for deprecation required to get all of the necessary attributes out of this. I'm pretty sure this is a major step backwards in that people looking to use Cordova as a component now have to jump through additional hoops to get this to work. What is the benefit of deprecating the Config static class and replacing it with the ConfigXmlParser again? I don't remember why this was done. On Mon, Mar 9, 2015 at 9:04 AM Andrew Grieve agri...@chromium.org wrote: On Mon, Mar 9, 2015 at 11:56 AM, Joe Bowser bows...@gmail.com wrote: On Mon, Mar 9, 2015 at 7:39 AM Andrew Grieve agri...@chromium.org wrote: You can now instantiate a CordovaWebView without a config.xml, and without using Config. This happened when I added an init() method to CordovaWebView. You can pass in a CordovaPreferences object, and a list of PluginEntry. Maybe we just need a better comment on Config saying to use these instead? Where does one get this PluginEntry list when they're embedding a WebView? This needs to be documented or at least put in the test that tests this use case. That has nothing to do with InAppBrowser, this is to do with
Re: Where does cordova-android@4.0.0-dev live?
Indeed, it has been merged into master and will be the next version of cordova-android released. On Fri, Mar 13, 2015 at 11:24 AM, Axel Nennker ignisvul...@gmail.com wrote: This? https://github.com/apache/cordova-android Version file says 4.0.0-dev https://github.com/apache/cordova-android/blob/master/VERSION On Mar 13, 2015 4:14 PM, Sam Kelleher sam.kelle...@redant.com wrote: The 4.0.0-dev version of cordova-android is referenced by the chromium wrapper of cordova, but the code itself seems to have since been removed from GIT. Am I missing something, or has it moved somewhere else?
Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib
Perfect. Thanks Steve. On Mon, Mar 9, 2015 at 7:46 PM, Steven Gill stevengil...@gmail.com wrote: Release steps: https://github.com/apache/cordova-coho/blob/master/docs/app-hello-world-release-process.md I will have to run through a release to see if I got it all right. Okay, I'm going to merge the copy-from-app-hello-world branch into master and start a vote thread! Lets hold off on merging the cordova-lib changes into master until cordova-app-hello-world gets released. This way we won't have failures on master according to travis. Sound good? On Fri, Mar 6, 2015 at 4:30 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Thanks for making the change to make it compatible. I took a brief look at your changes and they look good. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Friday, March 6, 2015 1:12 PM To: Steven Gill Cc: Michal Mocny; Andrew Grieve; dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Agreed. Everything is upstream on the branch. The package.json wasn't fully thought out, so please peak at it. Ping me if you need anything, I'll rebase cordova-lib and move to master when you are done. Thanks Steve. On Fri, Mar 6, 2015 at 4:08 PM, Steven Gill stevengil...@gmail.com wrote: Sure. I can make the changes to release process + coho for it. I imagine it won't be released often, so it might be best give app-hello-world its own release process instead of tying it into tools, platforms or plugins release. On Mar 6, 2015 1:04 PM, Michal Mocny mmo...@chromium.org wrote: (Sorry for all the messages) Fixed all the remaining breaks, and now all tests pass without modification and cordova-cli doesn't need changes. However, there is a new npm dependency on cordova-app-hello-word from cordova-lib. We will need to release that to npm before publishing the next tools release. Steve/Andrew, I will attempt to update coho etc, but I'm not sure of all the places to update release instructions for this new thing, nor am I sure of all the licensing requirements. Care to advise / help? Thanks! -Michal On Fri, Mar 6, 2015 at 11:30 AM, Michal Mocny mmo...@chromium.org wrote: Updated as described. Now you no longer need to use the branch of cordova-cli, so I'm pretty sure this is 100% compat. Huzzah. On Fri, Mar 6, 2015 at 11:06 AM, Michal Mocny mmo...@chromium.org wrote: I wanted to originally, but you can --copy-from a www/ only (no config.xml), and then we need a template. If I change cordova-lib to depend on app-hello-world then we can remove it. Another reason to do so. -Michal On Thu, Mar 5, 2015 at 10:17 PM, Andrew Grieve agri...@chromium.org wrote: Can we move the config.xml template out of cordova-lib/templates and into app-hello-world as a part of this? On Thu, Mar 5, 2015 at 5:13 PM, Michal Mocny mmo...@chromium.org wrote: The current breaking change is that you cannot create a new project using cordova-lib directly, without providing a project template to import from. cordova-cli works as it always has, and will provide the app-hello-world as a default if you do not use --copy-from / --link-to. However, writing that explanation out now, I realize I could just change cordova-lib to be the one to depend on cordova-app-hello-world and do the defaulting there, and not break compatibility. I think I originally envisioned the cordova-lib script to be more primitive, but its already doing a tremendous amount of input handling and backwards compat workarounds. Probably I can just make this adjustment. -Michal On Thu, Mar 5, 2015 at 4:57 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Michal: I'm new to this area - can you please elaborate why this change could potentially break downstream distributions? IS there an API change? -Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, March 5, 2015 1:12 PM To: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Alight, remote branches (named copy-from-app-hello-world) are created for cordova-lib, cordova-cli, and cordova-app-hello-world. There are still 2 failing cordova-lib tests, but I'm working to resolve that. My actual end-to-end tests appear to be working with all use cases. Please, please: if you develop a downstream distribution that uses cordova-lib directly (PhoneGap, BlackBerry, Ionic, etc
Re: Update: Plugins to NPM (Phase 1)
I guess since we have a MAJOR version bump on plugins, I agree thats the right choice. -Michal On Wed, Mar 11, 2015 at 11:15 AM, Andrew Grieve agri...@chromium.org wrote: On Wed, Mar 11, 2015 at 10:30 AM, Michal Mocny mmo...@chromium.org wrote: On Wed, Mar 11, 2015 at 10:10 AM, Andrew Grieve agri...@chromium.org wrote: On Mon, Mar 9, 2015 at 8:20 PM, Steven Gill stevengil...@gmail.com wrote: 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) Will need to update JS / native references where plugins depend on each other (e.g. in require()s). Think there are only a couple. Should make sure the mapper does this automatically for js require(), but we should still update core plugins to not rely on it. I don't think that would work since require()s are a runtime thing. I don't want to have a list of require mappings end up in every app's cordova.js. Pretty simple just to fix the couple of require()s. For native side plugin deps, we will need to make the updates. - 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?
Re: Update: Plugins to NPM (Phase 1)
On Wed, Mar 11, 2015 at 10:10 AM, Andrew Grieve agri...@chromium.org wrote: On Mon, Mar 9, 2015 at 8:20 PM, Steven Gill stevengil...@gmail.com wrote: 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) Will need to update JS / native references where plugins depend on each other (e.g. in require()s). Think there are only a couple. Should make sure the mapper does this automatically for js require(), but we should still update core plugins to not rely on it. For native side plugin deps, we will need to make the updates. - 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?
Re: Consolidating platform specific code from different places in cordova-lib
Reviewed, left comments. Overall looks good, thanks Mark.
However, seems you left something uncommitted, since you literally cannot
require('cordova-lib'); without an exception thrown. Yet all the
cordova-lib tests pass. What does it say about the quality of the tests ;)
On Tue, Mar 10, 2015 at 6:24 PM, Jesse purplecabb...@gmail.com wrote:
Had a quick look, looks great!
@purplecabbage
risingj.com
On Tue, Mar 10, 2015 at 3:09 PM, Mark Koudritsky kam...@google.com
wrote:
I've created a pull request with changes across cordova-lib that should
make it much easier to consolidate the platform specific code in
cordova-lib to reduce duplication and maybe eventually move this code to
the platforms repos.
https://github.com/apache/cordova-lib/pull/183
Feedback is welcome.
Those changes only deal with interfacing the platform specific code from
cordova/metadata/ and plugman/platforms/ dirs, the dirs themselves and
their contents weren't changed yet.
Re: Plugin Post Install Script
I don't think this is a good idea, but I'm open to be convinced. However, cannot we punt this discussion for now? The current phase 1 rollout does not actually have us installing plugins to node_modules, so really this is an independant feature request to create a new workflow. I don't see the benefit for this reason alone. I think supporting plugins / platforms / tolling inside node_modules *is* a good idea, but I think it should look even more radically different (can demo some ideas next Hangout). -Michal On Mon, Mar 9, 2015 at 9:59 PM, Steven Gill stevengil...@gmail.com wrote: On Mon, Mar 9, 2015 at 6:20 PM, Jesse purplecabb...@gmail.com wrote: What does `npm i -g cordova-plugin-device` do? Just because things are similar does not mean you should force them to be the same. I don't really see a benefit in doing this though, and I think we are going to end up with circular unresolvable dependencies. or at least greatly increased complexity in dependency resolution. I figure the post install script would fail if the plugin gets installed globally. I'd like to figure out exactly what dependency issues we would run into. Having 2 ways to do things just makes it harder for us Thinking outloud ... isn't the post install really just something like: ../../cordova plugin add npm_modules/cordova-plugin-device/ That assumes no dependency resolution ... which would make it explode. This could potentially be one way of doing it. Another way would be to move install logic into the script itself. Just thinking outloud. Overall, I don't think the feature is worth the complexity it would add, and I don't even think it makes things easier for users. What is the benefit of typing 'npm i cordova-plugin-device' vs 'cordova plugin add cordova-plugin-device' ? Character count? It is definitely early for me to bring up this suggestion. I don't see a reason why current cordova devs would use `npm install cordova-plugin-device` over cordova plugin add. I see it being more useful in a world where cordova projects are node projects. CLI created projects would have a package.json, and I could see users installing plugins via npm install. Also, I see cordova JSAPI based projects becoming more popular once we break cordova-lib into smaller scripts and offer alternative ways to build and manage projects using npm/gulp/grunt/etc. This should be beneficial to our many downstreams as well. Just wanting to start fleshing out what all of this will look like. If we do decide to go down this route, it would be nice to figure it out soon so we could start getting plugin authors to make updates while we wait for tooling. @purplecabbage risingj.com On Mon, Mar 9, 2015 at 5:36 PM, Steven Gill stevengil...@gmail.com wrote: I think it is worth exploring a generic post install script plugin authors could include that would install the plugin into a cordova project after a npm install. I haven't had any time to actually explore this yet though. My initial reaction was that it would be hard to get right. After some thought and discussion with the npm people Anis, it might be a really nice way of doing it. It would be pretty sweet if people could just go `npm i cordova-plugin-device` and have it install the plugin into their cordova projects. The script would have to: * detect if it is a cordova project and what version * do everything plugin install does now Just wanted to collect some feedback, advice, and concerns people have before I attempt to build it.
Re: Plugin Post Install Script
Thanks Steve! On Tue, Mar 10, 2015 at 12:18 PM, Steven Gill stevengil...@gmail.com wrote: Alright. Punted for now. Too early to talk about this. On Mar 10, 2015 8:56 AM, Michal Mocny mmo...@chromium.org wrote: I don't think this is a good idea, but I'm open to be convinced. However, cannot we punt this discussion for now? The current phase 1 rollout does not actually have us installing plugins to node_modules, so really this is an independant feature request to create a new workflow. I don't see the benefit for this reason alone. I think supporting plugins / platforms / tolling inside node_modules *is* a good idea, but I think it should look even more radically different (can demo some ideas next Hangout). -Michal On Mon, Mar 9, 2015 at 9:59 PM, Steven Gill stevengil...@gmail.com wrote: On Mon, Mar 9, 2015 at 6:20 PM, Jesse purplecabb...@gmail.com wrote: What does `npm i -g cordova-plugin-device` do? Just because things are similar does not mean you should force them to be the same. I don't really see a benefit in doing this though, and I think we are going to end up with circular unresolvable dependencies. or at least greatly increased complexity in dependency resolution. I figure the post install script would fail if the plugin gets installed globally. I'd like to figure out exactly what dependency issues we would run into. Having 2 ways to do things just makes it harder for us Thinking outloud ... isn't the post install really just something like: ../../cordova plugin add npm_modules/cordova-plugin-device/ That assumes no dependency resolution ... which would make it explode. This could potentially be one way of doing it. Another way would be to move install logic into the script itself. Just thinking outloud. Overall, I don't think the feature is worth the complexity it would add, and I don't even think it makes things easier for users. What is the benefit of typing 'npm i cordova-plugin-device' vs 'cordova plugin add cordova-plugin-device' ? Character count? It is definitely early for me to bring up this suggestion. I don't see a reason why current cordova devs would use `npm install cordova-plugin-device` over cordova plugin add. I see it being more useful in a world where cordova projects are node projects. CLI created projects would have a package.json, and I could see users installing plugins via npm install. Also, I see cordova JSAPI based projects becoming more popular once we break cordova-lib into smaller scripts and offer alternative ways to build and manage projects using npm/gulp/grunt/etc. This should be beneficial to our many downstreams as well. Just wanting to start fleshing out what all of this will look like. If we do decide to go down this route, it would be nice to figure it out soon so we could start getting plugin authors to make updates while we wait for tooling. @purplecabbage risingj.com On Mon, Mar 9, 2015 at 5:36 PM, Steven Gill stevengil...@gmail.com wrote: I think it is worth exploring a generic post install script plugin authors could include that would install the plugin into a cordova project after a npm install. I haven't had any time to actually explore this yet though. My initial reaction was that it would be hard to get right. After some thought and discussion with the npm people Anis, it might be a really nice way of doing it. It would be pretty sweet if people could just go `npm i cordova-plugin-device` and have it install the plugin into their cordova projects. The script would have to: * detect if it is a cordova project and what version * do everything plugin install does now Just wanted to collect some feedback, advice, and concerns people have before I attempt to build it.
Re: Deprecating the feature tag
Haven't looked at a patch, but +1 to plugin over feature On Mon, Mar 9, 2015 at 4:41 PM, Gorkem Ercan gorkem.er...@gmail.com wrote: I am about to deprecate the old feature tag use for saving plugin information in favour of plugin tag. I have a PR[1] that I hope to soon merge. The changes are backward compatible, old feature syntax will still be respected for read and remove operations but all new entries will be done with the new syntax. Please review the changes and let me know if you have any concerns, use cases that I am not aware of. As a note, this change does not effect the feature tags that are created on platform specific config.xml files. Platforms will still be using the legacy feature tag. [1] https://github.com/apache/cordova-lib/pull/182 -- Gorkem - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib
I wanted to originally, but you can --copy-from a www/ only (no config.xml), and then we need a template. If I change cordova-lib to depend on app-hello-world then we can remove it. Another reason to do so. -Michal On Thu, Mar 5, 2015 at 10:17 PM, Andrew Grieve agri...@chromium.org wrote: Can we move the config.xml template out of cordova-lib/templates and into app-hello-world as a part of this? On Thu, Mar 5, 2015 at 5:13 PM, Michal Mocny mmo...@chromium.org wrote: The current breaking change is that you cannot create a new project using cordova-lib directly, without providing a project template to import from. cordova-cli works as it always has, and will provide the app-hello-world as a default if you do not use --copy-from / --link-to. However, writing that explanation out now, I realize I could just change cordova-lib to be the one to depend on cordova-app-hello-world and do the defaulting there, and not break compatibility. I think I originally envisioned the cordova-lib script to be more primitive, but its already doing a tremendous amount of input handling and backwards compat workarounds. Probably I can just make this adjustment. -Michal On Thu, Mar 5, 2015 at 4:57 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Michal: I'm new to this area - can you please elaborate why this change could potentially break downstream distributions? IS there an API change? -Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, March 5, 2015 1:12 PM To: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Alight, remote branches (named copy-from-app-hello-world) are created for cordova-lib, cordova-cli, and cordova-app-hello-world. There are still 2 failing cordova-lib tests, but I'm working to resolve that. My actual end-to-end tests appear to be working with all use cases. Please, please: if you develop a downstream distribution that uses cordova-lib directly (PhoneGap, BlackBerry, Ionic, etc), please try this out and see if it works for you. I will do so for cca. Please forward this to anyone on your team responsible for this work! -Michal On Wed, Mar 4, 2015 at 2:21 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like moving this to npm because Apache Git as a distribution mechanism for the hello world app has been less reliable than desirable in the past. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 12:08 PM To: Michal Mocny Cc: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Pushed first attempt to remote branches: - https://github.com/Apache/cordova-cli/tree/copy-from-app-hello-world - https://github.com/Apache/cordova-app-hello-world/tree/copy-from-app-h ello-world Cleaning up cordova-lib is strictly required, though I think we should still take the opportunity to do so. On Tue, Mar 3, 2015 at 2:46 PM, Michal Mocny mmo...@chromium.org wrote: Jesse, I think not. The platform scripts just copy the bundled www/ (its already included with the platform). This is only for the top-level project www/ of a cordova-cli project. I guess, though, that we could consider changing the platform create scripts to import config.xml's, since they currently do not. This may be difficult given that the format is different even though the name is the same (platform vs project config). -Michal On Tue, Mar 3, 2015 at 2:40 PM, Jesse purplecabb...@gmail.com wrote: +1 Does this affect the ability to use an individual platform? ie. cordova-ios/bin/create ... Will platform create scripts need to change? @purplecabbage risingj.com On Tue, Mar 3, 2015 at 11:32 AM, Michal Mocny mmo...@google.com wrote: This came up in the context of whitelist discussion, but wanted to bring it to everyones attention. JIRA: https://issues.apache.org/jira/browse/CB-8597 We would like the default app to support installing the whitelist plugin automatically using the new plugin auto-restore feature (If you disagree, discuss on the whitelist thread, that is not the topic of this post). However, the cordova-lib create script cannot support this feature right now anyway (that is the topic of this post). I've outlined in the JIRA how we could fix that (open to feedback). TLDR; --copy-from already supports this, so lets just vastly
Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib
Updated as described. Now you no longer need to use the branch of cordova-cli, so I'm pretty sure this is 100% compat. Huzzah. On Fri, Mar 6, 2015 at 11:06 AM, Michal Mocny mmo...@chromium.org wrote: I wanted to originally, but you can --copy-from a www/ only (no config.xml), and then we need a template. If I change cordova-lib to depend on app-hello-world then we can remove it. Another reason to do so. -Michal On Thu, Mar 5, 2015 at 10:17 PM, Andrew Grieve agri...@chromium.org wrote: Can we move the config.xml template out of cordova-lib/templates and into app-hello-world as a part of this? On Thu, Mar 5, 2015 at 5:13 PM, Michal Mocny mmo...@chromium.org wrote: The current breaking change is that you cannot create a new project using cordova-lib directly, without providing a project template to import from. cordova-cli works as it always has, and will provide the app-hello-world as a default if you do not use --copy-from / --link-to. However, writing that explanation out now, I realize I could just change cordova-lib to be the one to depend on cordova-app-hello-world and do the defaulting there, and not break compatibility. I think I originally envisioned the cordova-lib script to be more primitive, but its already doing a tremendous amount of input handling and backwards compat workarounds. Probably I can just make this adjustment. -Michal On Thu, Mar 5, 2015 at 4:57 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Michal: I'm new to this area - can you please elaborate why this change could potentially break downstream distributions? IS there an API change? -Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, March 5, 2015 1:12 PM To: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Alight, remote branches (named copy-from-app-hello-world) are created for cordova-lib, cordova-cli, and cordova-app-hello-world. There are still 2 failing cordova-lib tests, but I'm working to resolve that. My actual end-to-end tests appear to be working with all use cases. Please, please: if you develop a downstream distribution that uses cordova-lib directly (PhoneGap, BlackBerry, Ionic, etc), please try this out and see if it works for you. I will do so for cca. Please forward this to anyone on your team responsible for this work! -Michal On Wed, Mar 4, 2015 at 2:21 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like moving this to npm because Apache Git as a distribution mechanism for the hello world app has been less reliable than desirable in the past. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 12:08 PM To: Michal Mocny Cc: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Pushed first attempt to remote branches: - https://github.com/Apache/cordova-cli/tree/copy-from-app-hello-world - https://github.com/Apache/cordova-app-hello-world/tree/copy-from-app-h ello-world Cleaning up cordova-lib is strictly required, though I think we should still take the opportunity to do so. On Tue, Mar 3, 2015 at 2:46 PM, Michal Mocny mmo...@chromium.org wrote: Jesse, I think not. The platform scripts just copy the bundled www/ (its already included with the platform). This is only for the top-level project www/ of a cordova-cli project. I guess, though, that we could consider changing the platform create scripts to import config.xml's, since they currently do not. This may be difficult given that the format is different even though the name is the same (platform vs project config). -Michal On Tue, Mar 3, 2015 at 2:40 PM, Jesse purplecabb...@gmail.com wrote: +1 Does this affect the ability to use an individual platform? ie. cordova-ios/bin/create ... Will platform create scripts need to change? @purplecabbage risingj.com On Tue, Mar 3, 2015 at 11:32 AM, Michal Mocny mmo...@google.com wrote: This came up in the context of whitelist discussion, but wanted to bring it to everyones attention. JIRA: https://issues.apache.org/jira/browse/CB-8597 We would like the default app to support installing the whitelist plugin automatically using the new plugin auto-restore feature (If you disagree, discuss on the whitelist thread, that is not the topic of this post). However, the cordova-lib create script cannot support this feature
Re: Plugins site down due to iriscouch??
FYI: plugins are installing fine. Seems just related to the actual website? On Fri, Mar 6, 2015 at 3:25 PM, Victor Sosa sosah.vic...@gmail.com wrote: Webpage not found :( 2015-03-06 14:17 GMT-06:00 Steven Gill stevengil...@gmail.com: Anyone having issues? Can't seem to reach Cordova.iriscouch.com -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco
Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib
Agreed. Everything is upstream on the branch. The package.json wasn't fully thought out, so please peak at it. Ping me if you need anything, I'll rebase cordova-lib and move to master when you are done. Thanks Steve. On Fri, Mar 6, 2015 at 4:08 PM, Steven Gill stevengil...@gmail.com wrote: Sure. I can make the changes to release process + coho for it. I imagine it won't be released often, so it might be best give app-hello-world its own release process instead of tying it into tools, platforms or plugins release. On Mar 6, 2015 1:04 PM, Michal Mocny mmo...@chromium.org wrote: (Sorry for all the messages) Fixed all the remaining breaks, and now all tests pass without modification and cordova-cli doesn't need changes. However, there is a new npm dependency on cordova-app-hello-word from cordova-lib. We will need to release that to npm before publishing the next tools release. Steve/Andrew, I will attempt to update coho etc, but I'm not sure of all the places to update release instructions for this new thing, nor am I sure of all the licensing requirements. Care to advise / help? Thanks! -Michal On Fri, Mar 6, 2015 at 11:30 AM, Michal Mocny mmo...@chromium.org wrote: Updated as described. Now you no longer need to use the branch of cordova-cli, so I'm pretty sure this is 100% compat. Huzzah. On Fri, Mar 6, 2015 at 11:06 AM, Michal Mocny mmo...@chromium.org wrote: I wanted to originally, but you can --copy-from a www/ only (no config.xml), and then we need a template. If I change cordova-lib to depend on app-hello-world then we can remove it. Another reason to do so. -Michal On Thu, Mar 5, 2015 at 10:17 PM, Andrew Grieve agri...@chromium.org wrote: Can we move the config.xml template out of cordova-lib/templates and into app-hello-world as a part of this? On Thu, Mar 5, 2015 at 5:13 PM, Michal Mocny mmo...@chromium.org wrote: The current breaking change is that you cannot create a new project using cordova-lib directly, without providing a project template to import from. cordova-cli works as it always has, and will provide the app-hello-world as a default if you do not use --copy-from / --link-to. However, writing that explanation out now, I realize I could just change cordova-lib to be the one to depend on cordova-app-hello-world and do the defaulting there, and not break compatibility. I think I originally envisioned the cordova-lib script to be more primitive, but its already doing a tremendous amount of input handling and backwards compat workarounds. Probably I can just make this adjustment. -Michal On Thu, Mar 5, 2015 at 4:57 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Michal: I'm new to this area - can you please elaborate why this change could potentially break downstream distributions? IS there an API change? -Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, March 5, 2015 1:12 PM To: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Alight, remote branches (named copy-from-app-hello-world) are created for cordova-lib, cordova-cli, and cordova-app-hello-world. There are still 2 failing cordova-lib tests, but I'm working to resolve that. My actual end-to-end tests appear to be working with all use cases. Please, please: if you develop a downstream distribution that uses cordova-lib directly (PhoneGap, BlackBerry, Ionic, etc), please try this out and see if it works for you. I will do so for cca. Please forward this to anyone on your team responsible for this work! -Michal On Wed, Mar 4, 2015 at 2:21 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like moving this to npm because Apache Git as a distribution mechanism for the hello world app has been less reliable than desirable in the past. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 12:08 PM To: Michal Mocny Cc: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Pushed first attempt to remote branches: - https://github.com/Apache/cordova-cli/tree/copy-from-app-hello-world - https://github.com/Apache/cordova-app-hello-world/tree/copy-from-app-h ello-world Cleaning up cordova-lib is strictly required, though I think we should still take the opportunity to do so. On Tue, Mar 3, 2015 at 2:46 PM, Michal Mocny mmo...@chromium.org wrote: Jesse, I think not. The platform scripts just copy the bundled www/ (its already included with the platform). This is only for the top-level project www/ of a cordova
Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib
Alight, remote branches (named copy-from-app-hello-world) are created for cordova-lib, cordova-cli, and cordova-app-hello-world. There are still 2 failing cordova-lib tests, but I'm working to resolve that. My actual end-to-end tests appear to be working with all use cases. Please, please: if you develop a downstream distribution that uses cordova-lib directly (PhoneGap, BlackBerry, Ionic, etc), please try this out and see if it works for you. I will do so for cca. Please forward this to anyone on your team responsible for this work! -Michal On Wed, Mar 4, 2015 at 2:21 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like moving this to npm because Apache Git as a distribution mechanism for the hello world app has been less reliable than desirable in the past. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 12:08 PM To: Michal Mocny Cc: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Pushed first attempt to remote branches: - https://github.com/Apache/cordova-cli/tree/copy-from-app-hello-world - https://github.com/Apache/cordova-app-hello-world/tree/copy-from-app-hello-world Cleaning up cordova-lib is strictly required, though I think we should still take the opportunity to do so. On Tue, Mar 3, 2015 at 2:46 PM, Michal Mocny mmo...@chromium.org wrote: Jesse, I think not. The platform scripts just copy the bundled www/ (its already included with the platform). This is only for the top-level project www/ of a cordova-cli project. I guess, though, that we could consider changing the platform create scripts to import config.xml's, since they currently do not. This may be difficult given that the format is different even though the name is the same (platform vs project config). -Michal On Tue, Mar 3, 2015 at 2:40 PM, Jesse purplecabb...@gmail.com wrote: +1 Does this affect the ability to use an individual platform? ie. cordova-ios/bin/create ... Will platform create scripts need to change? @purplecabbage risingj.com On Tue, Mar 3, 2015 at 11:32 AM, Michal Mocny mmo...@google.com wrote: This came up in the context of whitelist discussion, but wanted to bring it to everyones attention. JIRA: https://issues.apache.org/jira/browse/CB-8597 We would like the default app to support installing the whitelist plugin automatically using the new plugin auto-restore feature (If you disagree, discuss on the whitelist thread, that is not the topic of this post). However, the cordova-lib create script cannot support this feature right now anyway (that is the topic of this post). I've outlined in the JIRA how we could fix that (open to feedback). TLDR; --copy-from already supports this, so lets just vastly simplify cordova-lib create.js to just always do a --copy-from (or --link-to), and change cordova-cli to provide the default --copy-from=./node_modules/cordova-app-hello-world. This also implies we can remove our last use of lazy_load from cordova-lib (minus explicit git clones or platforms/plugins), and npm all the things! It also means a semver MAJOR change to cordova-lib that downstreams directly using cordova-lib's create will need to adjust to. Thoughts? -Michal
Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib
The current breaking change is that you cannot create a new project using cordova-lib directly, without providing a project template to import from. cordova-cli works as it always has, and will provide the app-hello-world as a default if you do not use --copy-from / --link-to. However, writing that explanation out now, I realize I could just change cordova-lib to be the one to depend on cordova-app-hello-world and do the defaulting there, and not break compatibility. I think I originally envisioned the cordova-lib script to be more primitive, but its already doing a tremendous amount of input handling and backwards compat workarounds. Probably I can just make this adjustment. -Michal On Thu, Mar 5, 2015 at 4:57 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Michal: I'm new to this area - can you please elaborate why this change could potentially break downstream distributions? IS there an API change? -Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, March 5, 2015 1:12 PM To: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Alight, remote branches (named copy-from-app-hello-world) are created for cordova-lib, cordova-cli, and cordova-app-hello-world. There are still 2 failing cordova-lib tests, but I'm working to resolve that. My actual end-to-end tests appear to be working with all use cases. Please, please: if you develop a downstream distribution that uses cordova-lib directly (PhoneGap, BlackBerry, Ionic, etc), please try this out and see if it works for you. I will do so for cca. Please forward this to anyone on your team responsible for this work! -Michal On Wed, Mar 4, 2015 at 2:21 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like moving this to npm because Apache Git as a distribution mechanism for the hello world app has been less reliable than desirable in the past. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 12:08 PM To: Michal Mocny Cc: dev Subject: Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib Pushed first attempt to remote branches: - https://github.com/Apache/cordova-cli/tree/copy-from-app-hello-world - https://github.com/Apache/cordova-app-hello-world/tree/copy-from-app-h ello-world Cleaning up cordova-lib is strictly required, though I think we should still take the opportunity to do so. On Tue, Mar 3, 2015 at 2:46 PM, Michal Mocny mmo...@chromium.org wrote: Jesse, I think not. The platform scripts just copy the bundled www/ (its already included with the platform). This is only for the top-level project www/ of a cordova-cli project. I guess, though, that we could consider changing the platform create scripts to import config.xml's, since they currently do not. This may be difficult given that the format is different even though the name is the same (platform vs project config). -Michal On Tue, Mar 3, 2015 at 2:40 PM, Jesse purplecabb...@gmail.com wrote: +1 Does this affect the ability to use an individual platform? ie. cordova-ios/bin/create ... Will platform create scripts need to change? @purplecabbage risingj.com On Tue, Mar 3, 2015 at 11:32 AM, Michal Mocny mmo...@google.com wrote: This came up in the context of whitelist discussion, but wanted to bring it to everyones attention. JIRA: https://issues.apache.org/jira/browse/CB-8597 We would like the default app to support installing the whitelist plugin automatically using the new plugin auto-restore feature (If you disagree, discuss on the whitelist thread, that is not the topic of this post). However, the cordova-lib create script cannot support this feature right now anyway (that is the topic of this post). I've outlined in the JIRA how we could fix that (open to feedback). TLDR; --copy-from already supports this, so lets just vastly simplify cordova-lib create.js to just always do a --copy-from (or --link-to), and change cordova-cli to provide the default --copy-from=./node_modules/cordova-app-hello-world. This also implies we can remove our last use of lazy_load from cordova-lib (minus explicit git clones or platforms/plugins), and npm all the things! It also means a semver MAJOR change to cordova-lib that downstreams directly using cordova-lib's create will need to adjust to. Thoughts? -Michal - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Some thoughts/questions on the new --save feature
Consensus is a strong word ;) On Thu, Mar 5, 2015 at 11:02 AM, Raymond Camden raymondcam...@gmail.com wrote: Hmm. Ok... so... is there a consensus to *not* promote it? On Thu, Mar 5, 2015 at 9:24 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: config.son is not created by CLI by default anymore. You need to do create the file and add the key. -- Gorkem On 5 Mar 2015, at 7:33, Raymond Camden wrote: Sorry - what file? I don't have that in my project. If you meant user root, I don't have it there either. On Tue, Mar 3, 2015 at 12:14 PM, Gorkem Ercan gorkem.er...@gmail.com wrote: You can enable auto save by adding auto_save_plugins to be true on the .cordova/config.json file. I think this helps with the case 1 -- Gorkem On 3 Mar 2015, at 9:27, Raymond Camden wrote: 1) Is there any reason why --save isn't true by default? It would seem that in a majority of cases I'd want to save my plugins to the configuration file. I definitely see times when I would *not* want to do so, but it seems like that would be the minority of cases. 2) This is probably an edge case, but... One of the things I do when building Cordova examples is put up my www folder in a repo. My thinking is that my readers can grab the repo, and then make a new project and use --copy-from to grab the folder. This gives them my www crap and lets them go crazy. For plugins, I've been using a readme file to tell users what to do. I'd like to make use of this new feature to persist plugins and save users at least one step. (In theory they would just need to add the platform they want to test on.) But in order to do so, I can't just ship the www folder, I have to ship an entire Cordova project. That isn't a big deal per se, but it does mean they would need to copy a folder manually, possibly modify the app id, and then start working on the assets. Given that I think my use case is probably pretty minor, is there some thought as to how one could distribute sample code and make use of this feature? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - 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 -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - 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 -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Some thoughts/questions on the new --save feature
Also also, I'm not sure we should actively promote it. It seems like the kind of config file we want to phase out. -Michal On Thu, Mar 5, 2015 at 10:22 AM, Michal Mocny mmo...@chromium.org wrote: By default, they do not get created unless they have non-default values. This is usually only applicable if you use the js interface of cordova-lib and not the command line cli, but possibly doing things like specifying a custom plugin search path will create the file? On Thu, Mar 5, 2015 at 7:43 AM, Raymond Camden raymondcam...@gmail.com wrote: I found this doc, https://wiki.apache.org/cordova/ConfigurationFiles, which mentions that you can have a .cordova/config.json in projects and your user dir. I don't have them in either location. Does that mean - by default - they don't exist until I make one? If so - where is the documentation showing possible settings? On Thu, Mar 5, 2015 at 6:34 AM, Raymond Camden raymondcam...@gmail.com wrote: Definitely - once I find the file. ;) On Tue, Mar 3, 2015 at 12:20 PM, Michal Mocny mmo...@chromium.org wrote: Worthy of a blogpost, Ray! On Tue, Mar 3, 2015 at 1:17 PM, Victor Sosa sosah.vic...@gmail.com wrote: Good to know this trick. .. Thanks, Gorkem! 2015-03-03 12:14 GMT-06:00 Gorkem Ercan gorkem.er...@gmail.com: You can enable auto save by adding auto_save_plugins to be true on the .cordova/config.json file. I think this helps with the case 1 -- Gorkem On 3 Mar 2015, at 9:27, Raymond Camden wrote: 1) Is there any reason why --save isn't true by default? It would seem that in a majority of cases I'd want to save my plugins to the configuration file. I definitely see times when I would *not* want to do so, but it seems like that would be the minority of cases. 2) This is probably an edge case, but... One of the things I do when building Cordova examples is put up my www folder in a repo. My thinking is that my readers can grab the repo, and then make a new project and use --copy-from to grab the folder. This gives them my www crap and lets them go crazy. For plugins, I've been using a readme file to tell users what to do. I'd like to make use of this new feature to persist plugins and save users at least one step. (In theory they would just need to add the platform they want to test on.) But in order to do so, I can't just ship the www folder, I have to ship an entire Cordova project. That isn't a big deal per se, but it does mean they would need to copy a folder manually, possibly modify the app id, and then start working on the assets. Given that I think my use case is probably pretty minor, is there some thought as to how one could distribute sample code and make use of this feature? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - 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 -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Is anyone available for a project to develop a Cordova plugin?
On Android, you could investigate WebRTC or try your hand at overlaying a native view (not easy). On iOS, I'm not sure this is possible. -Michal On Wed, Mar 4, 2015 at 10:27 AM, Guy Jacks guy.ja...@gmail.com wrote: We're trying to create an interface within ionic similar to instagram for users to take pictures and record videos. The existing plugin takes the user to the device's native camera app. Regards. -- fndrz.com (Founders) - Removing Barriers to Innovation for Entrepreneurs and SocialPreneurs. oneraft.com - Maximize your impact and enjoyment when you give to charity. theatertilt.com (coming soon) - Watch films you love at an Art Theater near you. mobile: 614.448.7649 guy.ja...@gmail.com gtalk: guy.jacks skype: guy.jacks
Re: Hello!
Hi Rob! Nice to see all the new faces. -Michal On Wed, Mar 4, 2015 at 9:51 AM, Andrew Grieve agri...@chromium.org wrote: Welcome Rob! On Tue, Mar 3, 2015 at 8:30 PM, Shazron shaz...@gmail.com wrote: Welcome Rob! On Tue, Mar 3, 2015 at 4:33 PM, Rob Paveza rob.pav...@microsoft.com wrote: Hello! I'm Rob Paveza. I'm a software engineer at Microsoft, on the Visual Studio team. I've been working on the Cordova tools for a short while, particularly getting a cordova-windows prototype ready to roll out with Windows 10 support. I wanted to start getting into the mix and getting involved in stuff that IS currently out in the open, so I thought I'd say hello! -Rob - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [CLI] Default target when not specified for build, compile?
I think its fine to fail if the attached device isn't provisioned. Perhaps we could append a message explaining `cordova run --emulator` or `cordova emulate` commands, but I think even that is not necessary. My personal expectation is that once I plug in a device using a cable, I very likely want to actually develop on it. -Michal On Tue, Mar 3, 2015 at 6:08 PM, Shazron shaz...@gmail.com wrote: Defaulting to device might be problematic on iOS: sure we can detect if a device is attached (using iso-deploy), but the build might fail because a signing cert/provisioning profile is not valid (I think the only way to check is to just build, I might be wrong). The only guaranteed way it will always run is through emulator (at least on iOS). On Tue, Mar 3, 2015 at 2:50 PM, Michal Mocny mmo...@chromium.org wrote: Imho, it should do what: cordova run would do. I would think it would run once for each platform, defaulting to device if attached. On Tue, Mar 3, 2015 at 4:37 PM, Shazron shaz...@gmail.com wrote: What is the expected behaviour here? `cordova build` My expectation is that it would build for both device and emulator. In iOS pre-3.8.0 it does, but now it only builds for emulator only after the node.js script port, which may or may not be a bug depending on consensus. The online docs and cli docs do not give any clue regarding this. What do other platforms experience? The problem with building for both device and emulator is your build times now approximately double. - 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: Android's new Whitelist Plugins
I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM To: dev Subject: Re: Android's new Whitelist Plugins I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Android's new Whitelist Plugins
+1 to names. On Wed, Mar 4, 2015 at 9:03 PM, Andrew Grieve agri...@chromium.org wrote: No comments about the names yet, but I'm now leaning towards: cordova-plugin-legacy-whitelist and cordova-plugin-whitelist as the two new git repos to create (rather than url-policy) On Wed, Mar 4, 2015 at 8:49 PM, Andrew Grieve agri...@chromium.org wrote: I think how Cordova works right now was the best way. Have access blocked by default, but have a access origin=*/ in the default template. It makes the setting visible, while still working out-of-the-box. If we turned on requests when no whitelist plugin is installed, then existing apps that have access tags will have their whitelist removed with 4.0.0 and not know it. If someone updates and their app can't hit the network anymore, then I think Stack Overflow will tell them why pretty quickly. We should also be very clear in the release notes and upgrade guide. On Wed, Mar 4, 2015 at 7:54 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: I like Ian's proposal of blocking network access only when a whitelist plugin is added to do so and is choosing to override the default behavior. Scanning config.xml on upgrade might be a good way to warn devs to refer them to use this plugin. These changes should also be documented in the migration guide from Android 3.x to 4.0. Thanks, Nikhil -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, March 4, 2015 11:05 AM To: dev@cordova.apache.org Subject: Re: Android's new Whitelist Plugins I like the defaults as discussed, regardless of how they are achieved. ie. network yes, intents no This is similar to how a plain webview works if you add it to a native app on ios or android, at least the network part, not sure what the default intent handling is. Are there portions of this functionality that make more sense as part of the platform native code? To me a plugin that is installed by default is just modular platform code. Is there ever a reason to NOT want this plugin, versus just opening up access? @purplecabbage risingj.com On Wed, Mar 4, 2015 at 9:37 AM, Michal Mocny mmo...@chromium.org wrote: I've been working on adding support to just install the whitelist plugin by default, and to add the access origin=* to the default app. Is that sufficient? I think we may still need to do what Ian suggests and prompt on upgrade (or prepare)? For downstreams, especially IDE based ones, they will need to make sure the plugin is added by default however they do that. On Wed, Mar 4, 2015 at 12:06 PM, Ian Clelland iclell...@chromium.org wrote: On Tue, Mar 3, 2015 at 8:20 PM, Nikhil Khandelwal nikhi...@microsoft.com wrote: Here are my thoughts on the default behavior: - navigation should be disabled. - XHR network request should be enabled. And application launch through intent URLs should also be disabled. (IMO) That's not a bad default -- it enables CSP usage by default, which I think is good. It also (I think) means we're giving up on suggesting that network requests can be completely blocked by default, because that's definitely not the case on Android. We can implement this within the new framework: there is the idea of a 'default policy' that only comes into effect when no plugins take responsibility for the whitelist. As soon as any plugin, though, handles the shouldAllowRequest() call, for instance, the default policy is no longer in effect, and it is a true whitelist (block-by-default) My biggest concern with this is that developers are going to blindly update to Cordova 4.0.0, and when their app *just works*, they are not going to realize that they are actually less secure than before. (Without a plugin, we've opened up all network access) Idea -- maybe we can scan config.xml -- at run time, or on prepare, or on upgrade -- and if we see any access tag other than access origin=* we can display a loud message, suggesting strongly that they install an appropriate plugin. Ian The plugin name is fine. I'm not convinced about a user having to add this plugin to enable network requests for Android/iOS. This default behavior should work with the platform and should not require a plugin. This inhibits users from getting the ground running on a Cordova app. It breaks existing templates in IDEs and other downstream CLIs as well - as all of them need to include this plugin to have any network access work. Thanks, Nikhil -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, March 3, 2015 11:22 AM
Re: Android's new Whitelist Plugins
..taking a look at the cli create.js script, we would need to update it a bit to actually have it import a hello-world config.xml. The lib actually ships the template config.xml right now instead of the hello-world project, which seems unnecessary given our --copy-from/--link-to import logic. Seems we could simplify the whole thing. -Michal On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Android's new Whitelist Plugins
My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: [REVIEW] NPM Registry integration for fetching plugins and plugin rm
Darryl, I believe that cordova-cli will continue to use `cordova plugin add` and not use `node_modules` at all for phase 1 rollout. It will use the `npm` library to fetch into the existing plugins/ folder. There will be no user visible change to project structure, though the plugins are being renamed as part of the transition. -Michal On Tue, Mar 3, 2015 at 10:31 AM, Darryl Pogue dvpdin...@gmail.com wrote: Less a comment on the code and more of a question about the NPM transition from an end-user pespective: Is Cordova going to automatically discover and use plugins that are found in the node_modules folder (from package.json), or will it still keep its own plugins folder and require they be installed using `cordova plugin add name`? On 3 March 2015 at 06:40, Andrew Grieve agri...@chromium.org wrote: Good stuff. Added some style comments, but logic lgtm! On Tue, Mar 3, 2015 at 3:55 AM, Steven Gill stevengil...@gmail.com wrote: Also, Issue: https://issues.apache.org/jira/browse/CB-8551 On Tue, Mar 3, 2015 at 12:54 AM, Steven Gill stevengil...@gmail.com wrote: PR: https://github.com/apache/cordova-lib/pull/175/files Please review, leave feedback and ask questions! - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Some thoughts/questions on the new --save feature
Raymond, you should just include your config.xml in the repo along with your www. It will be imported as part of --copy-from and should (I haven't tested!) auto-restore plugins with this new feature. As for default not --save, this is mostly for npm compatibility, but also because we decided to auto-restore on prepare (unlike npm which require manual install). This way, the new feature is 100% opt-in for users of the existing tools, but you automatically use the feature if you clone a project that is using the feature. I think thats a good balance. Also, if you forget to --save plugins, you can re-run the add command with --save without hitting the network. (But I don't think there is a cordova plugin --save to just add all installed plugins, we could consider adding that). -Michal On Tue, Mar 3, 2015 at 11:10 AM, Raymond Camden raymondcam...@gmail.com wrote: 1) I can see the logic there, but it seems like folks would want to save so much, overwhelmingly so, that it makes sense to not follow the expectation here? Also, would our typical user be more familiar with Node and be confused by this? 2) I know about the link too, my issue is more about what I (I being the person sharing code) would publish. Right now I share *just* the www folder so folks can --copy-from or link, whatever. But with this new feature, I'd have to publish the entire project. That's what I'm asking about - does that make sense? To be clear, I'm not saying we need a magical solution for this, as I said, my use case is *not* the norm. I'm mainly just wondering if there is perhaps some elegant solution to including a) a small amount of files and b) easy setup for folks using my demos. On Tue, Mar 3, 2015 at 9:51 AM, Steven Gill stevengil...@gmail.com wrote: 1) I would say it is not autosave by default so we follow node/npm style. You have to be explicit when saving dependencies to node projects. Example npm install browserify --save. 2) I believe their is a --link command to point to your www for your Cordova project to use. This isn't a perfect solution for your use case but it better than manually copying. Others who are more familiar with this can hopefully elaborate. On Mar 3, 2015 6:42 AM, Victor Sosa sosah.vic...@gmail.com wrote: +1 on Raymond's idea, I also why --save isn't default. When talking about SCMs, the best practice for Cordova applications is to share them with no platforms nor plugins, so each time a developer checks out the project from the repo, he/she will need to add the appropriate plugins and desired platform. Why not making the developers life easier with this --save flag? 2015-03-03 8:27 GMT-06:00 Raymond Camden raymondcam...@gmail.com: 1) Is there any reason why --save isn't true by default? It would seem that in a majority of cases I'd want to save my plugins to the configuration file. I definitely see times when I would *not* want to do so, but it seems like that would be the minority of cases. 2) This is probably an edge case, but... One of the things I do when building Cordova examples is put up my www folder in a repo. My thinking is that my readers can grab the repo, and then make a new project and use --copy-from to grab the folder. This gives them my www crap and lets them go crazy. For plugins, I've been using a readme file to tell users what to do. I'd like to make use of this new feature to persist plugins and save users at least one step. (In theory they would just need to add the platform they want to test on.) But in order to do so, I can't just ship the www folder, I have to ship an entire Cordova project. That isn't a big deal per se, but it does mean they would need to copy a folder manually, possibly modify the app id, and then start working on the assets. Given that I think my use case is probably pretty minor, is there some thought as to how one could distribute sample code and make use of this feature? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail:
Re: Some thoughts/questions on the new --save feature
Yet more clarification: your git repo should look like: - www/ - index.html - ... - config.xml - ... NOT - config.xml - index.html - ... On Tue, Mar 3, 2015 at 11:59 AM, Michal Mocny mmo...@chromium.org wrote: Raymond, you should just include your config.xml in the repo along with your www. It will be imported as part of --copy-from and should (I haven't tested!) auto-restore plugins with this new feature. As for default not --save, this is mostly for npm compatibility, but also because we decided to auto-restore on prepare (unlike npm which require manual install). This way, the new feature is 100% opt-in for users of the existing tools, but you automatically use the feature if you clone a project that is using the feature. I think thats a good balance. Also, if you forget to --save plugins, you can re-run the add command with --save without hitting the network. (But I don't think there is a cordova plugin --save to just add all installed plugins, we could consider adding that). -Michal On Tue, Mar 3, 2015 at 11:10 AM, Raymond Camden raymondcam...@gmail.com wrote: 1) I can see the logic there, but it seems like folks would want to save so much, overwhelmingly so, that it makes sense to not follow the expectation here? Also, would our typical user be more familiar with Node and be confused by this? 2) I know about the link too, my issue is more about what I (I being the person sharing code) would publish. Right now I share *just* the www folder so folks can --copy-from or link, whatever. But with this new feature, I'd have to publish the entire project. That's what I'm asking about - does that make sense? To be clear, I'm not saying we need a magical solution for this, as I said, my use case is *not* the norm. I'm mainly just wondering if there is perhaps some elegant solution to including a) a small amount of files and b) easy setup for folks using my demos. On Tue, Mar 3, 2015 at 9:51 AM, Steven Gill stevengil...@gmail.com wrote: 1) I would say it is not autosave by default so we follow node/npm style. You have to be explicit when saving dependencies to node projects. Example npm install browserify --save. 2) I believe their is a --link command to point to your www for your Cordova project to use. This isn't a perfect solution for your use case but it better than manually copying. Others who are more familiar with this can hopefully elaborate. On Mar 3, 2015 6:42 AM, Victor Sosa sosah.vic...@gmail.com wrote: +1 on Raymond's idea, I also why --save isn't default. When talking about SCMs, the best practice for Cordova applications is to share them with no platforms nor plugins, so each time a developer checks out the project from the repo, he/she will need to add the appropriate plugins and desired platform. Why not making the developers life easier with this --save flag? 2015-03-03 8:27 GMT-06:00 Raymond Camden raymondcam...@gmail.com: 1) Is there any reason why --save isn't true by default? It would seem that in a majority of cases I'd want to save my plugins to the configuration file. I definitely see times when I would *not* want to do so, but it seems like that would be the minority of cases. 2) This is probably an edge case, but... One of the things I do when building Cordova examples is put up my www folder in a repo. My thinking is that my readers can grab the repo, and then make a new project and use --copy-from to grab the folder. This gives them my www crap and lets them go crazy. For plugins, I've been using a readme file to tell users what to do. I'd like to make use of this new feature to persist plugins and save users at least one step. (In theory they would just need to add the platform they want to test on.) But in order to do so, I can't just ship the www folder, I have to ship an entire Cordova project. That isn't a big deal per se, but it does mean they would need to copy a folder manually, possibly modify the app id, and then start working on the assets. Given that I think my use case is probably pretty minor, is there some thought as to how one could distribute sample code and make use of this feature? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam
Re: Some thoughts/questions on the new --save feature
Also also ;) cca applications include a default .gitignore with these contents: --- ## ## This file is the suggested default .gitignore to be used by cca applications ## # Usually, you shouldn't version control `platforms/` and `plugins/`. They are # build artefacts which change from machine to machine and over time. # If you are manually making edits in these folders, proceed with caution. /platforms/ /plugins/ # Other cca artefacts. ... --- This has worked very well for us, since users can just git init git remote add git push a project without thinking about it. -Michal On Tue, Mar 3, 2015 at 12:12 PM, Michal Mocny mmo...@chromium.org wrote: Yet more clarification: your git repo should look like: - www/ - index.html - ... - config.xml - ... NOT - config.xml - index.html - ... On Tue, Mar 3, 2015 at 11:59 AM, Michal Mocny mmo...@chromium.org wrote: Raymond, you should just include your config.xml in the repo along with your www. It will be imported as part of --copy-from and should (I haven't tested!) auto-restore plugins with this new feature. As for default not --save, this is mostly for npm compatibility, but also because we decided to auto-restore on prepare (unlike npm which require manual install). This way, the new feature is 100% opt-in for users of the existing tools, but you automatically use the feature if you clone a project that is using the feature. I think thats a good balance. Also, if you forget to --save plugins, you can re-run the add command with --save without hitting the network. (But I don't think there is a cordova plugin --save to just add all installed plugins, we could consider adding that). -Michal On Tue, Mar 3, 2015 at 11:10 AM, Raymond Camden raymondcam...@gmail.com wrote: 1) I can see the logic there, but it seems like folks would want to save so much, overwhelmingly so, that it makes sense to not follow the expectation here? Also, would our typical user be more familiar with Node and be confused by this? 2) I know about the link too, my issue is more about what I (I being the person sharing code) would publish. Right now I share *just* the www folder so folks can --copy-from or link, whatever. But with this new feature, I'd have to publish the entire project. That's what I'm asking about - does that make sense? To be clear, I'm not saying we need a magical solution for this, as I said, my use case is *not* the norm. I'm mainly just wondering if there is perhaps some elegant solution to including a) a small amount of files and b) easy setup for folks using my demos. On Tue, Mar 3, 2015 at 9:51 AM, Steven Gill stevengil...@gmail.com wrote: 1) I would say it is not autosave by default so we follow node/npm style. You have to be explicit when saving dependencies to node projects. Example npm install browserify --save. 2) I believe their is a --link command to point to your www for your Cordova project to use. This isn't a perfect solution for your use case but it better than manually copying. Others who are more familiar with this can hopefully elaborate. On Mar 3, 2015 6:42 AM, Victor Sosa sosah.vic...@gmail.com wrote: +1 on Raymond's idea, I also why --save isn't default. When talking about SCMs, the best practice for Cordova applications is to share them with no platforms nor plugins, so each time a developer checks out the project from the repo, he/she will need to add the appropriate plugins and desired platform. Why not making the developers life easier with this --save flag? 2015-03-03 8:27 GMT-06:00 Raymond Camden raymondcam...@gmail.com: 1) Is there any reason why --save isn't true by default? It would seem that in a majority of cases I'd want to save my plugins to the configuration file. I definitely see times when I would *not* want to do so, but it seems like that would be the minority of cases. 2) This is probably an edge case, but... One of the things I do when building Cordova examples is put up my www folder in a repo. My thinking is that my readers can grab the repo, and then make a new project and use --copy-from to grab the folder. This gives them my www crap and lets them go crazy. For plugins, I've been using a readme file to tell users what to do. I'd like to make use of this new feature to persist plugins and save users at least one step. (In theory they would just need to add the platform they want to test on.) But in order to do so, I can't just ship the www folder, I have to ship an entire Cordova project. That isn't a big deal per se, but it does mean they would need to copy a folder manually, possibly modify the app id, and then start working on the assets. Given that I think my use case is probably pretty minor, is there some thought as to how one could distribute sample code and make use of this feature
Re: Some thoughts/questions on the new --save feature
Worthy of a blogpost, Ray! On Tue, Mar 3, 2015 at 1:17 PM, Victor Sosa sosah.vic...@gmail.com wrote: Good to know this trick. .. Thanks, Gorkem! 2015-03-03 12:14 GMT-06:00 Gorkem Ercan gorkem.er...@gmail.com: You can enable auto save by adding auto_save_plugins to be true on the .cordova/config.json file. I think this helps with the case 1 -- Gorkem On 3 Mar 2015, at 9:27, Raymond Camden wrote: 1) Is there any reason why --save isn't true by default? It would seem that in a majority of cases I'd want to save my plugins to the configuration file. I definitely see times when I would *not* want to do so, but it seems like that would be the minority of cases. 2) This is probably an edge case, but... One of the things I do when building Cordova examples is put up my www folder in a repo. My thinking is that my readers can grab the repo, and then make a new project and use --copy-from to grab the folder. This gives them my www crap and lets them go crazy. For plugins, I've been using a readme file to tell users what to do. I'd like to make use of this new feature to persist plugins and save users at least one step. (In theory they would just need to add the platform they want to test on.) But in order to do so, I can't just ship the www folder, I have to ship an entire Cordova project. That isn't a big deal per se, but it does mean they would need to copy a folder manually, possibly modify the app id, and then start working on the assets. Given that I think my use case is probably pretty minor, is there some thought as to how one could distribute sample code and make use of this feature? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - 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 -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco
Re: Android's new Whitelist Plugins
Ah, the bit about access being mostly useful for pre-kitkat was context I was missing. Seems important to note at the start of the section. I'll update the README. On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Some thoughts/questions on the new --save feature
Sweet! Ray: I think `www and config.xml crap` is a great way to say it ;) On Tue, Mar 3, 2015 at 12:53 PM, Mefire O. ommen...@microsoft.com wrote: Michal, there is a 'mass save' feature for both platforms and plugins on the way. They will allow the saving of already installed platforms and plugins respectively : 'cordova platform save' and 'cordova plugin save'. The platform's one is currently in code review: https://github.com/apache/cordova-lib/pull/170 Sent from my Windows Phone From: Michal Mocnymailto:mmo...@chromium.org Sent: 3/3/2015 9:00 AM To: devmailto:dev@cordova.apache.org Subject: Re: Some thoughts/questions on the new --save feature Raymond, you should just include your config.xml in the repo along with your www. It will be imported as part of --copy-from and should (I haven't tested!) auto-restore plugins with this new feature. As for default not --save, this is mostly for npm compatibility, but also because we decided to auto-restore on prepare (unlike npm which require manual install). This way, the new feature is 100% opt-in for users of the existing tools, but you automatically use the feature if you clone a project that is using the feature. I think thats a good balance. Also, if you forget to --save plugins, you can re-run the add command with --save without hitting the network. (But I don't think there is a cordova plugin --save to just add all installed plugins, we could consider adding that). -Michal On Tue, Mar 3, 2015 at 11:10 AM, Raymond Camden raymondcam...@gmail.com wrote: 1) I can see the logic there, but it seems like folks would want to save so much, overwhelmingly so, that it makes sense to not follow the expectation here? Also, would our typical user be more familiar with Node and be confused by this? 2) I know about the link too, my issue is more about what I (I being the person sharing code) would publish. Right now I share *just* the www folder so folks can --copy-from or link, whatever. But with this new feature, I'd have to publish the entire project. That's what I'm asking about - does that make sense? To be clear, I'm not saying we need a magical solution for this, as I said, my use case is *not* the norm. I'm mainly just wondering if there is perhaps some elegant solution to including a) a small amount of files and b) easy setup for folks using my demos. On Tue, Mar 3, 2015 at 9:51 AM, Steven Gill stevengil...@gmail.com wrote: 1) I would say it is not autosave by default so we follow node/npm style. You have to be explicit when saving dependencies to node projects. Example npm install browserify --save. 2) I believe their is a --link command to point to your www for your Cordova project to use. This isn't a perfect solution for your use case but it better than manually copying. Others who are more familiar with this can hopefully elaborate. On Mar 3, 2015 6:42 AM, Victor Sosa sosah.vic...@gmail.com wrote: +1 on Raymond's idea, I also why --save isn't default. When talking about SCMs, the best practice for Cordova applications is to share them with no platforms nor plugins, so each time a developer checks out the project from the repo, he/she will need to add the appropriate plugins and desired platform. Why not making the developers life easier with this --save flag? 2015-03-03 8:27 GMT-06:00 Raymond Camden raymondcam...@gmail.com: 1) Is there any reason why --save isn't true by default? It would seem that in a majority of cases I'd want to save my plugins to the configuration file. I definitely see times when I would *not* want to do so, but it seems like that would be the minority of cases. 2) This is probably an edge case, but... One of the things I do when building Cordova examples is put up my www folder in a repo. My thinking is that my readers can grab the repo, and then make a new project and use --copy-from to grab the folder. This gives them my www crap and lets them go crazy. For plugins, I've been using a readme file to tell users what to do. I'd like to make use of this new feature to persist plugins and save users at least one step. (In theory they would just need to add the platform they want to test on.) But in order to do so, I can't just ship the www folder, I have to ship an entire Cordova project. That isn't a big deal per se, but it does mean they would need to copy a folder manually, possibly modify the app id, and then start working on the assets. Given that I think my use case is probably pretty minor, is there some thought as to how one could distribute sample code and make use of this feature? -- === Raymond Camden, Developer Advocate for
Re: Android's new Whitelist Plugins
(Added this note: https://github.com/apache/cordova-plugins/commit/3ed17046ea7efaeccda4c4ffe82bb351e8b966f1, let me know if its inacurate). -Michal On Tue, Mar 3, 2015 at 1:06 PM, Michal Mocny mmo...@chromium.org wrote: Ah, the bit about access being mostly useful for pre-kitkat was context I was missing. Seems important to note at the start of the section. I'll update the README. On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib
Jesse, I think not. The platform scripts just copy the bundled www/ (its already included with the platform). This is only for the top-level project www/ of a cordova-cli project. I guess, though, that we could consider changing the platform create scripts to import config.xml's, since they currently do not. This may be difficult given that the format is different even though the name is the same (platform vs project config). -Michal On Tue, Mar 3, 2015 at 2:40 PM, Jesse purplecabb...@gmail.com wrote: +1 Does this affect the ability to use an individual platform? ie. cordova-ios/bin/create ... Will platform create scripts need to change? @purplecabbage risingj.com On Tue, Mar 3, 2015 at 11:32 AM, Michal Mocny mmo...@google.com wrote: This came up in the context of whitelist discussion, but wanted to bring it to everyones attention. JIRA: https://issues.apache.org/jira/browse/CB-8597 We would like the default app to support installing the whitelist plugin automatically using the new plugin auto-restore feature (If you disagree, discuss on the whitelist thread, that is not the topic of this post). However, the cordova-lib create script cannot support this feature right now anyway (that is the topic of this post). I've outlined in the JIRA how we could fix that (open to feedback). TLDR; --copy-from already supports this, so lets just vastly simplify cordova-lib create.js to just always do a --copy-from (or --link-to), and change cordova-cli to provide the default --copy-from=./node_modules/cordova-app-hello-world. This also implies we can remove our last use of lazy_load from cordova-lib (minus explicit git clones or platforms/plugins), and npm all the things! It also means a semver MAJOR change to cordova-lib that downstreams directly using cordova-lib's create will need to adjust to. Thoughts? -Michal
Re: [DISCUSS] publishing cordova-app-hello-world to npm and adding as dependency of cordova-lib
Pushed first attempt to remote branches: - https://github.com/Apache/cordova-cli/tree/copy-from-app-hello-world - https://github.com/Apache/cordova-app-hello-world/tree/copy-from-app-hello-world Cleaning up cordova-lib is strictly required, though I think we should still take the opportunity to do so. On Tue, Mar 3, 2015 at 2:46 PM, Michal Mocny mmo...@chromium.org wrote: Jesse, I think not. The platform scripts just copy the bundled www/ (its already included with the platform). This is only for the top-level project www/ of a cordova-cli project. I guess, though, that we could consider changing the platform create scripts to import config.xml's, since they currently do not. This may be difficult given that the format is different even though the name is the same (platform vs project config). -Michal On Tue, Mar 3, 2015 at 2:40 PM, Jesse purplecabb...@gmail.com wrote: +1 Does this affect the ability to use an individual platform? ie. cordova-ios/bin/create ... Will platform create scripts need to change? @purplecabbage risingj.com On Tue, Mar 3, 2015 at 11:32 AM, Michal Mocny mmo...@google.com wrote: This came up in the context of whitelist discussion, but wanted to bring it to everyones attention. JIRA: https://issues.apache.org/jira/browse/CB-8597 We would like the default app to support installing the whitelist plugin automatically using the new plugin auto-restore feature (If you disagree, discuss on the whitelist thread, that is not the topic of this post). However, the cordova-lib create script cannot support this feature right now anyway (that is the topic of this post). I've outlined in the JIRA how we could fix that (open to feedback). TLDR; --copy-from already supports this, so lets just vastly simplify cordova-lib create.js to just always do a --copy-from (or --link-to), and change cordova-cli to provide the default --copy-from=./node_modules/cordova-app-hello-world. This also implies we can remove our last use of lazy_load from cordova-lib (minus explicit git clones or platforms/plugins), and npm all the things! It also means a semver MAJOR change to cordova-lib that downstreams directly using cordova-lib's create will need to adjust to. Thoughts? -Michal
Re: Android's new Whitelist Plugins
I've filed a JIRA issue with my thoughts on how to approach this: https://issues.apache.org/jira/browse/CB-8597 On Tue, Mar 3, 2015 at 1:02 PM, Andrew Grieve agri...@chromium.org wrote: Like your ideas a lot. Updating the project template makes a lot of sense. Tried to make it clear in the README, so if any part was not clear please fix it. But, the CSP tag is the more important bit, since access can't actually block all requests. The only reason to even leave access in there is to support pre-kitkat webviews, where no CSP support exists. CSP is also used to set a navigation whitelist for subframes, which the native side is not able to do. On Tue, Mar 3, 2015 at 11:22 AM, Michal Mocny mmo...@chromium.org wrote: My thoughts: - The split between allow-navigation, allow-intent, and access: Like it a lot. - I think the defaults *for the plugin* are very reasonable. However, we may want to provide a default set of tags for the hello world app. A year or so ago we added a default access * whitelist and I think maybe we should continue that. (on the other hand, I've gotten used to explicitly whitelisting every url as part of chrome packaged app development and its not so bad). - Additionally, that means this plugin should be installed by default. As we discussed this morning, with the new plugin --save functionality we could just add this to the helloworld config.xml, I think! - Do you really need a CSP meta tag *and* access declarations? Thats what the README.md implies, but I would assume CSP trumps? -Michal On Mon, Mar 2, 2015 at 9:38 PM, Andrew Grieve agri...@chromium.org wrote: I've tried to explain it in the plugin's readme: https://github.com/apache/cordova-plugins/tree/master/url-policy Some points for discussion: - What should the default behaviour be for the three whitelists (what should happen if not whitelist plugin is installed). - right now it can't open external URLs - and can't do XHRs to http(s) - Is the plugin name decent (url-policy). We should make a dedicated git repo for it (as well as for legacy-whitelist plugin)
Re: Some thoughts/questions on the new --save feature
We should save the phase 2 planning for a separate thread / next hangout. Many strong opinions and bikeshedding to be had, lets finish phase 1 and sit on the changes for a bit to get comfortable. -Michal On Tue, Mar 3, 2015 at 1:55 PM, Steven Gill stevengil...@gmail.com wrote: On Tue, Mar 3, 2015 at 8:10 AM, Raymond Camden raymondcam...@gmail.com wrote: 1) I can see the logic there, but it seems like folks would want to save so much, overwhelmingly so, that it makes sense to not follow the expectation here? Also, would our typical user be more familiar with Node and be confused by this? I think it is best to stick to established best practices. I was on team autosave in the beginning but switched over. All of us should take a bigger role in educating our typical user on how to use npm and node. We provide Cordova so developers can make apps easily, but need to do a better job of helping developers improve their skills. Once we switch to package.json and improve our JSAPI, Cordova projects will be node projects. Our users will have to learn some node. I think we should take the opportunity to educate our users about node/npm and not just Cordova! 2) I know about the link too, my issue is more about what I (I being the person sharing code) would publish. Right now I share *just* the www folder so folks can --copy-from or link, whatever. But with this new feature, I'd have to publish the entire project. That's what I'm asking about - does that make sense? To be clear, I'm not saying we need a magical solution for this, as I said, my use case is *not* the norm. I'm mainly just wondering if there is perhaps some elegant solution to including a) a small amount of files and b) easy setup for folks using my demos. On Tue, Mar 3, 2015 at 9:51 AM, Steven Gill stevengil...@gmail.com wrote: 1) I would say it is not autosave by default so we follow node/npm style. You have to be explicit when saving dependencies to node projects. Example npm install browserify --save. 2) I believe their is a --link command to point to your www for your Cordova project to use. This isn't a perfect solution for your use case but it better than manually copying. Others who are more familiar with this can hopefully elaborate. On Mar 3, 2015 6:42 AM, Victor Sosa sosah.vic...@gmail.com wrote: +1 on Raymond's idea, I also why --save isn't default. When talking about SCMs, the best practice for Cordova applications is to share them with no platforms nor plugins, so each time a developer checks out the project from the repo, he/she will need to add the appropriate plugins and desired platform. Why not making the developers life easier with this --save flag? 2015-03-03 8:27 GMT-06:00 Raymond Camden raymondcam...@gmail.com: 1) Is there any reason why --save isn't true by default? It would seem that in a majority of cases I'd want to save my plugins to the configuration file. I definitely see times when I would *not* want to do so, but it seems like that would be the minority of cases. 2) This is probably an edge case, but... One of the things I do when building Cordova examples is put up my www folder in a repo. My thinking is that my readers can grab the repo, and then make a new project and use --copy-from to grab the folder. This gives them my www crap and lets them go crazy. For plugins, I've been using a readme file to tell users what to do. I'd like to make use of this new feature to persist plugins and save users at least one step. (In theory they would just need to add the platform they want to test on.) But in order to do so, I can't just ship the www folder, I have to ship an entire Cordova project. That isn't a big deal per se, but it does mean they would need to copy a folder manually, possibly modify the app id, and then start working on the assets. Given that I think my use case is probably pretty minor, is there some thought as to how one could distribute sample code and make use of this feature? -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter: raymondcamden - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org -- Victor Adrian Sosa Herrera IBM Software Engineer Guadalajara, Jalisco -- === Raymond Camden, Developer Advocate for MobileFirst at IBM Email : raymondcam...@gmail.com Blog : www.raymondcamden.com Twitter:
Re: [CLI] Default target when not specified for build, compile?
Imho, it should do what: cordova run would do. I would think it would run once for each platform, defaulting to device if attached. On Tue, Mar 3, 2015 at 4:37 PM, Shazron shaz...@gmail.com wrote: What is the expected behaviour here? `cordova build` My expectation is that it would build for both device and emulator. In iOS pre-3.8.0 it does, but now it only builds for emulator only after the node.js script port, which may or may not be a bug depending on consensus. The online docs and cli docs do not give any clue regarding this. What do other platforms experience? The problem with building for both device and emulator is your build times now approximately double. - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [DISCUSS] Cordova-Android 4.0.0 Release
And docs, I think. On Mon, Mar 2, 2015 at 4:37 PM, Joe Bowser bows...@gmail.com wrote: So, right now the whitelist changes are what's holding up the 4.0.0 release now? Is this really the only thing that's holding up this release? On Wed Feb 25 2015 at 1:18:26 PM Andrew Grieve agri...@chromium.org wrote: I think we'll also need to finish with the whitelist changes have both the legacy and new-way whitelist plugins released before we can do a 4.0.0 release (otherwise you wouldn't be able to write an app that hits the network) On Wed, Feb 25, 2015 at 12:41 PM, Andrew Grieve agri...@chromium.org wrote: Alright, branch is merged in and I fixed a couple other things I noticed broken in the native test app (back button background color). I've also gone ahead with removing the LinearLayout and confirmed that both maps and nativepagetransitions plugins are not affected at all. Might as well add in the key signing tweaks that have been agreed upon. I can do that today. Would like your input on: Deprecated show/hide customView - At first I thought this was just view twiddling for video on old androids that was not meant to be exposed - I see now though that there is custom back button logic for it - and that the maps plugin uses it to go fullscreen - so I'm thinking let's not deprecate. We're also still waiting for a tools release to happen that will set 3.7.1 as the default platform (don't have cycles to do it this week myself) On Tue, Feb 24, 2015 at 7:39 PM, Joe Bowser bows...@gmail.com wrote: I can't come up with any. Let's not delay the release on that. So, other than the platform docs, we should be good to go, right? On Thu Feb 19 2015 at 11:42:40 AM Andrew Grieve agri...@chromium.org wrote: Thanks for the quick review. I'll have a look through your comments. Now's a good time to change names, so feel free to suggest alternatives. On Thu, Feb 19, 2015 at 1:32 PM, Joe Bowser bows...@gmail.com wrote: I've done a quick read of the pull request and left some comments in there. I'm in Salt Lake this week, so I haven't had a chance to really test this pull request yet, but while I'm not in love with the naming convention used, it looks mostly OK. On Thu Feb 19 2015 at 11:19:51 AM Andrew Grieve agri...@chromium.org wrote: They would need to do similar to the PR for xwalk. It's actually a lot less code now to implement a custom engine, so I think it makes geckoview much more feasible. The embedded case (I'm guessing you mean layout xml?) is one of the unit tests. Have a look here: https://github.com/agrieve/cordova-android/blob/engine/ test/src/org/apache/cordova/test/CordovaWebViewTestActivity.java If we delete LinearLayout, we just pass the WebView itself to setContentView(). It will still have a FrameLayout as a parent (which is the unchangeable root View of all Activities) For reference, here's now NativePageTransitions inserts their own Layout: https://github.com/Telerik-Verified-Plugins/ NativePageTransitions/blob/ master/src/android/NativePageTransitions.java#L74 On Thu, Feb 19, 2015 at 1:01 PM, Joe Bowser bows...@gmail.com wrote: So, I know that XWalk is the only production-ready WebView right now, but what would other third party providers need to implement/change for their webviews to work? Also, I'm not clear how the embedded CordovaWebView use case would work in this scenario. If we delete the LinearLayout, what do we attach our view for the default use case? On Thu Feb 19 2015 at 10:39:59 AM Andrew Grieve agri...@chromium.org wrote: I've finished playing with third-party plugins. If anyone else wants to have fun with them, use --thirdpartyplugins in createmobilespec.js, and then find the manual test for them. TLDR - most compiled/worked fine. Two that interacted with Views a lot had lots of compile errors, but in the end I don't think there's a good way to fix them on our end. I've also taken some time to try and eliminate copy paste between AndroidWebView and XWalkWebView. I'd love to get some feedback on the changes (and hopefully get them in). More info /w PRs here: https://issues.apache.org/jira/browse/CB-8510 Another thing that came out of looking at these plugins is that they add in their own Layout, or have logic to handle various parent layout. So... I think we'd be fine (and should) delete our
Re: Cordova Automated Testing
On Fri, Feb 27, 2015 at 5:30 PM, Dmitry Blotsky dblot...@microsoft.com wrote: Thanks for the feedback, Michal! The issue we had with using the checkboxes was that it was not easily automatable. A more simple solution was to use a parameter to specify the plugins you want installed, instead of installing all of them and then disabling them. Also the dependencies-plugin in mobilespec is a hardcoded list, which requires more manipulation to modify than specifying a list as a parameter. Using it as the default is a great idea, but being able to override it during invocation would be great too I think. What do you think? I'm all for improving the tooling around this. Frankly that was the goal from the get go, and lots of teams have independently improved tests over time to fit their needs. Please feel free to experiment. Options: - At runtime, there is a window.tests object that holds metadata about all the plugins tests, and it includes an enabled flag. This is what the checkboxes are modifying. Setting the initial enabled values on startup using some form of config (a file perhaps, or perhaps a preference that is checked by the tests plugin). - At compile time, the createmobilespec.js script already maintains a list of plugins (e.g. CORDOVA_REGISTRY_PLUGINS, TELERIK_VERIFIED_PLUGINS), and the installPlugins function installs all nested tests automatically. You could change the script to accept a list (command line, file, ...) or turn the script into a node module that accepts an arbitrary list of plugins and write different scripts in terms of it, etc. The dependency plugin can easily be replaced by moving the list directly into the createmobilespec.js script, making it easier to configure. Totally open to modifications here, please send PR if you are willing! Also: Jesse, and others, do you think it might be worthwhile to collaborate and incorporate the features of paramedic (like specifying the plugins to run) into mobilespec? That way we will have one tool for testing throughout. I've definitely been sold on the idea of having mobilespec be the main point for running tests. That way we can use it in all our testing scenarios: local, Medic, Travis, etc. Kindly, Dmitry -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Wednesday, February 25, 2015 12:42 PM To: dev Subject: Re: Cordova Automated Testing I haven't followed this full thread, so sorry if this is out of context, but wanted to point out: - Jason added support for testing a subset of plugins in mobile-spec by way of checkboxes in the automated test runner. It defaults to all, but you can change that. - By design, the cordova-plugin-test-framework (and thus mobile-spec) will only run tests for the plugins you have actually installed (actually, for the nested plugin tests you have explicitly installed). The createmobilespec.js script will by default install all core plugins, but you can easily change that. -Michal On Wed, Feb 25, 2015 at 3:20 PM, Dmitry Blotsky dblot...@microsoft.com wrote: Thanks for the feedback, Jesse and Dmitriy! Judging from the responses, it definitely sounds like modifying mobilespec, or just plain using paramedic would be the way to go. I'm very much swinging in that direction. Medivac really only exists on its own because I wasn't comfortable enough with our git repos to make a branch off of mobilespec; because it really is just mobilespec with some things stripped away. Jesse: to me the primary value add was actually just simplicity. This guy doesn't depend on plugin-test-framework and has none of the heavier features like local storage and test segmentation. It's basically just a Cordova app with a single page to run Jasmine tests and an optional URI to post the results to, and the value is simplicity. It has very little code and has very few moving parts. Dmitriy Barkalov: I don't see what the use case is for adding plugin-test-framework to any Cordova app other than a blank one, and that is basically just doing manually what mobilespec does automatically. Kindly, Dmitry -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, February 25, 2015 11:36 AM To: dev@cordova.apache.org Subject: Re: Cordova Automated Testing Thanks for contributing, however, I do not see where the value add is in this. mobile-spec does much of this already, as does cordova-plugin-test-framework. Adding an argument to test an individual plugin is a good idea, I would definitely support adding this to mobile-spec. My own cordova-paramedic is also designed for simplified plugin testing, so you can test an individual plugin, and see the results back on the command line. Primarily this was intended for CI with Travis, so we could see immediately if a plugin pull request breaks a test on a platform. We can discuss
Re: [REVIEW] Tools Release Blog Post
Looks good. Few comments: - You can manage plugin and platform versions using the --save command = You can now save your list of installed plugins and platforms using the --save command. - (I don't think --save actually helps with management of versions) - We are going to be doing a blog post soon about transitioning plugins to npm = We are preparing to transition our plugin hosting over to npm. We will be doing a detailed blog post soon, stay tuned. - I think cordova-lib needs a better README.md.. - I don't mind the long list of changes, but some people like to keep only the important changes.. On Fri, Feb 27, 2015 at 8:30 PM, Steven Gill stevengil...@gmail.com wrote: Still have some formatting to do of the changes. https://github.com/cordova/apache-blog-posts/blob/master/2015-03-02-tools-release.md Any other highlights I should mention?
Re: [iOS] Merging cordova-ios/wkwebview branch into the mainline
huzzah! On Fri, Feb 27, 2015 at 7:07 PM, Shazron shaz...@gmail.com wrote: Proceeding with the wkwebview - 4.x branch merge next week, and also rebase/merge 4.x off master to pickup the latest master bits. On Thu, Jan 29, 2015 at 4:48 PM, Shazron shaz...@gmail.com wrote: Reviving this thread. After the hangout today, the proposal now is: 1. Integrate the wkwebview (pluggable webviews) branch into the 4.x branch, instead of releasing it for the 3.8.0 branch. This is so it will be aligned with cordova-android 4.x which has pluggable webviews 2. Once tested and reviewed, release cordova-ios 4.x branch In effect: - pluggable webviews will not exist in any 3.x version - any new 3.x releases will be security/critical fixes only, no new features On Mon, Jan 12, 2015 at 4:29 PM, Shazron shaz...@gmail.com wrote: I am proposing to integrate the aforementioned branch into the mainline, for a cordova-ios 3.8.0 release in the future. I will do testing using mobile-spec and the core plugins before I do this merge, and report back my findings to the list (including docs). I intend to spend the rest of the week on this. Contrary to the name of the branch, this does *not* include direct WKWebView support. It merely re-factors some of the cordova-ios code so that the webview used can be loaded as a plugin. The default webview engine used will always be UIWebView if not specified, and it is included as a plugin in the core platform. Each webview engine handles parsing its own preferences, and setting up its own bridge (however, this is still dependent on cordova.js having the bridge support -- perhaps in the future each webview plugin can set its own bridge independently of cordova-js repo). Related notes below -- but the state of the plugins below do *not* block the wkwebview branch merge at all. Related notes: -- The WKWebView engine plugin which requires the cordova-ios/wkwebview branch, resides in https://github.com/apache/cordova-plugins/tree/master/wkwebview-engine The WKWebView engine plugin is dependent on this local-webserver plugin: https://github.com/apache/cordova-plugins/tree/master/local-webserver The local-webserver plugin is in experimental stage -- it still needs to be tested with the Camera and File plugin since it facilitates setting a url transformer that maps urls to the appropriate localhost urls. Camera already has this code integrated, File has a pull request pending. Those are the only two plugins affected. Task list: https://issues.apache.org/jira/browse/CB-7991 - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: CLI installation from master
Certainly would match the equivalent cordova-cli repo name. On the other hand, I'm sometimes annoyed that the `cordova-cli` repo name != `cordova` package name. But with the move to npm, perhaps plugman-cli dies eventually anyway? -Michal On Fri, Feb 27, 2015 at 12:49 PM, Jesse purplecabb...@gmail.com wrote: We should consider calling plugman plugman-cli so it is more clear that this simply adds a (you guessed it) command line interface ... On Feb 27, 2015, at 8:01 AM, Mark Koudritsky kam...@google.com wrote: Yes, the instructions look correct. If you dan't need to use the `plugman` command, you don't need cordova-plugman. On Fri, Feb 27, 2015 at 12:21 AM, Toda, Shingo shin...@fast.au.fujitsu.com wrote: Hi devs I read through this document to know how I can install CLI from cloned cordova-cli. https://github.com/apache/cordova-cli In “Installing from master” section, it seems to say plugman should be linked to cordova-cli by npm link. But I think most of the plugman scripts are moved to cordova-lib which is dependency of CLI. Then if I don’t need plugman command, I just thought this installation steps could be git clone https://git-wip-us.apache.org/repos/asf/cordova-cli.git cd cordova-cli npm install sudo npm link Could you confirm this and correct me if I’m wrong? Regards, Shingo Disclaimer The information in this e-mail is confidential and may contain content that is subject to copyright and/or is commercial-in-confidence and is intended only for the use of the above named addressee. If you are not the intended recipient, you are hereby notified that dissemination, copying or use of the information is strictly prohibited. If you have received this e-mail in error, please telephone Fujitsu Australia Software Technology Pty Ltd on + 61 2 9452 9000 or by reply e-mail to the sender and delete the document and all copies thereof. Whereas Fujitsu Australia Software Technology Pty Ltd would not knowingly transmit a virus within an email communication, it is the receiver’s responsibility to scan all communication and any files attached for computer viruses and other defects. Fujitsu Australia Software Technology Pty Ltd does not accept liability for any loss or damage (whether direct, indirect, consequential or economic) however caused, and whether by negligence or otherwise, which may result directly or indirectly from this communication or any files attached. If you do not wish to receive commercial and/or marketing email messages from Fujitsu Australia Software Technology Pty Ltd, please email unsubscr...@fast.au.fujitsu.com - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Schedule for npm transition
On Wed, Feb 25, 2015 at 3:08 PM, Steven Gill stevengil...@gmail.com wrote: All versions of released core plugins have been published to npm. https://issues.apache.org/jira/browse/CB-8529 All our core plugins now have a package.json file. https://issues.apache.org/jira/browse/CB-8538 A few of us from Adobe met with NPM yesterday. Summary: - Migration - Use 'ecosystem:cordova' as a keyword in plugins for discoverability (instead of 'cordovaplugin'). I updated createpackagejson already with this. - npm has final say on naming disputes. We can go to them with issues. - Discoverability - npm Ecosystems will be up sometime this year - stopgap: they can give us list of plugins based on ecosystem:cordova keyword that we could use as data in our existing plugins site - you can already find all of our plugins on npm via searching ecosystem:cordova (https://www.npmjs.com/search?q=ecosystem%3Acordova) - Documentation - They don't have a way to handle uploading anything other than readme to npm - we could build our own packager that could publish doc/en/index.md, but not worth it - Potential Solution: Copy doc/en/index.md into readme, also add links to other language documentation in readme that points to github markdown files - Internationalization is something they want to solve, just no cycles for it in the immediate future - Dependency, Multiple versions of same plugin issue - This one was tricky. They don't have a good solution really - Seems like best case is to use peer dependencies in package.json files of plugins. Users will get a warning about missing dependency and will have to explicitly install the missing dependency. Make it a userland problem. - Ex: user installs cordova-plugin-file-transfer, they will see a warning about having to install cordova-plugin-file (maybe a specific version) - This would insure plugins are flat and should prevent multiple versions of the same plugin to be installed. - Plugin Post Install Hooks - It was brought up that having a generic post install hook that could move native files into cordova projects might be a good solution. I know we discussed it briefly and decided it would be to hard to get right. After more thought and discussion, I think we should revisit this as a potential solution. We wouldn't be dependent on cordova-lib/plugman to install plugins anymore. As long as plugins still have plugin.xml (which they will for a little while), we could still support the cordova-lib/plugman workflow too. Lets discuss this more in its own thread. Yes, lets start a new thread. Have many questions ;) Plugin TODO: - Rename id to package-name in package.json files and plugin.xml +1 - move english documentation into readme, add links for other languages into readme pointing to github markdown files +1 - Add peer dependencies to package.json +1, especially for as long as we are still fetching via plugman/cordova-cli. Though for the record, the plan for npm 3.0 seems to be to have a flat hierarchy even for dependencies. Was this discussed? - Major bump plugin versions +1 Tools TODO: - NPM fetch as fallback Do we agree to go directly to NPM if we know for sure the plugin name fails the CPR publishing requirements (aka, is not in reverse domain format)? - Mapper module will only warn to use the new name, won't actually redirect. We can turn on redirecting when we default to npm or shutdown cpr. Fair enough for step 1! Today I am working on the tools todos. On Mon, Feb 23, 2015 at 7:55 PM, Michal Mocny mmo...@chromium.org wrote: Summarizing conclusions so far (not 100% we all agree on this, please do speak up): - PluginId and Npm Package Name should be the same. We cannot force this for all plugins, but we can set the tone with core plugins. - We will change all plugins to use the cordova-plugin-* name/id. - We will bump MAJOR version to signal this change, and so plugins that depend on core plugins know to update to reflect the id change. - Publish old versions of plugins with the new package name but old plugin ids to npm. - CPR will be hit first, then fallback to npm, for the first N months. - We could go directly to npm first if the name is known to not match CPR requirements (i.e. cordova-plugin-* is known to not be in CPR by existing plugin id requirements) - Mapper module can help transition users of old ids to new package names, by warning that plugins have moved, and (perhaps?) automatically redirecting. - If we drop the automatic redirection requirement, we could just update CPR plugins with info inform users of the change. I think thats it.. Steve, mind updating us on how far along you are, and with what you would like help? -Michal On Mon, Feb 23, 2015 at 10:44 PM, Michal Mocny mmo...@chromium.org wrote: Just thinking out loud.. I guess it wouldn't actually do that unless you
Re: Cordova Automated Testing
I haven't followed this full thread, so sorry if this is out of context, but wanted to point out: - Jason added support for testing a subset of plugins in mobile-spec by way of checkboxes in the automated test runner. It defaults to all, but you can change that. - By design, the cordova-plugin-test-framework (and thus mobile-spec) will only run tests for the plugins you have actually installed (actually, for the nested plugin tests you have explicitly installed). The createmobilespec.js script will by default install all core plugins, but you can easily change that. -Michal On Wed, Feb 25, 2015 at 3:20 PM, Dmitry Blotsky dblot...@microsoft.com wrote: Thanks for the feedback, Jesse and Dmitriy! Judging from the responses, it definitely sounds like modifying mobilespec, or just plain using paramedic would be the way to go. I'm very much swinging in that direction. Medivac really only exists on its own because I wasn't comfortable enough with our git repos to make a branch off of mobilespec; because it really is just mobilespec with some things stripped away. Jesse: to me the primary value add was actually just simplicity. This guy doesn't depend on plugin-test-framework and has none of the heavier features like local storage and test segmentation. It's basically just a Cordova app with a single page to run Jasmine tests and an optional URI to post the results to, and the value is simplicity. It has very little code and has very few moving parts. Dmitriy Barkalov: I don't see what the use case is for adding plugin-test-framework to any Cordova app other than a blank one, and that is basically just doing manually what mobilespec does automatically. Kindly, Dmitry -Original Message- From: Jesse [mailto:purplecabb...@gmail.com] Sent: Wednesday, February 25, 2015 11:36 AM To: dev@cordova.apache.org Subject: Re: Cordova Automated Testing Thanks for contributing, however, I do not see where the value add is in this. mobile-spec does much of this already, as does cordova-plugin-test-framework. Adding an argument to test an individual plugin is a good idea, I would definitely support adding this to mobile-spec. My own cordova-paramedic is also designed for simplified plugin testing, so you can test an individual plugin, and see the results back on the command line. Primarily this was intended for CI with Travis, so we could see immediately if a plugin pull request breaks a test on a platform. We can discuss further here, but I think medivac would be better served as a fork+pull request to cordova-medic gh:purplecabbage/cordova-paramedic @purplecabbage risingj.com On Wed, Feb 25, 2015 at 9:35 AM, Dmitriy Barkalov (Akvelon) v-dmb...@microsoft.com wrote: Dmitry, I like your idea of adding tests from different formats. I.e. you search for standard Cordova plugin tests like in core plugins and for non-standard tests like plane test.js file. I think it is a good point to provide a way for plugin authors to either reformat their tests to existing format or provide new test format parser. Unfortunately, we can't run away from requirement to use Jasmin 2.0 but still it is more freedom. It also seems that in many ways your application is doing the same things as plugin testing framework. It provides a page to run tests, holds Jasmine and puts results into CouchDB. But it is less flexible because cannot be included into other application, while any Cordova application can install plugin testing framework and get a page to run manual and automated tests. So I vote for porting some of the new features from this tool back to plugin testing framework and letting developers reuse this functionality. Regards, Dmitriy -Original Message- From: Dmitry Blotsky [mailto:dblot...@microsoft.com] Sent: Wednesday, February 25, 2015 11:47 AM To: dev@cordova.apache.org Subject: Re: Cordova Automated Testing Hi Shazron, Thank you for your feedback! It actually doesn’t work on iOS because it seems like the most recent whitelist changes broke things. I ran npm test for the code in master and some of them fail because of whitelisting. That’s just my intuition though: I don’t know exactly why it’s not working yet. Regarding reporting though, reporting to localhost is actually just the default - you can pass a host and port on the CLI and it will report to a CouchDB server like mobilespec did. There is an immediate next step in my development efforts to make it not tied to CouchDB, or to at least allow the user to specify the URI format for reporting. Also, thanks for pointing out the ‘npm install’ requirement. I added it to the docs. The reporting to console also happens, but it’s currently just limited to console.log. Medivac uses all the standard Jasmine reporters (HTML, console, and JSAPI). And indeed, I will definitely drop a line to Jesse. Is it well-received in the Apache
Re: Great
Thanks! On Tue, Feb 24, 2015 at 10:53 AM, Villmer jasonvill...@gmail.com wrote: I just wanted to say thank you to everyone involved with the Cordova project. Took a little while to get used to the CLI but wow, wonderful technology! Keep up the great work. Best, Mr. Villmer www.villmer.com - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Proposal for CSP support
the metadata tag injection you mention is something we could probably just do all-up rather than only for specific platforms. -Chuck -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Thursday, February 19, 2015 2:25 PM To: dev Subject: Re: Proposal for CSP support Thanks for this clear outline. Jason, I know you've been working on the short-term items for a while as part of your investigation, fixing things as you went -- what is the current state of CSP support in platforms / plugins? What portion already has fixes (or PR for them), what work is known but undone, and what hasn't been investigated much at all? -Michal On Thu, Feb 19, 2015 at 4:55 PM, Jason Chase cha...@chromium.org wrote: I'm interested in full-blown support for CSP (Content Security Policy) in Cordova. While we're close to having new and improved whitelist functionality, there are gaps in what the whitelist is able to protect against. In particular, inline script and eval() are higher risks that are not addressed by whitelists. Many Cordova apps may use only static content, or not include any third-party content. However, there are certainly examples of apps that need to include user input/third-party content, mixed with the app's own HTML content. In some cases, platforms may even restrict functionality (see [1]). I think CSP is a compelling answer for these scenarios, and for security in general for apps. Assuming CSP support is valuable, the question is how to implement? Support for CSP is not universal across platforms. It is known to be supported on Android (KitKat and later), iOS (since 7.1), and Firefox. Where supported, it is typically via a HTTP response header, or a META tag in the document. I've done some investigation into feasible approaches. As a result, I'm proposing as below. Long term goal: Cordova supports CSP in apps *and* plugins, and is enabled/secure by default. Ideally, CSP rules can be configurable and automatically applied to all content (i.e. so developers can fall into the pit of success) Achieving this goal will likely require incremental progress over a number of releases. At a high level, first make changes so developers can manually apply CSP to their apps. Longer term, add support for configurability and automatic application of CSP. Short term plan: - Change new app template to contain CSP meta tag with a default, secure policy (i.e. no inline script, eval(), only local app content) - Remove any blockers to default policy from framework and core plugins. This would be a continuation of the work in CB-8210, applied to other platforms. For example, this would fix any framework code that relies on sending javascript to be executed inline, from the native side - Deprecate any framework APIs that allow less secure practices. Many already are marked as deprecated (at least on Android) - Update docs/samples to include CSP, and clearly state that use of inline javascript is deprecated Long term plan: - In a future major release, remove the previously deprecated framework APIs - Define/implement a configuration model for CSP rules - Implement a build/package step to apply configured CSP rules to all content as meta tags. Run-time support involves re-writing content, and/or intercepting resource requests. The feasibility of intercepting requests is highly variable across platforms, at greater cost/complexity than build-time. I'm very interested in any comments on this proposal. This includes questions around use cases (missing or otherwise), different requirements, technical concerns, .etc. Thanks, Jason Google Cordova Team [1] http://callback.markmail.org/thread/yxmmya2o2lc26tpi
Re: [VOTE] 3.8.0 iOS Release
Jesse did it only because you said Eh nicely. On Tue, Feb 24, 2015 at 7:17 PM, Jesse purplecabb...@gmail.com wrote: +1 Ran coho check-license Verified tags Ran npm tests against tagged repo Installed plugin test framework, device plugin + tests and all tests passed on emulator cordova create ~/VoteIOS380 cd ~/VoteIOS380 cordova platform add /Repos/cordova/cordova-ios/ cordova plugin add /Repos/cordova/cordova-plugin-test-framework cordova plugin add /Repos/cordova/cordova-plugin-device cordova plugin add /Repos/cordova/cordova-plugin-device/tests ... @purplecabbage risingj.com On Tue, Feb 24, 2015 at 3:33 PM, Shazron shaz...@gmail.com wrote: Bump. This vote thread needs one more vote eh On Sun, Feb 22, 2015 at 6:30 PM, Steven Gill stevengil...@gmail.com wrote: +1 Ran coho verify-archive Created and ran cordova hello world project On Thu, Feb 19, 2015 at 3:52 PM, Shazron shaz...@gmail.com wrote: Please review and vote on this 3.8.0 iOS Release. Release issue: https://issues.apache.org/jira/browse/CB-8511 Repos ready to be released have been published to dist/dev: https://dist.apache.org/repos/dist/dev/cordova/CB-8511 The package was published from its corresponding git tag: cordova-ios: 3.8.0 (d4d0c382b6) 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 - 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: Schedule for npm transition
On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve agri...@chromium.org wrote: You can use plugin.xml info to print a message upon installation. Plugins can specify dependencies on a per-platform basis. Don't think we can capture this with package.json without using custom keys. Do we need to? I mean, this is a breaking change, but perhaps once that is acceptable in practice. I.e. Contacts depends on com.blackberry.utils, but that plugin only supports the BB platform and so shouldn't be installed on others. In theory there exists a plugin which supports all platforms but is only explicitly needed for one platform as a dependency.. But I don't know. Does the issue come up in practice? On Mon, Feb 23, 2015 at 2:42 PM, Michal Mocny mmo...@chromium.org wrote: On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill stevengil...@gmail.com wrote: +1 to giving plugins major version bump +1 to publishing old versions to npm Short term we can keep dependency tag using plugin ids. Wouldn't it make more sense long term to move those dependencies into package.json file of each plugin? Probably peerDependencies not dependencies. I forgot about that.. Indeed that was the plan. I think one current benefit of dependency tag over package.json is that the latter only guarantees that the plugins are downloaded, while the former guarantees that they are installed. We could update our tools to do an install time check for a package.json and then scan the locally installed packages which are listed in its peerDependencies to see if any are cordova plugins and install those automatically, but I'm not quite sure thats the right voodoo.. Anyway, assuming we can come up with a sensible plan, I would rather do it all at once with the upcoming Major version bump. I am going to begin the process of adding package.json to all of our plugins today and will look into publishing older versions to npm. Third-party plugins can either keep their package-id as package-name or rename. It will be up to them. If they keep it, no need to send a PR to mapper module. If they decide on a new package-name, it is probably in their best interest to send a PR. Sounds good, though I'm hoping to provide guidance that renames are better by doing it for core plugins. The need for the mapper is probably a bit of an exaggeration anyway. Once CPR goes deprecated, we should start warning that plugins should be fetched from npm. Users will then search for the name of the npm package and the plugin author can rename freely by just documenting accordingly. Once the CPR goes down, this will be even more true. (Additionally, authors can publish a CPR plugin before CPR goes down that has an install hook which says This plugin has moved to npm under the name... I'm less and less convinced the mapper is needed at all..) On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana csantan...@gmail.com wrote: Lets consider to take this time and make our plugins 1.0.0 and start following semver 2.0 more strict. The community is starting to accept that is ok if the major number is not zero, and a number means something that can be use in production. I understand that people might have their own opinion on what is a MAJOR, meaning an API brake when the plugin is running on the device and the API of the javascript API to the plugin. But I want to consider how a plugin is manage in terms of tooling, declaring and resolving dependencies, plugin.xml schema, browersify/bootstrapjs, we could say that this consider an API for the plugin. Another point is if the plugin are going to change in terms how they are manage, we can take an opportunity to take the developers attention with the major version number change to easy distinguish that there something new going with plugins since 1.0.0 and up. On Tue, Feb 17, 2015 at 4:02 PM, Chuck Lantz cla...@microsoft.com wrote: I think the incident over the weekend pointed out that people are in fact pinning versions in plugin dependencies to avoid unexpected regressions or in apps due to things like security reviews. (Ex: Each version of a piece of software that is published inside an app needs to go through a legal review at some companies.) So, I think it will be critical that people can get back to older versions of plugins beyond the 3 + 6 = 9 month CPR window. Big time +1 to back publishing versions npm for that reason unless we intend to keep the CPR around for a long time. We also will want to tell plugin authors that they will want to do the same. (Note that I'm less worried about IDEs than I am app and plugin authors here.) What we're talking about so far has been around changing
Re: Schedule for npm transition
I scanned the core plugins, and only contacts uses platform specific deps, and only for 2 BB plugins. Also scanned the top 20 non-core plugins from CPR, and: - com.cranberrygame.phonegap.plugin.ad.admob - depends on google-play-services only on android, but that plugin only supports android. - com.google.cordova.admob (Note: not published by com.google..) - Same as above - plugin.google.maps - Same as above - also depends on android.support.v4 for android only (but its also an android only plugin) - also depends on com.googlemaps.ios for ios only (but its an ios only plugin) - net.yoik.cordova.plugins.screenorientation - Depends on com.blackberry.app only for BB (but its BB only plugin) So.. this is not an uncommon use, but it seems unnecessary in all cases I've found so far. -Michal On Mon, Feb 23, 2015 at 4:10 PM, Michal Mocny mmo...@chromium.org wrote: On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve agri...@chromium.org wrote: You can use plugin.xml info to print a message upon installation. Plugins can specify dependencies on a per-platform basis. Don't think we can capture this with package.json without using custom keys. Do we need to? I mean, this is a breaking change, but perhaps once that is acceptable in practice. I.e. Contacts depends on com.blackberry.utils, but that plugin only supports the BB platform and so shouldn't be installed on others. In theory there exists a plugin which supports all platforms but is only explicitly needed for one platform as a dependency.. But I don't know. Does the issue come up in practice? On Mon, Feb 23, 2015 at 2:42 PM, Michal Mocny mmo...@chromium.org wrote: On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill stevengil...@gmail.com wrote: +1 to giving plugins major version bump +1 to publishing old versions to npm Short term we can keep dependency tag using plugin ids. Wouldn't it make more sense long term to move those dependencies into package.json file of each plugin? Probably peerDependencies not dependencies. I forgot about that.. Indeed that was the plan. I think one current benefit of dependency tag over package.json is that the latter only guarantees that the plugins are downloaded, while the former guarantees that they are installed. We could update our tools to do an install time check for a package.json and then scan the locally installed packages which are listed in its peerDependencies to see if any are cordova plugins and install those automatically, but I'm not quite sure thats the right voodoo.. Anyway, assuming we can come up with a sensible plan, I would rather do it all at once with the upcoming Major version bump. I am going to begin the process of adding package.json to all of our plugins today and will look into publishing older versions to npm. Third-party plugins can either keep their package-id as package-name or rename. It will be up to them. If they keep it, no need to send a PR to mapper module. If they decide on a new package-name, it is probably in their best interest to send a PR. Sounds good, though I'm hoping to provide guidance that renames are better by doing it for core plugins. The need for the mapper is probably a bit of an exaggeration anyway. Once CPR goes deprecated, we should start warning that plugins should be fetched from npm. Users will then search for the name of the npm package and the plugin author can rename freely by just documenting accordingly. Once the CPR goes down, this will be even more true. (Additionally, authors can publish a CPR plugin before CPR goes down that has an install hook which says This plugin has moved to npm under the name... I'm less and less convinced the mapper is needed at all..) On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana csantan...@gmail.com wrote: Lets consider to take this time and make our plugins 1.0.0 and start following semver 2.0 more strict. The community is starting to accept that is ok if the major number is not zero, and a number means something that can be use in production. I understand that people might have their own opinion on what is a MAJOR, meaning an API brake when the plugin is running on the device and the API of the javascript API to the plugin. But I want to consider how a plugin is manage in terms of tooling, declaring and resolving dependencies, plugin.xml schema, browersify/bootstrapjs, we could say that this consider an API for the plugin. Another point is if the plugin are going to change in terms how they are manage, we can take an opportunity to take the developers attention with the major version number change to easy distinguish that there something new going with plugins since 1.0.0 and up. On Tue, Feb 17, 2015 at 4:02 PM, Chuck Lantz cla...@microsoft.com
Re: Schedule for npm transition
On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill stevengil...@gmail.com wrote: +1 to giving plugins major version bump +1 to publishing old versions to npm Short term we can keep dependency tag using plugin ids. Wouldn't it make more sense long term to move those dependencies into package.json file of each plugin? Probably peerDependencies not dependencies. I forgot about that.. Indeed that was the plan. I think one current benefit of dependency tag over package.json is that the latter only guarantees that the plugins are downloaded, while the former guarantees that they are installed. We could update our tools to do an install time check for a package.json and then scan the locally installed packages which are listed in its peerDependencies to see if any are cordova plugins and install those automatically, but I'm not quite sure thats the right voodoo.. Anyway, assuming we can come up with a sensible plan, I would rather do it all at once with the upcoming Major version bump. I am going to begin the process of adding package.json to all of our plugins today and will look into publishing older versions to npm. Third-party plugins can either keep their package-id as package-name or rename. It will be up to them. If they keep it, no need to send a PR to mapper module. If they decide on a new package-name, it is probably in their best interest to send a PR. Sounds good, though I'm hoping to provide guidance that renames are better by doing it for core plugins. The need for the mapper is probably a bit of an exaggeration anyway. Once CPR goes deprecated, we should start warning that plugins should be fetched from npm. Users will then search for the name of the npm package and the plugin author can rename freely by just documenting accordingly. Once the CPR goes down, this will be even more true. (Additionally, authors can publish a CPR plugin before CPR goes down that has an install hook which says This plugin has moved to npm under the name... I'm less and less convinced the mapper is needed at all..) On Thu, Feb 19, 2015 at 6:50 AM, Carlos Santana csantan...@gmail.com wrote: Lets consider to take this time and make our plugins 1.0.0 and start following semver 2.0 more strict. The community is starting to accept that is ok if the major number is not zero, and a number means something that can be use in production. I understand that people might have their own opinion on what is a MAJOR, meaning an API brake when the plugin is running on the device and the API of the javascript API to the plugin. But I want to consider how a plugin is manage in terms of tooling, declaring and resolving dependencies, plugin.xml schema, browersify/bootstrapjs, we could say that this consider an API for the plugin. Another point is if the plugin are going to change in terms how they are manage, we can take an opportunity to take the developers attention with the major version number change to easy distinguish that there something new going with plugins since 1.0.0 and up. On Tue, Feb 17, 2015 at 4:02 PM, Chuck Lantz cla...@microsoft.com wrote: I think the incident over the weekend pointed out that people are in fact pinning versions in plugin dependencies to avoid unexpected regressions or in apps due to things like security reviews. (Ex: Each version of a piece of software that is published inside an app needs to go through a legal review at some companies.) So, I think it will be critical that people can get back to older versions of plugins beyond the 3 + 6 = 9 month CPR window. Big time +1 to back publishing versions npm for that reason unless we intend to keep the CPR around for a long time. We also will want to tell plugin authors that they will want to do the same. (Note that I'm less worried about IDEs than I am app and plugin authors here.) What we're talking about so far has been around changing the behavior of cordova-lib over this period. A few questions assuming we go with having a mapper module: 1. During and after the transition period, should we recommend that 3rd party plugin authors contribute their IDs to the mapper module to maintain compat as the CPR shuts down if they want/need to publish to npm with a different name? Is there a process we want to setup to make this easy? 2. What about apps using old versions of Cordova that pre-date npm support being present? Given it sounds like Nodejitsu will help with any migration needed, is there an urgency to shut down the CPR itself (regardless of what cordova-lib itself does) in this time window? Or are we simply telling people they have to upgrade to install any new plugins? -Chuck -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, February 17, 2015 9:32 AM
Re: Schedule for npm transition
Summarizing conclusions so far (not 100% we all agree on this, please do speak up): - PluginId and Npm Package Name should be the same. We cannot force this for all plugins, but we can set the tone with core plugins. - We will change all plugins to use the cordova-plugin-* name/id. - We will bump MAJOR version to signal this change, and so plugins that depend on core plugins know to update to reflect the id change. - Publish old versions of plugins with the new package name but old plugin ids to npm. - CPR will be hit first, then fallback to npm, for the first N months. - We could go directly to npm first if the name is known to not match CPR requirements (i.e. cordova-plugin-* is known to not be in CPR by existing plugin id requirements) - Mapper module can help transition users of old ids to new package names, by warning that plugins have moved, and (perhaps?) automatically redirecting. - If we drop the automatic redirection requirement, we could just update CPR plugins with info inform users of the change. I think thats it.. Steve, mind updating us on how far along you are, and with what you would like help? -Michal On Mon, Feb 23, 2015 at 10:44 PM, Michal Mocny mmo...@chromium.org wrote: Just thinking out loud.. I guess it wouldn't actually do that unless you are using actual npm cli to install plugins. With the current plan we are still just using cordova/plugman to fetch using the npm lib, and so can probably resolve peerDependencies whenever/however we want (like auto-fetching only once the platform is added). If we did move to top-level package.json and installing dependencies via npm, it may be a little annoying to have that message. I guess the reason we are discussing dropping dependency anyway was for the move to using npm cli directly, and since we are still a ways away from that, I guess we can punt this change for now and keep using a tag? -Michal On Mon, Feb 23, 2015 at 9:52 PM, Andrew Grieve agri...@chromium.org wrote: I suppose it's workable, but it seems worse than what we currently have. E.g. I don't care about Android, but npm peerDependencies will complain until I've installed the android.support.v4 plugin into my node_modules. On Mon, Feb 23, 2015 at 4:26 PM, Michal Mocny mmo...@chromium.org wrote: I scanned the core plugins, and only contacts uses platform specific deps, and only for 2 BB plugins. Also scanned the top 20 non-core plugins from CPR, and: - com.cranberrygame.phonegap.plugin.ad.admob - depends on google-play-services only on android, but that plugin only supports android. - com.google.cordova.admob (Note: not published by com.google..) - Same as above - plugin.google.maps - Same as above - also depends on android.support.v4 for android only (but its also an android only plugin) - also depends on com.googlemaps.ios for ios only (but its an ios only plugin) - net.yoik.cordova.plugins.screenorientation - Depends on com.blackberry.app only for BB (but its BB only plugin) So.. this is not an uncommon use, but it seems unnecessary in all cases I've found so far. -Michal On Mon, Feb 23, 2015 at 4:10 PM, Michal Mocny mmo...@chromium.org wrote: On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve agri...@chromium.org wrote: You can use plugin.xml info to print a message upon installation. Plugins can specify dependencies on a per-platform basis. Don't think we can capture this with package.json without using custom keys. Do we need to? I mean, this is a breaking change, but perhaps once that is acceptable in practice. I.e. Contacts depends on com.blackberry.utils, but that plugin only supports the BB platform and so shouldn't be installed on others. In theory there exists a plugin which supports all platforms but is only explicitly needed for one platform as a dependency.. But I don't know. Does the issue come up in practice? On Mon, Feb 23, 2015 at 2:42 PM, Michal Mocny mmo...@chromium.org wrote: On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill stevengil...@gmail.com wrote: +1 to giving plugins major version bump +1 to publishing old versions to npm Short term we can keep dependency tag using plugin ids. Wouldn't it make more sense long term to move those dependencies into package.json file of each plugin? Probably peerDependencies not dependencies. I forgot about that.. Indeed that was the plan. I think one current benefit of dependency tag over package.json is that the latter only guarantees that the plugins are downloaded, while the former guarantees that they are installed. We could update our tools to do an install time check for a package.json and then scan the locally installed packages which are listed in its peerDependencies to see if any are cordova plugins and install those automatically, but I'm not quite sure thats the right voodoo
Re: Schedule for npm transition
Just thinking out loud.. I guess it wouldn't actually do that unless you are using actual npm cli to install plugins. With the current plan we are still just using cordova/plugman to fetch using the npm lib, and so can probably resolve peerDependencies whenever/however we want (like auto-fetching only once the platform is added). If we did move to top-level package.json and installing dependencies via npm, it may be a little annoying to have that message. I guess the reason we are discussing dropping dependency anyway was for the move to using npm cli directly, and since we are still a ways away from that, I guess we can punt this change for now and keep using a tag? -Michal On Mon, Feb 23, 2015 at 9:52 PM, Andrew Grieve agri...@chromium.org wrote: I suppose it's workable, but it seems worse than what we currently have. E.g. I don't care about Android, but npm peerDependencies will complain until I've installed the android.support.v4 plugin into my node_modules. On Mon, Feb 23, 2015 at 4:26 PM, Michal Mocny mmo...@chromium.org wrote: I scanned the core plugins, and only contacts uses platform specific deps, and only for 2 BB plugins. Also scanned the top 20 non-core plugins from CPR, and: - com.cranberrygame.phonegap.plugin.ad.admob - depends on google-play-services only on android, but that plugin only supports android. - com.google.cordova.admob (Note: not published by com.google..) - Same as above - plugin.google.maps - Same as above - also depends on android.support.v4 for android only (but its also an android only plugin) - also depends on com.googlemaps.ios for ios only (but its an ios only plugin) - net.yoik.cordova.plugins.screenorientation - Depends on com.blackberry.app only for BB (but its BB only plugin) So.. this is not an uncommon use, but it seems unnecessary in all cases I've found so far. -Michal On Mon, Feb 23, 2015 at 4:10 PM, Michal Mocny mmo...@chromium.org wrote: On Mon, Feb 23, 2015 at 3:36 PM, Andrew Grieve agri...@chromium.org wrote: You can use plugin.xml info to print a message upon installation. Plugins can specify dependencies on a per-platform basis. Don't think we can capture this with package.json without using custom keys. Do we need to? I mean, this is a breaking change, but perhaps once that is acceptable in practice. I.e. Contacts depends on com.blackberry.utils, but that plugin only supports the BB platform and so shouldn't be installed on others. In theory there exists a plugin which supports all platforms but is only explicitly needed for one platform as a dependency.. But I don't know. Does the issue come up in practice? On Mon, Feb 23, 2015 at 2:42 PM, Michal Mocny mmo...@chromium.org wrote: On Mon, Feb 23, 2015 at 2:22 PM, Steven Gill stevengil...@gmail.com wrote: +1 to giving plugins major version bump +1 to publishing old versions to npm Short term we can keep dependency tag using plugin ids. Wouldn't it make more sense long term to move those dependencies into package.json file of each plugin? Probably peerDependencies not dependencies. I forgot about that.. Indeed that was the plan. I think one current benefit of dependency tag over package.json is that the latter only guarantees that the plugins are downloaded, while the former guarantees that they are installed. We could update our tools to do an install time check for a package.json and then scan the locally installed packages which are listed in its peerDependencies to see if any are cordova plugins and install those automatically, but I'm not quite sure thats the right voodoo.. Anyway, assuming we can come up with a sensible plan, I would rather do it all at once with the upcoming Major version bump. I am going to begin the process of adding package.json to all of our plugins today and will look into publishing older versions to npm. Third-party plugins can either keep their package-id as package-name or rename. It will be up to them. If they keep it, no need to send a PR to mapper module. If they decide on a new package-name, it is probably in their best interest to send a PR. Sounds good, though I'm hoping to provide guidance that renames are better by doing it for core plugins. The need for the mapper is probably a bit of an exaggeration anyway. Once CPR goes deprecated, we should start warning that plugins should be fetched from npm. Users will then search for the name of the npm package and the plugin author can rename freely by just documenting accordingly. Once the CPR goes down, this will be even more true. (Additionally, authors can publish a CPR plugin before CPR goes down that has an install hook which says This plugin has moved to npm under the name... I'm less and less
Re: jquery plugins move to npm
Yeah, sounds like they weren't facing the same problems migrating that we are. On Wed, Feb 18, 2015 at 6:24 PM, Brian LeRoux b...@brian.io wrote: I'm on the jquery foundation board of advisers. TODO MVC and, rumour has it, Polymer are moving over too. Bower is not a package manager (though it certainly has marketed itself as such); all it does is download stuff for you which curl and web browsers do a decent job of. Anyhow. Yes. Jquery plugins are a totally manual thing. Could help setup a call though I'm not sure what the queries are. On Wed, Feb 18, 2015 at 2:42 PM, Parashuram N (MS OPEN TECH) panar...@microsoft.com wrote: We could talk to Dave Methvin, the president of the Jquery foundation. Do you think setting up a call with them would help? I could start that if the community thinks we could learn from them. -Original Message- From: Murat Sutunc [mailto:mura...@microsoft.com] Sent: Wednesday, February 18, 2015 2:16 PM To: dev@cordova.apache.org Subject: RE: jquery plugins move to npm Seems like it. According to their docs ( http://blog.jquery.com/2013/01/16/announcing-the-jquery-plugin-registry/ ) the only way to install plugins was to download from the website. -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Wednesday, February 18, 2015 1:56 PM To: dev Subject: Re: jquery plugins move to npm Indeed. May be worth discussing how they are doing a migration (Anyone have a contact at jQuery foundation?), though I believe their registry only supported manual downloads and they didn't have a cli tool or dependencies to worry about (am I right?). -Michal On Wed, Feb 18, 2015 at 3:40 PM, Murat Sutunc mura...@microsoft.com wrote: Oh wow, this is big news. I would have expected them to move to bower but npm works just fine. -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, February 18, 2015 12:14 PM To: dev@cordova.apache.org Subject: jquery plugins move to npm Relevant to us! http://blog.npmjs.org/post/111385956875/welcome-jquery-developers http://plugins.jquery.com/ - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: jquery plugins move to npm
Indeed. May be worth discussing how they are doing a migration (Anyone have a contact at jQuery foundation?), though I believe their registry only supported manual downloads and they didn't have a cli tool or dependencies to worry about (am I right?). -Michal On Wed, Feb 18, 2015 at 3:40 PM, Murat Sutunc mura...@microsoft.com wrote: Oh wow, this is big news. I would have expected them to move to bower but npm works just fine. -Original Message- From: Steven Gill [mailto:stevengil...@gmail.com] Sent: Wednesday, February 18, 2015 12:14 PM To: dev@cordova.apache.org Subject: jquery plugins move to npm Relevant to us! http://blog.npmjs.org/post/111385956875/welcome-jquery-developers http://plugins.jquery.com/ - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Schedule for npm transition
FYI since its perhaps relevant to npm transition (from npm weekly notes): We will also be changing the behavior of peerDependencies in npm@3. We won’t be automatically downloading the peer dependency anymore. Instead, we’ll warn you if the peer dependency isn’t already installed. This requires you to resolve peerDependency conflicts yourself, manually, but in the long run this should make it less likely that you’ll end up in a tricky spot with your packages’ dependencies. -Michal On Tue, Feb 17, 2015 at 12:13 PM, Andrew Grieve agri...@chromium.org wrote: On Tue, Feb 17, 2015 at 11:28 AM, Michal Mocny mmo...@chromium.org wrote: On Tue, Feb 17, 2015 at 10:09 AM, Andrew Grieve agri...@chromium.org wrote: Sorry to be dragging this out, but I think it's important that the plan here is crystal clear. On Wed, Feb 11, 2015 at 4:56 PM, Michal Mocny mmo...@chromium.org wrote: I would agree that we should change plugin ID as well as package name, but I don't think that affects the results. All 3 of those use cases you mentioned I think are addressed equivalently. Whether the plugin is added as a dependency, with save/restore, or explicitly from the command line, cordova-lib would first check if there is a mapping from old ID - new package name, or use what's given verbatim. So the only concern is with third party plugin authors who chose to rename plugins, and already have dependants, and don't register a mapping with us. There is a runtime dependency on plugin ID. It's used when require()ing other JS modules, and on Android it's used to access the plugin's native side (pluginManager.getPlugin(ID)). We could have a mapper that knows that I type plugin add , to fetch cordova-plugin-file, but if we also change the plugin ID, then we'll get runtime problems. So... if we have a mapper, then no changing plugin IDs. Correct? I agree at first, but after sleeping on it, perhaps this is not necessarily true. Perhaps changing plugin ID could just be a semver breaking change? Then, even if it was installed using old plugin-id and the mapper mapped to the npm package-name, any plugin compatible with this MAJOR version of the plugin would know to use the new plugin id. That'd probably work. In practice I haven't seen plugins pin versions within dependency, but they probably should. For old versions of the plugin published to npm, we do have to leave the plugin id as-is. Okay, so we don't change the plugin ID, just the package name. - When people use dependency, they should still use plugin ID Nit: why? dependency (and config.xml plugin) should use the same target as cordova plugin add, which at this point should change to package-name. If we do leave plugin-id different from package-name, it should only be used internally by plugin authors who depend on other plugins. plugin add can take git URLs, local directory paths. dependency id= / is pretty clear that it's an ID, and in this form it doesn't specify where to get the plugin from The logic for dependency in plugman is to: 1. Fetch it (e.g. use search paths, or find-by-id from the registry). 2. Validate that the plugin.xml we fetched matches the ID from dependency 3. Install it I don't think we can do the validation step if we allow package-name within dependency. Plus, except for core plugins that have a mapper, you couldn't do the search-path logic correctly without the plugin ID. - If they cordova plugin add, we'll allow them to specify NPM package name *or* plugin ID. Possibly only support plugin-id for some deprecation time? (Though if we publish old versions to npm, maybe we just leave it supported + warning always) - We'd use the reverse-mapping so that plugin search path will work if they specify package name. - E.g. cordova plugin add cordova-plugin-file, will need to know to scan search-path directories for org.apache.cordova.file. Indeed! I think the different-IDs-than-package-name approach will work, but I think it's too much of a hassle to be used by third-party plugins, because it's more work to have the names be different: I tend to agree. I think it *could* work, but we should think through if it is necessary. - If their ID is the same as the package name: - They fit in more naturally with NPM - The fetching logic will be faster (since we know we don't need to check CPR first) - They don't need to send a pull request and wait for a release so that people can install their plugin (mapper) If third-parties don't opt into having different package names from plugin IDs, then down the road the only plugins that will be in this state are the core plugins. Maybe that's fine? I believe the only real question is: do we prefer
Re: CB-8444: Proposal to deprecate the clobber of window.open by InAppBrowser
Open question: do we even need to clobber a symbol, or would
cordova.require('org.apache.cordova.iab').open() suffice?
Could we leave compatibility by default, but support opting-in to the
switch now? Perhaps a runs/ flag in the plugin and clobber window.open
from javascript only if a preference name=IABShouldNotClobberWindowOpen
is not set, instead of using unconditional clobbers/ from plugin.xml?
That may have a slight implication about when the clobber happens during
startup, but is unlikely to be an issue in practice.
-Michal
On Thu, Feb 12, 2015 at 5:19 PM, Jason Chase cha...@google.com wrote:
For CB-8444, I'm proposing to eventually remove the clobber of
'window.open' that is done by the InAppBrowser plugin.
The problem I'm trying to solve is unintended changes to the behaviour of
window.open calls in an app. An example of untended change is an app that
adds a plugin which provides an external web-based authentication flow.
The plugin has a dependency on InAppBrowser, in order to provide the
web-based login. The app developer would likely be unaware that the
InAppBrowser plugin clobbers window.open. As a result, window.open calls
that would open the system browser, will show the pages in the InAppBrowser
instead.
The first step is to add a new API to access the InAppBrowser, instead of
window.open. The behaviour of the plugin is unchanged, it's just accessed
via a different symbol. This is covered by the referenced pull request
[1].
In a future major release, the second step is to remove the clobber of
window.open. If an app wishes all window.open calls to be handled by the
InAppBrowser, the app can explicitly implement the clobber. Conversely,
other apps are no longer forced to work around the clobber of window.open.
I'd welcome any comments on this proposal. This includes any example use
cases that want the clobber of window.open by the plugin.
Thanks,
Jason
Google Cordova Team
[1] https://github.com/apache/cordova-plugin-inappbrowser/pull/80
Re: Android JUnit Tests Now Pass
on a branch? ;) On Thu, Feb 12, 2015 at 2:47 PM, Andrew Grieve agri...@chromium.org wrote: Awesomesauce. Going to move forward then (with putting back the accidentally deleted test). If there's other things missed, they can be brought back as well. On Thu, Feb 12, 2015 at 12:47 PM, Brian LeRoux b...@brian.io wrote: I see no situation where we don't want a feature branch vetted by 1 person before we land anything on master …short of fixing broken tests. I assume good faith. Joe: you had a bad day and, I think, you still feel mistrust after previous commits landing on master stalling out your work last summer. Lets put that behind us. Andrew pls fire a ping to the list w/ a PR for anything aiming to live on Android master until earn Joe's trust back. And lets avoid the editorial about motivations. We all want the same thing here: work on a kick ass open source project that makes a difference. On Thu, Feb 12, 2015 at 9:31 AM, Jesse purplecabb...@gmail.com wrote: This commit may not have warranted this discussion. I think we agree that large changes/commits should be on feature branches, and discussed before being merged. Let's go with that. On Feb 12, 2015, at 8:49 AM, Andrew Grieve agri...@chromium.org wrote: Sounds like you've been having a rough time. :( Hope you get through it. Believe me when I say I hear you loud and clear about making changes on feature branches. I just don't think this one fits. - No one (other than me) has touched the tests since September of last year, so it's unlikely that a change would cause merge conflicts. - The state of the tests show that they are not viewed as that important (at least not important enough for anyone other than me to have been working on them) - Anything I do to them doesn't affect shipping code. No risk. I find it hard to believe that my making changes contributes in a significant way to having people avoid working on Android. Perhaps being overly abrasive via email JIRA would be a deterrent though... On Thu, Feb 12, 2015 at 11:10 AM, Joe Bowser bows...@gmail.com wrote: On Thu Feb 12 2015 at 7:44:52 AM Andrew Grieve agri...@chromium.org wrote: I agree that significant changes should be reviewed first. But for the most part Cordova is a review-after-commit kind of place, No, it's not. Cordova is only like that because you consistently make it like that. Constantly committing to master without any review at all makes it next to impossible for anyone else to work on the project. You can tell that this is the case, because you own the majority of the commits over the last few months. That's not normal for a codebase this size with this many contributors. This is why we have topic branches, and we've had this discussion with you numerous times about using them. This is also why I write e-mails trying to get buy-in to what I want to do instead of just landing features straight on master that could break everything. and this change didn't touch any code that we release (strictly tests... that have been broken for a very long time), so I don't think it qualifies. I'll admit that the tests were a bit of the wild west. That said, there was always an understanding that tests would be added to and improved upon and not removed. Marcel and I probably wouldn't have had half the e-mails that we have had if it wasn't us arguing over whether to delete tests. I know it's frustrating to have to wait on other people, since people are human, get sick, and have to take care of others when they're sick. That said, it's equally frustrating to come back from vacation, or wake up from a nap after driving someone from the hospital and see that critical code that was a major issue only six months ago got accidentally removed in a sweeping change, along with other use cases. That's what happened yesterday, and that's why I got frustrated. If I'm having a bad day already, a random refactor that just gets dropped without at least a head's up beforehand makes it worse. I've been on both sides of the issue with this. I remember getting extremely frustrated with Bryce when we designed CordovaWebView, especially since my design had less of a change to the code. I thought things were moving too slowly, but at the end of the day we did produce something that a lot of people seem to use (at least that's what the sample repo I have on GitHub tells me, the GitHub analytics tools are all I have to go on). That said, we didn't ship that until it was mostly ready, and other than an awkward presentation at PhoneGap Day, it was mostly fine. I'm glad I didn't just
Re: Schedule for npm transition
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 stevengil...@gmail.com 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 gorkem.er...@gmail.com 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
Re: Schedule for npm transition
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 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 leo.treggi...@intel.com wrote: 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 mmo...@chromium.org 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 stevengil...@gmail.com 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 gorkem.er...@gmail.com 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: Schedule for npm transition
Leo, the rename isn't required, as a third party author you can publish your plugin using the plugin id to npm, and no mapping is required. But for cordova core plugins, we think the plugin id is a bad choice for package name for aesthetic reasons, and the fixed name mapping solution provides us with compatability. I think its a good forward looking choice. -Michal On Wed, Feb 11, 2015 at 3:50 PM, Michal Mocny mmo...@chromium.org 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 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 leo.treggi...@intel.com wrote: 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 mmo...@chromium.org 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 stevengil...@gmail.com 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 gorkem.er...@gmail.com 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: Schedule for npm transition
I would agree that we should change plugin ID as well as package name, but I don't think that affects the results. All 3 of those use cases you mentioned I think are addressed equivalently. Whether the plugin is added as a dependency, with save/restore, or explicitly from the command line, cordova-lib would first check if there is a mapping from old ID - new package name, or use what's given verbatim. So the only concern is with third party plugin authors who chose to rename plugins, and already have dependants, and don't register a mapping with us. I believe the only real question is: do we prefer a minimally easier transition by leaving all names as they are, or do we prefer to have package names on npm that don't look out of place. I think any argument that there is a technical preference for one way over the other hasn't really held up (but now would be a great time to mention if that isn't true). (Note: choosing leaving names as they are still only guarantees core plugins do this, 3rd party authors may not re-publish at all, or rename however they want) -Michal On Wed, Feb 11, 2015 at 4:07 PM, Andrew Grieve agri...@chromium.org wrote: Going to try and summarize my concerns with the proposal here: On Wed, Feb 11, 2015 at 2:39 PM, Steven Gill stevengil...@gmail.com wrote: 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. CPR doesn't allow non-reverse dns names. There'd be no reason to check it unless the name had at least 2 periods in it. If we're not using package names to detect which registry to use, I don't actually see any benefit in changing names. 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. While this works fine for our modules, I don't think it'll work well for others'. Three use-cases for them: 1. dependency within plugin.xml. 2. plugin within config.xml (for cordova plugin restore). 3. cordova plugin add FOO All three would be solved if we enforce that packageName == pluginId. I think we should either: - publish under npm under our existing IDs or: - publish under npm under cordova-plugin-FOO, and change plugin IDs to be cordova-plugin-FOO 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 mmo...@chromium.org 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 stevengil...@gmail.com 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 gorkem.er...@gmail.com 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
Re: Plugin Install Hooks
..Not to mention, these plugins will be running on end users' personal devices. That sounds vastly more concerning than running hooks on a server you control and can sandbox. On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny mmo...@chromium.org wrote: So, I think this is not different than downloading and running packages from any package manager. That said, I think a --suppress-hooks flag would be fine. I suggest you file a JIRA so others can chime in, and if you want it to land soon I would take a stab at a PR. -Michal On Tue, Feb 10, 2015 at 10:02 AM, Horn, Julian C julian.c.h...@intel.com wrote: Thanks for the pointer Shazron. I read through all of this interesting discussion. I agree that sandboxing is hard and prompting is problematic. But there's still an issue here. If there is no mechanism to exclude scripting in untrusted plugins then build servers are unlikely to accept any uncurated plugin, which is what PGBuild is doing. The Intel XDK provides a build server. We would like to support arbitrary third party plugins, not just ones we have curated. This install-time hooks feature creates a major security issue for us. Under no circumstances are we going to allow untrusted native code to run on our build server. And thanks to Sergey for pointing out that issue with pre_package hooks! We were under the impression that project-level hooks could be suppressed by excluding the hooks directory. I see now that this isn't sufficient. I have a very simple suggestion: add a --suppress-hooks flag. This doesn't prompt: it assumes the answer to the prompt is no. I don't have enough experience with install hooks to know if the plugin is likely to be usable without running the install-time hook. I expect that if you add a plugin that contains an install time hook and --suppress-hooks is present, then the plugin add should fail. If there's some reason to believe that a plugin could be usable without running the install time hook, then maybe it would be interesting to have a variant of --suppress-hooks that bypasses the hook but allows the plugin to be installed anyway. I would also expect that --suppress-hooks would suppress pre_package time hooks too. Julian -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, February 09, 2015 4:21 PM To: dev@cordova.apache.org Subject: Re: Plugin Install Hooks We did discuss this, and we rejected: 1. Having a prompt 2. Sandboxing Check out the discussion, for reasons: http://markmail.org/message/alknczhqdghaurrw On Mon, Feb 9, 2015 at 8:28 AM, Horn, Julian C julian.c.h...@intel.com wrote: We have identified a security issue with the recently added feature of install-time plugin hooks. As far as I can tell, there is nothing that prevents creation of a plugin with a malicious install-time hook script. Adding that plugin to a project could corrupt the user's host machine. If that project using that plugin is submitted to a build server, then the build server could be corrupted. Yes, you can use lower level plugman scripts to fetch plugins and then pre-scan them for install time hooks and track down all the dependencies and scan them too. So this is fixable (on a build server), but it's a lot of extra work; cordova plugin add should not be an unsafe operation. I propose that the CLI should check to see if a plugin requires an install-time hook and require the user to explicitly grant permission before executing the install hook. A build server would always deny permission. Is there something I'm missing here? Julian - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Plugin Install Hooks
So, I think this is not different than downloading and running packages from any package manager. That said, I think a --suppress-hooks flag would be fine. I suggest you file a JIRA so others can chime in, and if you want it to land soon I would take a stab at a PR. -Michal On Tue, Feb 10, 2015 at 10:02 AM, Horn, Julian C julian.c.h...@intel.com wrote: Thanks for the pointer Shazron. I read through all of this interesting discussion. I agree that sandboxing is hard and prompting is problematic. But there's still an issue here. If there is no mechanism to exclude scripting in untrusted plugins then build servers are unlikely to accept any uncurated plugin, which is what PGBuild is doing. The Intel XDK provides a build server. We would like to support arbitrary third party plugins, not just ones we have curated. This install-time hooks feature creates a major security issue for us. Under no circumstances are we going to allow untrusted native code to run on our build server. And thanks to Sergey for pointing out that issue with pre_package hooks! We were under the impression that project-level hooks could be suppressed by excluding the hooks directory. I see now that this isn't sufficient. I have a very simple suggestion: add a --suppress-hooks flag. This doesn't prompt: it assumes the answer to the prompt is no. I don't have enough experience with install hooks to know if the plugin is likely to be usable without running the install-time hook. I expect that if you add a plugin that contains an install time hook and --suppress-hooks is present, then the plugin add should fail. If there's some reason to believe that a plugin could be usable without running the install time hook, then maybe it would be interesting to have a variant of --suppress-hooks that bypasses the hook but allows the plugin to be installed anyway. I would also expect that --suppress-hooks would suppress pre_package time hooks too. Julian -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, February 09, 2015 4:21 PM To: dev@cordova.apache.org Subject: Re: Plugin Install Hooks We did discuss this, and we rejected: 1. Having a prompt 2. Sandboxing Check out the discussion, for reasons: http://markmail.org/message/alknczhqdghaurrw On Mon, Feb 9, 2015 at 8:28 AM, Horn, Julian C julian.c.h...@intel.com wrote: We have identified a security issue with the recently added feature of install-time plugin hooks. As far as I can tell, there is nothing that prevents creation of a plugin with a malicious install-time hook script. Adding that plugin to a project could corrupt the user's host machine. If that project using that plugin is submitted to a build server, then the build server could be corrupted. Yes, you can use lower level plugman scripts to fetch plugins and then pre-scan them for install time hooks and track down all the dependencies and scan them too. So this is fixable (on a build server), but it's a lot of extra work; cordova plugin add should not be an unsafe operation. I propose that the CLI should check to see if a plugin requires an install-time hook and require the user to explicitly grant permission before executing the install hook. A build server would always deny permission. Is there something I'm missing here? Julian - To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
Re: Plugin Install Hooks
I meant that the developer is shipping a plugin to the store which end users will run. If the contacts plugin is malicious, it wouldn't be running hooks on the devs machine, it would be uploading users' contacts to some website. You as a developer should vet the plugin to make sure it isn't. At the end of the day, in practice, it just comes down to trust. Download plugins from trusted sources. When there is no trust, you have to sandbox and audit. On Tue, Feb 10, 2015 at 12:22 PM, Horn, Julian C julian.c.h...@intel.com wrote: Actually I see it the other way around. If you want to trust a plugin, you can make that decision; it's your machine. The build server doesn’t trust the plugins you trust. -Original Message- From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny Sent: Tuesday, February 10, 2015 11:27 AM To: Michal Mocny Cc: dev Subject: Re: Plugin Install Hooks ..Not to mention, these plugins will be running on end users' personal devices. That sounds vastly more concerning than running hooks on a server you control and can sandbox. On Tue, Feb 10, 2015 at 11:25 AM, Michal Mocny mmo...@chromium.org wrote: So, I think this is not different than downloading and running packages from any package manager. That said, I think a --suppress-hooks flag would be fine. I suggest you file a JIRA so others can chime in, and if you want it to land soon I would take a stab at a PR. -Michal On Tue, Feb 10, 2015 at 10:02 AM, Horn, Julian C julian.c.h...@intel.com wrote: Thanks for the pointer Shazron. I read through all of this interesting discussion. I agree that sandboxing is hard and prompting is problematic. But there's still an issue here. If there is no mechanism to exclude scripting in untrusted plugins then build servers are unlikely to accept any uncurated plugin, which is what PGBuild is doing. The Intel XDK provides a build server. We would like to support arbitrary third party plugins, not just ones we have curated. This install-time hooks feature creates a major security issue for us. Under no circumstances are we going to allow untrusted native code to run on our build server. And thanks to Sergey for pointing out that issue with pre_package hooks! We were under the impression that project-level hooks could be suppressed by excluding the hooks directory. I see now that this isn't sufficient. I have a very simple suggestion: add a --suppress-hooks flag. This doesn't prompt: it assumes the answer to the prompt is no. I don't have enough experience with install hooks to know if the plugin is likely to be usable without running the install-time hook. I expect that if you add a plugin that contains an install time hook and --suppress-hooks is present, then the plugin add should fail. If there's some reason to believe that a plugin could be usable without running the install time hook, then maybe it would be interesting to have a variant of --suppress-hooks that bypasses the hook but allows the plugin to be installed anyway. I would also expect that --suppress-hooks would suppress pre_package time hooks too. Julian -Original Message- From: Shazron [mailto:shaz...@gmail.com] Sent: Monday, February 09, 2015 4:21 PM To: dev@cordova.apache.org Subject: Re: Plugin Install Hooks We did discuss this, and we rejected: 1. Having a prompt 2. Sandboxing Check out the discussion, for reasons: http://markmail.org/message/alknczhqdghaurrw On Mon, Feb 9, 2015 at 8:28 AM, Horn, Julian C julian.c.h...@intel.com wrote: We have identified a security issue with the recently added feature of install-time plugin hooks. As far as I can tell, there is nothing that prevents creation of a plugin with a malicious install-time hook script. Adding that plugin to a project could corrupt the user's host machine. If that project using that plugin is submitted to a build server, then the build server could be corrupted. Yes, you can use lower level plugman scripts to fetch plugins and then pre-scan them for install time hooks and track down all the dependencies and scan them too. So this is fixable (on a build server), but it's a lot of extra work; cordova plugin add should not be an unsafe operation. I propose that the CLI should check to see if a plugin requires an install-time hook and require the user to explicitly grant permission before executing the install hook. A build server would always deny permission. Is there something I'm missing here? Julian - 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
Re: Does this plugin support the current platform?
Generally, this is a bit of an unsolved problem. While plugins have platform tags, I believe we install all plugins for all platforms. This is because the platform tag was used for optional configuration initially and was never mandated. So, you can use that as a signal which says should support platform x but there are surely examples of plugins that blindly added all platform tags, and plugins which haven't added any platform tags at all, yet support some platforms. With feature detection, this will only work if the plugin has not blindly clobbered the js api for all platforms (which isn't uncommon). Some plugins provide no-op stubs, or just execute calls that won't work. Not quite sure we gave enough guidance on proper multi-platform plugin development, and some of the guidance we are still just learning. -Michal On Tue, Feb 10, 2015 at 12:18 PM, Horn, Julian C julian.c.h...@intel.com wrote: The natural way to determine whether some functionality is available is to use the feature detection pattern. That is, if you want to call some function normally found at myobj.myfunc, you write code like this: If (myobj (typeof myobj.myfunc === 'function')) ... For this to work you must take care to remove plugins that don't support your platform before you build for that platform. For example, before you build for firefoxos, you must remove the barcodescanner plugin (and then add it back when you build for supported platforms). Granted, this is awkward, but I think it's worse to read the package.json file. Really the CLI should make the feature detection pattern work without having to exclude plugins on unsupported platforms. That is, if a plugin doesn't support a platform, then it should contribute nothing when you build for that platform. Julian -Original Message- From: Axel Nennker [mailto:ignisvul...@gmail.com] Sent: Tuesday, February 10, 2015 11:48 AM To: dev Subject: Re: Does this plugin support the current platform? And then the app has to load that package.json ? On Feb 10, 2015 5:28 PM, Steven Gill stevengil...@gmail.com wrote: Plugin.xml has a platforms tag for what platforms it supports. That info gets uploaded to the Cordova plugins registry when publishing. Soon this info will be available in package.json file each plugin has. On Feb 10, 2015 7:25 AM, Axel Nennker ignisvul...@gmail.com wrote: Hi, is there a way how an app can determine whether a plugin supports the current platform? E.g.: the barcodescanner plugin is not supporting firefoxos How could an app know that which out hardcoding this into the app? If there is a standard way in Cordova then this is a userland question. If not then this is a feature request to add this info to e.g. cordova/plugin_list exports.metadata ?! -Axel
Re: Does this plugin support the current platform?
Indeed. No platform tag kinda implies js-only plugin, so captures the spirit of the intent well! On Tue, Feb 10, 2015 at 5:11 PM, Steven Gill stevengil...@gmail.com wrote: Sounds like a smart change. On Feb 10, 2015 2:10 PM, tommy-carlos williams to...@devgeeks.org wrote: Nice +1 One change in Cordova is a lot bette than expecting all plugins to change ;) -- tommy-carlos williams On 11 February 2015 at 07:54:17, Andrew Grieve (agri...@chromium.org) wrote: Strawman: If plugin.xml has *any* platforms, then only apply global tags to those platforms. If plugin.xml has *no* platforms, then apply global tags to all platforms. On Tue, Feb 10, 2015 at 2:18 PM, Tommy Williams to...@devgeeks.org wrote: This won't actually help right now, but that feature detection would actually be possible if the plugin's clobbers was always a child of the platform in plugin.xml. Right now, most plugins have their clobbers global to all platforms, supported or not. If the clobbers is a child of the platform, then the relevant js function/object would be undefined on an unsupported platform. This practice would also help in a situation where you might want different plugins for different platforms, but exposing similar functionality on one clobbered function/object (eg: the popular barcode scanner plugin + the blackberry barcode scanner plugin). Unfortunately, most plugins don't do this, even though it is possible. The natural way to determine whether some functionality is available is to use the feature detection pattern. That is, if you want to call some function normally found at myobj.myfunc, you write code like this: If (myobj (typeof myobj.myfunc === 'function')) ... For this to work you must take care to remove plugins that don't support your platform before you build for that platform. For example, before you build for firefoxos, you must remove the barcodescanner plugin (and then add it back when you build for supported platforms). Granted, this is awkward, but I think it's worse to read the package.json file. Really the CLI should make the feature detection pattern work without having to exclude plugins on unsupported platforms. That is, if a plugin doesn't support a platform, then it should contribute nothing when you build for that platform. Julian -Original Message- From: Axel Nennker [mailto:ignisvul...@gmail.com] Sent: Tuesday, February 10, 2015 11:48 AM To: dev Subject: Re: Does this plugin support the current platform? And then the app has to load that package.json ? On Feb 10, 2015 5:28 PM, Steven Gill stevengil...@gmail.com wrote: Plugin.xml has a platforms tag for what platforms it supports. That info gets uploaded to the Cordova plugins registry when publishing. Soon this info will be available in package.json file each plugin has. On Feb 10, 2015 7:25 AM, Axel Nennker ignisvul...@gmail.com wrote: Hi, is there a way how an app can determine whether a plugin supports the current platform? E.g.: the barcodescanner plugin is not supporting firefoxos How could an app know that which out hardcoding this into the app? If there is a standard way in Cordova then this is a userland question. If not then this is a feature request to add this info to e.g. cordova/plugin_list exports.metadata ?! -Axel
Re: Move platform parsers from CLI to platforms
You know, writing out my thoughts has crystallized that I think we should just be shipping the scripts as independent packages instead of bundling directly inside platforms. With that conclusion, I have to re-think what that implies ;) On Mon, Feb 9, 2015 at 5:07 PM, Michal Mocny mmo...@chromium.org wrote: Thoughts: 1. I'm happy to require cordova-android@FOO is required to be installed if you want to prepare a project that was created with it. I think we should leave a created-with file inside the platform artifacts to confirm this. Possibly it makes in-place upgrades harder, but I think the future of upgrade is uninstall-update-install or rm -rf add 2. To support older platforms, I suggest we create a new package (cordova-platform-scripts-legacy?), which simulate as-if old platforms had scripts embedded. This way, we can write the CLI/LIB tooling parts without many special cases, and gives us easier ability to polyfill the legacy scripts to future CLI/LIB api changes. 3. Regarding making refactoring harder.. maybe. Or maybe we have cordova-android depend on cordova-android-scripts and use semver. If the cordova-android-scripts change, but are backwards compatible, we can push an update that will automatically be picked up by all older platforms. If it isn't compatible, then you have a tooling-platform mismatch and have to upgrade no matter what. 4. Agree with assuming everything async -- and personally prefer promises (they are in io.js by default, node just updated to 0.12, may be there soon too) -- but I know there were some reservations on this lists about using them. (We can wrap one way with the other, so lets not bikeshed for now) On Mon, Feb 9, 2015 at 9:45 AM, Andrew Grieve agri...@chromium.org wrote: Been thinking about this as well, and one part I'm not 100% sure about is having this logic at create-time vs prepare-time vs plugin-add time. create-time - easy to see we just put it in cordova-FOO and allow deps within package.json prepare/plugin-add time though, should we relay on having the correct version of cordova-FOO around to use, or should we copy this logic into platforms/FOO/cordova? Moving these files into each repo will certainly make refactoring harder. E.g., making a change to the API now requires a version check + still supporting the old API + also supporting the new API. Still think this is worth doing, but I think we should also consider sanity-checking our API surface to ensure that it makes the most sense (e.g. all APIs that may have to do IO should return promises, even if they are sync right now). On Mon, Feb 9, 2015 at 12:42 AM, Mark Koudritsky kam...@google.com wrote: There are 2 main places in the lib with platform specific logic src/cordova/metadata/platform_parser.js src/plugman/platforms/platform.js Probably all of this logic should be moved to platforms. On Sun, Feb 8, 2015 at 4:36 AM, Josh Soref jso...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone.
Re: Move platform parsers from CLI to platforms
Thoughts: 1. I'm happy to require cordova-android@FOO is required to be installed if you want to prepare a project that was created with it. I think we should leave a created-with file inside the platform artifacts to confirm this. Possibly it makes in-place upgrades harder, but I think the future of upgrade is uninstall-update-install or rm -rf add 2. To support older platforms, I suggest we create a new package (cordova-platform-scripts-legacy?), which simulate as-if old platforms had scripts embedded. This way, we can write the CLI/LIB tooling parts without many special cases, and gives us easier ability to polyfill the legacy scripts to future CLI/LIB api changes. 3. Regarding making refactoring harder.. maybe. Or maybe we have cordova-android depend on cordova-android-scripts and use semver. If the cordova-android-scripts change, but are backwards compatible, we can push an update that will automatically be picked up by all older platforms. If it isn't compatible, then you have a tooling-platform mismatch and have to upgrade no matter what. 4. Agree with assuming everything async -- and personally prefer promises (they are in io.js by default, node just updated to 0.12, may be there soon too) -- but I know there were some reservations on this lists about using them. (We can wrap one way with the other, so lets not bikeshed for now) On Mon, Feb 9, 2015 at 9:45 AM, Andrew Grieve agri...@chromium.org wrote: Been thinking about this as well, and one part I'm not 100% sure about is having this logic at create-time vs prepare-time vs plugin-add time. create-time - easy to see we just put it in cordova-FOO and allow deps within package.json prepare/plugin-add time though, should we relay on having the correct version of cordova-FOO around to use, or should we copy this logic into platforms/FOO/cordova? Moving these files into each repo will certainly make refactoring harder. E.g., making a change to the API now requires a version check + still supporting the old API + also supporting the new API. Still think this is worth doing, but I think we should also consider sanity-checking our API surface to ensure that it makes the most sense (e.g. all APIs that may have to do IO should return promises, even if they are sync right now). On Mon, Feb 9, 2015 at 12:42 AM, Mark Koudritsky kam...@google.com wrote: There are 2 main places in the lib with platform specific logic src/cordova/metadata/platform_parser.js src/plugman/platforms/platform.js Probably all of this logic should be moved to platforms. On Sun, Feb 8, 2015 at 4:36 AM, Josh Soref jso...@blackberry.com wrote: +1 Sent from my BlackBerry 10 smartphone.
Re: [Review] Plugins Package.json
Left comments inline, but haven't tested. Overall, looks good and I like
the approach!
On Fri, Feb 6, 2015 at 3:41 PM, Steven Gill stevengil...@gmail.com wrote:
Hey All!
So createpackagejson script is done. I have it all on branch CB-8416.
USAGE: plugman createpackagejson PLUGIN_PATH
Commit:
https://github.com/apache/cordova-lib/commit/fcf37d03d12301d26cb4bcbb0107b085325f40d6
I am using init-package-json module. So our createpackagejson script feels
very much like npm init. It generates defaults based on info from
plugin.xml. Try it out!
When publishing to CPR, plugman publish will temporarily move an existing
package.json so it doesn't conflict with the package.json it needs to
create to publish.
https://github.com/apache/cordova-lib/commit/adab8c9accfd769019837bb1cc36a2975f9742b0
I'd like to push this to master and do a tools release today. After the
plugins release is completed, I will go through our plugins and add
package.json files to them all. Next plugins release should be published on
npm as well as CPR.
Thoughts?
On Wed, Feb 4, 2015 at 1:31 PM, Brian LeRoux b...@brian.io wrote:
love this, having a cordova key is a v good idea while this bakes too
On Wed, Feb 4, 2015 at 12:10 PM, Parashuram N (MS OPEN TECH)
panar...@microsoft.com wrote:
+1 to changing cordova-windows8 to cordova-windows.
On 2/4/15, 12:05 PM, Jesse purplecabb...@gmail.com wrote:
Yes, you can skip all the 'windows8' stuff and just use 'windows'.
windows8 is legacy and slowly all plugins are being migrated to just
use
the 'windows' section in plugin.xml
@purplecabbage
risingj.com
On Wed, Feb 4, 2015 at 11:36 AM, Steven Gill stevengil...@gmail.com
wrote:
I have made the changes you suggested. I like the idea of cordova
parent
key.
I added cordova-windows8 as a keyword but I would like someone from
microsoft to chime in about it. My understanding is that windows8 is
around
for legacy and windows is preferred. Please correct me if I'm wrong.
I'd
prefer to just list windows and cordova-windows.
If anyone else has feedback on the package.json file, please share!
You
can
view it at
https://github.com/stevengill/cordova-plugin-device/blob/npmpub/package.j
son
I am working on createpackagejson command now
https://issues.apache.org/jira/browse/CB-8416
On Tue, Feb 3, 2015 at 5:29 PM, Andrew Grieve agri...@chromium.org
wrote:
From looking at it, only thought is whether we should put all of
the
non-standard fields into a cordova parent key. E.g.:
{
name: cordova-plugin-device,
cordova: {
id: org.apache.cordova.device,
platforms: [...]
}
}
Sounds like we need to re-write the file when publishing to CPR
anyways,
so
transforming from this to what is currently expected can be done
in
that
step.
Other tidbits:
- windows8 is missing from keywords. Intentional? (not sure if
windows is
now an alias?)
- author: might just set this to Apache
On Tue, Feb 3, 2015 at 7:50 PM, Steven Gill
stevengil...@gmail.com
wrote:
Please review at
https://github.com/stevengill/cordova-plugin-device/blob/npmpub/package.j
son
You will notice that I added cordova-PLATFORM as a keyword.
I have also kept the platforms tag for now. I can remove it but
maybe
we
can find some future use for it. We currently need it when
publising to
CPR
but can add/rm it during plugman publish.
I am going to create a createpackagejson command in plugman that
will
build
something like this from plugin.xml. Other plugin devs will be
able
to
use
this command to quickly add package.json files to their plugins.
I will then modify plugman publish to use the createpackagejson
command
if
needed. Plugman publish will still have to add the contents of
the
readme
(or doc/index.md) to the package.json as well as the platforms
tag
if
we
decide to remove it. It will also have to change the
package-name
field
to
package-id when publishing to CPR. Once published, we can remove
these
changes package.json.
If the package.json file looks good, I'm going to start adding
one
to
all
of our plugins.
-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org
Re: [Review] plugman createpackagejson
(I commented on the other thread) Left comments inline, but haven't tested. Overall, looks good and I like the approach! On Mon, Feb 9, 2015 at 10:35 AM, Andrew Grieve agri...@chromium.org wrote: Plan sounds good to me! On Fri, Feb 6, 2015 at 7:11 PM, Steven Gill stevengil...@gmail.com wrote: Hey All! Figured this should get its own thread So createpackagejson script is done. I have it all on branch CB-8416. USAGE: plugman createpackagejson PLUGIN_PATH Commit: https://github.com/apache/cordova-lib/commit/fcf37d03d12301d26cb4bcbb0107b085325f40d6 I am using init-package-json module. So our createpackagejson script feels very much like npm init. It generates defaults based on info from plugin.xml. Try it out! When publishing to CPR, plugman publish will temporarily move an existing package.json so it doesn't conflict with the package.json it needs to create to publish. https://github.com/apache/cordova-lib/commit/adab8c9accfd769019837bb1cc36a2975f9742b0 I'd like to push this to master and do a tools release next week. After the plugins release is completed, I will go through our plugins and add package.json files to them all. Next plugins release should be published on npm as well as CPR. Thoughts?
