Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 22873E4A0 for ; Tue, 29 Jan 2013 00:22:15 +0000 (UTC) Received: (qmail 95285 invoked by uid 500); 29 Jan 2013 00:22:14 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 95262 invoked by uid 500); 29 Jan 2013 00:22:14 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 95254 invoked by uid 99); 29 Jan 2013 00:22:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 00:22:14 +0000 X-ASF-Spam-Status: No, hits=-1.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of fil@adobe.com designates 64.18.1.21 as permitted sender) Received: from [64.18.1.21] (HELO exprod6og108.obsmtp.com) (64.18.1.21) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 00:22:08 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUQcWGSF2GEDjzVy8vA3x+8x6pWjqi8KN@postini.com; Mon, 28 Jan 2013 16:21:47 PST Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r0T0Ig1v011574 for ; Mon, 28 Jan 2013 16:18:43 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r0T0LfXM018169 for ; Mon, 28 Jan 2013 16:21:43 -0800 (PST) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Mon, 28 Jan 2013 16:21:40 -0800 From: Filip Maj To: "dev@cordova.apache.org" Date: Mon, 28 Jan 2013 16:25:04 -0800 Subject: Re: Cordova CLI (and by proxy, platform) requirements Thread-Topic: Cordova CLI (and by proxy, platform) requirements Thread-Index: Ac39tpt/wKFn+H6hTeuGzWTHEjnPDQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Totally agree Jesse. My first pass at BB support includes interactive prompting. I would love to get rid of it, or provide another way to specify that stuff. Like you say, perhaps command line options is the way to go (if someone wants to automate the use of the script, for example). The easy fix is to spew out a big warning after you add BlackBerry to your project's platforms instructing the user to customize . People who use Cordova BlackBerry already (like Don) do something like this as it is. On 1/28/13 3:53 PM, "Jesse" wrote: >Fil, It will most likely not just be BB, so your solution may not be >future >proof. >I would draw a line in the sand stating that there must be a bb-config >file >which instructs the cli build command of which sdk version to use (via an >explicit path ). OR it could be a command line argument at build time. >I assume that we should be able to target any specific sdk version, and >this is not restricted to being a once only issue that can be resolved at >the time of 'adding a new platform target' and must be dealt with every >time we build. > >I think making this script interactive is extremely limiting if we want it >to be used by other tools. If this is not an issue, then go for it ... > > > > > > >On Mon, Jan 28, 2013 at 3:47 PM, Filip Maj wrote: > >> So that's what I'm trying to see if we can fix. >> >> The multiple SDKs that use the same executable script name throws a >>wrench >> into this whole thing.. Lame. >> >> What if we drew a line in the sand and said for BlackBerry we only >>support >> BB10? Then we can get rid of prompts and tell people to put their BB10 >>SDK >> (not their playbook SDK) bbwp path on their system PATH? >> >> On 1/28/13 3:37 PM, "Brian LeRoux" wrote: >> >> >uh oh. so, does this mean we do both and put prompting behind a >> >configuration option? >> > >> >RECURSIVE ERROR >> > >> >On Mon, Jan 28, 2013 at 5:25 PM, Gord Tanner wrote: >> >> I think the reason blackberry doesn't put the sdk on the path is >> >>because they need to have multiple sdk versions (all with the same >> >>command names) on the same machine. >> >> >> >> -1 for path >> >> +1 for prompting >> >> >> >> Sent from my iPhone >> >> >> >> On 2013-01-28, at 6:22 PM, Jesse MacFadyen >> >>wrote: >> >> >> >>> +1 path and configuration for credentials. >> >>> >> >>> -1 prompting for values, or confirming previous values. >> >>> >> >>> I think the tool should be non-interactive, or at least that is my >> >>>expectation. >> >>> >> >>> On fail simply provide advice on how to remedy the situation. >> >>> Prompting for a path is out of scope IMO. Its much better to >>document >> >>> expectations and fail noisily when they are not met. I thinks. >> >>> >> >>> Cheers, >> >>> Jesse >> >>> >> >>> Sent from my iPhone5 >> >>> >> >>> On 2013-01-28, at 2:23 PM, Don Coleman >>wrote: >> >>> >> >>> I have the Android tools in my path but not BlackBerry. >> >>> >> >>> Prompting for the BlackBerry file locations and passwords etc works >> >>>OK. It >> >>> would be nice to search the default location, or at least store all >> >>>this >> >>> info in ~/.cordova-cli so the next time I run the tool I can just >> >>>confirm >> >>> the previous entries. >> >>> >> >>> I like the way the yeoman.io audit script ( >> >>> https://github.com/yeoman/yeoman/wiki/Manual-Install) checks for >> what's >> >>> required and offers solutions for what's missing. >> >>> >> >>> >> >>> On Mon, Jan 28, 2013 at 5:14 PM, Filip Maj wrote: >> >>> >> >>>> Hey all, >> >>>> >> >>>> Working out some bootstrap-type stuff for cordova-cli. Here's a >> >>>>situation >> >>>> I am dealing with now in the cli code that I would like people's >> >>>>input. >> >>>> >> >>>> When you add Android to your project's platforms, the >>requirements, as >> >>>> imposed by the underlying cordova-android library, is that the >> >>>>Android SDK >> >>>> be installed (duh) and that the SDK tools are available on your >>path. >> >>>> When you add BlackBerry to your project's platforms, you also need >>the >> >>>> BlackBerry WebWorks SDK. However, because BlackBerry uses a >> >>>>configuration >> >>>> approach, you do not need to have the WEbWorks SDK on your path. >> >>>>Instead, >> >>>> you need to explicitly list out the location of the SDK in a config >> >>>>file >> >>>> (as well as device and signing key passwords, device and simulator >> >>>>Ips, >> >>>> and whatever else is necessary). >> >>>> >> >>>> As such, the CLI tools work similarly: you need Android tools on >>your >> >>>>path >> >>>> to work with Android, and for BlackBerry you are asked a few >> >>>>questions in >> >>>> a prompt when you add a blackberry project the first time (enter >>the >> >>>>path >> >>>> to your SDK, enter your signing key password, etc). >> >>>> >> >>>> So could easily go with this. It works as is. The question that >>comes >> >>>>to >> >>>> my mind though is, why is there a difference? I think we should >>pick >> >>>>one >> >>>> of these approaches and stick with it: either have the SDK's >>required >> >>>> tools on the system's PATH, or ask the user for them every time (or >> >>>>point >> >>>> them to the config file for filling out). >> >>>> >> >>>> Thoughts? >> >>>> >> >>>> >> >> > > >--=20 >@purplecabbage >risingj.com