Cordova CLI (and by proxy, platform) requirements

[Filip Maj <fi...@adobe.com>]

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?

Re: Cordova CLI (and by proxy, platform) requirements

[Simon MacDonald <si...@gmail.com>]

+1 PATH
Simon Mac Donald
http://hi.im/simonmacdonald


On Mon, Jan 28, 2013 at 5:14 PM, Filip Maj <fi...@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?
>

Re: Cordova CLI (and by proxy, platform) requirements

[Anis KADRI <an...@gmail.com>]

+1 PATH variable, config file (in this order).
-1 for asking every time.


On Mon, Jan 28, 2013 at 2:14 PM, Filip Maj <fi...@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?
>
>

Re: Cordova CLI (and by proxy, platform) requirements

[Filip Maj <fi...@adobe.com>]

Thanks for the feedback everyone! Very helpful.

Sounds like we will keep the prompting around. I will add (an issue for)
CLI parameters to allow providing any required information to enable
automation.

Final question, for the platforms that require more configuration: should
we prompt on every platform add for a configurable platform, or do so at
install-time for the tools?

On 1/29/13 9:13 AM, "Michael Brooks" <mi...@michaelbrooks.ca> wrote:

>About a year and a half ago, I started to refactor the BlackBerry bin/
>(ANT) script. My goal was the following:
>
>1. Use SDK path if explicitly stated in the config file
>(project.properties)
>2. Otherwise search the PATH and use the SDK found
>3. Otherwise fail noisily
>
>Back during our client work days, our apps were often built for a specific
>SDK (4.6, 5.0, or 6.0). The config file was an explicit way of telling
>collaborators that the target SDK. However, as WebWorks and the Playbook
>SDK emerged, explicitly stating the SDK became less a repetitive hassle.
>This is why the PATH option would have been nice. In general, I think
>every
>platform should strive to support PATHs. If you find that users need to
>switch between multiple SDKs, then consider allowing the user to
>explicitly
>override the default SDK PATH.
>
>As for the prompting discussion: I don't mind prompting, but it MUST be
>overridable for automation purposes. You should be able to provide an
>option that overrides that particular prompt (`--bbwp`,
>`--signing-password`, `--device-ip`, etc).
>
>Michael
>
>On Mon, Jan 28, 2013 at 4:25 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> 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 <path to bb config
>> file>. People who use Cordova BlackBerry already (like Don) do something
>> like this as it is.
>>
>> On 1/28/13 3:53 PM, "Jesse" <pu...@gmail.com> 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 <fi...@adobe.com> 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" <b...@brian.io> 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 <gt...@gmail.com>
>> 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
>><pu...@gmail.com>
>> >> >>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 <do...@gmail.com>
>> >>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 <fi...@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?
>> >> >>>>
>> >> >>>>
>> >>
>> >>
>> >
>> >
>> >--
>> >@purplecabbage
>> >risingj.com
>>
>>

Re: Cordova CLI (and by proxy, platform) requirements

[Giorgio Natili <g....@gnstudio.com>]

Is it possible to do both?
I mean path/configuration and if the path/configuration is not found a
prompt.

Giorgio

On 1/29/13 6:13 PM, "Michael Brooks" <mi...@michaelbrooks.ca> wrote:

>About a year and a half ago, I started to refactor the BlackBerry bin/
>(ANT) script. My goal was the following:
>
>1. Use SDK path if explicitly stated in the config file
>(project.properties)
>2. Otherwise search the PATH and use the SDK found
>3. Otherwise fail noisily
>
>Back during our client work days, our apps were often built for a specific
>SDK (4.6, 5.0, or 6.0). The config file was an explicit way of telling
>collaborators that the target SDK. However, as WebWorks and the Playbook
>SDK emerged, explicitly stating the SDK became less a repetitive hassle.
>This is why the PATH option would have been nice. In general, I think
>every
>platform should strive to support PATHs. If you find that users need to
>switch between multiple SDKs, then consider allowing the user to
>explicitly
>override the default SDK PATH.
>
>As for the prompting discussion: I don't mind prompting, but it MUST be
>overridable for automation purposes. You should be able to provide an
>option that overrides that particular prompt (`--bbwp`,
>`--signing-password`, `--device-ip`, etc).
>
>Michael
>
>On Mon, Jan 28, 2013 at 4:25 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> 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 <path to bb config
>> file>. People who use Cordova BlackBerry already (like Don) do something
>> like this as it is.
>>
>> On 1/28/13 3:53 PM, "Jesse" <pu...@gmail.com> 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 <fi...@adobe.com> 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" <b...@brian.io> 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 <gt...@gmail.com>
>> 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
>><pu...@gmail.com>
>> >> >>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 <do...@gmail.com>
>> >>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 <fi...@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?
>> >> >>>>
>> >> >>>>
>> >>
>> >>
>> >
>> >
>> >--
>> >@purplecabbage
>> >risingj.com
>>
>>

Re: Cordova CLI (and by proxy, platform) requirements

[Michael Brooks <mi...@michaelbrooks.ca>]

About a year and a half ago, I started to refactor the BlackBerry bin/
(ANT) script. My goal was the following:

