Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D5866F1DB for ; Mon, 25 Mar 2013 17:39:34 +0000 (UTC) Received: (qmail 80322 invoked by uid 500); 25 Mar 2013 17:39:34 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 80297 invoked by uid 500); 25 Mar 2013 17:39:34 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 80287 invoked by uid 99); 25 Mar 2013 17:39:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Mar 2013 17:39:34 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of brian.leroux@gmail.com designates 209.85.223.176 as permitted sender) Received: from [209.85.223.176] (HELO mail-ie0-f176.google.com) (209.85.223.176) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Mar 2013 17:39:30 +0000 Received: by mail-ie0-f176.google.com with SMTP id x14so7730395ief.21 for ; Mon, 25 Mar 2013 10:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=X8dW6t2QBnBqRvryIXkbLrmJo7TwirzqMEPxpclBoa4=; b=maAzt8RTHru9oYhCPRRwKq5Izj9aL+Rv6Kh/KAfk5cjOYO8S1cYBjJPqy/4wYqgtOz ufjg7fVnV6QhcEFOHXyZ2sWpRhQl9Vkuy9I7RueSXWL4lIlAH8dYO1HgKOkpMzds6+v7 UrlN9INJEmqON28bhq63OJSZxabwN2c4a1CJxo+hLJzSn01Eg3KI7mabR4CAHrb2xT4X hs9nu9IL7Slgt5jxUnCgNbSF0rJaAjJIqKXOIf9EukBHxX7lt2LnbsYkSKlVgCpe0His ufcVRnbo0lLwm7GFlY/4dwFjTdU1u4/LeKwfcQxJNmMpb0exavGL/wHNB72cPGCyv0hG io7Q== MIME-Version: 1.0 X-Received: by 10.50.208.68 with SMTP id mc4mr8561548igc.35.1364233150172; Mon, 25 Mar 2013 10:39:10 -0700 (PDT) Sender: brian.leroux@gmail.com Received: by 10.50.156.225 with HTTP; Mon, 25 Mar 2013 10:39:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Mar 2013 10:39:10 -0700 X-Google-Sender-Auth: 9yOjCH_zYmSRRblXqsU3ACkU_Gw Message-ID: Subject: Re: [cordova-cli] vendoring the platforms instead of lazy download From: Brian LeRoux To: dev@cordova.apache.org Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org To be clear, I am certain we all agree, but this is the future. We're working towards that future. We simply have too many users to not build the transition path into our releases. Maybe 3.0 is that time. Four months to move everything to plugins only. We'll see if we make it. On Mon, Mar 25, 2013 at 6:56 AM, Braden Shepherdson wrote: > I don't think there's a better place for that transition than moving to > 3.0, though. It's already a huge change with the CLI and plugins and the > rest. Also one of the key advantages to splitting up the core into plugins > is that we wanted to separate the permissions so that Cordova apps don't > ask for everything all the time, but only what they actually need. > > -1 to installing all the core plugins by default, and to lockstep > versioning them to the tools. > > > On Fri, Mar 22, 2013 at 6:08 PM, Brian LeRoux wrote: > >> Offline happens! >> >> I think by default nobody needs ANY of our APIs but the transition to >> that thinking will be the trick. >> >> >> On Fri, Mar 22, 2013 at 1:07 PM, Michal Mocny wrote: >> > Hmm, but then the versioning of the core plugins is tied to the version >> of >> > your cordova-cli tool at install time? >> > >> > I'm not opposed to installing cordova-core plugins by default which can >> > optionally be used as a fallback when or something, but I'm not sure that >> > every app you create should by default include those. You are right, >> this >> > is worthy of a longer discussion. >> > >> > (p.s. who goes offline?) >> > >> > -Michal >> > >> > >> > On Fri, Mar 22, 2013 at 4:01 PM, Brian LeRoux wrote: >> > >> >> Good question. >> >> >> >> My intuition is saying for as long as 3.x is around we preload w/ core >> >> plugins. We'll do as such w/ the PhoneGap distribution to minimize >> >> pain. Once ppl are used to the tools they'll be asking for us to >> >> default to none. >> >> >> >> My thoughts where that we'd start that way w/ Cordova but thats open >> too. >> >> >> >> >> >> On Fri, Mar 22, 2013 at 12:51 PM, Andrew Grieve >> >> wrote: >> >> > 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 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 >> >> 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 > > >> >> >> 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 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. >> >> >> >>> >> >> >> >> >> >>