cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: [cordova-cli] vendoring the platforms instead of lazy download
Date Fri, 22 Mar 2013 19:51:32 GMT
Yep, my biggest concern is that we are able to use CLI but still work
against master. I think braden's ask covers that though.

What good is working offline if you have no plugins? Are you suggesting
that we also include some set of plugins inside of cordova-cli?




On Fri, Mar 22, 2013 at 2:13 PM, Brian LeRoux <b@brian.io> wrote:

> It big. Certainly would be more efficient to lazy load, and cache so
> offline works.
>
> On Fri, Mar 22, 2013 at 11:04 AM, Gord Tanner <gtanner@gmail.com> wrote:
> > There was some issues over download size for our cli, any idea what the
> size of all the platforms are?
> >
> > Sent from my iPhone
> >
> > On 2013-03-22, at 1:42 PM, Braden Shepherdson <braden@chromium.org>
> wrote:
> >
> >> I'm content to have the vendoring, it has some advantages as you wrote.
> >>
> >> However, I would also very much like to add a platform that's running
> from
> >> somewhere on my local disk, as I described in my feature request in the
> doc.
> >>
> >> So I propose a flag like cordova platform add android
> >> --target=../../cordova-android   where that local directory can have
> >> whatever locally patched code I want.
> >>
> >> Braden
> >>
> >> On Fri, Mar 22, 2013 at 1:37 PM, Brian LeRoux <b@brian.io> wrote:
> >>
> >>> Right now we put the release of Cordova into the npm package for
> >>> cordova-cli and we version lock the two. (Codova/CLI 2.5.x ===
> >>> Cordova/Platform 2.5.latest).
> >>>
> >>> We did this because:
> >>>
> >>> - has to work offline
> >>> - cannot have a Git dep to do development
> >>> - issue tracking locked to the real version of Cordova
> >>>
> >>> We can solve all these issues. The code to do that isn't really a huge
> >>> deal. But to add it we gain very little that isn't already achieved by
> >>> vendoring. I'd like for us to be aware the current can be improved but
> >>> its low priority compared to, say, ripple and plugin integration.
> >>>
>

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