1. Use SDK path if explicitly stated in the config file (project.properties)
2. Otherwise search the PATH and use the SDK found
3. Otherwise fail noisily

Back during our client work days, our apps were often built for a specific
SDK (4.6, 5.0, or 6.0). The config file was an explicit way of telling
collaborators that the target SDK. However, as WebWorks and the Playbook
SDK emerged, explicitly stating the SDK became less a repetitive hassle.
This is why the PATH option would have been nice. In general, I think every
platform should strive to support PATHs. If you find that users need to
switch between multiple SDKs, then consider allowing the user to explicitly
override the default SDK PATH.

As for the prompting discussion: I don't mind prompting, but it MUST be
overridable for automation purposes. You should be able to provide an
option that overrides that particular prompt (`--bbwp`,
`--signing-password`, `--device-ip`, etc).

Michael

On Mon, Jan 28, 2013 at 4:25 PM, Filip Maj <fi...@adobe.com> wrote:

> 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 <path to bb config
> file>. People who use Cordova BlackBerry already (like Don) do something
> like this as it is.
>
> On 1/28/13 3:53 PM, "Jesse" <pu...@gmail.com> 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 <fi...@adobe.com> 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" <b...@brian.io> 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 <gt...@gmail.com>
> 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 <pu...@gmail.com>
> >> >>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 <do...@gmail.com>
> >>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 <fi...@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?
> >> >>>>
> >> >>>>
> >>
> >>
> >
> >
> >--
> >@purplecabbage
> >risingj.com
>
>

Re: Cordova CLI (and by proxy, platform) requirements

[Don Coleman <do...@gmail.com>]

The current BlackBerry interactive script works well, except I need to look
up and copy the path every time.

Without cordova cli I copy project.properties from an old BlackBerry
project into the new project and edit as necessary.

I don't think requiring BlackBerry on the path will work.  For supporting
BB7 and BB10 I have 2 SDKs in the project.properties file

  blackberry.bbwp.dir=/Developer/SDKs/Research\ In\ Motion/BlackBerry\
WebWorks\ SDK\ 2.3.1.5
  qnx.bbwp.dir=/Developer/SDKs/Research\ In\ Motion/BlackBerry\ 10\
WebWorks\ SDK\ 1.0.4.5



On Mon, Jan 28, 2013 at 6:53 PM, Jesse <pu...@gmail.com> 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 <fi...@adobe.com> 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" <b...@brian.io> 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 <gt...@gmail.com> 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 <pu...@gmail.com>
> > >>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 <do...@gmail.com>
> 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 <fi...@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?
> > >>>>
> > >>>>
> >
> >
>
>
> --
> @purplecabbage
> risingj.com
>

Re: Cordova CLI (and by proxy, platform) requirements

[Filip Maj <fi...@adobe.com>]

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 <path to bb config
file>. People who use Cordova BlackBerry already (like Don) do something
like this as it is.

On 1/28/13 3:53 PM, "Jesse" <pu...@gmail.com> 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 <fi...@adobe.com> 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" <b...@brian.io> 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 <gt...@gmail.com> 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 <pu...@gmail.com>
>> >>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 <do...@gmail.com>
>>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 <fi...@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?
>> >>>>
>> >>>>
>>
>>
>
>
>-- 
>@purplecabbage
>risingj.com

Re: Cordova CLI (and by proxy, platform) requirements

[Jesse <pu...@gmail.com>]

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 <fi...@adobe.com> 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" <b...@brian.io> 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 <gt...@gmail.com> 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 <pu...@gmail.com>
> >>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 <do...@gmail.com> 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 <fi...@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?
> >>>>
> >>>>
>
>


-- 
@purplecabbage
risingj.com

Re: Cordova CLI (and by proxy, platform) requirements

[Filip Maj <fi...@adobe.com>]

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" <b...@brian.io> 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 <gt...@gmail.com> 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 <pu...@gmail.com>
>>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 <do...@gmail.com> 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 <fi...@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?
>>>>
>>>>

Re: Cordova CLI (and by proxy, platform) requirements

[Brian LeRoux <b...@brian.io>]

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 <gt...@gmail.com> 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 <pu...@gmail.com> 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 <do...@gmail.com> 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 <fi...@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?
>>>
>>>

Re: Cordova CLI (and by proxy, platform) requirements

[Andrew Grieve <ag...@chromium.org>]

I think there are good reasons for either approach. How about we default to
an SDK path that's listed in your config file, and if none exists, use
what's on your PATH.



On Mon, Jan 28, 2013 at 6:25 PM, Gord Tanner <gt...@gmail.com> 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 <pu...@gmail.com>
> 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 <do...@gmail.com> 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 <fi...@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?
> >>
> >>
>

Re: Cordova CLI (and by proxy, platform) requirements

[Gord Tanner <gt...@gmail.com>]

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 <pu...@gmail.com> 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 <do...@gmail.com> 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 <fi...@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?
>> 
>> 

Re: Cordova CLI (and by proxy, platform) requirements

[Jesse MacFadyen <pu...@gmail.com>]

+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 <do...@gmail.com> 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 <fi...@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?
>
>

Re: Cordova CLI (and by proxy, platform) requirements

[Don Coleman <do...@gmail.com>]

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 <fi...@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?
>
>