Re: Tagging 3.1.0 today?
\o/ On Oct 3, 2013 2:40 AM, Andrew Grieve agri...@chromium.org wrote: WHO! On Wed, Oct 2, 2013 at 11:10 PM, Steven Gill stevengil...@gmail.com wrote: I have temporarily set the download back to dist.apache.org. I will change it once our stuff gets mirrored. Doap file updated. Only thing remaining is to fix docs redirect (only Michael B can do this and he is in Europe) Close Issue Great job on this release everyone. Not an easy one! -Steve On Wed, Oct 2, 2013 at 3:01 PM, Steven Gill stevengil...@gmail.com wrote: The apache mirrors haven't picked up 3.1.0 zip yet. Making it a little harder to get out on our site. Feel free to RT the release tweet. https://twitter.com/apachecordova/status/385523954724507648 On Wed, Oct 2, 2013 at 2:51 PM, Steven Gill stevengil...@gmail.com wrote: Sounds good. Also updating download links to point to 3.1.0 instead of 3.0.0 On Wed, Oct 2, 2013 at 2:48 PM, Andrew Grieve agri...@chromium.org wrote: Blog post is live. http://cordova.apache.org/blog/releases/2013/10/02/cordova-31.html Final steps: Tweet the post (steve) Update DOAP file with .zip release (steve) Update the docs.cordova.io redirect (Michael B) Mark as released in JIRA ( https://issues.apache.org/jira/plugins/servlet/project-config/CB/versions ) (steve) On Wed, Oct 2, 2013 at 10:03 PM, Steven Gill stevengil...@gmail.com wrote: Release is being uploaded as I type this email. Andrew, feel free to post the blog + update the site to say 3.1.0! Woot! On Wed, Oct 2, 2013 at 12:30 PM, Shazron shaz...@gmail.com wrote: I don't think Apache is breaking Git, it's just git. This has happened before, where I commented on the ML about a tag that had the tagged commit missing from any of the branches (I believe it was from a tag from Tim, not calling you out here Tim, but just for precedence purposes as a concrete example for this current issue). I hadn't updated my local cordova-android repo since yesterday. I see that a commit by Joe Bowser with subject Tagging 3.1.0 with hash 6f17e9fc9cd27f031d94d67fe118008d5f6ec5b3 - this was from the 3.1.0 tag. I searched using git for any local or remote branches (my last Apache fetch) and it did not contain the commit. $ git branch --contains 6f17e9fc9cd27f031d94d67fe118008d5f6ec5b3 (for local branches) $ git branch -a --contains 6f17e9fc9cd27f031d94d67fe118008d5f6ec5b3 (for remote branches) Thus, when someone pulled down the 3.1.x branch, it did not contain your commit. I assume, based on looking at the 3.1.x branch, and not seeing it tagged, that person then tagged it, and it appeared that your commit was removed. The evidence strongly suggests otherwise, imo. I have zipped up my local repo and can provide it to anyone if they want to take a look. On Wed, Oct 2, 2013 at 11:49 AM, Joe Bowser bows...@gmail.com wrote: On Wed, Oct 2, 2013 at 11:46 AM, Andrew Grieve agri...@chromium.org wrote: Sorry, was away from my computer for a while there. Joe, sounds like what happened was that you pushed the tag without pushing the branch. That has happened a few times in the past by others (including myself). No biggie. The ASF repos disable git push --force, so I don't think it's even possible for tampering to happen. I want github back! Apache is breaking git. :( As far as tampering, it's totally possible for it to happen. Sadly, it looks exactly like this. I apologize for getting super aggro about the git screw-up.
chrome dev summit
anyone here going? http://developer.chrome.com/devsummit
Re: Tagging 3.1.0 today?
This is a great team. Thanks for all your efforts!
RE: Tagging 3.1.0 today?
Love the update! Hope I can update my project soon! :) Thanks guys! Subject: Re: Tagging 3.1.0 today? From: cmarc...@gmail.com Date: Thu, 3 Oct 2013 07:56:11 -0400 To: dev@cordova.apache.org This is a great team. Thanks for all your efforts!
Re: Mobilespec / CI / version problems
bump With the release, its been a bit busy, but this issue needs some love. Note that someone else has commented on the same problem from a different angle (not mobilespec) [Commented] (CB-4889) ~ 3am this morning The renaming of plugins created a hole and there are a couple possible resolutions. to help out in a general way (not mobilespec) 1) smack a tag into the git repos for 3.0.x just in front of the name change. I think you can still do that? 2) publish plugins under the old name. might work if you use new tools with a 3.0 project 3) document the bug and tell people using 3.0 to switch to 3.1 or update the plugin name references in their project to fix mobilespec: 1) #1 above works 2) re-release mobilespec for 3.0.x 3) patch the ios project for 3.0.x to finish removing the Echo plugin files so you can build 3.0.x with the 3.1.x mobilespec Thoughts? On Tue, Oct 1, 2013 at 1:30 PM, David Kemp drk...@google.com wrote: Just for clarification... Testing 3.1.x works fine using 3.1 platforms, 3.1 mobilespec, and master plugins. Testing 'HEAD' works fine using master platforms, master mobilespec, and dev plugins. Thats all as expected. Up until a week ago, you could test 3.0.x using 3.0.x platforms, 3.0.x mobilespec, and master plugins. That no longer works. On Tue, Oct 1, 2013 at 12:40 PM, Joe Bowser bows...@gmail.com wrote: Aren't we testing 3.1.0 with the tests that were tagged in 3.1.0? Testing with 3.0.0 tests seems like you'll always have failing tests, since ideally the tests should have been added with the bug (although I don't know where to put platform-specific mobile-spec tests, the don't really have a home and people get upset when I check them in.) On Tue, Oct 1, 2013 at 9:34 AM, David Kemp drk...@google.com wrote: I believe that will be OK - testing it out now. It still probably deserves some documentation somewhere that the previously stated relationships don't work anymore, and that any plugin references in a 3.0.x project need attention. On Tue, Oct 1, 2013 at 12:03 PM, Andrew Grieve agri...@chromium.org wrote: Would it fix it to use mobile-spec from master when testing 3.0.x? Mobile-spec generally stays in sync with the plugins more so than the platforms, so it would make sense to me to use mobile-spec at master if using plugins from master/dev. On Tue, Oct 1, 2013 at 4:40 PM, David Kemp drk...@google.com wrote: The issue is the that stated methodology for getting the right versions to test is: * for release, get plugins from the master branch and platforms, tests etc from the release branch (3.0.x) * for tip of tree, get plugins from the dev branch and platforms, tests etc from the master branch Since the rename was done to the plugins on master (appropriate for 3.1.x) that no longer leaves a place to get plugins that are 'compatible' with 3.0.x The issue that I am pointing out right now is that the file: cordova-mobile-spec/dependencies-plugin/plugin.xml explicitly names the plugins with the old name in the 3.0.x branch of mobile-spec. so it breaks. If a developer has a similar references to their 3.0.x plugins, it will also fail next time they build a fresh new project. For CI it means that all tests of the 3.0.x branch now fail. On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard cmarc...@gmail.com wrote: In the past I've used #3. When checking out code to test, I try to get all the assets from the same branch / time period. But I may be skewed in that approach, since our product that embeds Cordova has a snapshot of the platforms and plugins, and doesn't get updates from the online repos. Does what you are saying infer that the rename of the plugins is a breaking change? And needs to have some verbage in the Upgrading guides? On Oct 1, 2013, at 11:14 AM, David Kemp drk...@chromium.org wrote: Summary: Due to the renaming of plugins, there is no longer a sensible way to test 3.0.x Detail: The process to test 3.0.x is to get platforms, mobile-spec, etc from 3.0.x and plugins from master. With the change on plugin names (remove core) the 3.0.x mobile-spec still refers to the names with core , but the master branch of the plugins no longer have that name. Possible resolutions: 1) never mind - mobilespec for 3.0.x is broken, it will be fixed in 3.1.x 2) cherrypick the change to mobilespec dependencies back to 3.0.x 3) find some other way to get the older plugins available to test. Thoughts? David Kemp
Re: chrome dev summit
Andrew and I. On Thu, Oct 3, 2013 at 4:29 AM, Brian LeRoux b...@brian.io wrote: anyone here going? http://developer.chrome.com/devsummit
Re: Mobilespec / CI / version problems
I'm fine with any of the options. On Thu, Oct 3, 2013 at 1:47 PM, David Kemp drk...@google.com wrote: bump With the release, its been a bit busy, but this issue needs some love. Note that someone else has commented on the same problem from a different angle (not mobilespec) [Commented] (CB-4889) ~ 3am this morning The renaming of plugins created a hole and there are a couple possible resolutions. to help out in a general way (not mobilespec) 1) smack a tag into the git repos for 3.0.x just in front of the name change. I think you can still do that? 2) publish plugins under the old name. might work if you use new tools with a 3.0 project 3) document the bug and tell people using 3.0 to switch to 3.1 or update the plugin name references in their project to fix mobilespec: 1) #1 above works 2) re-release mobilespec for 3.0.x 3) patch the ios project for 3.0.x to finish removing the Echo plugin files so you can build 3.0.x with the 3.1.x mobilespec Thoughts? On Tue, Oct 1, 2013 at 1:30 PM, David Kemp drk...@google.com wrote: Just for clarification... Testing 3.1.x works fine using 3.1 platforms, 3.1 mobilespec, and master plugins. Testing 'HEAD' works fine using master platforms, master mobilespec, and dev plugins. Thats all as expected. Up until a week ago, you could test 3.0.x using 3.0.x platforms, 3.0.x mobilespec, and master plugins. That no longer works. On Tue, Oct 1, 2013 at 12:40 PM, Joe Bowser bows...@gmail.com wrote: Aren't we testing 3.1.0 with the tests that were tagged in 3.1.0? Testing with 3.0.0 tests seems like you'll always have failing tests, since ideally the tests should have been added with the bug (although I don't know where to put platform-specific mobile-spec tests, the don't really have a home and people get upset when I check them in.) On Tue, Oct 1, 2013 at 9:34 AM, David Kemp drk...@google.com wrote: I believe that will be OK - testing it out now. It still probably deserves some documentation somewhere that the previously stated relationships don't work anymore, and that any plugin references in a 3.0.x project need attention. On Tue, Oct 1, 2013 at 12:03 PM, Andrew Grieve agri...@chromium.org wrote: Would it fix it to use mobile-spec from master when testing 3.0.x? Mobile-spec generally stays in sync with the plugins more so than the platforms, so it would make sense to me to use mobile-spec at master if using plugins from master/dev. On Tue, Oct 1, 2013 at 4:40 PM, David Kemp drk...@google.com wrote: The issue is the that stated methodology for getting the right versions to test is: * for release, get plugins from the master branch and platforms, tests etc from the release branch (3.0.x) * for tip of tree, get plugins from the dev branch and platforms, tests etc from the master branch Since the rename was done to the plugins on master (appropriate for 3.1.x) that no longer leaves a place to get plugins that are 'compatible' with 3.0.x The issue that I am pointing out right now is that the file: cordova-mobile-spec/dependencies-plugin/plugin.xml explicitly names the plugins with the old name in the 3.0.x branch of mobile-spec. so it breaks. If a developer has a similar references to their 3.0.x plugins, it will also fail next time they build a fresh new project. For CI it means that all tests of the 3.0.x branch now fail. On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard cmarc...@gmail.com wrote: In the past I've used #3. When checking out code to test, I try to get all the assets from the same branch / time period. But I may be skewed in that approach, since our product that embeds Cordova has a snapshot of the platforms and plugins, and doesn't get updates from the online repos. Does what you are saying infer that the rename of the plugins is a breaking change? And needs to have some verbage in the Upgrading guides? On Oct 1, 2013, at 11:14 AM, David Kemp drk...@chromium.org wrote: Summary: Due to the renaming of plugins, there is no longer a sensible way to test 3.0.x Detail: The process to test 3.0.x is to get platforms, mobile-spec, etc from 3.0.x and plugins from master. With the change on plugin names (remove core) the 3.0.x mobile-spec still refers to the names with core , but the master branch of the plugins no longer have that name. Possible resolutions: 1) never mind - mobilespec for 3.0.x is broken, it will be fixed in 3.1.x 2) cherrypick the change to mobilespec dependencies back to 3.0.x 3) find some other way to get the older plugins available to test. Thoughts? David Kemp
Re: Mobilespec / CI / version problems
On Thu, Oct 3, 2013 at 8:47 AM, David Kemp drk...@google.com wrote: bump With the release, its been a bit busy, but this issue needs some love. Note that someone else has commented on the same problem from a different angle (not mobilespec) [Commented] (CB-4889) ~ 3am this morning The renaming of plugins created a hole and there are a couple possible resolutions. to help out in a general way (not mobilespec) 1) smack a tag into the git repos for 3.0.x just in front of the name change. I think you can still do that? 2) publish plugins under the old name. might work if you use new tools with a 3.0 project 3) document the bug and tell people using 3.0 to switch to 3.1 or update the plugin name references in their project I think we (3) document the change, but it shouldn't mean you cannot use 3.0. You should be able to use 3.0 with the new plugin names, unless they actually have non 3.0 compatible changes (which I think is not the case except for Echo plugin which no one but mobilespec should be using). to fix mobilespec: 1) #1 above works 2) re-release mobilespec for 3.0.x (2) is my preference. I don't think future versions of mobile-spec should necessarily work well with older platforms. The mobile-spec tied to the platform cad-version should be run instead. This is still useful to test the ever-changing plugins to make sure they are compatible, and right not they are not since we introduced a backward-incompatible change to the ID. If we do with (3) above, then I think we need to update mobile-spec to use the new ID much like we will advise users to do. 3) patch the ios project for 3.0.x to finish removing the Echo plugin files so you can build 3.0.x with the 3.1.x mobilespec Thoughts? On Tue, Oct 1, 2013 at 1:30 PM, David Kemp drk...@google.com wrote: Just for clarification... Testing 3.1.x works fine using 3.1 platforms, 3.1 mobilespec, and master plugins. Testing 'HEAD' works fine using master platforms, master mobilespec, and dev plugins. Thats all as expected. Up until a week ago, you could test 3.0.x using 3.0.x platforms, 3.0.x mobilespec, and master plugins. That no longer works. On Tue, Oct 1, 2013 at 12:40 PM, Joe Bowser bows...@gmail.com wrote: Aren't we testing 3.1.0 with the tests that were tagged in 3.1.0? Testing with 3.0.0 tests seems like you'll always have failing tests, since ideally the tests should have been added with the bug (although I don't know where to put platform-specific mobile-spec tests, the don't really have a home and people get upset when I check them in.) On Tue, Oct 1, 2013 at 9:34 AM, David Kemp drk...@google.com wrote: I believe that will be OK - testing it out now. It still probably deserves some documentation somewhere that the previously stated relationships don't work anymore, and that any plugin references in a 3.0.x project need attention. On Tue, Oct 1, 2013 at 12:03 PM, Andrew Grieve agri...@chromium.org wrote: Would it fix it to use mobile-spec from master when testing 3.0.x? Mobile-spec generally stays in sync with the plugins more so than the platforms, so it would make sense to me to use mobile-spec at master if using plugins from master/dev. On Tue, Oct 1, 2013 at 4:40 PM, David Kemp drk...@google.com wrote: The issue is the that stated methodology for getting the right versions to test is: * for release, get plugins from the master branch and platforms, tests etc from the release branch (3.0.x) * for tip of tree, get plugins from the dev branch and platforms, tests etc from the master branch Since the rename was done to the plugins on master (appropriate for 3.1.x) that no longer leaves a place to get plugins that are 'compatible' with 3.0.x The issue that I am pointing out right now is that the file: cordova-mobile-spec/dependencies-plugin/plugin.xml explicitly names the plugins with the old name in the 3.0.x branch of mobile-spec. so it breaks. If a developer has a similar references to their 3.0.x plugins, it will also fail next time they build a fresh new project. For CI it means that all tests of the 3.0.x branch now fail. On Tue, Oct 1, 2013 at 11:23 AM, Marcel Kinard cmarc...@gmail.com wrote: In the past I've used #3. When checking out code to test, I try to get all the assets from the same branch / time period. But I may be skewed in that approach, since our product that embeds Cordova has a snapshot of the platforms and plugins, and doesn't get updates from the online repos. Does what you are saying infer that the rename of the plugins is a breaking change? And needs to have some verbage in the Upgrading guides? On Oct 1, 2013, at 11:14 AM, David Kemp drk...@chromium.org wrote:
Re: Android platform scripts
(Finally back from two days of intern interviews and one day of writing feedback.) I would prefer to do it part by part, but this is difficult. If the callers of the method I port are expecting it to be synchronous, they'll continue on to the next step too early. If I only change the outermost callers, and not the callees, there's little benefit to this. Especially since these have no tests, I'd love to keep it small, but I can't see a way to do that without porting all of one command, at least. (And there are some interdependencies.) Braden On Fri, Sep 27, 2013 at 5:40 PM, Brian LeRoux b...@brian.io wrote: Giver. Now, instead if the grand rewrite how about a refactor of a single method for review. Easier for us to buy in and perhaps collab on w you. On Sep 27, 2013 7:31 PM, Braden Shepherdson bra...@chromium.org wrote: I had since learned that shelljs is used for other things. That's fine, it's not hurting anything unless we use synchronous exec. Braden On Fri, Sep 27, 2013 at 12:47 PM, Andrew Grieve agri...@chromium.org wrote: SGTM. shelljs is used for other things though, so we won't be able to get rid of it. On Fri, Sep 27, 2013 at 4:13 PM, Braden Shepherdson bra...@chromium.org wrote: The Android platform scripts use shelljs.exec's synchronous mode. This is a terrible hack that leaks filehandles by the hundred, wastes lots of CPU cycles, and can cause EMFILE on OSX because it runs out of filehandles. I wanted to rewrite the scripts to be async and use child_process.exec or .spawn. I started to, but rapidly found that the tangle of callbacks that resulted was terrible and confusing. I propose using Q.js here as well (and dropping shelljs as a dependency, if it was only ever used for .exec). Any objections? Braden
Re: Updating plugin code on prepare
I agree that the syncing solutions are too complex and confusing. I return, then, to my original proposal all those emails ago: updating the native plugin files in platforms/foo when you prepare, to make life easier for plugin developers. When coupled with the present cordova plugin add --link, and future cordova watch, I think this makes the plugin developer flow pretty good, and without making it too magical or harder to understand. I think it simplifies prepare: on prepare, your native projects are updated to reflect the state of plugins/ and www/. Right now, only www/, assets and js-modules get updated, but not native code. As to Xcode and symlinks and all the rest of the borderline thread hijacking, I think that regardless of what editor you use, you have to be editing the right file. Xcode and Eclipse make this harder than it needs to be, but our job is not to make them suck less. Braden On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana csantan...@gmail.comwrote: +1 Anis corodova-cli/plugman should be building block components to higher level Tools/IDE. That we can do better sure, lets provide a few examples using blog pots and maybe videos tutorials vs. trying to support every use case with code. A watch function could be as simple as using grunt-contrib-watch to a more complicated environment like rsync/Eclipse I agree lets put emphasis on documenting use cases and the correct approach. When to get the best out of using prepare, merges, and hooks All I said applies when you have the Web Developer hat. For people that have the Native Plugin Developer hat then we can do things first for cordova-contributors than others can choose to use on their own risk since it could be changing too fast and maybe too narrow use case. --Carlos --Carlos On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI anis.ka...@gmail.com wrote: I gave some thought to this problem and I think we should just leave everything as is. Here's my reasoning: - Most web developers use a text editor (vim, sublime text, text mate, notepad++, ) to edit their HTML/CSS/Javascript. I've never seen anyone use a fully fledged IDE to edit web assets. It would be like using Microsoft Word to edit a simple .TXT or .MD file - Other developers, people who write Java or Objective C, etc.. use Xcode, Eclipse, IntelliJ, ...and I think these people are not good candidates for cordova-cli. The original PhoneGap promise (now Apache Cordova) was to make it easy for Web Developers to write Mobile Apps using web technologies and I believe that promise is fulfilled with cordova-cli. You have a folder where you drop in your web assets and you can build/deploy to a device or simulate. If people want to use an IDE, then they should be creating native projects with our create scripts and use plugman to manage their plugins. Our documentation should point our users to the right approach depending on the use case. For example: - Building for only one platform ? Building a hybrid app ? Want to use an IDE (Eclipse, Xcode) ? You should use the create scripts and plugman to manage plugins - Building a cross-platform app ? Like managing your project from the command-line ? Want to use your favo(u)rite text editor ? Use cordova-cli These double symlinking, backsyncing solutions will be a source of confusion and issues in my humble opinion. I've said it before but sometimes by trying to please everyone you end up pleasing no one. my .02c -a On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny mmo...@chromium.org wrote: On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve agri...@chromium.org wrote: Just tried some symlinks in Xcode 5: - Copying assets work (due to our custom build step) - Building works (compiler follows links just fine) - Editing a fail (big fail. Files open but changes cannot be saved.) Hmm, changes via xcode to symlinks fail, you mean? That would be hard to fix, but perhaps at least its feedback to the user not to make direct edits there, when using CLI workflow ;) so may still be a valid change to make. For Xcode though, it is an option to change our installation step to have Xcode reference the native files within plugins/ rather than within platforms/. Symlinks in Eclipse: - Copying assets works out-of-the-box - Build works fine - Editing seems to work fine (edits saved to symlinked location). Still though, maybe the best solution would be a combination of the two? Have prepare know when an remove+add is necessary? Yes, I think thats what we are suggesting. The original email mentioned prepare knowing when remove+add are necessary, which I think is already settled as a good idea. Not sure if you had more to add about how prepare should know when to do this (currently, its only on plugin.xml changes). The more recent
Re: Mapping plugin ID - URL
On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny mmo...@chromium.org wrote: On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI anis.ka...@gmail.com wrote: Braden and I have talked about it in the past but there is already a $HOME/.plugman/cache and plugman will not attempt to fetch plugins if they are already in the cache. Unless I am missing something can you just not drop your dependencies in there? This sounds like it would work, but I'm hesitant to force a global installation of the cache. I think it would mean you cannot develop BB webworks apps on the same machine as you develop vanilla cordova apps since the same plugin id would map to different places across *all* plugman using projects. Note that it already has been a source of problems to have things needlessly added to ~/.cordova and ~/.plugman. Thinking about this more, I think using the global cache is subtly different than what we want here. However, I think we could perhaps leverage the concept and share most of the code. Here is the big difference: - The global plugman cache is used *after* going out to registry to lookup latest version, so as not to download the same plugin version multiple times. - This proposed local search path is to be used *before* going out to registry, without caring about its content or version number. Perhaps the current behaviour can be decomposed into two steps: (1) update global cache with newest plugin version via registry and (2) install plugin from cache. Then, installing a plugin by ID could be: - Attempt Step (2) from local search path(s) - then, if above failed, do Step (1) - then, if above succeeded, Attempt Step (2) from global cache How does that sound? Are there other use cases than simply 'not fetching from registry and using local path' for a given plugin ID ? I think this is the only use case we are looking to solve, but it shows up in different situations: during cordova plugin add ID or plugman --install with dependancy etc. #1 and #2 can be solutions to some problems but do we have those problems yet ? They can be a solution to managing multiple registry sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...) because right now we only support. Yes, we already do have these problems, as said: IBM, BB, and to some extent Mobile-Chrome-Apps is already needing this solution. Implementing a new registry would be fine, if it worked offline for local-only installs, preferably without the need to set up a server/couchdb for such simple local only mappings, which is exactly Andrews proposal. Your proposed changes also seem to only affect CLI since you mentioned a .cordova/config.json. plugman only users would potentially be penalized once again. I completely agree this is implemented in plugman. We are discussing CLI just to establish the convention for how to store the cache, but plugman would have all the underlying functionality. It *has* to be this way, since its the one that resolves dependencies, and will need a new argument alongside --install to know where to lookup id for local mapping. On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny mmo...@chromium.org wrote: I think the missing piece is that the plugin author has the option of specifying dependencies in terms exactly *one* of these options: (a) id, to be looked up in the registry (b) explicit git url (c) relative path The problem is that a downstream *distributor* cannot override these values at the moment, without making direct edits to the plugin.xml. e.g. IBM and BlackBerry have already both spoken up about the problem of shipping a cordova based tool with plugins bundled, and having full control over plugin versions, supporting offline work, etc. How can we solve the generic case of using the CLI with the registry, while supporting the bundling/tarball use case? Andrews proposal would allow for option (a) to be overwritten by a distributor without changes to the plugin.xml, by implementing a local workspace mapping of id - path, which is used by cli instead of reaching out to the registry (though it could still use the registry for id's that are not in the mapping). I suspect it would also make (a) the only necessary way to specify plugin dependencies in practice, which I think is a win for simplicity. Thats my understanding anyway. -Michal On Wed, Oct 2, 2013 at 10:55 AM, Brian LeRoux b...@brian.io wrote: Well, not npm but rather http://plugins.cordova.io or by URL or by relative path (allowing for vendored plugins). That is how Node does it TMK and should cover our use cases too without adding new config file options (or worse more config files). Am I missing something? On Wed, Oct 2, 2013 at 2:31 PM, Andrew Grieve agri...@chromium.org wrote: Could you give an example of how you'd use npm or vendor dependencies? On Wed, Oct 2, 2013 at 10:12 AM, Brian LeRoux
Re: Updating plugin code on prepare
Yeah Braden we've diverged sorry, lets focus. Big +1 for your proposal to make prepare step do what users expect. -Michal On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson bra...@chromium.orgwrote: I agree that the syncing solutions are too complex and confusing. I return, then, to my original proposal all those emails ago: updating the native plugin files in platforms/foo when you prepare, to make life easier for plugin developers. When coupled with the present cordova plugin add --link, and future cordova watch, I think this makes the plugin developer flow pretty good, and without making it too magical or harder to understand. I think it simplifies prepare: on prepare, your native projects are updated to reflect the state of plugins/ and www/. Right now, only www/, assets and js-modules get updated, but not native code. As to Xcode and symlinks and all the rest of the borderline thread hijacking, I think that regardless of what editor you use, you have to be editing the right file. Xcode and Eclipse make this harder than it needs to be, but our job is not to make them suck less. Braden On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana csantan...@gmail.com wrote: +1 Anis corodova-cli/plugman should be building block components to higher level Tools/IDE. That we can do better sure, lets provide a few examples using blog pots and maybe videos tutorials vs. trying to support every use case with code. A watch function could be as simple as using grunt-contrib-watch to a more complicated environment like rsync/Eclipse I agree lets put emphasis on documenting use cases and the correct approach. When to get the best out of using prepare, merges, and hooks All I said applies when you have the Web Developer hat. For people that have the Native Plugin Developer hat then we can do things first for cordova-contributors than others can choose to use on their own risk since it could be changing too fast and maybe too narrow use case. --Carlos --Carlos On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI anis.ka...@gmail.com wrote: I gave some thought to this problem and I think we should just leave everything as is. Here's my reasoning: - Most web developers use a text editor (vim, sublime text, text mate, notepad++, ) to edit their HTML/CSS/Javascript. I've never seen anyone use a fully fledged IDE to edit web assets. It would be like using Microsoft Word to edit a simple .TXT or .MD file - Other developers, people who write Java or Objective C, etc.. use Xcode, Eclipse, IntelliJ, ...and I think these people are not good candidates for cordova-cli. The original PhoneGap promise (now Apache Cordova) was to make it easy for Web Developers to write Mobile Apps using web technologies and I believe that promise is fulfilled with cordova-cli. You have a folder where you drop in your web assets and you can build/deploy to a device or simulate. If people want to use an IDE, then they should be creating native projects with our create scripts and use plugman to manage their plugins. Our documentation should point our users to the right approach depending on the use case. For example: - Building for only one platform ? Building a hybrid app ? Want to use an IDE (Eclipse, Xcode) ? You should use the create scripts and plugman to manage plugins - Building a cross-platform app ? Like managing your project from the command-line ? Want to use your favo(u)rite text editor ? Use cordova-cli These double symlinking, backsyncing solutions will be a source of confusion and issues in my humble opinion. I've said it before but sometimes by trying to please everyone you end up pleasing no one. my .02c -a On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny mmo...@chromium.org wrote: On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve agri...@chromium.org wrote: Just tried some symlinks in Xcode 5: - Copying assets work (due to our custom build step) - Building works (compiler follows links just fine) - Editing a fail (big fail. Files open but changes cannot be saved.) Hmm, changes via xcode to symlinks fail, you mean? That would be hard to fix, but perhaps at least its feedback to the user not to make direct edits there, when using CLI workflow ;) so may still be a valid change to make. For Xcode though, it is an option to change our installation step to have Xcode reference the native files within plugins/ rather than within platforms/. Symlinks in Eclipse: - Copying assets works out-of-the-box - Build works fine - Editing seems to work fine (edits saved to symlinked location). Still though, maybe the best solution would be a combination of the two? Have prepare know when an remove+add is necessary? Yes,
Re: CLI tool - Medic testing
Should this info be in the wiki? Very useful, I was using similar approach but ending with same result. On Thursday, October 3, 2013, Braden Shepherdson wrote: Ack, sorry I wasn't around. This is a known problem, and a general one not specific to this release. If you're using master CLI, you need to be linking in master plugman as well. The sequence of commands to get everything working is: git clone https://git-wip-us.apache.org/repos/asf/cordova-plugman.git cd cordova-plugman npm install sudo npm link -g cd .. git clone https://git-wip-us.apache.org/repos/asf/cordova-cli.git cd cordova-cli npm install sudo npm link -g npm link plugman Now your global cordova command is master, and its plugman is master as well. Braden On Mon, Sep 30, 2013 at 1:48 PM, Steven Gill stevengil...@gmail.comjavascript:; wrote: Hey David, I think this is known and we need to do a plugman release pretty soon. Thanks for reporting this on the list! -Steve On Mon, Sep 30, 2013 at 10:14 AM, David Kemp drk...@chromium.orgjavascript:; wrote: Summary: Fresh checkout of Cordova-Cli from master results in a cli that will not add a plugin. [Error: Error fetching plugin: TypeError: Cannot call method 'fetch' of undefined] Details: The current Cordova-cli master requires a version of plugman that has not yet been published. Cli requires plugman 0.12.x and that plugman does not expose 'raw'. Cordova-plugman (master) does expose 'raw', but that version has not been published to npm. This will only be an issue if you get a fresh git checkout of cli from master, and don't overwrite the plugman with a fresh checkout as well. It does not affect the version of cli that is published via npm. David Kemp -- Carlos Santana csantan...@gmail.com
Re: CLI tool - Medic testing
Might be better in the CLI's README.md On Thu, Oct 3, 2013 at 3:47 PM, Carlos Santana csantan...@gmail.com wrote: Should this info be in the wiki? Very useful, I was using similar approach but ending with same result. On Thursday, October 3, 2013, Braden Shepherdson wrote: Ack, sorry I wasn't around. This is a known problem, and a general one not specific to this release. If you're using master CLI, you need to be linking in master plugman as well. The sequence of commands to get everything working is: git clone https://git-wip-us.apache.org/repos/asf/cordova-plugman.git cd cordova-plugman npm install sudo npm link -g cd .. git clone https://git-wip-us.apache.org/repos/asf/cordova-cli.git cd cordova-cli npm install sudo npm link -g npm link plugman Now your global cordova command is master, and its plugman is master as well. Braden On Mon, Sep 30, 2013 at 1:48 PM, Steven Gill stevengil...@gmail.com javascript:; wrote: Hey David, I think this is known and we need to do a plugman release pretty soon. Thanks for reporting this on the list! -Steve On Mon, Sep 30, 2013 at 10:14 AM, David Kemp drk...@chromium.org javascript:; wrote: Summary: Fresh checkout of Cordova-Cli from master results in a cli that will not add a plugin. [Error: Error fetching plugin: TypeError: Cannot call method 'fetch' of undefined] Details: The current Cordova-cli master requires a version of plugman that has not yet been published. Cli requires plugman 0.12.x and that plugman does not expose 'raw'. Cordova-plugman (master) does expose 'raw', but that version has not been published to npm. This will only be an issue if you get a fresh git checkout of cli from master, and don't overwrite the plugman with a fresh checkout as well. It does not affect the version of cli that is published via npm. David Kemp -- Carlos Santana csantan...@gmail.com
Re: CLI tool - Medic testing
Even better, I prefer things like this to be closer to the source/repo On Thursday, October 3, 2013, Andrew Grieve wrote: Might be better in the CLI's README.md On Thu, Oct 3, 2013 at 3:47 PM, Carlos Santana csantan...@gmail.comjavascript:; wrote: Should this info be in the wiki? Very useful, I was using similar approach but ending with same result. On Thursday, October 3, 2013, Braden Shepherdson wrote: Ack, sorry I wasn't around. This is a known problem, and a general one not specific to this release. If you're using master CLI, you need to be linking in master plugman as well. The sequence of commands to get everything working is: git clone https://git-wip-us.apache.org/repos/asf/cordova-plugman.git cd cordova-plugman npm install sudo npm link -g cd .. git clone https://git-wip-us.apache.org/repos/asf/cordova-cli.git cd cordova-cli npm install sudo npm link -g npm link plugman Now your global cordova command is master, and its plugman is master as well. Braden On Mon, Sep 30, 2013 at 1:48 PM, Steven Gill stevengil...@gmail.comjavascript:; javascript:; wrote: Hey David, I think this is known and we need to do a plugman release pretty soon. Thanks for reporting this on the list! -Steve On Mon, Sep 30, 2013 at 10:14 AM, David Kemp drk...@chromium.orgjavascript:; javascript:; wrote: Summary: Fresh checkout of Cordova-Cli from master results in a cli that will not add a plugin. [Error: Error fetching plugin: TypeError: Cannot call method 'fetch' of undefined] Details: The current Cordova-cli master requires a version of plugman that has not yet been published. Cli requires plugman 0.12.x and that plugman does not expose 'raw'. Cordova-plugman (master) does expose 'raw', but that version has not been published to npm. This will only be an issue if you get a fresh git checkout of cli from master, and don't overwrite the plugman with a fresh checkout as well. It does not affect the version of cli that is published via npm. David Kemp -- Carlos Santana csantan...@gmail.com javascript:; -- Carlos Santana csantan...@gmail.com
Re: Plugman Release
I called it cordova-3.1.x because it's about the 3.1.x version of Cordova, the CadVer, not the CLI's own version numbering. We can always make a new branch and drop the old one, if we like. Braden On Tue, Oct 1, 2013 at 3:38 PM, Steven Gill stevengil...@gmail.com wrote: the branch for both CLI and Plugman is called cordova-3.1.x (don't know why we didn't call it 3.1.x instead) On Tue, Oct 1, 2013 at 12:04 PM, Jeffrey Heifetz jheif...@blackberry.com wrote: It seems as though there is no cordova-cli 3.1.x branch, does this mean we always release off of master? There is a bug I found where element tree needs to be bumped to the same version as plugman to support namespace xml elements and I'd like to know where to push this. Thanks, Jeff On 13-10-01 12:17 PM, Steven Gill stevengil...@gmail.com wrote: Firefoxos is broken on master after the refactor. It works fine on the cordova-3.1.x branch though. I am testing jesse's pull requests for CLI + plugman today for cordova-3.1.x branch. If they look good I will merge them in. We should release CLI + Plugman at the same time as 3.1.0. The release should be based off cordova-3.1.x branch and not master. On Oct 1, 2013 7:41 AM, Andrew Grieve agri...@chromium.org wrote: Braden's out doing intern interviews yesterday today, so it's unlikely he'll see this email until tomorrow if not Thursday. We could still do a tools release, but just don't update the platforms.js file to point at 3.1.0. That said, I think I saw Firefox was broken on HEAD? Think we'll want to fix that before doing so. In terms of testing the RC - as Steven said - using cordova@3.0.10 should do the trick On Tue, Oct 1, 2013 at 2:22 AM, Jesse purplecabb...@gmail.com wrote: I have an open pull request I would like someone else to look at. [1] This addresses the issue that Carlos brought up during plugin remove [2] It would be great if this could be part of the release, or at least the commit cherry picked into it. Cheers, Jesse [1] https://github.com/purplecabbage/cordova-plugman/pull/2 [2] https://issues.apache.org/jira/browse/CB-4943 @purplecabbage risingj.com On Mon, Sep 30, 2013 at 4:12 PM, Steven Gill stevengil...@gmail.com wrote: I believe Braden did the same type of release for plugman that he did for cordova cli. He updated both packages on npm but set the latest tag to point to the previous version until we were ready to do our full release. If you install the CLI RC sudo npm install -g cordova@3.0.10, you actually get version 0.12.0 of plugman as a dependency. I will wait for Braden to chime in. I figure the CLI and Plugman should both be released on the same day we release 3.1.0. On Mon, Sep 30, 2013 at 1:39 PM, David Kemp drk...@google.com wrote: +1 to a plugman npm release. David Kemp On Mon, Sep 30, 2013 at 4:34 PM, Steven Gill stevengil...@gmail.com wrote: Anyone see any issue with me doing a npm plugman release today? Testing the CLI RC is kind of weird when the plugman dependency is incompatible. -Steve - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
w3c DAP wg - battery test cases
FYI: https://github.com/w3c/web-platform-tests/tree/master/battery-status Lisa Seacat DeLuca ldel...@apache.org
Cordova versioning
Hi, I'm a NetBeans developer and we are really close to releasing NetBeans 7.4 with support for cordova. NetBeans FCS bits are now ready for testing. NetBeans checks for cordova version and expects version string to be in format number.number.number in hope, that this format marks stable cordova versions. Now I updated to new cordova and it does not work with NetBeans, because version string is 3.1.0-0.1.0 and NetBeans things that it is dev version and refuse to work with it. Is this final state? Is there a way how to install 3.1.0 version? Can I ask to follow versioning scheme and release versions in format number.number.number? Thanks, Jan
Introduction and follow-up questions
Hello, Cordova Devs, I am a software developer at Lab126 @amazon. I am part of HTML5 WebApp Platform team here. As some of you might know, amazon recently introduced FireOS for its KindleFire tablets. For more info please see https://developer.amazon.com/sdk/fireos.html I would like to add FireOS as a platform for Cordova. I have been recently exploring various cordova's git repositories and plug-in mechanism. Based on my initial readings I have some ideas but would like to hear if you guys have any better suggestions. Basically, here is what I am thinking. 1. A new git repo for FireOS which is very similar to cordova-android but with FireOS related changes. Should I create a new one or would a committer do that? 2. For most plug-ins, add amazon as a platform in plugin.xml but point to android sources or create a separate source file if required. 3. Update cordova-cli, to add FireOS platform. 4. Update mobile-spec to run the test suite for FireOS. 5. Update documentation across the repos wherever platform is mentioned. (might need help in finding out places and how to go about it) :) Please let me know what you guys think. Thanks Archana
Re: Introduction and follow-up questions
Hey I'm very unclear as to why it would be similar to cordova-android, since it sounds like FireOS already has support for a lot of what Cordova does. What does the current FireOS WebApp API look like, and how does it compare to Cordova? I thought they were already very similar. Also, would the modifications to cordova-android mean that the WebView would be based on Chromium builds, and not the awful WebKit that's in Cordova by default? Joe On Thu, Oct 3, 2013 at 8:26 AM, Naik, Archana na...@lab126.com wrote: Hello, Cordova Devs, I am a software developer at Lab126 @amazon. I am part of HTML5 WebApp Platform team here. As some of you might know, amazon recently introduced FireOS for its KindleFire tablets. For more info please see https://developer.amazon.com/sdk/fireos.html I would like to add FireOS as a platform for Cordova. I have been recently exploring various cordova's git repositories and plug-in mechanism. Based on my initial readings I have some ideas but would like to hear if you guys have any better suggestions. Basically, here is what I am thinking. 1. A new git repo for FireOS which is very similar to cordova-android but with FireOS related changes. Should I create a new one or would a committer do that? 2. For most plug-ins, add amazon as a platform in plugin.xml but point to android sources or create a separate source file if required. 3. Update cordova-cli, to add FireOS platform. 4. Update mobile-spec to run the test suite for FireOS. 5. Update documentation across the repos wherever platform is mentioned. (might need help in finding out places and how to go about it) :) Please let me know what you guys think. Thanks Archana
Re: Cordova versioning
Jan, This project has two different versioning strategies for the various pieces: Cadence versioning (ie, 3.1.0 for end of Sept 2013) and Semantic versioning (ie, major.minor.point), and for 3.1 release the CLI uses a combination of both! Please take a look at http://wiki.apache.org/cordova/VersioningAndReleaseStrategy for more information on this. I'm not sure how likely we are to change the versioning scheme again, since there have been a few hiccups as we move to a more SemVer friendly scheme, but at the moment I would suggest supporting the new style of version number for CLI (i.e. CAD-SEM, a.b.c-x.y.z). -Michal On Thu, Oct 3, 2013 at 11:18 AM, Jan Becicka jan.beci...@oracle.com wrote: Hi, I'm a NetBeans developer and we are really close to releasing NetBeans 7.4 with support for cordova. NetBeans FCS bits are now ready for testing. NetBeans checks for cordova version and expects version string to be in format number.number.number in hope, that this format marks stable cordova versions. Now I updated to new cordova and it does not work with NetBeans, because version string is 3.1.0-0.1.0 and NetBeans things that it is dev version and refuse to work with it. Is this final state? Is there a way how to install 3.1.0 version? Can I ask to follow versioning scheme and release versions in format number.number.number? Thanks, Jan
Re: Mapping plugin ID - URL
I think plugman is trying to do more than it should. We should look into something like bower to handle dependencies and fetching them to a local folder for a project. Bower can be use by user via cli and plugman can use it as a node library. Bower handles the download of packages/repo with it's versions/tags to a local folder. I see a cordova plugin be analogous and not that different from a package. Then plugman uses a local folder (bower_components, cordova_components, or what ever name) to install plugins from that folder. Cache only solved the problem of network usage, it doesn't solve portability of a project/repo. I'm out on vacation but wanted to bring up Bower for front-end dependencies. We can leverage their lessons learned or their code and we don't have to re-invent the wheel. TLDR: I vote for plugman to have an option for install command to skip the registry and use local folder already populated with a set of plugins. -- Carlos On Thursday, October 3, 2013, Michal Mocny wrote: On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny mmo...@chromium.orgjavascript:; wrote: On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI anis.ka...@gmail.comjavascript:; wrote: Braden and I have talked about it in the past but there is already a $HOME/.plugman/cache and plugman will not attempt to fetch plugins if they are already in the cache. Unless I am missing something can you just not drop your dependencies in there? This sounds like it would work, but I'm hesitant to force a global installation of the cache. I think it would mean you cannot develop BB webworks apps on the same machine as you develop vanilla cordova apps since the same plugin id would map to different places across *all* plugman using projects. Note that it already has been a source of problems to have things needlessly added to ~/.cordova and ~/.plugman. Thinking about this more, I think using the global cache is subtly different than what we want here. However, I think we could perhaps leverage the concept and share most of the code. Here is the big difference: - The global plugman cache is used *after* going out to registry to lookup latest version, so as not to download the same plugin version multiple times. - This proposed local search path is to be used *before* going out to registry, without caring about its content or version number. Perhaps the current behaviour can be decomposed into two steps: (1) update global cache with newest plugin version via registry and (2) install plugin from cache. Then, installing a plugin by ID could be: - Attempt Step (2) from local search path(s) - then, if above failed, do Step (1) - then, if above succeeded, Attempt Step (2) from global cache How does that sound? Are there other use cases than simply 'not fetching from registry and using local path' for a given plugin ID ? I think this is the only use case we are looking to solve, but it shows up in different situations: during cordova plugin add ID or plugman --install with dependancy etc. #1 and #2 can be solutions to some problems but do we have those problems yet ? They can be a solution to managing multiple registry sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...) because right now we only support. Yes, we already do have these problems, as said: IBM, BB, and to some extent Mobile-Chrome-Apps is already needing this solution. Implementing a new registry would be fine, if it worked offline for local-only installs, preferably without the need to set up a server/couchdb for such simple local only mappings, which is exactly Andrews proposal. Your proposed changes also seem to only affect CLI since you mentioned a .cordova/config.json. plugman only users would potentially be penalized once again. I completely agree this is implemented in plugman. We are discussing CLI just to establish the convention for how to store the cache, but plugman would have all the underlying functionality. It *has* to be this way, since its the one that resolves dependencies, and will need a new argument alongside --install to know where to lookup id for local mapping. On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny mmo...@chromium.org wrote: I think the missing piece is that the plugin author has the option of specifying dependencies in terms exactly *one* of these options: (a) id, to be looked up in the registry (b) explicit git url (c) relative path The problem is that a downstream *distributor* cannot override these values at the moment, without making direct edits to the plugin.xml. e.g. IBM and BlackBerry have already both spoken up about the problem of shipping a cordova based tool with plugins bundled, and having full control over plugin versions, supporting offline work, etc. How can we solve the generic case of using the CLI with the
Re: Introduction and follow-up questions
Often how new platforms go, is that you should just make your own git repo for it, and then we can look at copying it into a sanctioned apache repo once some initial progress is made. One thing I think it would be important to consider though, is how close FireOS will be to Android. E.g., would it be at all possible to install a plugin written for android onto FireOS? On Thu, Oct 3, 2013 at 4:26 PM, Naik, Archana na...@lab126.com wrote: Hello, Cordova Devs, I am a software developer at Lab126 @amazon. I am part of HTML5 WebApp Platform team here. As some of you might know, amazon recently introduced FireOS for its KindleFire tablets. For more info please see https://developer.amazon.com/sdk/fireos.html I would like to add FireOS as a platform for Cordova. I have been recently exploring various cordova's git repositories and plug-in mechanism. Based on my initial readings I have some ideas but would like to hear if you guys have any better suggestions. Basically, here is what I am thinking. 1. A new git repo for FireOS which is very similar to cordova-android but with FireOS related changes. Should I create a new one or would a committer do that? 2. For most plug-ins, add amazon as a platform in plugin.xml but point to android sources or create a separate source file if required. 3. Update cordova-cli, to add FireOS platform. 4. Update mobile-spec to run the test suite for FireOS. 5. Update documentation across the repos wherever platform is mentioned. (might need help in finding out places and how to go about it) :) Please let me know what you guys think. Thanks Archana
cordova emulate ios not working
Hi Guys, I upgraded to 3.1.0 and cordova emulate ios no longer works. I filed report https://issues.apache.org/jira/browse/CB-4990. Cheers, Mike
Re: cordova emulate ios not working
what does ios-sim --version show for you? On Thu, Oct 3, 2013 at 11:46 AM, Michael Gauthier m...@silverorange.comwrote: Hi Guys, I upgraded to 3.1.0 and cordova emulate ios no longer works. I filed report https://issues.apache.org/**jira/browse/CB-4990https://issues.apache.org/jira/browse/CB-4990 . Cheers, Mike
Re: cordova emulate ios not working
$ ios-sim --version 1.8.2 On 2013-10-03 15:59, Shazron wrote: what does ios-sim --version show for you? On Thu, Oct 3, 2013 at 11:46 AM, Michael Gauthier m...@silverorange.comwrote: Hi Guys, I upgraded to 3.1.0 and cordova emulate ios no longer works. I filed report https://issues.apache.org/**jira/browse/CB-4990https://issues.apache.org/jira/browse/CB-4990 . Cheers, Mike
Re: PSA: watch for stipped [CB-####] from patch subject line when using git am
I never used brackets so I guess I don't have to change anything :-) On Thu, Oct 3, 2013 at 3:35 AM, Andrew Grieve agri...@chromium.org wrote: That applies to cordova-js only, and I think it's a nice-to-have. If it's left out, it just means I need to open the diff to see what's changed. If it's there though, I don't need to. On Wed, Oct 2, 2013 at 10:47 PM, Marcel Kinard cmarc...@gmail.com wrote: ContributorWorkflow and CommitterWorkflow wiki pages updated. I noticed the following verbage in CommitterWorkflow: • Prefix the message with the affected_platform so that it's clear who should take interest in the commit • e.g.: CB-1234 android: Improved exec bridge by using strings instead of JSON • e.g.: CB-1234 all: Fixed plugin loading paths that start with /. Should that verbage stay in? I don't think we do that consistently. On Oct 2, 2013, at 3:29 PM, Andrew Grieve agri...@chromium.org wrote: +1 On Wed, Oct 2, 2013 at 8:17 PM, Marcel Kinard cmarc...@gmail.com wrote: So new format should be: CB-1234 Fixed the RockOn widget Correct?
Re: chrome dev summit
I'd like to go too! On Thu, Oct 3, 2013 at 6:07 PM, Shazron shaz...@gmail.com wrote: I wouldn't mind dropping by. On Thu, Oct 3, 2013 at 1:29 AM, Brian LeRoux b...@brian.io wrote: anyone here going? http://developer.chrome.com/devsummit
Re: Mapping plugin ID - URL
@Michal SGTM. The original approach has some other benefits on top of the current requirements. However, I don't know if we need those benefits just yet. On Thu, Oct 3, 2013 at 6:06 PM, Carlos Santana csantan...@gmail.com wrote: I think plugman is trying to do more than it should. We should look into something like bower to handle dependencies and fetching them to a local folder for a project. Bower can be use by user via cli and plugman can use it as a node library. Bower handles the download of packages/repo with it's versions/tags to a local folder. I see a cordova plugin be analogous and not that different from a package. Then plugman uses a local folder (bower_components, cordova_components, or what ever name) to install plugins from that folder. Cache only solved the problem of network usage, it doesn't solve portability of a project/repo. I'm out on vacation but wanted to bring up Bower for front-end dependencies. We can leverage their lessons learned or their code and we don't have to re-invent the wheel. TLDR: I vote for plugman to have an option for install command to skip the registry and use local folder already populated with a set of plugins. -- Carlos On Thursday, October 3, 2013, Michal Mocny wrote: On Wed, Oct 2, 2013 at 3:09 PM, Michal Mocny mmo...@chromium.orgjavascript:; wrote: On Wed, Oct 2, 2013 at 2:49 PM, Anis KADRI anis.ka...@gmail.comjavascript:; wrote: Braden and I have talked about it in the past but there is already a $HOME/.plugman/cache and plugman will not attempt to fetch plugins if they are already in the cache. Unless I am missing something can you just not drop your dependencies in there? This sounds like it would work, but I'm hesitant to force a global installation of the cache. I think it would mean you cannot develop BB webworks apps on the same machine as you develop vanilla cordova apps since the same plugin id would map to different places across *all* plugman using projects. Note that it already has been a source of problems to have things needlessly added to ~/.cordova and ~/.plugman. Thinking about this more, I think using the global cache is subtly different than what we want here. However, I think we could perhaps leverage the concept and share most of the code. Here is the big difference: - The global plugman cache is used *after* going out to registry to lookup latest version, so as not to download the same plugin version multiple times. - This proposed local search path is to be used *before* going out to registry, without caring about its content or version number. Perhaps the current behaviour can be decomposed into two steps: (1) update global cache with newest plugin version via registry and (2) install plugin from cache. Then, installing a plugin by ID could be: - Attempt Step (2) from local search path(s) - then, if above failed, do Step (1) - then, if above succeeded, Attempt Step (2) from global cache How does that sound? Are there other use cases than simply 'not fetching from registry and using local path' for a given plugin ID ? I think this is the only use case we are looking to solve, but it shows up in different situations: during cordova plugin add ID or plugman --install with dependancy etc. #1 and #2 can be solutions to some problems but do we have those problems yet ? They can be a solution to managing multiple registry sources for example (Cordova, PhoneGap, WorkLight, BlackBerry, ...) because right now we only support. Yes, we already do have these problems, as said: IBM, BB, and to some extent Mobile-Chrome-Apps is already needing this solution. Implementing a new registry would be fine, if it worked offline for local-only installs, preferably without the need to set up a server/couchdb for such simple local only mappings, which is exactly Andrews proposal. Your proposed changes also seem to only affect CLI since you mentioned a .cordova/config.json. plugman only users would potentially be penalized once again. I completely agree this is implemented in plugman. We are discussing CLI just to establish the convention for how to store the cache, but plugman would have all the underlying functionality. It *has* to be this way, since its the one that resolves dependencies, and will need a new argument alongside --install to know where to lookup id for local mapping. On Wed, Oct 2, 2013 at 8:57 AM, Michal Mocny mmo...@chromium.org wrote: I think the missing piece is that the plugin author has the option of specifying dependencies in terms exactly *one* of these options: (a) id, to be looked up in the registry (b) explicit git url (c) relative path The problem is that a downstream *distributor* cannot override these values at the moment, without making direct edits to the plugin.xml. e.g. IBM and BlackBerry have
Re: Updating plugin code on prepare
+1! On Thu, Oct 3, 2013 at 4:30 PM, Michal Mocny mmo...@chromium.org wrote: Yeah Braden we've diverged sorry, lets focus. Big +1 for your proposal to make prepare step do what users expect. -Michal On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson bra...@chromium.orgwrote: I agree that the syncing solutions are too complex and confusing. I return, then, to my original proposal all those emails ago: updating the native plugin files in platforms/foo when you prepare, to make life easier for plugin developers. When coupled with the present cordova plugin add --link, and future cordova watch, I think this makes the plugin developer flow pretty good, and without making it too magical or harder to understand. I think it simplifies prepare: on prepare, your native projects are updated to reflect the state of plugins/ and www/. Right now, only www/, assets and js-modules get updated, but not native code. As to Xcode and symlinks and all the rest of the borderline thread hijacking, I think that regardless of what editor you use, you have to be editing the right file. Xcode and Eclipse make this harder than it needs to be, but our job is not to make them suck less. Braden On Sun, Sep 29, 2013 at 1:43 PM, Carlos Santana csantan...@gmail.com wrote: +1 Anis corodova-cli/plugman should be building block components to higher level Tools/IDE. That we can do better sure, lets provide a few examples using blog pots and maybe videos tutorials vs. trying to support every use case with code. A watch function could be as simple as using grunt-contrib-watch to a more complicated environment like rsync/Eclipse I agree lets put emphasis on documenting use cases and the correct approach. When to get the best out of using prepare, merges, and hooks All I said applies when you have the Web Developer hat. For people that have the Native Plugin Developer hat then we can do things first for cordova-contributors than others can choose to use on their own risk since it could be changing too fast and maybe too narrow use case. --Carlos --Carlos On Sun, Sep 29, 2013 at 9:18 AM, Anis KADRI anis.ka...@gmail.com wrote: I gave some thought to this problem and I think we should just leave everything as is. Here's my reasoning: - Most web developers use a text editor (vim, sublime text, text mate, notepad++, ) to edit their HTML/CSS/Javascript. I've never seen anyone use a fully fledged IDE to edit web assets. It would be like using Microsoft Word to edit a simple .TXT or .MD file - Other developers, people who write Java or Objective C, etc.. use Xcode, Eclipse, IntelliJ, ...and I think these people are not good candidates for cordova-cli. The original PhoneGap promise (now Apache Cordova) was to make it easy for Web Developers to write Mobile Apps using web technologies and I believe that promise is fulfilled with cordova-cli. You have a folder where you drop in your web assets and you can build/deploy to a device or simulate. If people want to use an IDE, then they should be creating native projects with our create scripts and use plugman to manage their plugins. Our documentation should point our users to the right approach depending on the use case. For example: - Building for only one platform ? Building a hybrid app ? Want to use an IDE (Eclipse, Xcode) ? You should use the create scripts and plugman to manage plugins - Building a cross-platform app ? Like managing your project from the command-line ? Want to use your favo(u)rite text editor ? Use cordova-cli These double symlinking, backsyncing solutions will be a source of confusion and issues in my humble opinion. I've said it before but sometimes by trying to please everyone you end up pleasing no one. my .02c -a On Fri, Sep 27, 2013 at 8:20 PM, Michal Mocny mmo...@chromium.org wrote: On Fri, Sep 27, 2013 at 2:10 PM, Andrew Grieve agri...@chromium.org wrote: Just tried some symlinks in Xcode 5: - Copying assets work (due to our custom build step) - Building works (compiler follows links just fine) - Editing a fail (big fail. Files open but changes cannot be saved.) Hmm, changes via xcode to symlinks fail, you mean? That would be hard to fix, but perhaps at least its feedback to the user not to make direct edits there, when using CLI workflow ;) so may still be a valid change to make. For Xcode though, it is an option to change our installation step to have Xcode reference the native files within plugins/ rather than within platforms/. Symlinks in Eclipse: - Copying assets works out-of-the-box - Build works fine - Editing seems to work fine (edits saved to symlinked location). Still though, maybe the best solution would be a combination of
TestFlight plugin
I am sorry, this message may be better sent directly to shazron, but I thought others might be interested too. I just built up a new Cordova 3.1.0 project, installed the device, console, splash screen, testflight and my own plugin. They all installed in a way that I did not have to add any script include tags in my html - they are part of the cordova_plugins.js. All except the test flight plugin. That one I had to add the plugins/testflight.js. Perhaps shazron can add the magic to the plugin.xml needed to get it installed automatically? Looks to me through a simple compare it is the js-module element that is needed (it has the clobbers element that is in the cordova_plugins.js file. The plugin is working great besides that little niggle BTW. Thanks, Tyler
Re: TestFlight plugin
Thanks. This doesn't belong here in this list. And I already added an issue in my repo earlier today to do just so. File issues in the repo, they get to me. On Thursday, October 3, 2013, Tyler Wilson wrote: I am sorry, this message may be better sent directly to shazron, but I thought others might be interested too. I just built up a new Cordova 3.1.0 project, installed the device, console, splash screen, testflight and my own plugin. They all installed in a way that I did not have to add any script include tags in my html - they are part of the cordova_plugins.js. All except the test flight plugin. That one I had to add the plugins/testflight.js. Perhaps shazron can add the magic to the plugin.xml needed to get it installed automatically? Looks to me through a simple compare it is the js-module element that is needed (it has the clobbers element that is in the cordova_plugins.js file. The plugin is working great besides that little niggle BTW. Thanks, Tyler
