cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Moving www into an app folder
Date Sat, 23 Mar 2013 02:35:41 GMT
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
<tommy@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 <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
> > <tommy@devgeeks.org>wrote:
> >
> >> Can I just ask a question about this?
> >>
> >> Is the config.xml supposed to be compatible with build.phonegap.com at
> >> 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
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message