You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cordova.apache.org by Brian LeRoux <b...@brian.io> on 2013/03/22 18:53:15 UTC

[cordova-cli] versioning

Right now the global executable is version locked to a Cordova
release. If you have a project running 2.5 you are required to have
Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
downgrade (not really but you would to be safe).

In Grunt .4 the global executable is dumb. It just shells to locally
installed ./node_module version of Grunt. This enables project level
versioning of Grunt. Nice feature. We can do the same thing: with the
caveat that you would then require a package.json and ./node_modules
folder in our Cordova projects.

Discuss.

Re: [cordova-cli] versioning

Posted by Andrew Grieve <ag...@chromium.org>.

Maybe a good first stab at this (and maybe this works already), is to
ensure multiple versions of CLI can be installed at the same time.

e.g.

/usr/loca/cordova-cli/2.4
/usr/loca/cordova-cli/2.5
/usr/loca/cordova-cli/2.6

The global symlink in /usr/local/bin would point to the latest, but your
project can just call the relevant one directly.







On Fri, Mar 22, 2013 at 2:58 PM, tommy-carlos Williams
<to...@devgeeks.org>wrote:

> I don't have much to add except that I really like this about Grunt.
>
> However, it would get "interesting" with Cordova since the global is what
> creates a project in the first place. I still think it could work and have
> the global only responsible for creating dirs and setting up package.json
> stuff etc...
>
> +1 for looking into this.
>
> On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
>
> > Right now the global executable is version locked to a Cordova
> > release. If you have a project running 2.5 you are required to have
> > Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
> > downgrade (not really but you would to be safe).
> >
> > In Grunt .4 the global executable is dumb. It just shells to locally
> > installed ./node_module version of Grunt. This enables project level
> > versioning of Grunt. Nice feature. We can do the same thing: with the
> > caveat that you would then require a package.json and ./node_modules
> > folder in our Cordova projects.
> >
> > Discuss.
>

Re: [cordova-cli] versioning

Posted by Filip Maj <fi...@adobe.com>.

Noted in https://issues.apache.org/jira/browse/CB-2163

On 3/26/13 11:34 AM, "Braden Shepherdson" <br...@chromium.org> wrote:

