cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Coleman <don.cole...@gmail.com>
Subject Re: Cordova CLI (and by proxy, platform) requirements
Date Mon, 28 Jan 2013 22:22:57 GMT
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 <fil@adobe.com> 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?
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message