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 <b...@brian.io> 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 > <bra...@chromium.org> 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 <b...@brian.io> wrote: > > > >> (Btw this isn't a vote thread guys.) > >> > >> On Mon, Mar 25, 2013 at 9:37 AM, Brian LeRoux <b...@brian.io> 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 <wjamesj...@gmail.com> > >> wrote: > >> >> +1 for app folder and cordova create <app location> > >> >> 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 < > bra...@chromium.org> > >> wrote: > >> >> > >> >>> A big +1 from me for this world, Michal's option 2. > >> >>> > >> >>> I want to be able to cordova create <some-git-URL>, 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 <mmo...@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 > >> >>>> <path-to-app>), 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 < > mmo...@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 > >> >>>>>> <to...@devgeeks.org>wrote: > >> >>>>>> > >> >>>>>>> I just mean that build expects config.xml to be in www, yeah? > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>>>> On 23/03/2013, at 1:12 PM, Michal Mocny <mmo...@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 > >> >>>>>>>> <to...@devgeeks.org>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 < > >> >>>> mmo...@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 > >> >>>>>>>>> > >> >>>>>>>>> > >> >>>>>>> > >> >>>>>>> > >> >>>>> > >> >>>> > >> >> > >> >