>+1 to having ~/.cordova/thing/name/version. I know we name our releases
>foo-version, but this is an unambiguous split on a character that isn't
>legal in plugin names.
>
>Braden
>
>
>On Tue, Mar 26, 2013 at 1:34 PM, Michael Brooks
><mi...@michaelbrooks.ca>wrote:
>
>> >
>> >  ~/.cordova/<thing>/<name>/<version>
>>
>>
>> I originally wrote this but expected some backlash on breaking our
>> <name>-<version> convention. I agree, it makes the tool parsing easier.
>>
>> One thing, though: cordova-cli currently runs up the file tree searching
>> > for '.cordova' to identify a cordova-cli-generated project root (like
>> > git). Can we rename the cache folder to something other than .cordova?
>> > .cordovalibs or something?
>>
>>
>> I think we can solve this without renaming:
>>
>>     if .cordova path is HOME_DIR
>>        then path is not a project
>>
>> Thoughts?
>> Michael
>>
>> On Tue, Mar 26, 2013 at 10:24 AM, Filip Maj <fi...@adobe.com> wrote:
>>
>> > Yep, on it, and agree.
>> >
>> > One thing, though: cordova-cli currently runs up the file tree
>>searching
>> > for '.cordova' to identify a cordova-cli-generated project root (like
>> > git). Can we rename the cache folder to something other than .cordova?
>> > .cordovalibs or something?
>> >
>> > On 3/26/13 10:22 AM, "Brian LeRoux" <b...@brian.io> wrote:
>> >
>> > >Ok. I really like Mike's proposal. Think we should do this. Its
>>solves
>> > >most of our woe. Slight caveat that I would like the cache to be in
>> > >the format of:
>> > >
>> > > ~/.cordova/<thing>/<name>/<version>
>> > >
>> > >(To prevent weird string splitting logic/bugs emerging.)
>> > >
>> > >Fil: can you backlog this? I think it should come AFTER we finish
>> > >fixing up plugman/jsinstall and at least one plugin xplatform done.
>> > >
>> > >
>> > >On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks
>> > ><mi...@michaelbrooks.ca> wrote:
>> > >> With respect to the lazy-loading suggestion, I know Brian has
>>raised
>> the
>> > >> offline scenario on a previous thread.
>> > >>
>> > >> At install time of the CLI (`npm install -g cordova`), we can
>> lazy-load
>> > >>all
>> > >> platforms and sample app(s) for a given version.
>> > >>
>> > >> At install time of the CLI as a library (`npm install cordova`), we
>> can
>> > >>not
>> > >> lazy-load the platforms. This allows other distributions (e.g.
>> > >> `phonegap-cli`) to not be forced to download a large number of
>> > >> unnecessary files.
>> > >>
>> > >> Michael
>> > >>
>> > >> On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj <fi...@adobe.com> wrote:
>> > >>
>> > >>> Really like this. It a) slims down the cli tools by lazy loading
>>the
>> > >>> libraries as they are needed and b) solves the upgrade/downgrade
>> story,
>> > >>> since eventually you'll be able to simply change the version of
>>the
>> > >>> cordova npm dependency at a project-level.
>> > >>>
>> > >>> The only "downside" (not really) is that every generated
>>cordova-cli
>> > >>> project now is implicitly an npm project as it needs a
>>package.json
>> at
>> > >>>the
>> > >>> top-level.
>> > >>>
>> > >>> On 3/25/13 11:06 AM, "Michael Brooks" <mi...@michaelbrooks.ca>
>> > wrote:
>> > >>>
>> > >>> >+1 to locking the CLI to a version
>> > >>> >+1 to the Grunt vision
>> > >>> >
>> > >>> >However, I'd like to propose a different approach to the CLI
>> > >>>versioning
>> > >>> >and
>> > >>> >it can also solve the `create` command issue to help move
>>towards a
>> > >>>dumb
>> > >>> >global `cordova`.
>> > >>> >
>> > >>> >## Cordova-CLI
>> > >>> >
>> > >>> >- npm version is still associated with a Cordova distribution
>> > >>> >- Cordova-CLI does not vendor the Cordova distribution
>> > >>> >- Adding a platform will lazy load the platform distribution into
>> > >>> >~/.cordova/platform/<name>-<version>/
>> > >>> >    - We can lazy load by downloading a gzip from the Apache Git
>>web
>> > >>> >server
>> > >>> >- Next time the platform is needed, it is copied from
>> > >>> >~/.cordova/platform/<name>-<version/
>> > >>> >
>> > >>> >## Cordova Create
>> > >>> >
>> > >>> >- Creating an app should be a lazy load of the Hello World app
>> > >>> >   - Cached in ~/.cordova/app/<name>-<version>/
>> > >>> >- We can update the Hello World app to match a standard Cordova
>>CLI
>> > >>> >project
>> > >>> >- Now the global Cordova CLI is a dumb tool
>> > >>> >   - On create: lazy loading or copying the hello world app
>> > >>> >   - On project command: shelling to ./node_modules/bin/cordova
>> > >>><command>
>> > >>> >
>> > >>> >On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj <fi...@adobe.com> wrote:
>> > >>> >
>> > >>> >> As Tommay pointed out, you need to create the cordova project
>> > >>>structure
>> > >>> >>in
>> > >>> >> the first place with some manner of tool..
>> > >>> >>
>> > >>> >> On 3/22/13 11:58 AM, "tommy-carlos Williams"
>><to...@devgeeks.org>
>> > >>> wrote:
>> > >>> >>
>> > >>> >> >I don't have much to add except that I really like this about
>> > >>>Grunt.
>> > >>> >> >
>> > >>> >> >However, it would get "interesting" with Cordova since the
>>global
>> > >>>is
>> > >>> >>what
>> > >>> >> >creates a project in the first place. I still think it could
>>work
>> > >>>and
>> > >>> >> >have the global only responsible for creating dirs and
>>setting up
>> > >>> >> >package.json stuff etc...
>> > >>> >> >
>> > >>> >> >+1 for looking into this.
>> > >>> >> >
>> > >>> >> >On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
>> > >>> >> >
>> > >>> >> >> Right now the global executable is version locked to a
>>Cordova
>> > >>> >> >> release. If you have a project running 2.5 you are required
>>to
>> > >>>have
>> > >>> >> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you
>> > >>>need to
>> > >>> >> >> downgrade (not really but you would to be safe).
>> > >>> >> >>
>> > >>> >> >> In Grunt .4 the global executable is dumb. It just shells to
>> > >>>locally
>> > >>> >> >> installed ./node_module version of Grunt. This enables
>>project
>> > >>>level
>> > >>> >> >> versioning of Grunt. Nice feature. We can do the same thing:
>> > >>>with the
>> > >>> >> >> caveat that you would then require a package.json and
>> > >>>./node_modules
>> > >>> >> >> folder in our Cordova projects.
>> > >>> >> >>
>> > >>> >> >> Discuss.
>> > >>> >>
>> > >>> >>
>> > >>>
>> > >>>
>> >
>> >
>>

Re: [cordova-cli] versioning

Posted by Braden Shepherdson <br...@chromium.org>.

+1 to having ~/.cordova/thing/name/version. I know we name our releases
foo-version, but this is an unambiguous split on a character that isn't
legal in plugin names.

Braden


On Tue, Mar 26, 2013 at 1:34 PM, Michael Brooks <mi...@michaelbrooks.ca>wrote:

