+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 <mich...@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 <f...@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 > > ><mich...@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 <f...@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" <mich...@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 <f...@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. > > >>> >> > > >>> >> > > >>> > > >>> > > > > >
