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 <b...@brian.io> 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 > <bra...@chromium.org> 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 <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 > >> >> >>>>>>>>> > >> >> >>>>>>>>> > >> >> >>>>>>> > >> >> >>>>>>> > >> >> >>>>> > >> >> >>>> > >> >> >> > >> >> > >> >