> >
> >  ~/.cordova/<thing>/<name>/<version>
>
>
> I originally wrote this but expected some backlash on breaking our
> <name>-<version> convention. I agree, it makes the tool parsing easier.
>
> One thing, though: cordova-cli currently runs up the file tree searching
> > for '.cordova' to identify a cordova-cli-generated project root (like
> > git). Can we rename the cache folder to something other than .cordova?
> > .cordovalibs or something?
>
>
> I think we can solve this without renaming:
>
>     if .cordova path is HOME_DIR
>        then path is not a project
>
> Thoughts?
> Michael
>
> On Tue, Mar 26, 2013 at 10:24 AM, Filip Maj <fi...@adobe.com> wrote:
>
> > Yep, on it, and agree.
> >
> > One thing, though: cordova-cli currently runs up the file tree searching
> > for '.cordova' to identify a cordova-cli-generated project root (like
> > git). Can we rename the cache folder to something other than .cordova?
> > .cordovalibs or something?
> >
> > On 3/26/13 10:22 AM, "Brian LeRoux" <b...@brian.io> wrote:
> >
> > >Ok. I really like Mike's proposal. Think we should do this. Its solves
> > >most of our woe. Slight caveat that I would like the cache to be in
> > >the format of:
> > >
> > > ~/.cordova/<thing>/<name>/<version>
> > >
> > >(To prevent weird string splitting logic/bugs emerging.)
> > >
> > >Fil: can you backlog this? I think it should come AFTER we finish
> > >fixing up plugman/jsinstall and at least one plugin xplatform done.
> > >
> > >
> > >On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks
> > ><mi...@michaelbrooks.ca> wrote:
> > >> With respect to the lazy-loading suggestion, I know Brian has raised
> the
> > >> offline scenario on a previous thread.
> > >>
> > >> At install time of the CLI (`npm install -g cordova`), we can
> lazy-load
> > >>all
> > >> platforms and sample app(s) for a given version.
> > >>
> > >> At install time of the CLI as a library (`npm install cordova`), we
> can
> > >>not
> > >> lazy-load the platforms. This allows other distributions (e.g.
> > >> `phonegap-cli`) to not be forced to download a large number of
> > >> unnecessary files.
> > >>
> > >> Michael
> > >>
> > >> On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj <fi...@adobe.com> wrote:
> > >>
> > >>> Really like this. It a) slims down the cli tools by lazy loading the
> > >>> libraries as they are needed and b) solves the upgrade/downgrade
> story,
> > >>> since eventually you'll be able to simply change the version of the
> > >>> cordova npm dependency at a project-level.
> > >>>
> > >>> The only "downside" (not really) is that every generated cordova-cli
> > >>> project now is implicitly an npm project as it needs a package.json
> at
> > >>>the
> > >>> top-level.
> > >>>
> > >>> On 3/25/13 11:06 AM, "Michael Brooks" <mi...@michaelbrooks.ca>
> > wrote:
> > >>>
> > >>> >+1 to locking the CLI to a version
> > >>> >+1 to the Grunt vision
> > >>> >
> > >>> >However, I'd like to propose a different approach to the CLI
> > >>>versioning
> > >>> >and
> > >>> >it can also solve the `create` command issue to help move towards a
> > >>>dumb
> > >>> >global `cordova`.
> > >>> >
> > >>> >## Cordova-CLI
> > >>> >
> > >>> >- npm version is still associated with a Cordova distribution
> > >>> >- Cordova-CLI does not vendor the Cordova distribution
> > >>> >- Adding a platform will lazy load the platform distribution into
> > >>> >~/.cordova/platform/<name>-<version>/
> > >>> >    - We can lazy load by downloading a gzip from the Apache Git web
> > >>> >server
> > >>> >- Next time the platform is needed, it is copied from
> > >>> >~/.cordova/platform/<name>-<version/
> > >>> >
> > >>> >## Cordova Create
> > >>> >
> > >>> >- Creating an app should be a lazy load of the Hello World app
> > >>> >   - Cached in ~/.cordova/app/<name>-<version>/
> > >>> >- We can update the Hello World app to match a standard Cordova CLI
> > >>> >project
> > >>> >- Now the global Cordova CLI is a dumb tool
> > >>> >   - On create: lazy loading or copying the hello world app
> > >>> >   - On project command: shelling to ./node_modules/bin/cordova
> > >>><command>
> > >>> >
> > >>> >On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj <fi...@adobe.com> wrote:
> > >>> >
> > >>> >> As Tommay pointed out, you need to create the cordova project
> > >>>structure
> > >>> >>in
> > >>> >> the first place with some manner of tool..
> > >>> >>
> > >>> >> On 3/22/13 11:58 AM, "tommy-carlos Williams" <to...@devgeeks.org>
> > >>> wrote:
> > >>> >>
> > >>> >> >I don't have much to add except that I really like this about
> > >>>Grunt.
> > >>> >> >
> > >>> >> >However, it would get "interesting" with Cordova since the global
> > >>>is
> > >>> >>what
> > >>> >> >creates a project in the first place. I still think it could work
> > >>>and
> > >>> >> >have the global only responsible for creating dirs and setting up
> > >>> >> >package.json stuff etc...
> > >>> >> >
> > >>> >> >+1 for looking into this.
> > >>> >> >
> > >>> >> >On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
> > >>> >> >
> > >>> >> >> Right now the global executable is version locked to a Cordova
> > >>> >> >> release. If you have a project running 2.5 you are required to
> > >>>have
> > >>> >> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you
> > >>>need to
> > >>> >> >> downgrade (not really but you would to be safe).
> > >>> >> >>
> > >>> >> >> In Grunt .4 the global executable is dumb. It just shells to
> > >>>locally
> > >>> >> >> installed ./node_module version of Grunt. This enables project
> > >>>level
> > >>> >> >> versioning of Grunt. Nice feature. We can do the same thing:
> > >>>with the
> > >>> >> >> caveat that you would then require a package.json and
> > >>>./node_modules
> > >>> >> >> folder in our Cordova projects.
> > >>> >> >>
> > >>> >> >> Discuss.
> > >>> >>
> > >>> >>
> > >>>
> > >>>
> >
> >
>

