Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id ACDE6DF86 for ; Sun, 16 Sep 2012 02:30:27 +0000 (UTC) Received: (qmail 30881 invoked by uid 500); 16 Sep 2012 02:30:27 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 30856 invoked by uid 500); 16 Sep 2012 02:30:27 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 30847 invoked by uid 99); 16 Sep 2012 02:30:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Sep 2012 02:30:27 +0000 X-ASF-Spam-Status: No, hits=-1.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of fil@adobe.com designates 64.18.1.184 as permitted sender) Received: from [64.18.1.184] (HELO exprod6ob103.obsmtp.com) (64.18.1.184) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 16 Sep 2012 02:30:19 +0000 Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUFU5pVMOtEAgb8XK5M8mrqYkhT4eUa2g@postini.com; Sat, 15 Sep 2012 19:29:58 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q8G2RL5I011356 for ; Sat, 15 Sep 2012 19:27:21 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q8G2TuLc010491 for ; Sat, 15 Sep 2012 19:29:56 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sat, 15 Sep 2012 19:29:56 -0700 From: Filip Maj To: "callback-dev@incubator.apache.org" Date: Sat, 15 Sep 2012 19:29:53 -0700 Subject: Re: plugin tooling/specification Thread-Topic: plugin tooling/specification Thread-Index: Ac2TsykdqTq4z85zR22hQ6ZyibfAPw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Right. I'm ok with this but wanted to keep the exact cordova-powered platform projects as untouched as possible, so you could cd into those directories and do whatever you want (run usual cordova project commands, compile, etc). So removing the www from there forces everyone to always go through the tool. On 9/15/12 7:23 PM, "Anis KADRI" wrote: >On Sat, Sep 15, 2012 at 5:32 PM, Filip Maj wrote: > >> >> >Ohhh I think I understand. So basically it packages the www resources >>into >> >the binary at build time? >> >> Correct. Each platform's underlying implementation has its own "www" >> folder. At build time, the top-level www of your project gets copied >>into >> each platform before doing a compile for that platform. >> >> >> platforms/xxx/www gets destroyed and recreated on every build. See >> >> here. >> >> It's needed to build packages for every platform. It could arguably >>be >> >> destroyed after every build though. Fil is there a reason why that's >>not >> >> the case ? >> >> That is the case is it not? Line 57? >> >> Or do you mean, we should delete the platforms//www (or >> equivalent) after building? >> > >Yes that's what I meant. > > >> >> If the latter, I don't see the point. >> > >To avoid confusion. The reason why we're discussing this is because Mike >got confused after seeing the root www and a www in each platform >subfolder. There is also no reason to keep them around since they get >destroyed before every build anyway. So maybe they should just get >destroyed _after_ every build. You'd just recursively copy the folder >before every build. I don't really care either way. Just trying to avoid >the "Where do I drop my code?" scenario.