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 8F8E2FDD5 for ; Tue, 26 Mar 2013 17:19:31 +0000 (UTC) Received: (qmail 87621 invoked by uid 500); 26 Mar 2013 17:19:31 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 87540 invoked by uid 500); 26 Mar 2013 17:19:31 -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 87530 invoked by uid 99); 26 Mar 2013 17:19:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Mar 2013 17:19:31 +0000 X-ASF-Spam-Status: No, hits=0.3 required=5.0 tests=FRT_ADOBE2,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com designates 209.85.223.177 as permitted sender) Received: from [209.85.223.177] (HELO mail-ie0-f177.google.com) (209.85.223.177) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 26 Mar 2013 17:19:25 +0000 Received: by mail-ie0-f177.google.com with SMTP id tp5so4843912ieb.36 for ; Tue, 26 Mar 2013 10:19:04 -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=TNHzQaBuagTcneF8FGwG+68jcU8sx0vOjisdUrp+V8w=; b=SRnCs0aqdneIarLytQ445hWNd55tzl1DWdHJSdefaL4WgsGsVoGJ6r/oKVd+SkbBge wFqrVb28UgUufkF6jlXezVHYzN59w+8ru/NkOhPh56TtCjJjUs8j5uh5TLjiRDKHgpGv cNHL1dtR1Me+STvy7oyZ/15c+7KNbMJTvs8tN/krStwg+QUfABp09es13WW16eb6FUth ZKEDmlAdW/na5itXC9Ja/3sSOwtwm8i9RjetoowmMiD17oWMPeZhT5lgbagEcE7NegrS ZvAXDGIssje3UwxfBmJwlq8HmcUJT5/r5CuHgRUsVcnNpEdstw8iJyU22SGQmP0otUD3 O+BQ== MIME-Version: 1.0 X-Received: by 10.42.107.73 with SMTP id c9mr3462145icp.9.1364318344533; Tue, 26 Mar 2013 10:19:04 -0700 (PDT) Sender: brian.leroux@gmail.com Received: by 10.50.156.225 with HTTP; Tue, 26 Mar 2013 10:19:04 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Mar 2013 10:19:04 -0700 X-Google-Sender-Auth: 4D0U2mEoWeREphLfG5yKf9yRKes Message-ID: Subject: Re: Moving www into an app folder 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 I'm into this proposal fwiw too. Think we need to get plugman/jsinstall/plugins for all things covered before we tread back into CLI land. On Mon, Mar 25, 2013 at 3:44 PM, Michal Mocny wrote: > Thanks Fil. > > Theres a long list of feature requests we've just pushed on y'all so I > understand. > > > On Mon, Mar 25, 2013 at 6:31 PM, Filip Maj wrote: > >> Not at all, I think it would be a great feature to land. >> >> Agree that specifying dependencies in the app manifest, config.xml >> currently, is the way to go. >> >> I'm trying to organize the goal/direction of moving to this approach in my >> head together with all the other moves we are making. Keeping the >> objectives high level and working on iterating to reach those objectives >> is what I want to keep clear in my mind. >> >> On 3/25/13 3:22 PM, "Michal Mocny" wrote: >> >> >Precisely! I thought plugin dependancies for apps was already on the >> >roadmap. Is that request still debatable? >> > >> > >> >On Mon, Mar 25, 2013 at 6:01 PM, Braden Shepherdson >> >wrote: >> > >> >> I agree that this recreation is a goal, but I don't think moving >> >>plugins/ >> >> under app/ is the right way to do it. >> >> >> >> I think the right way to do it is to specify the plugin dependencies of >> >>the >> >> app in app/. Currently that means in the documentation or a script, in >> >>the >> >> future probably in config.xml. >> >> >> >> Braden >> >> >> >> >> >> On Mon, Mar 25, 2013 at 4:09 PM, Filip Maj wrote: >> >> >> >> > I think the issue here is: how far do we want to dictate the project >> >> > structure for a cordova-cli-generated app? >> >> > >> >> > Merges kind of "evolved" out of an actual user who needed a viable use >> >> > case covered (thanks Michael Wolf!). It is where it is for really no >> >> > reason other than "this is a good feature to have." Consider it like a >> >> > first pass at an implementation. We can iterate on it to make it >> >>better. >> >> > >> >> > One thing about the app/ proposal is that the stated objective is to >> >> > enable shipping a single directory to be able to recreate the native >> >> > projects. If that is the case, wouldn't we also have to move the >> >>plugins >> >> > into app/ ? >> >> > >> >> > On 3/25/13 11:25 AM, "Braden Shepherdson" >> wrote: >> >> > >> >> > >They are, right now, a kind of middle ground. If you rm -rf'd the >> >> > >directory, it wouldn't be all better on the next cordova prepare; >> >>that's >> >> > >where we hope to reach soon. >> >> > > >> >> > >On the other hand, you definitely shouldn't be having code in them - >> >> > >native >> >> > >or otherwise - that didn't come from a plugin or from www/. So they >> >> could >> >> > >be reconstructed from data stored elsewhere, which makes them mostly >> >>a >> >> > >build artifact, and certainly not necessary to store in your source >> >> > >control. >> >> > > >> >> > >Braden >> >> > > >> >> > > >> >> > >On Mon, Mar 25, 2013 at 2:17 PM, Brian LeRoux wrote: >> >> > > >> >> > >> While this might be our goal it is in no way true that ./platforms >> >>ia >> >> > >> build artifact today or anytime soon. >> >> > >> >> >> > >> On Mon, Mar 25, 2013 at 10:55 AM, Braden Shepherdson >> >> > >> wrote: >> >> > >> > The same is /not/ true of the current structure, because one >> >> > >>(probably) >> >> > >> > doesn't want to be committing build artifacts like platforms/, or >> >> > >>cached >> >> > >> > third-party data like plugins/ into your git repo. >> >> > >> > >> >> > >> > The idea here is that everything under app/ is what you would >> >>keep >> >> in >> >> > >>git >> >> > >> > for a team working on an app: www, config.xml, docs, samples, >> >>etc. >> >> > >> Putting >> >> > >> > that content at the top-level instead means you have lots of >> >>extra >> >> > >>build >> >> > >> > artifact cruft in your git repo, or your devs just have to know >> >>that >> >> > >> > platforms/ and plugins/ are in .gitignore. >> >> > >> > >> >> > >> > Braden >> >> > >> > >> >> > >> > >> >> > >> > On Mon, Mar 25, 2013 at 1:45 PM, Brian LeRoux >> wrote: >> >> > >> > >> >> > >> >> But, if you go up one level, the same is true w/ the current >> >> > >> >> structure. Its just an organizational difference? (Thats a >> >> perfectly >> >> > >> >> ok answer of course. Aesthetics and symmetry are plenty >> >>convincing >> >> > >> >> arguments.) >> >> > >> >> >> >> > >> >> In my view ./merges isn't your app. The ./merges dir is in >> >>parts of >> >> > >> >> your app on a per platform basis. Hence the logic for having it >> >> exist >> >> > >> >> at the same level as ./platforms. >> >> > >> >> >> >> > >> >> Having config.xml exist in the ../www does bother me. >> >> > >> >> >> >> > >> >> >> >> > >> >> On Mon, Mar 25, 2013 at 10:33 AM, Braden Shepherdson >> >> > >> >> wrote: >> >> > >> >> > It allows easier cloning of your app (meaning the www, >> >> config.xml, >> >> > >>and >> >> > >> >> any >> >> > >> >> > samples and so on) into a self-contained directory. It also >> >>lets >> >> us >> >> > >> keep >> >> > >> >> > the user's app within a single top-level directory (rather >> >>than >> >> www >> >> > >> and >> >> > >> >> > merges and potentially more later). >> >> > >> >> > >> >> > >> >> > Because only the www (and merges) would get pulled into the >> >> actual >> >> > >> app, >> >> > >> >> any >> >> > >> >> > docs, samples, tests, or other miscellany in the git repo >> >>won't >> >> be >> >> > >> part >> >> > >> >> of >> >> > >> >> > the app. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > On Mon, Mar 25, 2013 at 1:19 PM, Brian LeRoux >> >> wrote: >> >> > >> >> > >> >> > >> >> >> Ok, let me try again. What is precisely problem we are >> >>solving >> >> by >> >> > >> >> >> changing the structure? To be clear, I'm not really against >> >>or >> >> for >> >> > >> it. >> >> > >> >> >> I just don't understand why this is important. >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> On Mon, Mar 25, 2013 at 10:06 AM, Braden Shepherdson >> >> > >> >> >> wrote: >> >> > >> >> >> > +1 is still a handy means of displaying your support or >> >> > >>otherwise. >> >> > >> >> >> > >> >> > >> >> >> > If you do want to version the platforms/ and plugins/ >> >>folders >> >> at >> >> > >> the >> >> > >> >> top >> >> > >> >> >> > level, you can do that. If you're versioning everything, >> >>then >> >> > >>you >> >> > >> >> should >> >> > >> >> >> be >> >> > >> >> >> > checking out that master repo, rather than the master repo >> >>and >> >> > >>then >> >> > >> >> the >> >> > >> >> >> app >> >> > >> >> >> > repo inside it, so it should all work fine. >> >> > >> >> >> > >> >> > >> >> >> > Braden >> >> > >> >> >> > >> >> > >> >> >> > >> >> > >> >> >> > On Mon, Mar 25, 2013 at 12:37 PM, Brian LeRoux > > >> >> > >>wrote: >> >> > >> >> >> > >> >> > >> >> >> >> (Btw this isn't a vote thread guys.) >> >> > >> >> >> >> >> >> > >> >> >> >> On Mon, Mar 25, 2013 at 9:37 AM, Brian LeRoux > > >> >> > >>wrote: >> >> > >> >> >> >> > So, what if you want to version the ./platorms folder? I >> >> > >>don't >> >> > >> like >> >> > >> >> >> >> > it, but ppl will do. >> >> > >> >> >> >> > >> >> > >> >> >> >> > On Mon, Mar 25, 2013 at 9:10 AM, James Jong < >> >> > >> wjamesjong@gmail.com> >> >> > >> >> >> >> wrote: >> >> > >> >> >> >> >> +1 for app folder and cordova create >> >> > >> >> >> >> >> I would like to see it support a git-URL or local. >> >>It's >> >> > >>nice >> >> > >> to >> >> > >> >> have >> >> > >> >> >> >> it all neatly in app/ but can also see arguments for >> >>having >> >> > >>www/ >> >> > >> as >> >> > >> >> >> >> top-level. >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> -James Jong >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> On Mar 25, 2013, at 10:32 AM, Braden Shepherdson < >> >> > >> >> >> braden@chromium.org> >> >> > >> >> >> >> wrote: >> >> > >> >> >> >> >> >> >> > >> >> >> >> >>> A big +1 from me for this world, Michal's option 2. >> >> > >> >> >> >> >>> >> >> > >> >> >> >> >>> I want to be able to cordova create , >> >>and >> >> > >>have >> >> > >> it >> >> > >> >> >> create >> >> > >> >> >> >> an >> >> > >> >> >> >> >>> empty project where the app/ directory is the git >> >>repo. >> >> > >> >> >> >> >>> >> >> > >> >> >> >> >>> Then a full project might look like this: >> >> > >> >> >> >> >>> >> >> > >> >> >> >> >>> platforms/ >> >> > >> >> >> >> >>> android/ >> >> > >> >> >> >> >>> ios/ >> >> > >> >> >> >> >>> plugins/ >> >> > >> >> >> >> >>> ... >> >> > >> >> >> >> >>> app/ >> >> > >> >> >> >> >>> merges/ >> >> > >> >> >> >> >>> ... >> >> > >> >> >> >> >>> www/ >> >> > >> >> >> >> >>> ... >> >> > >> >> >> >> >>> README.md >> >> > >> >> >> >> >>> config.xml >> >> > >> >> >> >> >>> docs/ >> >> > >> >> >> >> >>> etc... >> >> > >> >> >> >> >>> >> >> > >> >> >> >> >>> So I can have whatever meta-information I want inside >> >>my >> >> > >>app/ >> >> > >> >> (and >> >> > >> >> >> >> >>> therefore my git repo) - tests, docs, samples, etc. - >> >>but >> >> > >>not >> >> > >> >> inside >> >> > >> >> >> >> the >> >> > >> >> >> >> >>> www that actually ships. This makes it sane to have >> >>just >> >> > >>the >> >> > >> >> app's >> >> > >> >> >> >> files in >> >> > >> >> >> >> >>> git, but not the platforms/ or plugins/ directories. >> >> > >> >> >> >> >>> >> >> > >> >> >> >> >>> Braden >> >> > >> >> >> >> >>> >> >> > >> >> >> >> >>> >> >> > >> >> >> >> >>> On Sun, Mar 24, 2013 at 6:02 PM, Michal Mocny < >> >> > >> >> mmocny@chromium.org> >> >> > >> >> >> >> wrote: >> >> > >> >> >> >> >>> >> >> > >> >> >> >> >>>> So a few questions: >> >> > >> >> >> >> >>>> >> >> > >> >> >> >> >>>> 0. Do we want to support app distribution? Sample >> >>apps, >> >> > >>Test >> >> > >> >> >> Harness, >> >> > >> >> >> >> >>>> working in a team, open source projects.. hint at >> >>yes, >> >> > >>but we >> >> > >> >> could >> >> > >> >> >> >> just >> >> > >> >> >> >> >>>> leave that to be done manually. >> >> > >> >> >> >> >>>> 1. Do we want to support app documentation? Where >> >>would >> >> > >>you >> >> > >> put >> >> > >> >> it >> >> > >> >> >> if >> >> > >> >> >> >> you >> >> > >> >> >> >> >>>> wanted to ship it along with a app? >> >> > >> >> >> >> >>>> 2. Do we have any apps already using the merges/ >> >>folder? >> >> > >> How do >> >> > >> >> >> they >> >> > >> >> >> >> ship >> >> > >> >> >> >> >>>> it? >> >> > >> >> >> >> >>>> >> >> > >> >> >> >> >>>> I suspect what would happen now is app devs would >> >> already >> >> > >> need >> >> > >> >> an >> >> > >> >> >> app >> >> > >> >> >> >> >>>> folder to keep all the pieces, would cordova create a >> >> > >> workspace, >> >> > >> >> >> and >> >> > >> >> >> >> >>>> link/copy over www/ and merges/. >> >> > >> >> >> >> >>>> >> >> > >> >> >> >> >>>> If we wanted to support app distribution (such that >> >>say >> >> > >> cordova >> >> > >> >> >> create >> >> > >> >> >> >> >>>> ), we would need to support importing >> >>from >> >> an >> >> > >> app >> >> > >> >> >> folder >> >> > >> >> >> >> (for >> >> > >> >> >> >> >>>> the two folder merges and www reason alone). Yet we >> >> > >> currently >> >> > >> >> >> plan to >> >> > >> >> >> >> >>>> unpack that app folder inside the workspace. >> >> > >> >> >> >> >>>> >> >> > >> >> >> >> >>>> -Michal >> >> > >> >> >> >> >>>> >> >> > >> >> >> >> >>>> >> >> > >> >> >> >> >>>> On Sun, Mar 24, 2013 at 5:22 PM, Brian LeRoux < >> >> b@brian.io >> >> > > >> >> > >> >> wrote: >> >> > >> >> >> >> >>>> >> >> > >> >> >> >> >>>>> Ya no worries we'll advocate on best for the >> >>project vs >> >> > >>our >> >> > >> >> >> >> particular >> >> > >> >> >> >> >>>>> downstream. File path handling, while tedious, is >> >>most >> >> > >> >> certainly >> >> > >> >> >> not >> >> > >> >> >> >> a >> >> > >> >> >> >> >>>>> reason to block a reasonable change. >> >> > >> >> >> >> >>>>> >> >> > >> >> >> >> >>>>> I think this is reasonable but not convinced it is a >> >> win. >> >> > >> >> >> >> >>>>> >> >> > >> >> >> >> >>>>> On Fri, Mar 22, 2013 at 7:35 PM, Michal Mocny < >> >> > >> >> >> mmocny@chromium.org> >> >> > >> >> >> >> >>>> wrote: >> >> > >> >> >> >> >>>>>> Ah yes, I see what you are asking. The point being >> >> that >> >> > >> >> phonegap >> >> > >> >> >> >> build >> >> > >> >> >> >> >>>>>> would need to change to work with the new >> >>structure. >> >> > >> >> >> >> >>>>>> >> >> > >> >> >> >> >>>>>> Its a fair point, and its important generally to >> >>not >> >> > >>harm >> >> > >> >> >> downstream >> >> > >> >> >> >> >>>>>> distributions on purpose, but I think we generally >> >> > >>should >> >> > >> do >> >> > >> >> >> whats >> >> > >> >> >> >> best >> >> > >> >> >> >> >>>>> for >> >> > >> >> >> >> >>>>>> cordova and give downstream every opportunity to >> >> adjust. >> >> > >> With >> >> > >> >> >> this >> >> > >> >> >> >> >>>>>> particular proposal I can only image it would not >> >>be a >> >> > >> >> problem, >> >> > >> >> >> >> >>>>> especially >> >> > >> >> >> >> >>>>>> if they use the same tools internally (but the >> >>actual >> >> > >> phonegap >> >> > >> >> >> build >> >> > >> >> >> >> >>>> team >> >> > >> >> >> >> >>>>>> should speak here). >> >> > >> >> >> >> >>>>>> >> >> > >> >> >> >> >>>>>> -Michal >> >> > >> >> >> >> >>>>>> >> >> > >> >> >> >> >>>>>> >> >> > >> >> >> >> >>>>>> On Fri, Mar 22, 2013 at 10:27 PM, Tommy-Carlos >> >> Williams >> >> > >> >> >> >> >>>>>> wrote: >> >> > >> >> >> >> >>>>>> >> >> > >> >> >> >> >>>>>>> I just mean that build expects config.xml to be in >> >> www, >> >> > >> yeah? >> >> > >> >> >> >> >>>>>>> >> >> > >> >> >> >> >>>>>>> >> >> > >> >> >> >> >>>>>>> >> >> > >> >> >> >> >>>>>>> On 23/03/2013, at 1:12 PM, Michal Mocny < >> >> > >> mmocny@chromium.org >> >> > >> >> > >> >> > >> >> >> >> wrote: >> >> > >> >> >> >> >>>>>>> >> >> > >> >> >> >> >>>>>>>> But isn't the app incomplete without the merges >> >> > >>folder? >> >> > >> >> Most >> >> > >> >> >> apps >> >> > >> >> >> >> >>>>>>> probably >> >> > >> >> >> >> >>>>>>>> don't use it, but for those that do, a zip of www >> >> > >>isn't >> >> > >> >> enough, >> >> > >> >> >> >> you >> >> > >> >> >> >> >>>>>>> already >> >> > >> >> >> >> >>>>>>>> need to ship more than just the www folder. >> >> Creating >> >> > >>an >> >> > >> app >> >> > >> >> >> >> folder >> >> > >> >> >> >> >>>>> would >> >> > >> >> >> >> >>>>>>>> actually make the situation easier I think. >> >> > >> >> >> >> >>>>>>>> >> >> > >> >> >> >> >>>>>>>> project >> >> > >> >> >> >> >>>>>>>> - platforms >> >> > >> >> >> >> >>>>>>>> - .. >> >> > >> >> >> >> >>>>>>>> - plugins >> >> > >> >> >> >> >>>>>>>> - ... >> >> > >> >> >> >> >>>>>>>> - app(s?) >> >> > >> >> >> >> >>>>>>>> - www/ >> >> > >> >> >> >> >>>>>>>> - merges/ >> >> > >> >> >> >> >>>>>>>> - config.xml >> >> > >> >> >> >> >>>>>>>> - README.md >> >> > >> >> >> >> >>>>>>>> - docs/ >> >> > >> >> >> >> >>>>>>>> - etc stuff that doesn't get copied into >> >>platform/ >> >> > >> output on >> >> > >> >> >> build >> >> > >> >> >> >> >>>>>>>> >> >> > >> >> >> >> >>>>>>>> >> >> > >> >> >> >> >>>>>>>> (oh, and hey, notice the similarity in structure >> >>to >> >> > >> plugins? >> >> > >> >> >> just >> >> > >> >> >> >> >>>>>>> sayin..) >> >> > >> >> >> >> >>>>>>>> >> >> > >> >> >> >> >>>>>>>> >> >> > >> >> >> >> >>>>>>>> >> >> > >> >> >> >> >>>>>>>> On Fri, Mar 22, 2013 at 7:00 PM, Tommy-Carlos >> >> Williams >> >> > >> >> >> >> >>>>>>>> wrote: >> >> > >> >> >> >> >>>>>>>> >> >> > >> >> >> >> >>>>>>>>> Can I just ask a question about this? >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>>>> Is the config.xml supposed to be compatible with >> >> > >> >> >> >> >>>> build.phonegap.comat >> >> > >> >> >> >> >>>>>>>>> all? >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>>>> I ask because I could see a scenario where you >> >> might >> >> > >> want >> >> > >> >> to >> >> > >> >> >> use >> >> > >> >> >> >> >>>> the >> >> > >> >> >> >> >>>>> cli >> >> > >> >> >> >> >>>>>>>>> tools, but still utilise build.phonegap.com for >> >> > other >> >> > >> >> >> platforms >> >> > >> >> >> >> >>>> (or >> >> > >> >> >> >> >>>>>>> even >> >> > >> >> >> >> >>>>>>>>> for the ones supported by the cli). >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>>>> If the cli config.xml is "build" compatible, it >> >> makes >> >> > >> sense >> >> > >> >> >> for >> >> > >> >> >> >> it >> >> > >> >> >> >> >>>>> to be >> >> > >> >> >> >> >>>>>>>>> in the www folder so that the www folder can go >> >> > >> straight to >> >> > >> >> >> >> >>>>>>>>> build.phonegap.com. >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>>>> On 23/03/2013, at 9:15 AM, Brian LeRoux < >> >> b@brian.io> >> >> > >> >> wrote: >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>> I'm ok with ./merges at the same level as ./www >> >> but >> >> > >>the >> >> > >> >> >> >> config.xml >> >> > >> >> >> >> >>>>>>>>>> inside of ./www bugs me too. I think having a >> >>root >> >> > >> level >> >> > >> >> >> ./www >> >> > >> >> >> >> >>>> just >> >> > >> >> >> >> >>>>>>>>>> works well mentally in that its obvious whats >> >> there, >> >> > >> what >> >> > >> >> it >> >> > >> >> >> >> does, >> >> > >> >> >> >> >>>>> and >> >> > >> >> >> >> >>>>>>>>>> who it effects. The ./merges folder is really >> >>just >> >> > >> stuff >> >> > >> >> that >> >> > >> >> >> >> gets >> >> > >> >> >> >> >>>>>>>>>> added to ./www in the right cases so having at >> >>the >> >> > >>same >> >> > >> >> >> depth is >> >> > >> >> >> >> >>>> ok >> >> > >> >> >> >> >>>>>>>>>> (for me). >> >> > >> >> >> >> >>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>> I get where you are coming from though. >> >> > >> >> >> >> >>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>> The real sticky bit is a config file hiding >> >>with >> >> the >> >> > >> app >> >> > >> >> >> >> >>>>>>>>>> implementation. It seems like that would live >> >>at >> >> the >> >> > >> root. >> >> > >> >> >> The >> >> > >> >> >> >> >>>> idea >> >> > >> >> >> >> >>>>> of >> >> > >> >> >> >> >>>>>>>>>> having it inside of ./www is a simple zip and >> >> > >>rename of >> >> > >> >> ./www >> >> > >> >> >> >> >>>> would >> >> > >> >> >> >> >>>>>>>>>> result in an installable package...but >> >>logically >> >> > >>with >> >> > >> our >> >> > >> >> >> >> tooling >> >> > >> >> >> >> >>>>> and >> >> > >> >> >> >> >>>>>>>>>> such that would be a build artifact that just >> >> lives >> >> > >>in >> >> > >> >> >> >> ./platforms >> >> > >> >> >> >> >>>>>>>>>> after we do our magic. >> >> > >> >> >> >> >>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>> =/ >> >> > >> >> >> >> >>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>> On Fri, Mar 22, 2013 at 1:24 PM, Michal Mocny < >> >> > >> >> >> >> >>>> mmocny@chromium.org> >> >> > >> >> >> >> >>>>>>>>> wrote: >> >> > >> >> >> >> >>>>>>>>>>> Paraphrasing our meeting notes today: >> >> > >> >> >> >> >>>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>>> * currently www/ has to have config.xml inside >> >> it, >> >> > >> docs >> >> > >> >> >> inside >> >> > >> >> >> >> >>>> it, >> >> > >> >> >> >> >>>>>>>>> README >> >> > >> >> >> >> >>>>>>>>>>> etc >> >> > >> >> >> >> >>>>>>>>>>> * merges folder is already a sibling of www/ >> >>but >> >> > >>its >> >> > >> >> >> logically >> >> > >> >> >> >> >>>>> part of >> >> > >> >> >> >> >>>>>>>>> the >> >> > >> >> >> >> >>>>>>>>>>> app. >> >> > >> >> >> >> >>>>>>>>>>> * So, why not move everything that isn't the >> >> actual >> >> > >> >> assets >> >> > >> >> >> of >> >> > >> >> >> >> the >> >> > >> >> >> >> >>>>> app >> >> > >> >> >> >> >>>>>>>>>>> itself out of www? >> >> > >> >> >> >> >>>>>>>>>>> * Option 1: move everything out into the root. >> >> > >> >> >> >> >>>>>>>>>>> * harder for git versioning your app, since >> >> cordova >> >> > >> >> >> artifacts >> >> > >> >> >> >> >>>>>>>>>>> (platforms, plugins) are inside. >> >> > >> >> >> >> >>>>>>>>>>> * Option 2: make a new top level "app/" folder >> >> that >> >> > >> holds >> >> > >> >> >> >> merges/ >> >> > >> >> >> >> >>>>> and >> >> > >> >> >> >> >>>>>>>>> www/ >> >> > >> >> >> >> >>>>>>>>>>> and manifestes etc >> >> > >> >> >> >> >>>>>>>>>>> * then you can just clone/install an app into >> >>one >> >> > >> >> location >> >> > >> >> >> >> >>>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>>> And I'll throw out a third option: Create an >> >> "apps" >> >> > >> >> folder >> >> > >> >> >> >> which >> >> > >> >> >> >> >>>>> can >> >> > >> >> >> >> >>>>>>>>> have >> >> > >> >> >> >> >>>>>>>>>>> any number of named apps, like plugins. >> >> > >> >> >> >> >>>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>>> I think (2) should be totally doable (just >> >>change >> >> > >>some >> >> > >> >> >> default >> >> > >> >> >> >> >>>>> paths >> >> > >> >> >> >> >>>>>>> in >> >> > >> >> >> >> >>>>>>>>> the >> >> > >> >> >> >> >>>>>>>>>>> tooling) and is a strict improvement (minus >> >>the >> >> > >> hassle of >> >> > >> >> >> >> moving >> >> > >> >> >> >> >>>>> your >> >> > >> >> >> >> >>>>>>>>> files >> >> > >> >> >> >> >>>>>>>>>>> around the first time for app devs). (3) I >> >>think >> >> > >>is >> >> > >> >> >> >> interesting, >> >> > >> >> >> >> >>>>> but >> >> > >> >> >> >> >>>>>>>>> is a >> >> > >> >> >> >> >>>>>>>>>>> bit of a departure. >> >> > >> >> >> >> >>>>>>>>>>> >> >> > >> >> >> >> >>>>>>>>>>> -Michal >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>>>> >> >> > >> >> >> >> >>>>>>> >> >> > >> >> >> >> >>>>>>> >> >> > >> >> >> >> >>>>> >> >> > >> >> >> >> >>>> >> >> > >> >> >> >> >> >> >> > >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> >> >> >>