Re: [cordova-cli] versioning

Posted by Michael Brooks <mi...@michaelbrooks.ca>.

>
>  ~/.cordova/<thing>/<name>/<version>


I originally wrote this but expected some backlash on breaking our
<name>-<version> convention. I agree, it makes the tool parsing easier.

One thing, though: cordova-cli currently runs up the file tree searching
> for '.cordova' to identify a cordova-cli-generated project root (like
> git). Can we rename the cache folder to something other than .cordova?
> .cordovalibs or something?


I think we can solve this without renaming:

    if .cordova path is HOME_DIR
       then path is not a project

Thoughts?
Michael

On Tue, Mar 26, 2013 at 10:24 AM, Filip Maj <fi...@adobe.com> wrote:

> Yep, on it, and agree.
>
> One thing, though: cordova-cli currently runs up the file tree searching
> for '.cordova' to identify a cordova-cli-generated project root (like
> git). Can we rename the cache folder to something other than .cordova?
> .cordovalibs or something?
>
> On 3/26/13 10:22 AM, "Brian LeRoux" <b...@brian.io> wrote:
>
> >Ok. I really like Mike's proposal. Think we should do this. Its solves
> >most of our woe. Slight caveat that I would like the cache to be in
> >the format of:
> >
> > ~/.cordova/<thing>/<name>/<version>
> >
> >(To prevent weird string splitting logic/bugs emerging.)
> >
> >Fil: can you backlog this? I think it should come AFTER we finish
> >fixing up plugman/jsinstall and at least one plugin xplatform done.
> >
> >
> >On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks
> ><mi...@michaelbrooks.ca> wrote:
> >> With respect to the lazy-loading suggestion, I know Brian has raised the
> >> offline scenario on a previous thread.
> >>
> >> At install time of the CLI (`npm install -g cordova`), we can lazy-load
> >>all
> >> platforms and sample app(s) for a given version.
> >>
> >> At install time of the CLI as a library (`npm install cordova`), we can
> >>not
> >> lazy-load the platforms. This allows other distributions (e.g.
> >> `phonegap-cli`) to not be forced to download a large number of
> >> unnecessary files.
> >>
> >> Michael
> >>
> >> On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj <fi...@adobe.com> wrote:
> >>
> >>> Really like this. It a) slims down the cli tools by lazy loading the
> >>> libraries as they are needed and b) solves the upgrade/downgrade story,
> >>> since eventually you'll be able to simply change the version of the
> >>> cordova npm dependency at a project-level.
> >>>
> >>> The only "downside" (not really) is that every generated cordova-cli
> >>> project now is implicitly an npm project as it needs a package.json at
> >>>the
> >>> top-level.
> >>>
> >>> On 3/25/13 11:06 AM, "Michael Brooks" <mi...@michaelbrooks.ca>
> wrote:
> >>>
> >>> >+1 to locking the CLI to a version
> >>> >+1 to the Grunt vision
> >>> >
> >>> >However, I'd like to propose a different approach to the CLI
> >>>versioning
> >>> >and
> >>> >it can also solve the `create` command issue to help move towards a
> >>>dumb
> >>> >global `cordova`.
> >>> >
> >>> >## Cordova-CLI
> >>> >
> >>> >- npm version is still associated with a Cordova distribution
> >>> >- Cordova-CLI does not vendor the Cordova distribution
> >>> >- Adding a platform will lazy load the platform distribution into
> >>> >~/.cordova/platform/<name>-<version>/
> >>> >    - We can lazy load by downloading a gzip from the Apache Git web
> >>> >server
> >>> >- Next time the platform is needed, it is copied from
> >>> >~/.cordova/platform/<name>-<version/
> >>> >
> >>> >## Cordova Create
> >>> >
> >>> >- Creating an app should be a lazy load of the Hello World app
> >>> >   - Cached in ~/.cordova/app/<name>-<version>/
> >>> >- We can update the Hello World app to match a standard Cordova CLI
> >>> >project
> >>> >- Now the global Cordova CLI is a dumb tool
> >>> >   - On create: lazy loading or copying the hello world app
> >>> >   - On project command: shelling to ./node_modules/bin/cordova
> >>><command>
> >>> >
> >>> >On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj <fi...@adobe.com> wrote:
> >>> >
> >>> >> As Tommay pointed out, you need to create the cordova project
> >>>structure
> >>> >>in
> >>> >> the first place with some manner of tool..
> >>> >>
> >>> >> On 3/22/13 11:58 AM, "tommy-carlos Williams" <to...@devgeeks.org>
> >>> wrote:
> >>> >>
> >>> >> >I don't have much to add except that I really like this about
> >>>Grunt.
> >>> >> >
> >>> >> >However, it would get "interesting" with Cordova since the global
> >>>is
> >>> >>what
> >>> >> >creates a project in the first place. I still think it could work
> >>>and
> >>> >> >have the global only responsible for creating dirs and setting up
> >>> >> >package.json stuff etc...
> >>> >> >
> >>> >> >+1 for looking into this.
> >>> >> >
> >>> >> >On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
> >>> >> >
> >>> >> >> Right now the global executable is version locked to a Cordova
> >>> >> >> release. If you have a project running 2.5 you are required to
> >>>have
> >>> >> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you
> >>>need to
> >>> >> >> downgrade (not really but you would to be safe).
> >>> >> >>
> >>> >> >> In Grunt .4 the global executable is dumb. It just shells to
> >>>locally
> >>> >> >> installed ./node_module version of Grunt. This enables project
> >>>level
> >>> >> >> versioning of Grunt. Nice feature. We can do the same thing:
> >>>with the
> >>> >> >> caveat that you would then require a package.json and
> >>>./node_modules
> >>> >> >> folder in our Cordova projects.
> >>> >> >>
> >>> >> >> Discuss.
> >>> >>
> >>> >>
> >>>
> >>>
>
>

