It doesn't use the app's cordova_plugins.js? I thought we wanted to verify that the right set of plugins are installed and to do that we need to load the apps' version. If we are doing that "for now" thats fine, but I'm curious if that is the long term plan?
Are we loading *any* assets outside of whats available in the top level www/? Once upon a time serve served up the top level www/, then changed to platform www/.. should we change it back? I'm with Jesse that devs should not need (but can if they want) to version control platforms/ or plugins/, and his workaround seems quite agreeable to me. -Michal On Tue, Feb 4, 2014 at 11:23 AM, Braden Shepherdson <bra...@chromium.org>wrote: > For the record, the App Harness makes child apps use the cordova.js, > cordova_plugins.js, and plugins/* which are included with the App Harness, > not the ones that come with the child app. This is because it ensures > compatibility with the native code and the Javascript side, though it can > break the JS API for a plugin if there's a version mismatch (which the App > Harness can warn about). Generally these APIs are more stable than the > bridge calls the plugin is making under the hood, hence the decision to use > the bundled JS code. > > Braden > > > > On Tue, Feb 4, 2014 at 9:44 AM, Michal Mocny <mmo...@chromium.org> wrote: > >> I think we've previously also thrown around the idea of Installed vs >> Enabled (though the context I think was about plugins and being >> conditionally disabled on various platforms). >> >> Perhaps we could always install the platforms you ask for, but leave then >> disabled for local builds until check_req's pass? >> >> >> On Tue, Feb 4, 2014 at 9:37 AM, Ian Clelland <iclell...@chromium.org> >> wrote: >> >> > In that case, I feel like we should be calling check_reqs on create, but >> > not throwing an error; just display a warning if the build tools aren't >> > installed. >> > >> > We've had reports from people using the cca toolchain that `create` lets >> > them start the project, but then they can't build because they're >> missing >> > javac or something else essential. I think there's an expectation that >> we >> > at least let people know early if they're going to have a bad time >> later on. >> > >> > >> > On Tue, Feb 4, 2014 at 9:30 AM, Michal Mocny <mmo...@chromium.org> >> wrote: >> > >> >> ..matter of fact, for those same reasons we should change the other >> >> platforms to support installation when check_reqs fail. I should be >> able >> >> to test Android using AH the exact same way without a full dev >> >> environment. >> >> >> >> >> >> On Tue, Feb 4, 2014 at 9:27 AM, Michal Mocny <mmo...@chromium.org> >> wrote: >> >> >> >> > With the app-harness, you actually can test on iOS from windows, so >> this >> >> > is becoming a use case. So long as the pre-packaged native plugins >> >> running >> >> > on the app-harness match version requirements for your app, you won't >> >> need >> >> > to build the native bits locally. >> >> > >> >> > All we need is to serve web assets from your development machine to >> the >> >> > AH, and the easiest way to make sure we serve the right assets is to >> use >> >> > the platform targeted prepare step. If for no other reason, than >> just >> >> to >> >> > make sure we serve the right cordova_plugins.js (though Braden will >> know >> >> > what other platform bits the AH consumes, at some point it was using >> the >> >> > app's cordova.js and plugins' js-modules, but I think it changed to >> used >> >> > the AH bundled versions). >> >> > >> >> > -Michal >> >> > >> >> > >> >> > On Mon, Feb 3, 2014 at 12:50 PM, Jesse <purplecabb...@gmail.com> >> wrote: >> >> > >> >> >> Personally, I would not expect a multi-platform team to even checkin >> >> the >> >> >> platforms folder. >> >> >> >> >> >> Addressing Axel's use case: It would only require a few commands to >> be >> >> >> ready to build an iOS Cordova project: >> >> >> npm install -g cordova >> >> >> cordova create ~/HelloCordova >> >> >> cd ~/HelloCordova >> >> >> cordova platform add ios >> >> >> >> >> >> As an alternative, the phonegap-cli [1] allows actual building of >> iOS >> >> >> targets from Windows, by using the phonegap-build service. Or you >> could >> >> >> just use the PhoneGap build site directly. You would need to setup >> an >> >> >> account either way, >> >> >> >> >> >> My reason for creating the issue CB-5963 was NOT to enable the >> >> >> functionality Baz referred to with CB-5706, but to provide an easy >> way >> >> to >> >> >> test plugins in WP7/8 and Windows8. I will/am changing the >> >> functionality >> >> >> a >> >> >> bit in the nodejs scripts because it doesn't make sense to platform >> add >> >> >> ios >> >> >> on windows because you won't be able to run the tests anyway. >> >> >> >> >> >> My plan is that the node script for testing mobile spec will only >> >> platform >> >> >> add whatever platform is specified in the arguments. >> >> >> ie. >> >> >> node createmobilespec.js --platform wp8 >> >> >> and possibly in the future, allow the testing of specific plugins, >> from >> >> >> specific locations, using a specific cordova, and a specific >> platform >> >> >> location. >> >> >> >> >> >> This really is all I have to say on the CB-5706 subject, if you >> still >> >> want >> >> >> to do it, then go ahead. However, if it is a significant change, >> and I >> >> >> think I'll have to support the added code in wp8/windows8, then I >> will >> >> be >> >> >> very strict in accepting pull requests as I work on these projects >> >> every >> >> >> day. You may want to choose a less controversial issue to work on. >> >> >> >> >> >> [1] https://github.com/phonegap/phonegap-cli >> >> >> [2] https://build.phonegap.com/ >> >> >> >> >> >> >> >> >> @purplecabbage >> >> >> risingj.com >> >> >> >> >> >> >> >> >> On Mon, Feb 3, 2014 at 8:09 AM, Andrew Grieve <agri...@chromium.org >> > >> >> >> wrote: >> >> >> >> >> >> > Converting the scripts to node is exactly what we'd need to do to >> >> have >> >> >> them >> >> >> > work on Win, I think. We can just remove the call to check_reqs >> made >> >> >> from >> >> >> > create(). >> >> >> > >> >> >> > A use-case I can see for this is PhoneGap Build / AppHarness >> >> >> development. >> >> >> > >> >> >> > If you'd like to work on this issue, then I think that's great! >> >> >> > >> >> >> > >> >> >> > On Sun, Feb 2, 2014 at 9:20 AM, Bas Bosman <m...@nazgul.nu> >> wrote: >> >> >> > >> >> >> > > I do think it's beneficial to have that option available on >> >> Windows. >> >> >> > > >> >> >> > > As far as i know Cordova strives for feature parity across all >> >> >> deployment >> >> >> > > platforms (where possible) and I don't think it's strange to >> extend >> >> >> that >> >> >> > > feature parity to the development platform (where possible). I >> >> agree >> >> >> that >> >> >> > > you need XCode to build, test and deploy an iOS app, but you >> don't >> >> >> need >> >> >> > it >> >> >> > > for large parts of developing the app. For that same reason I >> think >> >> >> that >> >> >> > > the ability to do a cordova add wp8 (not build) on a Mac for >> >> example >> >> >> > would >> >> >> > > be a good thing to have as well. >> >> >> > > >> >> >> > > The 'platform add' code currently doesn't actually use any of >> the >> >> >> things >> >> >> > > checked for in check_req as far as I can tell, so there is no >> >> >> technical >> >> >> > > reason not to do it. And we do allow a 'plugin add' to add iOS >> >> >> specific >> >> >> > > stuff on a Windows machine. >> >> >> > > >> >> >> > > If a group of people start developing a multi platform app using >> >> >> Cordova >> >> >> > a >> >> >> > > valid use case in my opinion would be that there is one >> developer >> >> who >> >> >> > does >> >> >> > > the initial setup. So adding the base platforms and plugins for >> the >> >> >> team >> >> >> > > to use. Currently he has to use multiple development platforms, >> >> which >> >> >> he >> >> >> > > may not have, to do so while there is a good chance he'll only >> be >> >> >> working >> >> >> > > on the on Mac or Windows only development parts of the app after >> >> that >> >> >> > > initial setup. Giving him the opportunity to do that all from >> the >> >> >> > > environment he's familiar with seems like a nice thing to have. >> >> >> > > >> >> >> > > Another reason I started looking into this is mobile-spec. There >> >> is a >> >> >> > JIRA >> >> >> > > issue (CB-5963, submitted by a core contributor) about >> >> >> > createmobilespec.sh >> >> >> > > only working on a Mac. That script wouldn't be to hard to port >> >> over to >> >> >> > > JavaScript to have it run on other platforms as well, but it >> also >> >> has >> >> >> a >> >> >> > > dependency on the platform add ios stuff. I think that having >> >> >> something >> >> >> > > there that works on all platforms and produces the same end >> result >> >> >> would >> >> >> > > be a good thing as well. >> >> >> > > >> >> >> > > And I agree with Axel, although I hadn't thought of it before, >> that >> >> >> > having >> >> >> > > similar create scripts across the platforms would be easier to >> >> >> maintain >> >> >> > > and extend Cordova wide in the future. >> >> >> > > >> >> >> > > But those are just my opinions. I didn't assign the JIRA issue >> to >> >> >> myself >> >> >> > > yet because I wanted to have your input first. And thank you for >> >> the >> >> >> > input >> >> >> > > so far. >> >> >> > > >> >> >> > > I see a lot of benefit for myself (and others) in this, but I >> won't >> >> >> start >> >> >> > > the coding and testing effort if it isn't something that's >> wanted >> >> by a >> >> >> > > majority of the group. :) >> >> >> > > >> >> >> > > Bas >> >> >> > > >> >> >> > > > Without wanting to say that it makes _much_ sense or is worth >> the >> >> >> > effort >> >> >> > > I >> >> >> > > > tried this two weeks ago because I needed the iOS app on a >> >> manager's >> >> >> > > > iPhone >> >> >> > > > but the project's iOS devs were not available. I wanted to add >> >> the >> >> >> iOS >> >> >> > > > platform, zip the platforms/ios folder and send it to another >> iOS >> >> >> > > > developer >> >> >> > > > (no Cordova there) to build it there. >> >> >> > > > >> >> >> > > > Maybe a deeper - low priority - goal here would be to have the >> >> same >> >> >> > node >> >> >> > > > scripts on most platforms. >> >> >> > > > Am 02.02.2014 00:06 schrieb "Jesse" <purplecabb...@gmail.com >> >: >> >> >> > > > >> >> >> > > >> Bas, keep in mind that anyone can enter an issue in JIRA, it >> >> >> doesn't >> >> >> > > >> necessarily mean that it is valid, or thought through, it is >> >> just a >> >> >> > > >> request. >> >> >> > > >> Andrew's comment on the issue itself points some of this out. >> >> >> > > >> It may make more sense to start with issues that have be >> created >> >> >> by a >> >> >> > > >> core >> >> >> > > >> contributor. >> >> >> > > >> You probably chose this issue because it was unassigned, >> >> choosing >> >> >> an >> >> >> > > >> assigned bug ( but not in-progress ) may be better as well, >> >> just be >> >> >> > sure >> >> >> > > >> to >> >> >> > > >> reassign it to yourself, and mark it in-progress. >> >> >> > > >> >> >> >> > > >> @purplecabbage >> >> >> > > >> risingj.com >> >> >> > > >> >> >> >> > > >> >> >> >> > > >> On Sat, Feb 1, 2014 at 2:46 PM, Steven Gill < >> >> >> stevengil...@gmail.com> >> >> >> > > >> wrote: >> >> >> > > >> >> >> >> > > >> > Why do we want to allow IOS create on windows? Xcode(a mac) >> >> is a >> >> >> > > >> > requirement for development for iOS. I don't understand why >> >> this >> >> >> > > >> > functionality is needed. WP stuff needs a windows machine >> to >> >> >> > > >> > run/build/emulate. Hence why those commands are only >> available >> >> >> on a >> >> >> > > >> windows >> >> >> > > >> > machine. >> >> >> > > >> > >> >> >> > > >> > >> >> >> > > >> > On Sat, Feb 1, 2014 at 1:05 PM, Bas Bosman < >> cord...@nazgul.nu >> >> > >> >> >> > wrote: >> >> >> > > >> > >> >> >> > > >> > > I've been looking into this. (JIRA CB-5706) >> >> >> > > >> > > >> >> >> > > >> > > The current create and update scripts for iOS are shell >> and >> >> >> Python >> >> >> > > >> > script. >> >> >> > > >> > > Both of which aren't available on Windows without jumping >> >> >> through >> >> >> > a >> >> >> > > >> lot >> >> >> > > >> > of >> >> >> > > >> > > hoops. >> >> >> > > >> > > >> >> >> > > >> > > Converting the scripts to JavaScript, modeled after the >> >> Android >> >> >> > > >> scripts, >> >> >> > > >> > > will fix the issues of not being able to run them on >> Windows >> >> >> as we >> >> >> > > >> > already >> >> >> > > >> > > have a Node dependency. >> >> >> > > >> > > >> >> >> > > >> > > But the bigger problem is check_reqs. That will never >> >> succeed >> >> >> on >> >> >> > > >> Windows >> >> >> > > >> > > as there's no XCode there. >> >> >> > > >> > > >> >> >> > > >> > > Maybe add an optional --force parameter that will allow >> >> people >> >> >> to >> >> >> > > >> ignore >> >> >> > > >> > > the check_reqs result? >> >> >> > > >> > > >> >> >> > > >> > > Before creating a JIRA issue for that I wanted to solicit >> >> some >> >> >> > > >> opinions >> >> >> > > >> > > here. Is this a valid course of action? Are there better >> >> >> > > >> alternatives? >> >> >> > > >> > > >> >> >> > > >> > > Bas >> >> >> > > >> > > >> >> >> > > >> > > >> >> >> > > >> > >> >> >> > > >> >> >> >> > > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > >> >> >> >> >> > >> >> > >> >> >> > >> > >> > >
