To confirm
To confirm that you would like shirleya.fu...@gmail.com added to the dev mailing list, please send a short reply to this address: dev-sc.1373960447.iohjpbmggoobjdlomiio-shirleya.fui26= gmail@cordova.apache.org
Re: [windows] Scripts for Windows Phone
[?] On Tue, Mar 26, 2013 at 11:29 AM, Jesse MacFadyen purplecabb...@gmail.comwrote: Benn, Leave it for now, there are deeper implications to removing it. We can discuss more here once I am back to work. Cheers, Jesse Sent from my iPhone5 On 2013-03-25, at 10:36 PM, Benn Mapes benn.ma...@gmail.com wrote: Yah, the difference is that Windows Phone has multiple of these templates so that's why i wanted to pull the cordova folder it out. Sounds like we're on the same page now so i'll go ahead and do that. On Mon, Mar 25, 2013 at 8:24 PM, Filip Maj f...@adobe.com wrote: Yes sounds good. Most other platforms implement it in this way: - Android's create script [1] uses a templates folder [2] that it makes copies of on-create, which contains (among other things) the cordova folder [3]. - Blackberry does a similar thing [4] - so does iOS [5] [1] https://github.com/apache/cordova-android/blob/master/bin/create#L159 [2] https://github.com/apache/cordova-android/tree/master/bin/templates [3] https://github.com/apache/cordova-android/tree/master/bin/templates/cordova [4] https://github.com/apache/cordova-blackberry/tree/master/bin/templates [5] https://github.com/apache/cordova-ios/tree/master/bin/templates On 3/25/13 5:45 PM, Benn Mapes benn.ma...@gmail.com wrote: I could be reading your responses wrong but, this does not answer my proposal, maybe I wasn't clear enough. For the windows platform there are multiple templates, there is the full template which includes a dll of the cordovaLib(native code) and a standalone template which uses the source code. Right now there cordova folders within each of these containing all the project scripts (when you create a project it will use one of these templates - default is full template). My proposal was to pull the cordova folder out of the templates and put it in one spot so there isn't any duplication of these scripts which will add more consistency. Then when create is called, it will just copy that single cordova folder containing all the scripts into the created project folder. Does that make sense? On Mon, Mar 25, 2013 at 1:48 PM, Filip Maj f...@adobe.com wrote: We already have established spots for scripts. Global scripts: cordova-platform/bin/create cordova-platform/bin/check_reqs (in the works) Project-level scripts: Myapp/cordova Myapp/cordova/lib (soon to come) On 3/25/13 1:38 PM, Benn Mapes benn.ma...@gmail.com wrote: Right now most of the scripts for windows phone except create are in /tooling/scripts/ and there are duplicate cordova folders in each template (/templates/*) folder with the emulate and debug scripts for deploying to emulator/device respectively. In light of the recent scripting discussion I would like to propose moving all the scripts that will go into the cordova folder of a project into /framework/cordova/ (or maybe /tooling/cordova/). This folder can then be copied into a new project when the create command is called. That way we only have one place where all these scripts reside, instead of having a cordova folder for each template. Thoughts?
Re: Plugin Repos Created!
Hello. Although I'm new to Appache... I've been programming since the 1980s.. I've always found foo much information can slow the programming process down.. so I agree with Andrew Grieves... best to get thins up and running. Thanks. Shirley On Tue, Mar 26, 2013 at 11:54 AM, Brian LeRoux b...@brian.io wrote: I'm somewhat agonizing this. On one hand: we need all the help we can get! On the other: its complicated. We need to extract each plugin from their respective native platform, and cordova-js, and then ensure gluing it all together still works. Ideally we start extracting mobile-spec too but maybe thats a little later. I'm thinking we kick up a thread dedicated to prioritizing this. Thoughts? On Tue, Mar 26, 2013 at 8:44 AM, Andrew Grieve agri...@chromium.org wrote: Sounds good to add them - but I'd actually prefer not to encourage contributions until we've at least got one plugin fully working. On Tue, Mar 26, 2013 at 12:18 AM, Brian LeRoux b...@brian.io wrote: Hate to 'make work' but we might want to drop a README in them explaining what is supposed to go there (maybe a link to plugman) and the mailing list before we open those up to speculation. On Mon, Mar 25, 2013 at 7:21 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. I think that makes sense. Originally, we tried to keep platforms on the left column and supporting projects on the right column. It makes sense to have the plugins on the right - hopefully that wouldn't make the site look unbalanced. I know the site is configured to support 3 columns, so we ask our designer to tweak the template if it looks weird. Thanks for volunteering Marcel! On Mon, Mar 25, 2013 at 7:04 PM, Marcel Kinard cmarc...@gmail.com wrote: Would it make sense to add these new repos to the list on http://cordova.apache.org? The intent is to encourage contributions. I'd be fine to do that, but wanted to get a sanity check on that first. -- Marcel On Mar 22, 2013, at 8:54 PM, Andrew Grieve agri...@google.com wrote: https://issues.apache.org/jira/browse/INFRA-5839
Re: App-Harness Description
[?] On Tue, Mar 26, 2013 at 1:03 PM, Michal Mocny mmo...@chromium.org wrote: I like the kinky version. On Tue, Mar 26, 2013 at 12:52 PM, Brian LeRoux b...@brian.io wrote: Heh, DX sounds *very* Adobe. (Remember Flash MX?) Meanwhile Devtool sounds very Google. Either way I like both more than calling it a harness. ;) On Tue, Mar 26, 2013 at 9:39 AM, Andrew Grieve agri...@chromium.org wrote: Awesome! Yep - it's editable so that you can edit it :) I like Cordova DX, or maybe Cordova DevTool On Tue, Mar 26, 2013 at 12:10 PM, Michael Brooks mich...@michaelbrooks.ca wrote: Hey Andrew, This is exactly what I had planned as well. It's as if we read each other's minds. I'll go through the document a second time and add some comments. Do you mind if I edit the document? What is this thing going to be called? cordova-app-harness sounds kinky. For naming, my stance has been the Cordova App. There is no reason to make it complicated. If the app stores, users would install Cordova. If you think this is confusing users with downloading the Cordova framework (which they sort of are), then call it Cordova DX (DX is developer experience). Michael On Tue, Mar 26, 2013 at 9:06 AM, Brian LeRoux b...@brian.io wrote: Looks great Andrew. I'd add Ripple and device mirroring as part of this. (More than one device navigates in concert.) What is this thing going to be called? cordova-app-harness sounds kinky. On Mon, Mar 25, 2013 at 5:59 PM, Andrew Grieve agri...@chromium.org wrote: Hey Michael (and anyone else interested), I've written up a requirements doc for this: https://docs.google.com/document/d/14LG1IiEiQ9npc2RmPo5_UEKQTfsg-3ivJu7R2iPBmsw/edit?usp=sharing It's a bit biased towards hosting Chrome Apps, but I think the majority of the app will be generic. The chrome bits will be implemented as a combination of extra plugins that are installed in, and some UI tweaks. Would definitely love feedback to know if this describes the same type of thing you were thinking of. Shravan will likely be starting on this this week.
Re: Platform-level command line scripts
Yes... Why Not... That's part of the fun ... Isn't it?? [?] On Thu, Mar 21, 2013 at 6:14 PM, Brian LeRoux b...@brian.io wrote: I think we can have our cake and eat it too. We should have four high level commands. Those commands can shell to lower level discreetly testable commands. The end user will never know the difference. The developers win the tight abstraction we seek. Make sense? On Thu, Mar 21, 2013 at 2:55 PM, Anis KADRI anis.ka...@gmail.com wrote: On Thu, Mar 21, 2013 at 2:29 PM, Michael Brooks mich...@michaelbrooks.cawrote: +1 Fil's outlined design. I'm still not convinced of what Anis and Andrew are in favour of. Having each script do more will make it more difficult for common results across all platforms. I really like Anis's suggestion of just four scripts. What's the motivation for having many scripts? Having fewer will dramatically reduce copy paste bugs. It will also aid discoverability (since you'll get --help instead of just ls and infer from the name what they do). The motivation for having many scripts is that there is a single entry point for a single action. Each action is discrete. Either a platform supports `deploy-emulator` or doesn't. If we have a single `run` entry-point, it becomes confusing whether a platform supports all requirements of the `run` action. I feel the code repetition is also a weak argument. We are defining entry-point scripts. You can refactor out the common routines (e.g. build) into a helper script that can be invoked by multiple scripts. As far as I know, this is possible in bash, batch, and Windows Script Hosting. I guess this topic will need a vote to follow the Apache Way. We've been talking about/implementing/changing these scripts for a long time and we can't seem to come to a complete agreement. ripple should be a separate option and not a separate command in my opinion. To simplify things and if everyone agrees we can ignore the `run` command flow above and launch ripple by default and ask users to specify options if they want to deploy and run to a particular device/emulator. I feel Ripple has no place in the platform-specific scripts. I love Ripple, but Ripple belongs is a higher-level tool such as Cordova CLI. The platform-specific scripts are meant to deal with platform-specific functions. I don't have a strong opinion on this. So I could agree with you that this Ripple could be a higher-level tool. Michael On Wed, Mar 20, 2013 at 8:22 PM, Benn Mapes benn.ma...@gmail.com wrote: I liked the idea you mentioned earlier with having one wrapper script, that way there is one entry point for the given commands for the needed functionality. Then it doesn't matter what underlying scripts actually do the work. Then our only focus would be on the commands and not so much the name of the scripts. On Wed, Mar 20, 2013 at 7:36 PM, Andrew Grieve agri...@chromium.org wrote: I really like Anis's suggestion of just four scripts. What's the motivation for having many scripts? Having fewer will dramatically reduce copy paste bugs. It will also aid discoverability (since you'll get --help instead of just ls and infer from the name what they do). On Wed, Mar 20, 2013 at 7:06 PM, Filip Maj f...@adobe.com wrote: Ya ya ya we're all on agreement on this specific issue. The underlying platform scripts can be used regardless of whether you're using cordova-cli or not. On 3/20/13 3:51 PM, Anis KADRI anis.ka...@gmail.com wrote: On Wed, Mar 20, 2013 at 3:43 PM, Benn Mapes benn.ma...@gmail.com wrote: I know that sounds like a lot of scripts but we're building them for the cordova-cli to use, so i like the idea of breaking them out so each script does a *very specific* task with as little-to-no No we're not. cordova-cli is a cool tool that people can use but it should not be the only way of building Cordova apps in my opinion.