Re: [cordova-cli] versioning

Posted by Filip Maj <fi...@adobe.com>.

Yep, on it, and agree.

One thing, though: cordova-cli currently runs up the file tree searching
for '.cordova' to identify a cordova-cli-generated project root (like
git). Can we rename the cache folder to something other than .cordova?
.cordovalibs or something?

On 3/26/13 10:22 AM, "Brian LeRoux" <b...@brian.io> wrote:

>Ok. I really like Mike's proposal. Think we should do this. Its solves
>most of our woe. Slight caveat that I would like the cache to be in
>the format of:
>
> ~/.cordova/<thing>/<name>/<version>
>
>(To prevent weird string splitting logic/bugs emerging.)
>
>Fil: can you backlog this? I think it should come AFTER we finish
>fixing up plugman/jsinstall and at least one plugin xplatform done.
>
>
>On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks
><mi...@michaelbrooks.ca> wrote:
>> With respect to the lazy-loading suggestion, I know Brian has raised the
>> offline scenario on a previous thread.
>>
>> At install time of the CLI (`npm install -g cordova`), we can lazy-load
>>all
>> platforms and sample app(s) for a given version.
>>
>> At install time of the CLI as a library (`npm install cordova`), we can
>>not
>> lazy-load the platforms. This allows other distributions (e.g.
>> `phonegap-cli`) to not be forced to download a large number of
>> unnecessary files.
>>
>> Michael
>>
>> On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj <fi...@adobe.com> wrote:
>>
>>> Really like this. It a) slims down the cli tools by lazy loading the
>>> libraries as they are needed and b) solves the upgrade/downgrade story,
>>> since eventually you'll be able to simply change the version of the
>>> cordova npm dependency at a project-level.
>>>
>>> The only "downside" (not really) is that every generated cordova-cli
>>> project now is implicitly an npm project as it needs a package.json at
>>>the
>>> top-level.
>>>
>>> On 3/25/13 11:06 AM, "Michael Brooks" <mi...@michaelbrooks.ca> wrote:
>>>
>>> >+1 to locking the CLI to a version
>>> >+1 to the Grunt vision
>>> >
>>> >However, I'd like to propose a different approach to the CLI
>>>versioning
>>> >and
>>> >it can also solve the `create` command issue to help move towards a
>>>dumb
>>> >global `cordova`.
>>> >
>>> >## Cordova-CLI
>>> >
>>> >- npm version is still associated with a Cordova distribution
>>> >- Cordova-CLI does not vendor the Cordova distribution
>>> >- Adding a platform will lazy load the platform distribution into
>>> >~/.cordova/platform/<name>-<version>/
>>> >    - We can lazy load by downloading a gzip from the Apache Git web
>>> >server
>>> >- Next time the platform is needed, it is copied from
>>> >~/.cordova/platform/<name>-<version/
>>> >
>>> >## Cordova Create
>>> >
>>> >- Creating an app should be a lazy load of the Hello World app
>>> >   - Cached in ~/.cordova/app/<name>-<version>/
>>> >- We can update the Hello World app to match a standard Cordova CLI
>>> >project
>>> >- Now the global Cordova CLI is a dumb tool
>>> >   - On create: lazy loading or copying the hello world app
>>> >   - On project command: shelling to ./node_modules/bin/cordova
>>><command>
>>> >
>>> >On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj <fi...@adobe.com> wrote:
>>> >
>>> >> As Tommay pointed out, you need to create the cordova project
>>>structure
>>> >>in
>>> >> the first place with some manner of tool..
>>> >>
>>> >> On 3/22/13 11:58 AM, "tommy-carlos Williams" <to...@devgeeks.org>
>>> wrote:
>>> >>
>>> >> >I don't have much to add except that I really like this about
>>>Grunt.
>>> >> >
>>> >> >However, it would get "interesting" with Cordova since the global
>>>is
>>> >>what
>>> >> >creates a project in the first place. I still think it could work
>>>and
>>> >> >have the global only responsible for creating dirs and setting up
>>> >> >package.json stuff etc...
>>> >> >
>>> >> >+1 for looking into this.
>>> >> >
>>> >> >On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
>>> >> >
>>> >> >> Right now the global executable is version locked to a Cordova
>>> >> >> release. If you have a project running 2.5 you are required to
>>>have
>>> >> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you
>>>need to
>>> >> >> downgrade (not really but you would to be safe).
>>> >> >>
>>> >> >> In Grunt .4 the global executable is dumb. It just shells to
>>>locally
>>> >> >> installed ./node_module version of Grunt. This enables project
>>>level
>>> >> >> versioning of Grunt. Nice feature. We can do the same thing:
>>>with the
>>> >> >> caveat that you would then require a package.json and
>>>./node_modules
>>> >> >> folder in our Cordova projects.
>>> >> >>
>>> >> >> Discuss.
>>> >>
>>> >>
>>>
>>>

