getting the platforms passed as well as other options in a hook
All: Curious what you thought of this. We have a situation where we would want to know the platforms being built and other arguments being passed, in the hooks. See any reason why this shouldn't be integrated ? If not I'm going to look into adding this. mw
Re: Serve vs. opening an HTML file in the browser
This is how we are using itŠ as a local server for remote devices to then attach for example chrome remote debugging. mw On 8/6/13 10:20 AM, Michal Mocny mmo...@chromium.org wrote: file:// urls come with a lot of restrictions in chrome in desktop, but that isn't the intended use case anyway. The intended purpose was to load the web assets from a mobile device instead of loading the bundled versions, so as to get rapid edit-refresh when not making changes to native bits. As Andrew points out 'serve' command will 'prepare' whenever necessary (grunt watch?) and also serve up files via local web server. The simple local alternative may be to just use your own local web server from the top level www/ dir, thus avoiding the need to prepare -- but it only works if and only if you do not use merges/, and none of your plugins have web assets (js-modules are fine I think?), which is not usually the situation. -Michal On Tue, Aug 6, 2013 at 9:53 AM, Andrew Grieve agri...@chromium.org wrote: One of the original motivations for cordova serve was for it to watch for changes and automatically run prepare for you. I don't think this is working right now though. On Fri, Aug 2, 2013 at 4:23 PM, Anis KADRI anis.ka...@gmail.com wrote: XHRs won't work by default on certain browsers such as Chrome. I don't think there are any other benefits. This restriction does not exist on a device. On Fri, Aug 2, 2013 at 1:13 PM, John M. Wargo jwarg...@gmail.com wrote: Can someone help me understand why I would want to use cordova serve rather than just loading the web content in the browser directly (through File - Open for example)? Is there something special that serve does that makes this approach better?
any one going to //build
Any folks going to be at the //build conference in sf next week, hit me up and lets grab a drink or 2. mw
Re: New directory structure in cordova-cli's future branch
dependancies, such that you could distill workflow #1 down to: cordova create Foo cd Foo cordova app add git-repo .. and it would run the plugin/platform add automatically. Can even get that down to a single cordova create git-repo line. That would make sharing apps, such as mobile-spec-test, really trivial. -Michal On Tue, Apr 16, 2013 at 9:19 AM, Andrew Grieve agri...@chromium.orgwrote: So, reading through the thread Braden linked to: http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html There are two advantage that were brought up: 1. config.xml (configuration) does not live along side of app resources 2. It will make it easier to package apps - E.g. zip the app/ directory and install it into the app-harness (instead of zipping www + merges). Likewise for phonegap build. - E.g. cordova-mobile-spec would contain the contents of app/. With our current setup, it would contain www/ merges/, and have the CLI place build artifacts within the repo's directory instead of as a sibling to it. I think everyone acknowledged the benefits, but there was still not consensus over whether it was worth it. I don't really feel strongly about it. Braden says it's easy to change code-wise. Does anyone want to go to bat for it? On Mon, Apr 15, 2013 at 6:59 PM, Brian LeRoux b...@brian.io wrote: I'd rather we did not go ahead w/ the new directory structure. It offers no functional benefit, and comes at an upgrade cost for ppl using the CLI tools today. On Mon, Apr 15, 2013 at 12:46 PM, Andrew Grieve agri...@chromium.org wrote: Just catching up on the past week of emails and it's not clear that there was a consensus here. By the sounds of it though: 1. Lots of users are using Cordova-CLI (master branch) 2. Cordova-CLI's future branch has non-backwards-compatible changes. 3. One of these changes is the directory structure. The main debate is on how to message these changes to users. What we should do is: 1. Have an upgrade guide. (e.g. paths are now relative to plugin.xml) 2. Ensure that our error handling shows useful messages when they result from an old-way-of-doing-things (e.g. your app's structure doesn't match.) Rather than printing out the commands to run to convert their project, maybe we could have them in the upgrade guide and have the error messages point to the guide? On Wed, Apr 10, 2013 at 5:47 PM, Tim Kim timki...@gmail.com wrote: Braden I have merged master and the future branch: https://github.com/timkim/plugman/tree/future_master_merge I think it's about ready to merge back in to future. I've gotten the android-one-install and the ios-config-xml-install (minus one weird test I don't understand) working. On 10 April 2013 14:42, Anis KADRI anis.ka...@gmail.com wrote: As far as I am concerned I don't really have a strong opinion on this topic. As I said in the previous thread, I do like this new directory structure and if you have it there and tested then fine. We break shit all the time it's not like this change is one too many. What matters is to communicate it to our users and give them an upgrade path to this new app structure (the Cordova docs are a good place for that). However, I agree with Brian that there are more important things to tackle right now. Now sure what you had on your list but since js only modules are in Plugman right now (untested) The next big thing that is going to be non-trivial is: plugin dependencies (which will in some ways involve discovery I think). We should have a discussion about that (hangout, IRC, connect...whatever). I have a couple of ideas about that. Tim is working on fixing/adding/updating plugman tests and it looks like he's making good progress on it. -a On Wed, Apr 10, 2013 at 11:53 AM, Michael Wolf michael.w...@cynergy.com wrote: +1 I get the intention, however anything we can do to reduce this type of breaking change should be done. These type of changes should be considered for major releases only so users can plan for them. mw On 4/9/13 5:05 PM, Jesse purplecabb...@gmail.com wrote: +1 to the sanity plea of devgeek Tommy Also, if it didn't happen on this list
Re: New directory structure in cordova-cli's future branch
the benefits, but there was still not consensus over whether it was worth it. I don't really feel strongly about it. Braden says it's easy to change code-wise. Does anyone want to go to bat for it? On Mon, Apr 15, 2013 at 6:59 PM, Brian LeRoux b...@brian.io wrote: I'd rather we did not go ahead w/ the new directory structure. It offers no functional benefit, and comes at an upgrade cost for ppl using the CLI tools today. On Mon, Apr 15, 2013 at 12:46 PM, Andrew Grieve agri...@chromium.org wrote: Just catching up on the past week of emails and it's not clear that there was a consensus here. By the sounds of it though: 1. Lots of users are using Cordova-CLI (master branch) 2. Cordova-CLI's future branch has non-backwards-compatible changes. 3. One of these changes is the directory structure. The main debate is on how to message these changes to users. What we should do is: 1. Have an upgrade guide. (e.g. paths are now relative to plugin.xml) 2. Ensure that our error handling shows useful messages when they result from an old-way-of-doing-things (e.g. your app's structure doesn't match.) Rather than printing out the commands to run to convert their project, maybe we could have them in the upgrade guide and have the error messages point to the guide? On Wed, Apr 10, 2013 at 5:47 PM, Tim Kim timki...@gmail.com wrote: Braden I have merged master and the future branch: https://github.com/timkim/plugman/tree/future_master_merge I think it's about ready to merge back in to future. I've gotten the android-one-install and the ios-config-xml-install (minus one weird test I don't understand) working. On 10 April 2013 14:42, Anis KADRI anis.ka...@gmail.com wrote: As far as I am concerned I don't really have a strong opinion on this topic. As I said in the previous thread, I do like this new directory structure and if you have it there and tested then fine. We break shit all the time it's not like this change is one too many. What matters is to communicate it to our users and give them an upgrade path to this new app structure (the Cordova docs are a good place for that). However, I agree with Brian that there are more important things to tackle right now. Now sure what you had on your list but since js only modules are in Plugman right now (untested) The next big thing that is going to be non-trivial is: plugin dependencies (which will in some ways involve discovery I think). We should have a discussion about that (hangout, IRC, connect...whatever). I have a couple of ideas about that. Tim is working on fixing/adding/updating plugman tests and it looks like he's making good progress on it. -a On Wed, Apr 10, 2013 at 11:53 AM, Michael Wolf michael.w...@cynergy.com wrote: +1 I get the intention, however anything we can do to reduce this type of breaking change should be done. These type of changes should be considered for major releases only so users can plan for them. mw On 4/9/13 5:05 PM, Jesse purplecabb...@gmail.com wrote: +1 to the sanity plea of devgeek Tommy Also, if it didn't happen on this list, 'Consensus' should always be tracked back to a thread here, regardless of meetings, hangouts, irc, bbs, ... @purplecabbage risingj.com On Tue, Apr 9, 2013 at 1:48 PM, tommy-carlos Williams to...@devgeeks.orgwrote: Sorry, but as someone that helps users everyday, the almost it's alpha, they shoulda seen it coming tone of this is a bit upsetting. It reminds me of before the deprecation policy, etc when PhoneGap would completely break everything whenever a new version came out. I feel like we have come a long way since then (with a ways still to go, no question about it). I would hate to be the one in IRC and on the Google Group list having to explain this to everyone using the cli. I was under the impression that the cli was shipping now, not just
Re: [Android] The Deprecation of Froyo
Generally we are pushing clients to not touch anything lower than 2.3 (And having serious discussions about their need for 2.3 support). So from a cordova users perspective this wouldn't bother me. mw On 4/10/13 2:10 PM, Joe Bowser bows...@gmail.com wrote: Android 2.2 is a pain point because we only have one device in the Vancouver office that is on that version of Android (LG Optimus 3D). I'm sure that other places have more of them, but they are becoming increasingly rare, and I'd rather us only have to test 2.3 and higher when we prepare for a release. On Wed, Apr 10, 2013 at 10:54 AM, Braden Shepherdson bra...@chromium.org wrote: Do we have a picture of what this would gain us? What are the pain points in terms of bugs or missing APIs between 2.2 and 2.3? I have the vague impression that there are several things, but I actually don't know. If there are advantages, I'm all for it. Braden On Wed, Apr 10, 2013 at 1:49 PM, Joe Bowser bows...@gmail.com wrote: Hey Good news everyone! Android 2.2 (Froyo) has dipped below 5%. This means that we can safely drop support for this version of Android and set our lower bound to Android 2.3. The cool thing about this is that we will only support devices that you can actually buy in a store at this point, which I think is something that we should aim towards. Honestly, if Key Lime Pie figured out a way to get 4.x functionality on single-core devices, that'd be awesome, but I highly doubt it. :( So, what do people think about getting rid of Froyo support? Joe
Re: New directory structure in cordova-cli's future branch
+1 I get the intention, however anything we can do to reduce this type of breaking change should be done. These type of changes should be considered for major releases only so users can plan for them. mw On 4/9/13 5:05 PM, Jesse purplecabb...@gmail.com wrote: +1 to the sanity plea of devgeek Tommy Also, if it didn't happen on this list, 'Consensus' should always be tracked back to a thread here, regardless of meetings, hangouts, irc, bbs, ... @purplecabbage risingj.com On Tue, Apr 9, 2013 at 1:48 PM, tommy-carlos Williams to...@devgeeks.orgwrote: Sorry, but as someone that helps users everyday, the almost it's alpha, they shoulda seen it coming tone of this is a bit upsetting. It reminds me of before the deprecation policy, etc when PhoneGap would completely break everything whenever a new version came out. I feel like we have come a long way since then (with a ways still to go, no question about it). I would hate to be the one in IRC and on the Google Group list having to explain this to everyone using the cli. I was under the impression that the cli was shipping now, not just a little side thing. I know that quite a few people are using it for real apps (myself included). If that is true, then we have a duty to at least think very carefully before breaking something and come up with a good plan for easing that transition. - tommy On 10/04/2013, at 1:40, Braden Shepherdson bra...@chromium.org wrote: This mailing list post is, or will shortly be, indexed by Google and others. Any newcomers will see the new docs and create new projects. As I mentioned on IRC, existing users are either accepting or ignoring the alpha warnings that this software is new and under heavy development, and if they want to jump on it early they're going to have to expect some pain. That said, I don't really know of any better way to socialize it. Is there anywhere where a brief blog post on this would make sense? I don't know how many people are using these tools and not on the mailing list, though certainly some turn up on IRC occasionally. Braden On Tue, Apr 9, 2013 at 11:24 AM, Filip Maj f...@adobe.com wrote: How will we communicate this change to our existing users? On 4/9/13 5:22 PM, Braden Shepherdson bra...@chromium.org wrote: I've just pushed a change to the future branch that changes the directory structure to: app/ merges/ android/ ios/ www/ config.xml As was discussed at our video conference meeting a couple of weeks ago, this has a number of advantages: - config.xml is no longer in the www/ directory - One can easily version control the whole app/ directory, and get their web assets, merges and so on into the repo. - That repo can contain additional information: a README.md, supplementary documentation, tests, whatever. The CLI will ignore anything outside of the merges and www directories. The downside is that this is a breaking change: running the new version of the tools on an old project will fail (but I think in a harmless way) until you rearrange the directories. You can do that with the following commands: $ mkdir app $ mv www/config.xml app $ mv www app $ mv merges app All docs and tests are updated as well. Any problems should be reported on JIRA and assigned to me. Braden
Re: [Android] The Deprecation of Froyo
Fwiw I wasn't saying 2.3, but 2.2. The consideration of supporting 2.3 goes based on who your consumer base is, and if 2.3 is worth it (had several customers recently where this is a serious discussion). AnywhoŠ loosing 2.2 I don't think would hurt the community greatly. mw On 4/10/13 2:54 PM, Joe Bowser bows...@gmail.com wrote: Anyone who thinks we don't need 2.3 support needs to look at what I was considering purchasing for my US phone when on road trips to weird places like Idaho: http://www.verizonwireless.com/b2c/prepay/getPhoneDetail.do?item=prepayIte mselectedPhoneId=6093selectedPlanCatId=4997 On Wed, Apr 10, 2013 at 11:51 AM, Michael Wolf michael.w...@cynergy.com wrote: Generally we are pushing clients to not touch anything lower than 2.3 (And having serious discussions about their need for 2.3 support). So from a cordova users perspective this wouldn't bother me. mw On 4/10/13 2:10 PM, Joe Bowser bows...@gmail.com wrote: Android 2.2 is a pain point because we only have one device in the Vancouver office that is on that version of Android (LG Optimus 3D). I'm sure that other places have more of them, but they are becoming increasingly rare, and I'd rather us only have to test 2.3 and higher when we prepare for a release. On Wed, Apr 10, 2013 at 10:54 AM, Braden Shepherdson bra...@chromium.org wrote: Do we have a picture of what this would gain us? What are the pain points in terms of bugs or missing APIs between 2.2 and 2.3? I have the vague impression that there are several things, but I actually don't know. If there are advantages, I'm all for it. Braden On Wed, Apr 10, 2013 at 1:49 PM, Joe Bowser bows...@gmail.com wrote: Hey Good news everyone! Android 2.2 (Froyo) has dipped below 5%. This means that we can safely drop support for this version of Android and set our lower bound to Android 2.3. The cool thing about this is that we will only support devices that you can actually buy in a store at this point, which I think is something that we should aim towards. Honestly, if Key Lime Pie figured out a way to get 4.x functionality on single-core devices, that'd be awesome, but I highly doubt it. :( So, what do people think about getting rid of Froyo support? Joe
Re: [cordova-cli] windows phone 8, firefox os, webos are at a disadvantage
Looks like your lacking tests in both the metadata as well as places like platform (https://github.com/bennmapes/cordova-cli/blob/windows2/spec/platform.spec. js) etc Happy to give your changes a whirl, but are you planning on contributing tests? Particularly in that https://github.com/bennmapes/cordova-cli/blob/windows2/src/metadata/wp8_par ser.js needs to do the fun stuff of updating the proj file , which would easily go screwy. mw On 4/10/13 4:46 PM, Benn Mapes benn.ma...@gmail.com wrote: I well the pull request is still there and I have 2 branches with the windows phone support, the old one: https://github.com/bennmapes/cordova-cli/tree/windows And the updated one with the latest cli changes (2.6.0) https://github.com/bennmapes/cordova-cli/tree/windows2 The only thing that needs to happen is for people to start using it and submitting issues. If we're not going to pull out the the platforms in /lib and add them dynamically then I see no reason to hold off pulling this in. On Wed, Apr 10, 2013 at 12:08 PM, Michael Wolf michael.w...@cynergy.comwrote: Benn: Looking for any help here ? Really looking for the wp8 cli to come in so we can drop our own sad little wp8 scripts. Hit me up directly if your looking for a hand/eye. mw On 3/22/13 6:06 PM, Filip Maj f...@adobe.com wrote: Sweet. Don't forget tests :) On 3/22/13 3:02 PM, Benn Mapes benn.ma...@gmail.com wrote: I have added support for wp7 + wp8 on this branch and made a pull request to cordova-cli but I think it would be best to hold off merging it in until we decide what to do with the lib folder (i.e dynamically load platforms when we call `cordova platform add foo` for the first time). https://github.com/bennmapes/cordova-cli/tree/windows Just woking on the update_config function in the wp*_parser so that you can change the name/id from the config.xml On Fri, Mar 22, 2013 at 10:58 AM, Brian LeRoux b...@brian.io wrote: None have support currently in the CLI tools. - Herm is pursuing platform level scripts so support for FxOS can happen. - Mapes is doing the same in Windows land. Both cases we could use some help. If any on this list care about those platforms and would like to pitch in this is the thread to introduce yourself.
Re: [cordova-cli] windows phone 8, firefox os, webos are at a disadvantage
OK hit me up directly when its updated I can help make the some of the initial tests to review w/ you. Id really like to see this get into 2.7 so happy to help see this happen. mw On 4/10/13 5:15 PM, Benn Mapes benn.ma...@gmail.com wrote: Oops, just realized that the wp8_parser didn't get updated with the latest push to those branches. It should look like the wp7_parser since they are virtually identical. I'll fix that tonight and clean it up a bit. ~Benn On Wed, Apr 10, 2013 at 2:08 PM, Benn Mapes benn.ma...@gmail.com wrote: As for the test I'll try and get to those hopefully before 2.7.0, maybe you can help me out a bit on those ones. I've been working mostly on the scripting for windows and now for android. On Wed, Apr 10, 2013 at 2:06 PM, Benn Mapes benn.ma...@gmail.com wrote: For the .csproj file you can just use Content Include=www\** / to include all the files in the www folder. I used to have it adding each file individually like Content Include=www\file\name.x / but using the wildcard works the same way. On Wed, Apr 10, 2013 at 2:01 PM, Michael Wolf michael.w...@cynergy.comwrote: Looks like your lacking tests in both the metadata as well as places like platform ( https://github.com/bennmapes/cordova-cli/blob/windows2/spec/platform.sp ec. jshttps://github.com/bennmapes/cordova-cli/blob/windows2/spec/platform .spec.js) etc Happy to give your changes a whirl, but are you planning on contributing tests? Particularly in that https://github.com/bennmapes/cordova-cli/blob/windows2/src/metadata/wp8 _par ser.jshttps://github.com/bennmapes/cordova-cli/blob/windows2/src/metad ata/wp8_parser.jsneeds to do the fun stuff of updating the proj file , which would easily go screwy. mw On 4/10/13 4:46 PM, Benn Mapes benn.ma...@gmail.com wrote: I well the pull request is still there and I have 2 branches with the windows phone support, the old one: https://github.com/bennmapes/cordova-cli/tree/windows And the updated one with the latest cli changes (2.6.0) https://github.com/bennmapes/cordova-cli/tree/windows2 The only thing that needs to happen is for people to start using it and submitting issues. If we're not going to pull out the the platforms in /lib and add them dynamically then I see no reason to hold off pulling this in. On Wed, Apr 10, 2013 at 12:08 PM, Michael Wolf michael.w...@cynergy.comwrote: Benn: Looking for any help here ? Really looking for the wp8 cli to come in so we can drop our own sad little wp8 scripts. Hit me up directly if your looking for a hand/eye. mw On 3/22/13 6:06 PM, Filip Maj f...@adobe.com wrote: Sweet. Don't forget tests :) On 3/22/13 3:02 PM, Benn Mapes benn.ma...@gmail.com wrote: I have added support for wp7 + wp8 on this branch and made a pull request to cordova-cli but I think it would be best to hold off merging it in until we decide what to do with the lib folder (i.e dynamically load platforms when we call `cordova platform add foo` for the first time). https://github.com/bennmapes/cordova-cli/tree/windows Just woking on the update_config function in the wp*_parser so that you can change the name/id from the config.xml On Fri, Mar 22, 2013 at 10:58 AM, Brian LeRoux b...@brian.io wrote: None have support currently in the CLI tools. - Herm is pursuing platform level scripts so support for FxOS can happen. - Mapes is doing the same in Windows land. Both cases we could use some help. If any on this list care about those platforms and would like to pitch in this is the thread to introduce yourself.
Re: [cordova-cli] - what does the plugins folder do?
Agreed +1 On 3/22/13 4:23 PM, Brian LeRoux b...@brian.io wrote: Ya love it. =) On Fri, Mar 22, 2013 at 1:02 PM, Filip Maj f...@adobe.com wrote: Agree with everything Braden said On 3/22/13 12:05 PM, tommy-carlos Williams to...@devgeeks.org wrote: +1 for ./platforms becoming a build artifact. That is already how we are attempting to roll in our project using the cli, though its not quite right yet. On 23/03/2013, at 5:26, Braden Shepherdson bra...@chromium.org wrote: We want this to stick around. One of my goals for the CLI is to make the platforms/foo subdirectories completely build artifacts. Native code, web assets, JS code, all get copied on every prepare. That's not currently true for native code, but it is for the rest. Since we're doing that, we need the full content of the plugins to stick around. Is there a problem with keeping this around? Braden On Fri, Mar 22, 2013 at 2:12 PM, Brian LeRoux b...@brian.io wrote: Cool. So, is this interim or necessary to exist for all of time? (Would assume you need some sort of staging area but not sure you need to keep em around if we can cache the manifest info or something.) On Fri, Mar 22, 2013 at 11:01 AM, Braden Shepherdson bra...@chromium.org wrote: I assume you mean the top-level plugins/ folder in the CLI? That is where plugins are cached when you cordova plugin add them. Whether they're coming from local directories or git or wherever, they get copied here. Then on a prepare this is where the plugin's assets are copied from. Braden On Fri, Mar 22, 2013 at 1:56 PM, Brian LeRoux b...@brian.io wrote: ...
Re: Platform-level command line scripts ;)
I like this. mw On 3/22/13 6:03 PM, Brian LeRoux b...@brian.io wrote: YES. Do it. On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj f...@adobe.com wrote: Hai gaiz! Main contention between the two camps in this debate is four vs eight scripts.. But Brian points out that refactoring smaller bits of functionality into their own script allows us to have our cake and eat it too. This, in turn, results in four + (a subset of the 8) = 10 scripts in total.. Which is an argument for just starting with smaller more discrete scripts to begin with, lol. How about this as a middle ground: - under /cordova/ we have the four scripts Anis/Andrew recommend: clean, log, build and run. These call into various scripts under cordova/lib, such as.. - under /cordova/lib we have the ~6 scripts I recommended: build-debug, build-release, start-emulator, deploy-device, deploy-emulator, and possibly a list-devices one as well. The final point is nailing what `run` does, step-by-step. Paraphrasing Anis: If device(s) connected: * Pick device (ignore emulators). * Prompt, timeout and pick first one (5 to 10 seconds) if multiple devices are connected (ignore emulators). If device(s) not connected: * Emulator if it is running * Prompt, timeout and pick first one (5 to 10 seconds) if multiple emulators are running. * Start emulator. If you have multiple ones set up (Android's case), prompt, timeout and launch first one (5 to 10 seconds). Yes/no/discuss. Let's try to get to a consensus :) On 3/21/13 5:29 PM, Brian LeRoux b...@brian.io wrote: I knew you'd bring that up! We'll talk more tmrw. On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI anis.ka...@gmail.com wrote: Šor you can have functions do discrete actions like so: https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f= bi n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6; hb =HEAD Šinstead of creating more inodes. On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux b...@brian.io wrote: You could make more scripts as helper scripts, but I still think that it will be confusing if a user types ls and sees a large number of scripts, having to guess what each of them does. Put them in a subdir called ./lib and be done w/ it. I don't think having more scripts will make it more likely that the scripts will be consistent across platforms. Ah, but having smaller responsibilities for a module of code makes it more testable in discreet form making it easier to confirm said suspicions.
Re: Moving www into an app folder
On merges in the root, in our internal implementation it was under www, however this became problematic to devs understanding. It became far to easy for root level www code to end up in merges. We even named ours _platformOverrides to try and make it pretty explicit, but no one liked the mixing the peanut butter w/ the jelly. Thus the root level designation, which I like. Option 2 doesn't kill me, however it does muddy the water a bit when deving purely in browser that www lives under a top level app, as app is Š dare I say nebulous. The benefit of the current set up is that while it might not be strictly just www, its simple. When some one starts they gravitate to www, and look around and then the readme and config are in context to where they will for the most partŠ. live, which is a good thing. mw On 3/22/13 6:15 PM, Brian LeRoux b...@brian.io wrote: I'm ok with ./merges at the same level as ./www but the config.xml inside of ./www bugs me too. I think having a root level ./www just works well mentally in that its obvious whats there, what it does, and who it effects. The ./merges folder is really just stuff that gets added to ./www in the right cases so having at the same depth is ok (for me). I get where you are coming from though. The real sticky bit is a config file hiding with the app implementation. It seems like that would live at the root. The idea of having it inside of ./www is a simple zip and rename of ./www would result in an installable package...but logically with our tooling and such that would be a build artifact that just lives in ./platforms after we do our magic. =/ On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny mmo...@chromium.org wrote: Paraphrasing our meeting notes today: * currently www/ has to have config.xml inside it, docs inside it, README etc * merges folder is already a sibling of www/ but its logically part of the app. * So, why not move everything that isn't the actual assets of the app itself out of www? * Option 1: move everything out into the root. * harder for git versioning your app, since cordova artifacts (platforms, plugins) are inside. * Option 2: make a new top level app/ folder that holds merges/ and www/ and manifestes etc * then you can just clone/install an app into one location And I'll throw out a third option: Create an apps folder which can have any number of named apps, like plugins. I think (2) should be totally doable (just change some default paths in the tooling) and is a strict improvement (minus the hassle of moving your files around the first time for app devs). (3) I think is interesting, but is a bit of a departure. -Michal
Re: cordova command cli and merges concept pull request
Awesome glad to help! mw On 3/4/13 7:22 PM, Filip Maj f...@adobe.com wrote: Hey everyone Just merged this functionality in and pushed up to the apache repo. It's available on master now, and will be released in our Cordova 2.6.0rc1 release. In the meantime it exists as 2.5.2 on npm (just in the process of publishing). Michael I've added you to the contributors list. Thanks again for your work! On 2/18/13 2:39 PM, Michael Wolf michael.w...@cynergy.com wrote: No, will get the icla sorted this week. Happy to help. Sent from my Windows Phone From: Filip Majmailto:f...@adobe.com Sent: ?2/?18/?2013 2:07 PM To: dev@cordova.apache.orgmailto:dev@cordova.apache.org Subject: Re: cordova command cli and merges concept pull request Hey Michael, I've rebased/merged your changes with the latest master and did a bit of refactoring and tweaks to get the tests passing again. I've pushed this up to the merges branch on apache: https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=re f s /heads/merges Once we have your ICLA sorted, I will merge it into master. Thanks for taking the time to do the work! Really appreciate it! Best, Fil On 2/17/13 3:53 PM, Michael Wolf michael.w...@cynergy.com wrote: Hey All: Posted changes to include tests (making sure the method gets called in the build and then per parser making sure the copied files make their way into the build) and made a subtle change in where in the process merges were being copied, per Filip's feedback. Thanks, let me know if you have any feedback. mw On 2/13/13 2:20 AM, Filip Maj f...@adobe.com wrote: I'm working with Michael off this discussion thread to get the code up to par. Michael, feel free to update your pull request and ping this thread whenever you get a chance to update it. Then we can all take a look. On 2/12/13 10:15 PM, Anis KADRI anis.ka...@gmail.com wrote: I believe this is a valid request. I like the idea of having platform-specific code only deployed to matching devices. I looked at the pull request and it looks good but as Fil mentioned, it needs some tests. On Tue, Feb 12, 2013 at 11:07 AM, Brian LeRoux b...@brian.io wrote: yes there is some issues w/ emulation in this approach but I think its a better architectural pattern for a universal project. we can make ripple w/ this style rather the other way around. On Tue, Feb 12, 2013 at 6:48 PM, Michael Wolf michael.w...@cynergy.com wrote: Have looked at suggesting folks mock in-browser using ripple... however there are a few issues with that, firstly being simply doesn't work for non webkit platforms (ie windows phone... yah the cli doesn't currently support windows phone but no reason why it can't) ... Also while you can mock to work in ripple, you still have to write code in your base www that only runs in browser / ripple and mock for it (unless I'm doing it wrong :) ), which then introduces this conditional code which then ends up on a device (which I recommend people to shy away from when they can)... where as using the merges folder for this purpose makes the existence of those mocks a purely www artifact that never ends up on a device or native emulator... But I'll also admit I haven't looked deeper into ripple to see if there is an alternative there, because the merges concept just worked for us. mw On 2/12/13 12:05 PM, Filip Maj f...@adobe.com wrote: Cool, thanks Michael. I will take a look when I get a chance. Curious what the rest of the list thinks. As for mocking in-browser, I recommend trying out Ripple - it has great support for mocking out arbitrary cordova plugins. On 2/12/13 6:10 AM, Gorkem Ercan gorkem.er...@gmail.com wrote: I have been cooking up a similar functionality for Cordova development plugins for Eclipse IDE that I am building. I think the only real difference with what I have is I have named the merges folder as www_platform. As my goal is to keep 100% compatible with cordova-cli I was planning to provide a PL for the same so I would be interested with this work and offer help if needed. -- Gorkem On Tue, Feb 12, 2013 at 6:28 AM, Michael Wolf michael.w...@cynergy.comwrote: Hey all: I submitted a pull request for an enhancement of the addition of a merges folder/concept into the cli build process. https://github.com/apache/cordova-cli/pull/3 The concept of merges is pretty simple, to support a common core web base across platforms, but allow for deploying platform specific www content to specific platforms. The addition to the CLI tool adds a new folder merges to the root level. Upon running cordova platforms add|remove platform a new folder is created under the merges folder (ie: merges/ios , merges/android etc). Upon running cordova buid any content added to this folder will be deployed to the associated www folder in the platforms. This carries for either new content being
RE: cordova command cli and merges concept pull request
No, will get the icla sorted this week. Happy to help.
Sent from my Windows Phone
From: Filip Majmailto:f...@adobe.com
Sent: 2/18/2013 2:07 PM
To: dev@cordova.apache.orgmailto:dev@cordova.apache.org
Subject: Re: cordova command cli and merges concept pull request
Hey Michael,
I've rebased/merged your changes with the latest master and did a bit of
refactoring and tweaks to get the tests passing again.
I've pushed this up to the merges branch on apache:
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs
/heads/merges
Once we have your ICLA sorted, I will merge it into master.
Thanks for taking the time to do the work! Really appreciate it!
Best,
Fil
On 2/17/13 3:53 PM, Michael Wolf michael.w...@cynergy.com wrote:
Hey All:
Posted changes to include tests (making sure the method gets called in the
build and then per parser making sure the copied files make their way into
the build) and made a subtle change in where in the process merges were
being copied, per Filip's feedback.
Thanks, let me know if you have any feedback.
mw
On 2/13/13 2:20 AM, Filip Maj f...@adobe.com wrote:
I'm working with Michael off this discussion thread to get the code up to
par.
Michael, feel free to update your pull request and ping this thread
whenever you get a chance to update it. Then we can all take a look.
On 2/12/13 10:15 PM, Anis KADRI anis.ka...@gmail.com wrote:
I believe this is a valid request. I like the idea of having
platform-specific code only deployed to matching devices.
I looked at the pull request and it looks good but as Fil mentioned, it
needs some tests.
On Tue, Feb 12, 2013 at 11:07 AM, Brian LeRoux b...@brian.io wrote:
yes there is some issues w/ emulation in this approach but I think its
a better architectural pattern for a universal project. we can make
ripple w/ this style rather the other way around.
On Tue, Feb 12, 2013 at 6:48 PM, Michael Wolf
michael.w...@cynergy.com
wrote:
Have looked at suggesting folks mock in-browser using ripple...
however
there are a few issues with that, firstly being simply doesn't work
for
non webkit platforms (ie windows phone... yah the cli doesn't
currently
support windows phone but no reason why it can't) ... Also while you
can
mock to work in ripple, you still have to write code in your base
www
that
only runs in browser / ripple and mock for it (unless I'm doing it
wrong
:) ), which then introduces this conditional code which then ends up
on a
device (which I recommend people to shy away from when they can)...
where as
using the merges folder for this purpose makes the existence of
those
mocks a purely www artifact that never ends up on a device or native
emulator...
But I'll also admit I haven't looked deeper into ripple to see if
there
is
an alternative there, because the merges concept just worked for us.
mw
On 2/12/13 12:05 PM, Filip Maj f...@adobe.com wrote:
Cool, thanks Michael. I will take a look when I get a chance.
Curious
what
the rest of the list thinks.
As for mocking in-browser, I recommend trying out Ripple - it has
great
support for mocking out arbitrary cordova plugins.
On 2/12/13 6:10 AM, Gorkem Ercan gorkem.er...@gmail.com wrote:
I have been cooking up a similar functionality for Cordova
development
plugins for Eclipse IDE that I am building. I think the only real
difference with what I have is I have named the merges folder as
www_platform.
As my goal is to keep 100% compatible with cordova-cli I was
planning to
provide a PL for the same so I would be interested with this work
and
offer
help if needed.
--
Gorkem
On Tue, Feb 12, 2013 at 6:28 AM, Michael Wolf
michael.w...@cynergy.comwrote:
Hey all:
I submitted a pull request for an enhancement of the addition of
a
merges
folder/concept into the cli build process.
https://github.com/apache/cordova-cli/pull/3
The concept of merges is pretty simple, to support a common core
web
base
across platforms, but allow for deploying platform specific www
content
to
specific platforms. The addition to the CLI tool adds a new
folder
merges to the root level. Upon running cordova platforms
add|remove
platform a new folder is created under the merges folder (ie:
merges/ios
, merges/android etc). Upon running cordova buid any content
added
to
this folder will be deployed to the associated www folder in the
platforms.
This carries for either new content being added, or more
importantly
overrides existing content from the www folder. For a very
simple
example
imagine you have a css file named css/chrome.css in the www
folder,
where
you could have .backButton { display:block;} , but then under
merges/android/css/chrome.css you could have
.backButton{display:none;},
this is a very simplistic use but it illustrates the concept.
This
additional workflow to the build system in the cli enables some
great
processes
Re: cordova command cli and merges concept pull request
Hey All:
Posted changes to include tests (making sure the method gets called in the
build and then per parser making sure the copied files make their way into
the build) and made a subtle change in where in the process merges were
being copied, per Filip's feedback.
Thanks, let me know if you have any feedback.
mw
On 2/13/13 2:20 AM, Filip Maj f...@adobe.com wrote:
I'm working with Michael off this discussion thread to get the code up to
par.
Michael, feel free to update your pull request and ping this thread
whenever you get a chance to update it. Then we can all take a look.
On 2/12/13 10:15 PM, Anis KADRI anis.ka...@gmail.com wrote:
I believe this is a valid request. I like the idea of having
platform-specific code only deployed to matching devices.
I looked at the pull request and it looks good but as Fil mentioned, it
needs some tests.
On Tue, Feb 12, 2013 at 11:07 AM, Brian LeRoux b...@brian.io wrote:
yes there is some issues w/ emulation in this approach but I think its
a better architectural pattern for a universal project. we can make
ripple w/ this style rather the other way around.
On Tue, Feb 12, 2013 at 6:48 PM, Michael Wolf
michael.w...@cynergy.com
wrote:
Have looked at suggesting folks mock in-browser using ripple...
however
there are a few issues with that, firstly being simply doesn't work
for
non webkit platforms (ie windows phone... yah the cli doesn't
currently
support windows phone but no reason why it can't) ... Also while you
can
mock to work in ripple, you still have to write code in your base www
that
only runs in browser / ripple and mock for it (unless I'm doing it
wrong
:) ), which then introduces this conditional code which then ends up
on a
device (which I recommend people to shy away from when they can)...
where as
using the merges folder for this purpose makes the existence of those
mocks a purely www artifact that never ends up on a device or native
emulator...
But I'll also admit I haven't looked deeper into ripple to see if
there
is
an alternative there, because the merges concept just worked for us.
mw
On 2/12/13 12:05 PM, Filip Maj f...@adobe.com wrote:
Cool, thanks Michael. I will take a look when I get a chance. Curious
what
the rest of the list thinks.
As for mocking in-browser, I recommend trying out Ripple - it has
great
support for mocking out arbitrary cordova plugins.
On 2/12/13 6:10 AM, Gorkem Ercan gorkem.er...@gmail.com wrote:
I have been cooking up a similar functionality for Cordova
development
plugins for Eclipse IDE that I am building. I think the only real
difference with what I have is I have named the merges folder as
www_platform.
As my goal is to keep 100% compatible with cordova-cli I was
planning to
provide a PL for the same so I would be interested with this work
and
offer
help if needed.
--
Gorkem
On Tue, Feb 12, 2013 at 6:28 AM, Michael Wolf
michael.w...@cynergy.comwrote:
Hey all:
I submitted a pull request for an enhancement of the addition of a
merges
folder/concept into the cli build process.
https://github.com/apache/cordova-cli/pull/3
The concept of merges is pretty simple, to support a common core
web
base
across platforms, but allow for deploying platform specific www
content
to
specific platforms. The addition to the CLI tool adds a new
folder
merges to the root level. Upon running cordova platforms
add|remove
platform a new folder is created under the merges folder (ie:
merges/ios
, merges/android etc). Upon running cordova buid any content
added
to
this folder will be deployed to the associated www folder in the
platforms.
This carries for either new content being added, or more
importantly
overrides existing content from the www folder. For a very simple
example
imagine you have a css file named css/chrome.css in the www
folder,
where
you could have .backButton { display:block;} , but then under
merges/android/css/chrome.css you could have
.backButton{display:none;},
this is a very simplistic use but it illustrates the concept. This
additional workflow to the build system in the cli enables some
great
processes for building a nice clean cordova app for example.
* Allows for keeping code clean and limits the need for
platform
specific js logic per platform
* Enables a process of mocking in custom plugins for in browser
dev
(mocks under www real implementations under merges) , and not
risking
this
code filtering into production/device code
* Allows for creating platform specific assets such as css /
font /
images/ videos etc that only gets merged into the specific desired
platform
* Allows for accepting that each platform is unique and
sometimes
need
specific logic and or shims, and always deserves the platform
specific
love, and the build process should support doing this cleanly
AnywhoŠ.. Would love to see this integrated in.
Thanks
Re: cordova command cli and merges concept pull request
Have looked at suggesting folks mock in-browser using ripple... however
there are a few issues with that, firstly being simply doesn't work for
non webkit platforms (ie windows phone... yah the cli doesn't currently
support windows phone but no reason why it can't) ... Also while you can
mock to work in ripple, you still have to write code in your base www that
only runs in browser / ripple and mock for it (unless I'm doing it wrong
:) ), which then introduces this conditional code which then ends up on a
device (which I recommend people to shy away from when they can)... where as
using the merges folder for this purpose makes the existence of those
mocks a purely www artifact that never ends up on a device or native
emulator...
But I'll also admit I haven't looked deeper into ripple to see if there is
an alternative there, because the merges concept just worked for us.
mw
On 2/12/13 12:05 PM, Filip Maj f...@adobe.com wrote:
Cool, thanks Michael. I will take a look when I get a chance. Curious what
the rest of the list thinks.
As for mocking in-browser, I recommend trying out Ripple - it has great
support for mocking out arbitrary cordova plugins.
On 2/12/13 6:10 AM, Gorkem Ercan gorkem.er...@gmail.com wrote:
I have been cooking up a similar functionality for Cordova development
plugins for Eclipse IDE that I am building. I think the only real
difference with what I have is I have named the merges folder as
www_platform.
As my goal is to keep 100% compatible with cordova-cli I was planning to
provide a PL for the same so I would be interested with this work and
offer
help if needed.
--
Gorkem
On Tue, Feb 12, 2013 at 6:28 AM, Michael Wolf
michael.w...@cynergy.comwrote:
Hey all:
I submitted a pull request for an enhancement of the addition of a
merges
folder/concept into the cli build process.
https://github.com/apache/cordova-cli/pull/3
The concept of merges is pretty simple, to support a common core web
base
across platforms, but allow for deploying platform specific www content
to
specific platforms. The addition to the CLI tool adds a new folder
merges to the root level. Upon running cordova platforms add|remove
platform a new folder is created under the merges folder (ie:
merges/ios
, merges/android etc). Upon running cordova buid any content added
to
this folder will be deployed to the associated www folder in the
platforms.
This carries for either new content being added, or more importantly
overrides existing content from the www folder. For a very simple
example
imagine you have a css file named css/chrome.css in the www folder,
where
you could have .backButton { display:block;} , but then under
merges/android/css/chrome.css you could have
.backButton{display:none;},
this is a very simplistic use but it illustrates the concept. This
additional workflow to the build system in the cli enables some great
processes for building a nice clean cordova app for example.
* Allows for keeping code clean and limits the need for platform
specific js logic per platform
* Enables a process of mocking in custom plugins for in browser dev
(mocks under www real implementations under merges) , and not risking
this
code filtering into production/device code
* Allows for creating platform specific assets such as css / font /
images/ videos etc that only gets merged into the specific desired
platform
* Allows for accepting that each platform is unique and sometimes
need
specific logic and or shims, and always deserves the platform specific
love, and the build process should support doing this cleanly
AnywhoŠ.. Would love to see this integrated in.
Thanks
mw
--
--
Gorkem
http://www.gorkem-ercan.com
cordova command cli and merges concept pull request
Hey all:
I submitted a pull request for an enhancement of the addition of a merges
folder/concept into the cli build process.
https://github.com/apache/cordova-cli/pull/3
The concept of merges is pretty simple, to support a common core web base
across platforms, but allow for deploying platform specific www content to
specific platforms. The addition to the CLI tool adds a new folder merges to
the root level. Upon running cordova platforms add|remove platform a new
folder is created under the merges folder (ie: merges/ios , merges/android
etc). Upon running cordova buid any content added to this folder will be
deployed to the associated www folder in the platforms. This carries for
either new content being added, or more importantly overrides existing content
from the www folder. For a very simple example imagine you have a css file
named css/chrome.css in the www folder, where you could have .backButton {
display:block;} , but then under merges/android/css/chrome.css you could have
.backButton{display:none;}, this is a very simplistic use but it illustrates
the concept. This additional workflow to the build system in the cli enables
some great processes for building a nice clean cordova app for example.
* Allows for keeping code clean and limits the need for platform specific js
logic per platform
* Enables a process of mocking in custom plugins for in browser dev (mocks
under www real implementations under merges) , and not risking this code
filtering into production/device code
* Allows for creating platform specific assets such as css / font / images/
videos etc that only gets merged into the specific desired platform
* Allows for accepting that each platform is unique and sometimes need
specific logic and or shims, and always deserves the platform specific love,
and the build process should support doing this cleanly
Anywho….. Would love to see this integrated in.
Thanks
mw
