cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Cordova CLI (and by proxy, platform) requirements
Date Tue, 29 Jan 2013 17:51:55 GMT
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" <michael@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 <fil@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" <purplecabbage@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 <fil@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 <gtanner@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
>><purplecabbage@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 <don.coleman@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 <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?
>> >> >>>>
>> >> >>>>
>> >>
>> >>
>> >
>> >
>> >--
>> >@purplecabbage
>> >risingj.com
>>
>>


Mime
View raw message