Re: [cordova-cli] versioning

Posted by Brian LeRoux <b...@brian.io>.

Ok. I really like Mike's proposal. Think we should do this. Its solves
most of our woe. Slight caveat that I would like the cache to be in
the format of:

 ~/.cordova/<thing>/<name>/<version>

(To prevent weird string splitting logic/bugs emerging.)

Fil: can you backlog this? I think it should come AFTER we finish
fixing up plugman/jsinstall and at least one plugin xplatform done.


On Mon, Mar 25, 2013 at 3:26 PM, Michael Brooks
<mi...@michaelbrooks.ca> wrote:
> With respect to the lazy-loading suggestion, I know Brian has raised the
> offline scenario on a previous thread.
>
> At install time of the CLI (`npm install -g cordova`), we can lazy-load all
> platforms and sample app(s) for a given version.
>
> At install time of the CLI as a library (`npm install cordova`), we can not
> lazy-load the platforms. This allows other distributions (e.g.
> `phonegap-cli`) to not be forced to download a large number of
> unnecessary files.
>
> Michael
>
> On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> Really like this. It a) slims down the cli tools by lazy loading the
>> libraries as they are needed and b) solves the upgrade/downgrade story,
>> since eventually you'll be able to simply change the version of the
>> cordova npm dependency at a project-level.
>>
>> The only "downside" (not really) is that every generated cordova-cli
>> project now is implicitly an npm project as it needs a package.json at the
>> top-level.
>>
>> On 3/25/13 11:06 AM, "Michael Brooks" <mi...@michaelbrooks.ca> wrote:
>>
>> >+1 to locking the CLI to a version
>> >+1 to the Grunt vision
>> >
>> >However, I'd like to propose a different approach to the CLI versioning
>> >and
>> >it can also solve the `create` command issue to help move towards a dumb
>> >global `cordova`.
>> >
>> >## Cordova-CLI
>> >
>> >- npm version is still associated with a Cordova distribution
>> >- Cordova-CLI does not vendor the Cordova distribution
>> >- Adding a platform will lazy load the platform distribution into
>> >~/.cordova/platform/<name>-<version>/
>> >    - We can lazy load by downloading a gzip from the Apache Git web
>> >server
>> >- Next time the platform is needed, it is copied from
>> >~/.cordova/platform/<name>-<version/
>> >
>> >## Cordova Create
>> >
>> >- Creating an app should be a lazy load of the Hello World app
>> >   - Cached in ~/.cordova/app/<name>-<version>/
>> >- We can update the Hello World app to match a standard Cordova CLI
>> >project
>> >- Now the global Cordova CLI is a dumb tool
>> >   - On create: lazy loading or copying the hello world app
>> >   - On project command: shelling to ./node_modules/bin/cordova <command>
>> >
>> >On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj <fi...@adobe.com> wrote:
>> >
>> >> As Tommay pointed out, you need to create the cordova project structure
>> >>in
>> >> the first place with some manner of tool..
>> >>
>> >> On 3/22/13 11:58 AM, "tommy-carlos Williams" <to...@devgeeks.org>
>> wrote:
>> >>
>> >> >I don't have much to add except that I really like this about Grunt.
>> >> >
>> >> >However, it would get "interesting" with Cordova since the global is
>> >>what
>> >> >creates a project in the first place. I still think it could work and
>> >> >have the global only responsible for creating dirs and setting up
>> >> >package.json stuff etc...
>> >> >
>> >> >+1 for looking into this.
>> >> >
>> >> >On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
>> >> >
>> >> >> Right now the global executable is version locked to a Cordova
>> >> >> release. If you have a project running 2.5 you are required to have
>> >> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
>> >> >> downgrade (not really but you would to be safe).
>> >> >>
>> >> >> In Grunt .4 the global executable is dumb. It just shells to locally
>> >> >> installed ./node_module version of Grunt. This enables project level
>> >> >> versioning of Grunt. Nice feature. We can do the same thing: with the
>> >> >> caveat that you would then require a package.json and ./node_modules
>> >> >> folder in our Cordova projects.
>> >> >>
>> >> >> Discuss.
>> >>
>> >>
>>
>>

Re: [cordova-cli] versioning

Posted by Michael Brooks <mi...@michaelbrooks.ca>.

