Okay, we've got options, so lets try to distill the details.
First, some of the other (perceived) benefits of an app folder are:
* we do a raw cp -r of the www/ folder, and so that should have only
platform agnostic and "necessary" files.
* merges folder was removed from www/ because it did not meet above
criteria, and config.xml is another candidate
* there also potentially exist docs/ (useful for shared apps, like
mobile-spec), platform specific resource files (icons, splash screen), etc
* a git repository is already basically mirroring the concept of the "app
folder"
So, I've come up with the following potential workflows for starting with
an existing app:
#1: "your app repo is moved into some subdirectory of a cordova project --
its exact location is basically a cordova artifact"
cordova create Foo
cd Foo
cordova app add [--link] git-repo/local-repo (nicely akin to plugin add)
cordova plugin/platforms add ...
#2: "your app repo becomes a cordova project in-place"
git clone FooApp (this repo contains merges/ and www/)
cordova create FooApp Foo (cli should not clobber existing folders)
cd FooApp
set up .gitignore for cordova artifacts (cordova should try not to
introduce new artifacts)
cordova plugin/platforms add ...
#3: "what we have now"
git clone FooApp
cordova create Foo
cp -R FooApp/{www,merges,...} Foo (or ln -s)
cd Foo
cordova plugin/platforms add ...
(Please let me know of more workflows)
Workflow #1 I think is very clean, and requires an app folder concept (we
could maybe use a temporary intermediate folder to get around this, but
why).
Workflow #2 essentially your app repo is the app folder concept, but now
the cordova artifacts also go inside it. Would require minimal changes to
cordova-cli to not clobber, and requires gitignore.
Workflow #3 is what we have now, which I think is the worst option for app
management, but can work with or without an app folder.
Also, I think it would be great if apps had both plugin and platform
dependancies, such that you could distill workflow #1 down to:
cordova create Foo
cd Foo
cordova app add git-repo
.. and it would run the plugin/platform add automatically. Can even get
that down to a single "cordova create git-repo" line. That would make
sharing apps, such as mobile-spec-test, really trivial.
-Michal
On Tue, Apr 16, 2013 at 9:19 AM, Andrew Grieve <agri...@chromium.org> wrote:
> So, reading through the thread Braden linked to:
> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>
> There are two advantage that were brought up:
> 1. config.xml (configuration) does not live along side of app resources
> 2. It will make it easier to package apps
> - E.g. zip the app/ directory and install it into the app-harness
> (instead of zipping www + merges). Likewise for phonegap build.
> - E.g. cordova-mobile-spec would contain the contents of app/. With our
> current setup, it would contain www/ merges/, and have the CLI place build
> artifacts within the repo's directory instead of as a sibling to it.
>
> I think everyone acknowledged the benefits, but there was still
> not consensus over whether it was "worth it".
>
> I don't really feel strongly about it. Braden says it's easy to change
> code-wise. Does anyone want to go to bat for it?
>
>
>
> On Mon, Apr 15, 2013 at 6:59 PM, Brian LeRoux <b...@brian.io> wrote:
>
> > I'd rather we did not go ahead w/ the new directory structure. It offers
> no
> > functional benefit, and comes at an upgrade cost for ppl using the CLI
> > tools today.
> >
> >
> > On Mon, Apr 15, 2013 at 12:46 PM, Andrew Grieve <agri...@chromium.org
> > >wrote:
> >
> > > Just catching up on the past week of emails and it's not clear that
> there
> > > was a consensus here. By the sounds of it though:
> > >
> > > 1. Lots of users are using Cordova-CLI (master branch)
> > > 2. Cordova-CLI's "future" branch has non-backwards-compatible changes.
> > > 3. One of these changes is the directory structure.
> > >
> > > The main debate is on how to message these changes to users. What we
> > should
> > > do is:
> > >
> > > 1. Have an upgrade guide. (e.g. paths are now relative to plugin.xml)
> > > 2. Ensure that our error handling shows useful messages when they
> result
> > > from an old-way-of-doing-things (e.g. your app's structure doesn't
> > match.)
> > >
> > > Rather than printing out the commands to run to convert their project,
> > > maybe we could have them in the upgrade guide and have the error
> messages
> > > point to the guide?
> > >
> > >
> > >
> > >
> > > On Wed, Apr 10, 2013 at 5:47 PM, Tim Kim <timki...@gmail.com> wrote:
> > >
> > > > Braden I have merged master and the future branch:
> > > > https://github.com/timkim/plugman/tree/future_master_merge
> > > >
> > > > I think it's about ready to merge back in to future. I've gotten the
> > > > android-one-install and the ios-config-xml-install (minus one weird
> > test
> > > I
> > > > don't understand) working.
> > > >
> > > >
> > > > On 10 April 2013 14:42, Anis KADRI <anis.ka...@gmail.com> wrote:
> > > >
> > > > > As far as I am concerned I don't really have a strong opinion on
> this
> > > > > topic. As I said in the previous thread, I do like this new
> directory
> > > > > structure and if you have it there and tested then fine. We break
> > shit
> > > > all
> > > > > the time it's not like this change is one too many. What matters is
> > to
> > > > > communicate it to our users and give them an upgrade path to this
> new
> > > app
> > > > > structure (the Cordova docs are a good place for that).
> > > > >
> > > > > However, I agree with Brian that there are more important things to
> > > > tackle
> > > > > right now. Now sure what you had on your list but since js only
> > modules
> > > > are
> > > > > in Plugman right now (untested) The next big thing that is going to
> > be
> > > > > non-trivial is: plugin dependencies (which will in some ways
> involve
> > > > > discovery I think). We should have a discussion about that
> (hangout,
> > > IRC,
> > > > > connect...whatever). I have a couple of ideas about that.
> > > > >
> > > > > Tim is working on fixing/adding/updating plugman tests and it looks
> > > like
> > > > > he's making good progress on it.
> > > > >
> > > > > -a
> > > > >
> > > > >
> > > > > On Wed, Apr 10, 2013 at 11:53 AM, Michael Wolf <
> > > michael.w...@cynergy.com
> > > > > >wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > I get the intention, however anything we can do to reduce this
> type
> > > of
> > > > > > breaking change should be done. These type of changes should be
> > > > > > considered for major releases only so users can plan for them.
> > > > > >
> > > > > > mw
> > > > > >
> > > > > > On 4/9/13 5:05 PM, "Jesse" <purplecabb...@gmail.com> wrote:
> > > > > >
> > > > > > >+1 to the sanity plea of devgeek Tommy
> > > > > > >
> > > > > > >Also, if it didn't happen on this list, ....
> > > > > > >'Consensus' should always be tracked back to a thread here,
> > > regardless
> > > > > of
> > > > > > >meetings, hangouts, irc, bbs, ...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >@purplecabbage
> > > > > > >risingj.com
> > > > > > >
> > > > > > >
> > > > > > >On Tue, Apr 9, 2013 at 1:48 PM, tommy-carlos Williams
> > > > > > ><to...@devgeeks.org>wrote:
> > > > > > >
> > > > > > >> Sorry, but as someone that helps users everyday, the almost
> > "it's
> > > > > alpha,
> > > > > > >> they shoulda seen it coming" tone of this is a bit upsetting.
> > > > > > >>
> > > > > > >> It reminds me of before the deprecation policy, etc when
> > PhoneGap
> > > > > would
> > > > > > >> completely break everything whenever a new version came out.
> > > > > > >>
> > > > > > >> I feel like we have come a long way since then (with a ways
> > still
> > > to
> > > > > go,
> > > > > > >> no question about it). I would hate to be the one in IRC and
> on
> > > the
> > > > > > >>Google
> > > > > > >> Group list having to explain this to everyone using the cli.
> > > > > > >>
> > > > > > >> I was under the impression that the cli was "shipping" now,
> not
> > > > just a
> > > > > > >> little side thing. I know that quite a few people are using it
> > for
> > > > > real
> > > > > > >> apps (myself included). If that is true, then we have a duty
> to
> > at
> > > > > least
> > > > > > >> think very carefully before breaking something and come up
> with
> > a
> > > > good
> > > > > > >>plan
> > > > > > >> for easing that transition.
> > > > > > >>
> > > > > > >> - tommy
> > > > > > >>
> > > > > > >> On 10/04/2013, at 1:40, Braden Shepherdson <
> bra...@chromium.org
> > >
> > > > > wrote:
> > > > > > >>
> > > > > > >> > This mailing list post is, or will shortly be, indexed by
> > Google
> > > > and
> > > > > > >> > others. Any newcomers will see the new docs and create new
> > > > projects.
> > > > > > >> >
> > > > > > >> > As I mentioned on IRC, existing users are either accepting
> or
> > > > > ignoring
> > > > > > >> the
> > > > > > >> > "alpha" warnings that this software is new and under heavy
> > > > > > >>development,
> > > > > > >> and
> > > > > > >> > if they want to jump on it early they're going to have to
> > expect
> > > > > some
> > > > > > >> pain.
> > > > > > >> >
> > > > > > >> > That said, I don't really know of any better way to
> socialize
> > > it.
> > > > Is
> > > > > > >> there
> > > > > > >> > anywhere where a brief blog post on this would make sense?
> > > > > > >> >
> > > > > > >> > I don't know how many people are using these tools and not
> on
> > > the
> > > > > > >>mailing
> > > > > > >> > list, though certainly some turn up on IRC occasionally.
> > > > > > >> >
> > > > > > >> > Braden
> > > > > > >> >
> > > > > > >> >
> > > > > > >> > On Tue, Apr 9, 2013 at 11:24 AM, Filip Maj <f...@adobe.com>
> > > wrote:
> > > > > > >> >
> > > > > > >> >> How will we communicate this change to our existing users?
> > > > > > >> >>
> > > > > > >> >> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> bra...@chromium.org
> > >
> > > > > wrote:
> > > > > > >> >>
> > > > > > >> >>> I've just pushed a change to the future branch that
> changes
> > > the
> > > > > > >> directory
> > > > > > >> >>> structure to:
> > > > > > >> >>>
> > > > > > >> >>> app/
> > > > > > >> >>> merges/
> > > > > > >> >>> android/
> > > > > > >> >>> ios/
> > > > > > >> >>> www/
> > > > > > >> >>> config.xml
> > > > > > >> >>>
> > > > > > >> >>> As was discussed at our video conference meeting a couple
> of
> > > > weeks
> > > > > > >>ago,
> > > > > > >> >>> this has a number of advantages:
> > > > > > >> >>> - config.xml is no longer in the www/ directory
> > > > > > >> >>> - One can easily version control the whole app/ directory,
> > and
> > > > get
> > > > > > >> their
> > > > > > >> >>> web assets, merges and so on into the repo.
> > > > > > >> >>> - That repo can contain additional information: a
> README.md,
> > > > > > >> supplementary
> > > > > > >> >>> documentation, tests, whatever. The CLI will ignore
> anything
> > > > > > >>outside of
> > > > > > >> >>> the
> > > > > > >> >>> merges and www directories.
> > > > > > >> >>>
> > > > > > >> >>>
> > > > > > >> >>> The downside is that this is a breaking change: running
> the
> > > new
> > > > > > >> version of
> > > > > > >> >>> the tools on an old project will fail (but I think in a
> > > harmless
> > > > > > >>way)
> > > > > > >> >>> until
> > > > > > >> >>> you rearrange the directories. You can do that with the
> > > > following
> > > > > > >> >>> commands:
> > > > > > >> >>>
> > > > > > >> >>> $ mkdir app
> > > > > > >> >>> $ mv www/config.xml app
> > > > > > >> >>> $ mv www app
> > > > > > >> >>> $ mv merges app
> > > > > > >> >>>
> > > > > > >> >>> All docs and tests are updated as well. Any problems
> should
> > be
> > > > > > >> reported on
> > > > > > >> >>> JIRA and assigned to me.
> > > > > > >> >>>
> > > > > > >> >>> Braden
> > > > > > >> >>
> > > > > > >> >>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Timothy Kim
> > > >
> > >
> >
>