With respect to the lazy-loading suggestion, I know Brian has raised the
offline scenario on a previous thread.

At install time of the CLI (`npm install -g cordova`), we can lazy-load all
platforms and sample app(s) for a given version.

At install time of the CLI as a library (`npm install cordova`), we can not
lazy-load the platforms. This allows other distributions (e.g.
`phonegap-cli`) to not be forced to download a large number of
unnecessary files.

Michael

On Mon, Mar 25, 2013 at 3:18 PM, Filip Maj <fi...@adobe.com> wrote:

> Really like this. It a) slims down the cli tools by lazy loading the
> libraries as they are needed and b) solves the upgrade/downgrade story,
> since eventually you'll be able to simply change the version of the
> cordova npm dependency at a project-level.
>
> The only "downside" (not really) is that every generated cordova-cli
> project now is implicitly an npm project as it needs a package.json at the
> top-level.
>
> On 3/25/13 11:06 AM, "Michael Brooks" <mi...@michaelbrooks.ca> wrote:
>
> >+1 to locking the CLI to a version
> >+1 to the Grunt vision
> >
> >However, I'd like to propose a different approach to the CLI versioning
> >and
> >it can also solve the `create` command issue to help move towards a dumb
> >global `cordova`.
> >
> >## Cordova-CLI
> >
> >- npm version is still associated with a Cordova distribution
> >- Cordova-CLI does not vendor the Cordova distribution
> >- Adding a platform will lazy load the platform distribution into
> >~/.cordova/platform/<name>-<version>/
> >    - We can lazy load by downloading a gzip from the Apache Git web
> >server
> >- Next time the platform is needed, it is copied from
> >~/.cordova/platform/<name>-<version/
> >
> >## Cordova Create
> >
> >- Creating an app should be a lazy load of the Hello World app
> >   - Cached in ~/.cordova/app/<name>-<version>/
> >- We can update the Hello World app to match a standard Cordova CLI
> >project
> >- Now the global Cordova CLI is a dumb tool
> >   - On create: lazy loading or copying the hello world app
> >   - On project command: shelling to ./node_modules/bin/cordova <command>
> >
> >On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj <fi...@adobe.com> wrote:
> >
> >> As Tommay pointed out, you need to create the cordova project structure
> >>in
> >> the first place with some manner of tool..
> >>
> >> On 3/22/13 11:58 AM, "tommy-carlos Williams" <to...@devgeeks.org>
> wrote:
> >>
> >> >I don't have much to add except that I really like this about Grunt.
> >> >
> >> >However, it would get "interesting" with Cordova since the global is
> >>what
> >> >creates a project in the first place. I still think it could work and
> >> >have the global only responsible for creating dirs and setting up
> >> >package.json stuff etc...
> >> >
> >> >+1 for looking into this.
> >> >
> >> >On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
> >> >
> >> >> Right now the global executable is version locked to a Cordova
> >> >> release. If you have a project running 2.5 you are required to have
> >> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
> >> >> downgrade (not really but you would to be safe).
> >> >>
> >> >> In Grunt .4 the global executable is dumb. It just shells to locally
> >> >> installed ./node_module version of Grunt. This enables project level
> >> >> versioning of Grunt. Nice feature. We can do the same thing: with the
> >> >> caveat that you would then require a package.json and ./node_modules
> >> >> folder in our Cordova projects.
> >> >>
> >> >> Discuss.
> >>
> >>
>
>

Re: [cordova-cli] versioning

Posted by Filip Maj <fi...@adobe.com>.

Really like this. It a) slims down the cli tools by lazy loading the
libraries as they are needed and b) solves the upgrade/downgrade story,
since eventually you'll be able to simply change the version of the
cordova npm dependency at a project-level.

The only "downside" (not really) is that every generated cordova-cli
project now is implicitly an npm project as it needs a package.json at the
top-level.

On 3/25/13 11:06 AM, "Michael Brooks" <mi...@michaelbrooks.ca> wrote:

>+1 to locking the CLI to a version
>+1 to the Grunt vision
>
>However, I'd like to propose a different approach to the CLI versioning
>and
>it can also solve the `create` command issue to help move towards a dumb
>global `cordova`.
>
>## Cordova-CLI
>
>- npm version is still associated with a Cordova distribution
>- Cordova-CLI does not vendor the Cordova distribution
>- Adding a platform will lazy load the platform distribution into
>~/.cordova/platform/<name>-<version>/
>    - We can lazy load by downloading a gzip from the Apache Git web
>server
>- Next time the platform is needed, it is copied from
>~/.cordova/platform/<name>-<version/
>
>## Cordova Create
>
>- Creating an app should be a lazy load of the Hello World app
>   - Cached in ~/.cordova/app/<name>-<version>/
>- We can update the Hello World app to match a standard Cordova CLI
>project
>- Now the global Cordova CLI is a dumb tool
>   - On create: lazy loading or copying the hello world app
>   - On project command: shelling to ./node_modules/bin/cordova <command>
>
>On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> As Tommay pointed out, you need to create the cordova project structure
>>in
>> the first place with some manner of tool..
>>
>> On 3/22/13 11:58 AM, "tommy-carlos Williams" <to...@devgeeks.org> wrote:
>>
>> >I don't have much to add except that I really like this about Grunt.
>> >
>> >However, it would get "interesting" with Cordova since the global is
>>what
>> >creates a project in the first place. I still think it could work and
>> >have the global only responsible for creating dirs and setting up
>> >package.json stuff etc...
>> >
>> >+1 for looking into this.
>> >
>> >On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
>> >
>> >> Right now the global executable is version locked to a Cordova
>> >> release. If you have a project running 2.5 you are required to have
>> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
>> >> downgrade (not really but you would to be safe).
>> >>
>> >> In Grunt .4 the global executable is dumb. It just shells to locally
>> >> installed ./node_module version of Grunt. This enables project level
>> >> versioning of Grunt. Nice feature. We can do the same thing: with the
>> >> caveat that you would then require a package.json and ./node_modules
>> >> folder in our Cordova projects.
>> >>
>> >> Discuss.
>>
>>

Re: [cordova-cli] versioning

Posted by Michael Brooks <mi...@michaelbrooks.ca>.

+1 to locking the CLI to a version
+1 to the Grunt vision

However, I'd like to propose a different approach to the CLI versioning and
it can also solve the `create` command issue to help move towards a dumb
global `cordova`.

## Cordova-CLI

- npm version is still associated with a Cordova distribution
- Cordova-CLI does not vendor the Cordova distribution
- Adding a platform will lazy load the platform distribution into
~/.cordova/platform/<name>-<version>/
    - We can lazy load by downloading a gzip from the Apache Git web server
- Next time the platform is needed, it is copied from
~/.cordova/platform/<name>-<version/

## Cordova Create

- Creating an app should be a lazy load of the Hello World app
   - Cached in ~/.cordova/app/<name>-<version>/
- We can update the Hello World app to match a standard Cordova CLI project
- Now the global Cordova CLI is a dumb tool
   - On create: lazy loading or copying the hello world app
   - On project command: shelling to ./node_modules/bin/cordova <command>

On Fri, Mar 22, 2013 at 1:08 PM, Filip Maj <fi...@adobe.com> wrote:

> As Tommay pointed out, you need to create the cordova project structure in
> the first place with some manner of tool..
>
> On 3/22/13 11:58 AM, "tommy-carlos Williams" <to...@devgeeks.org> wrote:
>
> >I don't have much to add except that I really like this about Grunt.
> >
> >However, it would get "interesting" with Cordova since the global is what
> >creates a project in the first place. I still think it could work and
> >have the global only responsible for creating dirs and setting up
> >package.json stuff etc...
> >
> >+1 for looking into this.
> >
> >On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
> >
> >> Right now the global executable is version locked to a Cordova
> >> release. If you have a project running 2.5 you are required to have
> >> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
> >> downgrade (not really but you would to be safe).
> >>
> >> In Grunt .4 the global executable is dumb. It just shells to locally
> >> installed ./node_module version of Grunt. This enables project level
> >> versioning of Grunt. Nice feature. We can do the same thing: with the
> >> caveat that you would then require a package.json and ./node_modules
> >> folder in our Cordova projects.
> >>
> >> Discuss.
>
>

Re: [cordova-cli] versioning

Posted by Filip Maj <fi...@adobe.com>.

As Tommay pointed out, you need to create the cordova project structure in
the first place with some manner of tool..

On 3/22/13 11:58 AM, "tommy-carlos Williams" <to...@devgeeks.org> wrote:

>I don't have much to add except that I really like this about Grunt.
>
>However, it would get "interesting" with Cordova since the global is what
>creates a project in the first place. I still think it could work and
>have the global only responsible for creating dirs and setting up
>package.json stuff etc...
>
>+1 for looking into this.
>
>On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:
>
>> Right now the global executable is version locked to a Cordova
>> release. If you have a project running 2.5 you are required to have
>> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
>> downgrade (not really but you would to be safe).
>> 
>> In Grunt .4 the global executable is dumb. It just shells to locally
>> installed ./node_module version of Grunt. This enables project level
>> versioning of Grunt. Nice feature. We can do the same thing: with the
>> caveat that you would then require a package.json and ./node_modules
>> folder in our Cordova projects.
>> 
>> Discuss.

Re: [cordova-cli] versioning

Posted by tommy-carlos Williams <to...@devgeeks.org>.

I don't have much to add except that I really like this about Grunt. 

However, it would get "interesting" with Cordova since the global is what creates a project in the first place. I still think it could work and have the global only responsible for creating dirs and setting up package.json stuff etc...

+1 for looking into this.

On 23/03/2013, at 4:53, Brian LeRoux <b...@brian.io> wrote:

> Right now the global executable is version locked to a Cordova
> release. If you have a project running 2.5 you are required to have
> Cordova/CLI 2.5. If you need to then work in Cordova 2.4 you need to
> downgrade (not really but you would to be safe).
> 
> In Grunt .4 the global executable is dumb. It just shells to locally
> installed ./node_module version of Grunt. This enables project level
> versioning of Grunt. Nice feature. We can do the same thing: with the
> caveat that you would then require a package.json and ./node_modules
> folder in our Cordova projects.
> 
> Discuss.