Re: New directory structure in cordova-cli's future branch

[Filip Maj <fi...@adobe.com>]

I'm reviving this discussion re: additional app/ folder in the
cli-generated project structure.

To recap, there were two main discussions:

A)
http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
hsfjmvwtoi+state:results
B) http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html

Arguments for moving to app/:

 - easier to version control relevant / non-build-artifact app bits
 - aesthetics

Arguments against it:

 - we break shit for users
 - config.xml location and PhoneGap Build compatibility (but I don't see
this as a valid argument against. This is an easy problem to solve for us
Adobe folk and the tooling can handle the trivial steps of going up one
directory to grab the right file before interfacing with Build)

Also worth noting: people we're not against it for architectural reasons,
in fact, most people were favorable for the change to app/.

So, with plugman stabilizing and my focus moving to cli work, I feel I
have a good grasp of both projects and the direction they are going, here
is my suggestion on how to move forward with this:

1. cordova-cli's master branch, which will soon merge future work in, will
revert to the old /www-based structure, then
2. In 3.0 we make the change, where landing such a breaking change is
easier and we'll have a bunch of press/noise about the release out there
too so communicating this change would be easier.

If there are any other arguments for/against the app/ based structure, now
is the time to bring it up. We can give this some more time to bake, but
after 2.8 is released, I'd like to call a vote on whether we should move
to this structure or not in 3.0.

On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:

>I should also add.  I appreciate that this is a change, and every change
>has some learning overhead and we shouldn't stuff everything possible in
>all the time.
>
>However, I think 3.0 and cli are a big change, and we should do the big
>re-org all at once, so lets decide this now in a way we wont regret.
>Thats
>why we are being picky, I guess.  I like knowing that the root of the
>project has cordova-only artifacts and your app-repo is just a
>subdirectory
>somewhere.  Then, the exact location and exact contents are way more
>flexible.
>
>-Michal
>
>
>On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <mm...@chromium.org>
>wrote:
>
>> 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
>><ag...@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 <agrieve@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 <ti...@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 <an...@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.Wolf@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" <pu...@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 <
>>> braden@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
>>><fi...@adobe.com>
>>> > > wrote:
>>> > > > > > >> >
>>> > > > > > >> >> How will we communicate this change to our existing
>>>users?
>>> > > > > > >> >>
>>> > > > > > >> >> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>>> braden@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
>>> > > >
>>> > >
>>> >
>>>
>>
>>

Re: New directory structure in cordova-cli's future branch

[Michal Mocny <mm...@chromium.org>]

Sure, move the RC along so we can discuss calmly.

-Michal


On Thu, May 23, 2013 at 2:31 PM, Brian LeRoux <b...@brian.io> wrote:

> +1
>
> Lets start a fresh thread that describes the problem discreetly and
> work out a solution together. I suspect we'll arrive at a different
> solution than moving folders around.
>
>
> On Thu, May 23, 2013 at 11:04 AM, Filip Maj <fi...@adobe.com> wrote:
> > So for the sake of moving the RC release along, Michal/Braden/Andrew are
> > you guys cool if we:
> >
> > A) revert to www/ as root folder
> > B) proceed with 2.8.0rc1 tagging
> > C) continue with this discussion to try to get to a resolution.
> Worst-case
> > we call a vote next week?
> >
> > On 5/23/13 10:56 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> >
> >>Fil, that sounds extremely sensible.
> >>
> >>
> >>On Thu, May 23, 2013 at 12:32 PM, Filip Maj <fi...@adobe.com> wrote:
> >>
> >>> https://npmjs.org/package/cordova
> >>>
> >>>
> >>> While CLI is not a documented flow, it is deployed and has > 1000
> >>> downloads per month.
> >>>
> >>> That's my only concern: not fucking those people over.
> >>>
> >>> I'm in favor of that structure I just don't want it to change without
> >>> warning in this next release. Ideally set up deprecation messages, be
> >>> noisy about the change, and sure, possibly supporting a transitioning
> >>> automatically in our tooling, and then land it in full and remove
> >>> deprecation messages about it in 3.0.
> >>>
> >>> On 5/23/13 9:27 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> >>>
> >>> >Clarification of typing mistake, below..
> >>> >
> >>> >Also, curious why this breaks things in the first place?  I thought
> >>>this
> >>> >is
> >>> >the first time we are releasing these tools?  The current create
> script
> >>> >workflow is totally different, and I know there is a npm package for
> >>> >cordova cli already, but that was never a promoted flow (matter of
> >>>fact,
> >>> >why was it released? Are we supporting current users of that, is that
> >>>it?)
> >>> >
> >>> >-Michal
> >>> >
> >>> >On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mm...@chromium.org>
> >>> >wrote:
> >>> >
> >>> >> Brian,
> >>> >> I do not really understand your previous point, but I'll take a
> stab.
> >>> >>
> >>> >> First some clarification:  I think there are two logical "roots",
> (1)
> >>> >>the
> >>> >> root of your web app (holds merges/ and www/ and maybe more), and
> (2)
> >>> >>the
> >>> >> root of your cordova workspace (holds platforms/ plugins/ and maybe
> >>> >>more).
> >>> >>
> >>> >> With the app/ folder, (1) is a subdirectory (2).  With the current
> >>> >> situation, they overlap inside the same folder.
> >>> >>
> >>> >> I think it should be a goal to version control, share, and perhaps
> >>> >>bundle
> >>> >> auxiliary resources with app/'s.
> >>> >> I think it should also be a goal to not limit the future structure
> of
> >>> >>the
> >>> >> cordova workspace (ie, build artifacts).
> >>> >>
> >>> >> The current situation makes these goals harder.
> >>> >>
> >>> >> As one data point, our team here has a workflow where we share
> >>>several
> >>> >> apps (containing only the contents(2)), and we share the common
> >>>plugins
> >>> >>we
> >>> >> work on.
> >>> >> The contents of (1) are never committed, shared, etc, and are just
> >>> >> recreated on a regular basis as cordova versions change and as we
> >>>test
> >>> >>for
> >>> >> different platforms.  Sidenote: yes, I have multiple different
> >>>cordova
> >>> >> workspaces pointing to one common app to test with different
> >>>versions.
> >>> >>  This is a bit of a cordova-developer necessity, but it would be
> >>> >> interesting if external devs could trial out new cordova releases on
> >>>the
> >>> >> side, trivially..
> >>> >>
> >>> >Sigh, of course I got the numbers reversed here.. my bad.  Of course I
> >>> >mean
> >>> >we only commit (1).
> >>> >
> >>> >
> >>> >>
> >>> >>
> >>> >> So, like you Brian, we are just trying to get all the
> >>> >>requirements/wishes
> >>> >> on the table so we can make a conscious decision here.  It looks
> like
> >>> >>you
> >>> >> are not seeing sufficient motivation for making the change, and we
> >>>are
> >>> >>not
> >>> >> seeing any reason to not make it.
> >>> >>
> >>> >> Another observation: the transition path even easier than we have
> >>> >>outlined
> >>> >> above.
> >>> >>
> >>> >> If your existing project is:
> >>> >> - app_name/
> >>> >>  - platforms/
> >>> >>  - plugins/
> >>> >>  - www/
> >>> >>  - merges/
> >>> >>
> >>> >> All you need to do is rm -rf platforms/ plugins/ www/config.xml --
> >>>which
> >>> >> you need to do anyway to upgrade to 3.0 -- create a new config.xml
> at
> >>> >>the
> >>> >> root and you now have a shareable app, and you can create as many
> >>> >>cordova
> >>> >> different workspaces using it as you want.
> >>> >>
> >>> >> -Michal
> >>> >>
> >>> >>
> >>> >> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote:
> >>> >>
> >>> >>> Not buying that either. The `./app` directory lives in the root so
> >>> >>> everything will have to change when we hit the reality you describe
> >>> >>> where `./app` IS the root.
> >>> >>>
> >>> >>> What you are really saying this is a transition step until such
> time
> >>> >>> as `./app` becomes top level and things return to the same as they
> >>>are
> >>> >>> today but we do not require native bits to be revisioned.
> >>>Essentially
> >>> >>> this is an aesthetic forcing function to get back to the original
> >>> >>> structure. =P
> >>> >>>
> >>> >>> This is a very complicated way to achieve the goal of native bits
> >>> >>> being build artifacts. A goal I share, many do, and I think we can
> >>> >>> achieve it by NOT breaking things today.
> >>> >>>
> >>> >>>
> >>> >>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson
> >>> >>><br...@chromium.org>
> >>> >>> wrote:
> >>> >>> > cd app
> >>> >>> > git init
> >>> >>> >
> >>> >>> > Now my app directory - everything that makes this app mine and
> >>>isn't
> >>> >>> just a
> >>> >>> > cordova-cli artifact - is version controlled. I can easily check
> >>>out
> >>> >>>a
> >>> >>> new
> >>> >>> > copy with a cordova create ...; rm -rf app; git clone https://
> >>> >>> .../myrepo.git
> >>> >>> > app
> >>> >>> >
> >>> >>> > Once we have app-level dependencies (which is planned
> >>>regardless), I
> >>> >>>can
> >>> >>> > add cordova fetch-deps or whatever we decide the command should
> >>>be,
> >>> >>>and
> >>> >>> now
> >>> >>> > my app is fully set up. No need to juggle .gitignore or anything
> >>> >>>else.
> >>> >>> It's
> >>> >>> > hardly a killer feature, but I think it is an improvement.
> >>> >>> >
> >>> >>> > Michal asked what change we would regret more a year from now. I
> >>> >>>think
> >>> >>> this
> >>> >>> > style makes the separation of CLI artifacts and my app more
> clear,
> >>> >>>and
> >>> >>> if
> >>> >>> > we add more pieces to either it won't require changing people's
> >>> >>> .gitignore
> >>> >>> > files or knowing about the architecture.
> >>> >>> >
> >>> >>> > Braden
> >>> >>> >
> >>> >>> >
> >>> >>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io>
> wrote:
> >>> >>> >
> >>> >>> >> I want to be very clear that my tone here is emotionless! I'm
> >>> >>>totally
> >>> >>> >> indifferent.
> >>> >>> >>
> >>> >>> >> Now, please explain: how is a new directory make version control
> >>> >>> >> easier? I don't buy it.
> >>> >>> >>
> >>> >>> >>
> >>> >>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
> >>> >>> braden@chromium.org>
> >>> >>> >> wrote:
> >>> >>> >> > The change is not purely aesthetic; it means that the "my app"
> >>> >>> portions
> >>> >>> >> of
> >>> >>> >> > the structure are now contained in a single directory, and
> >>>easier
> >>> >>>to
> >>> >>> >> > version control.
> >>> >>> >> >
> >>> >>> >> > This change gets more expensive every day. If we're ever going
> >>>to
> >>> >>>do
> >>> >>> it,
> >>> >>> >> it
> >>> >>> >> > should be done now, I believe.
> >>> >>> >> >
> >>> >>> >> > It seems like the (not universally supported) consensus from
> >>>the
> >>> >>> first
> >>> >>> >> pass
> >>> >>> >> > at this thread was to keep the app/ dir but have automatic
> >>> >>>detection
> >>> >>> and
> >>> >>> >> > ask-then-automatic conversion.
> >>> >>> >> >
> >>> >>> >> > If that approach is still acceptable, I will implement that
> >>> >>>support
> >>> >>> today
> >>> >>> >> > before we tag CLI for 2.8.
> >>> >>> >> >
> >>> >>> >> > Braden
> >>> >>> >> >
> >>> >>> >> >
> >>> >>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny
> >>> >>><mm...@chromium.org>
> >>> >>> >> wrote:
> >>> >>> >> >
> >>> >>> >> >> Fil, good summary, thanks for that.  I also agree with your
> >>> >>> proposal.
> >>> >>> >> >>  Would it be possible to just support both options starting
> >>>now,
> >>> >>>and
> >>> >>> >> >> "deprecate" www/ at the top level in 3.0?
> >>> >>> >> >>
> >>> >>> >> >> Brian, this isn't just aesthetics, but its true that either
> >>> >>>option
> >>> >>> can,
> >>> >>> >> >> with varying difficulty, be made to work for all use cases.
> >>> >>> >> >>
> >>> >>> >> >> Migration path is trivial but will be paid by all users,
> >>>still,
> >>> >>> >> workflows
> >>> >>> >> >> will change completely with 3.0 anyway, this being the least
> >>>of
> >>> >>>the
> >>> >>> >> >> changes.  Which decision is more likely to be regretted a
> year
> >>> >>>from
> >>> >>> now?
> >>> >>> >> >>
> >>> >>> >> >> -Michal
> >>> >>> >> >>
> >>> >>> >> >>
> >>> >>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
> >>> >>> agrieve@chromium.org
> >>> >>> >> >> >wrote:
> >>> >>> >> >>
> >>> >>> >> >> > I don't really think this directory change is a big deal.
> We
> >>> >>>break
> >>> >>> >> things
> >>> >>> >> >> > in almost every release (e.g. loading pages of http), yet
> >>>we're
> >>> >>> >> having so
> >>> >>> >> >> > much debate over alpha tool.
> >>> >>> >> >> >
> >>> >>> >> >> > The migration path is: mkdir app && git mv www merges app
> &&
> >>> >>>git
> >>> >>> mv
> >>> >>> >> >> > app/www/config.xml app
> >>> >>> >> >> >
> >>> >>> >> >> > I think the least amount of work here is to just
> >>>console.log an
> >>> >>> error
> >>> >>> >> >> > message with this command if the app/ directory is not
> >>>found.
> >>> >>> >> >> >
> >>> >>> >> >> >
> >>> >>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
> >>> >>> >> >> > <to...@devgeeks.org>wrote:
> >>> >>> >> >> >
> >>> >>> >> >> > > Is it bad that I both agree vehemently with Brian's
> >>>calling
> >>> >>>it
> >>> >>> not
> >>> >>> >> >> > > beneficial enough to justify, but also really really like
> >>>the
> >>> >>> >> proposed
> >>> >>> >> >> > > structure better that the current one? hehe.
> >>> >>> >> >> > >
> >>> >>> >> >> > > *soŠ conflicted...*
> >>> >>> >> >> > >
> >>> >>> >> >> > > - tommy
> >>> >>> >> >> > >
> >>> >>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io>
> >>>wrote:
> >>> >>> >> >> > >
> >>> >>> >> >> > > > There are two paths. I argue there is no functional
> >>>benefit
> >>> >>> and
> >>> >>> >> that
> >>> >>> >> >> > > > this change is purely aesthetic. Aesthetics are
> >>>important
> >>> >>>but
> >>> >>> I'd
> >>> >>> >> >> > > > argue folder structure is the last part of the
> developer
> >>> >>> >> aesthetics
> >>> >>> >> >> we
> >>> >>> >> >> > > > should worry about and especially not beneficial enough
> >>>to
> >>> >>> >> justify a
> >>> >>> >> >> > > > breaking change.
> >>> >>> >> >> > > >
> >>> >>> >> >> > > > Today:
> >>> >>> >> >> > > >
> >>> >>> >> >> > > > ./
> >>> >>> >> >> > > > |- merges/
> >>> >>> >> >> > > > |- platforms/
> >>> >>> >> >> > > > |- plugins/
> >>> >>> >> >> > > > '- www/
> >>> >>> >> >> > > >    |- index.html
> >>> >>> >> >> > > >    '- config.xml
> >>> >>> >> >> > > >
> >>> >>> >> >> > > > Proposed:
> >>> >>> >> >> > > >
> >>> >>> >> >> > > > ./
> >>> >>> >> >> > > > |- platforms/
> >>> >>> >> >> > > > |- plugins/
> >>> >>> >> >> > > > '- app/
> >>> >>> >> >> > > >    |- merges/
> >>> >>> >> >> > > >    |- www/
> >>> >>> >> >> > > >    |       '- index.html
> >>> >>> >> >> > > >    '- config.xml
> >>> >>> >> >> > > >
> >>> >>> >> >> > > >
> >>> >>> >> >> > > >
> >>> >>> >> >> > > >
> >>> >>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj
> >>><fi...@adobe.com>
> >>> >>> wrote:
> >>> >>> >> >> > > >> I'm reviving this discussion re: additional app/
> >>>folder in
> >>> >>> the
> >>> >>> >> >> > > >> cli-generated project structure.
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> To recap, there were two main discussions:
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> A)
> >>> >>> >> >> > > >>
> >>> >>> >> >> > >
> >>> >>> >> >> >
> >>> >>> >> >>
> >>> >>> >>
> >>> >>>
> >>> >>>
> >>>
> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76
> >>> >>>xli
> >>> >>> >> >> > > >> hsfjmvwtoi+state:results
> >>> >>> >> >> > > >> B)
> >>> >>> >>
> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> Arguments for moving to app/:
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> - easier to version control relevant /
> >>>non-build-artifact
> >>> >>>app
> >>> >>> >> bits
> >>> >>> >> >> > > >> - aesthetics
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> Arguments against it:
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> - we break shit for users
> >>> >>> >> >> > > >> - config.xml location and PhoneGap Build compatibility
> >>> >>>(but I
> >>> >>> >> don't
> >>> >>> >> >> > see
> >>> >>> >> >> > > >> this as a valid argument against. This is an easy
> >>>problem
> >>> >>>to
> >>> >>> >> solve
> >>> >>> >> >> for
> >>> >>> >> >> > > us
> >>> >>> >> >> > > >> Adobe folk and the tooling can handle the trivial
> >>>steps of
> >>> >>> going
> >>> >>> >> up
> >>> >>> >> >> > one
> >>> >>> >> >> > > >> directory to grab the right file before interfacing
> >>>with
> >>> >>> Build)
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> Also worth noting: people we're not against it for
> >>> >>> architectural
> >>> >>> >> >> > > reasons,
> >>> >>> >> >> > > >> in fact, most people were favorable for the change to
> >>> >>>app/.
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> So, with plugman stabilizing and my focus moving to
> cli
> >>> >>> work, I
> >>> >>> >> >> feel I
> >>> >>> >> >> > > >> have a good grasp of both projects and the direction
> >>>they
> >>> >>>are
> >>> >>> >> going,
> >>> >>> >> >> > > here
> >>> >>> >> >> > > >> is my suggestion on how to move forward with this:
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge
> >>> >>>future
> >>> >>> work
> >>> >>> >> >> in,
> >>> >>> >> >> > > will
> >>> >>> >> >> > > >> revert to the old /www-based structure, then
> >>> >>> >> >> > > >> 2. In 3.0 we make the change, where landing such a
> >>> >>>breaking
> >>> >>> >> change
> >>> >>> >> >> is
> >>> >>> >> >> > > >> easier and we'll have a bunch of press/noise about the
> >>> >>> release
> >>> >>> >> out
> >>> >>> >> >> > there
> >>> >>> >> >> > > >> too so communicating this change would be easier.
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> If there are any other arguments for/against the app/
> >>> >>>based
> >>> >>> >> >> structure,
> >>> >>> >> >> > > now
> >>> >>> >> >> > > >> is the time to bring it up. We can give this some more
> >>> >>>time
> >>> >>> to
> >>> >>> >> bake,
> >>> >>> >> >> > but
> >>> >>> >> >> > > >> after 2.8 is released, I'd like to call a vote on
> >>>whether
> >>> >>>we
> >>> >>> >> should
> >>> >>> >> >> > move
> >>> >>> >> >> > > >> to this structure or not in 3.0.
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny"
> >>><mm...@chromium.org>
> >>> >>> wrote:
> >>> >>> >> >> > > >>
> >>> >>> >> >> > > >>> I should also add.  I appreciate that this is a
> >>>change,
> >>> >>>and
> >>> >>> >> every
> >>> >>> >> >> > > change
> >>> >>> >> >> > > >>> has some learning overhead and we shouldn't stuff
> >>> >>>everything
> >>> >>> >> >> possible
> >>> >>> >> >> > > in
> >>> >>> >> >> > > >>> all the time.
> >>> >>> >> >> > > >>>
> >>> >>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we
> >>> >>> should do
> >>> >>> >> the
> >>> >>> >> >> > big
> >>> >>> >> >> > > >>> re-org all at once, so lets decide this now in a way
> >>>we
> >>> >>>wont
> >>> >>> >> >> regret.
> >>> >>> >> >> > > >>> Thats
> >>> >>> >> >> > > >>> why we are being picky, I guess.  I like knowing that
> >>>the
> >>> >>> root
> >>> >>> >> of
> >>> >>> >> >> the
> >>> >>> >> >> > > >>> project has cordova-only artifacts and your app-repo
> >>>is
> >>> >>> just a
> >>> >>> >> >> > > >>> subdirectory
> >>> >>> >> >> > > >>> somewhere.  Then, the exact location and exact
> >>>contents
> >>> >>>are
> >>> >>> way
> >>> >>> >> >> more
> >>> >>> >> >> > > >>> flexible.
> >>> >>> >> >> > > >>>
> >>> >>> >> >> > > >>> -Michal
> >>> >>> >> >> > > >>>
> >>> >>> >> >> > > >>>
> >>> >>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
> >>> >>> >> >> mmocny@chromium.org>
> >>> >>> >> >> > > >>> wrote:
> >>> >>> >> >> > > >>>
> >>> >>> >> >> > > >>>> 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
> >>> >>> >> >> > > >>>> <ag...@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 <
> >>> >>> >> >> > > agrieve@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 <
> >>> >>> >> timkim85@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.kadri@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.Wolf@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"
> >>> >>><pu...@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 <
> >>> >>> >> >> > > >>>>> braden@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
> >>> >>> >> >> > > >>>>> <fi...@adobe.com>
> >>> >>> >> >> > > >>>>>>> wrote:
> >>> >>> >> >> > > >>>>>>>>>>>>>
> >>> >>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
> >>> >>> existing
> >>> >>> >> >> > > >>>>> users?
> >>> >>> >> >> > > >>>>>>>>>>>>>>
> >>> >>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> >>> >>> >> >> > > >>>>> braden@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
> >>> >>> >> >> > > >>>>>>>>
> >>> >>> >> >> > > >>>>>>>
> >>> >>> >> >> > > >>>>>>
> >>> >>> >> >> > > >>>>>
> >>> >>> >> >> > > >>>>
> >>> >>> >> >> > > >>>>
> >>> >>> >> >> > > >>
> >>> >>> >> >> > >
> >>> >>> >> >> > >
> >>> >>> >> >> >
> >>> >>> >> >>
> >>> >>> >>
> >>> >>>
> >>> >>
> >>> >>
> >>>
> >>>
> >
>

Re: New directory structure in cordova-cli's future branch

[Brian LeRoux <b...@brian.io>]

+1

Lets start a fresh thread that describes the problem discreetly and
work out a solution together. I suspect we'll arrive at a different
solution than moving folders around.


On Thu, May 23, 2013 at 11:04 AM, Filip Maj <fi...@adobe.com> wrote:
> So for the sake of moving the RC release along, Michal/Braden/Andrew are
> you guys cool if we:
>
> A) revert to www/ as root folder
> B) proceed with 2.8.0rc1 tagging
> C) continue with this discussion to try to get to a resolution. Worst-case
> we call a vote next week?
>
> On 5/23/13 10:56 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>
>>Fil, that sounds extremely sensible.
>>
>>
>>On Thu, May 23, 2013 at 12:32 PM, Filip Maj <fi...@adobe.com> wrote:
>>
>>> https://npmjs.org/package/cordova
>>>
>>>
>>> While CLI is not a documented flow, it is deployed and has > 1000
>>> downloads per month.
>>>
>>> That's my only concern: not fucking those people over.
>>>
>>> I'm in favor of that structure I just don't want it to change without
>>> warning in this next release. Ideally set up deprecation messages, be
>>> noisy about the change, and sure, possibly supporting a transitioning
>>> automatically in our tooling, and then land it in full and remove
>>> deprecation messages about it in 3.0.
>>>
>>> On 5/23/13 9:27 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>>>
>>> >Clarification of typing mistake, below..
>>> >
>>> >Also, curious why this breaks things in the first place?  I thought
>>>this
>>> >is
>>> >the first time we are releasing these tools?  The current create script
>>> >workflow is totally different, and I know there is a npm package for
>>> >cordova cli already, but that was never a promoted flow (matter of
>>>fact,
>>> >why was it released? Are we supporting current users of that, is that
>>>it?)
>>> >
>>> >-Michal
>>> >
>>> >On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mm...@chromium.org>
>>> >wrote:
>>> >
>>> >> Brian,
>>> >> I do not really understand your previous point, but I'll take a stab.
>>> >>
>>> >> First some clarification:  I think there are two logical "roots", (1)
>>> >>the
>>> >> root of your web app (holds merges/ and www/ and maybe more), and (2)
>>> >>the
>>> >> root of your cordova workspace (holds platforms/ plugins/ and maybe
>>> >>more).
>>> >>
>>> >> With the app/ folder, (1) is a subdirectory (2).  With the current
>>> >> situation, they overlap inside the same folder.
>>> >>
>>> >> I think it should be a goal to version control, share, and perhaps
>>> >>bundle
>>> >> auxiliary resources with app/'s.
>>> >> I think it should also be a goal to not limit the future structure of
>>> >>the
>>> >> cordova workspace (ie, build artifacts).
>>> >>
>>> >> The current situation makes these goals harder.
>>> >>
>>> >> As one data point, our team here has a workflow where we share
>>>several
>>> >> apps (containing only the contents(2)), and we share the common
>>>plugins
>>> >>we
>>> >> work on.
>>> >> The contents of (1) are never committed, shared, etc, and are just
>>> >> recreated on a regular basis as cordova versions change and as we
>>>test
>>> >>for
>>> >> different platforms.  Sidenote: yes, I have multiple different
>>>cordova
>>> >> workspaces pointing to one common app to test with different
>>>versions.
>>> >>  This is a bit of a cordova-developer necessity, but it would be
>>> >> interesting if external devs could trial out new cordova releases on
>>>the
>>> >> side, trivially..
>>> >>
>>> >Sigh, of course I got the numbers reversed here.. my bad.  Of course I
>>> >mean
>>> >we only commit (1).
>>> >
>>> >
>>> >>
>>> >>
>>> >> So, like you Brian, we are just trying to get all the
>>> >>requirements/wishes
>>> >> on the table so we can make a conscious decision here.  It looks like
>>> >>you
>>> >> are not seeing sufficient motivation for making the change, and we
>>>are
>>> >>not
>>> >> seeing any reason to not make it.
>>> >>
>>> >> Another observation: the transition path even easier than we have
>>> >>outlined
>>> >> above.
>>> >>
>>> >> If your existing project is:
>>> >> - app_name/
>>> >>  - platforms/
>>> >>  - plugins/
>>> >>  - www/
>>> >>  - merges/
>>> >>
>>> >> All you need to do is rm -rf platforms/ plugins/ www/config.xml --
>>>which
>>> >> you need to do anyway to upgrade to 3.0 -- create a new config.xml at
>>> >>the
>>> >> root and you now have a shareable app, and you can create as many
>>> >>cordova
>>> >> different workspaces using it as you want.
>>> >>
>>> >> -Michal
>>> >>
>>> >>
>>> >> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote:
>>> >>
>>> >>> Not buying that either. The `./app` directory lives in the root so
>>> >>> everything will have to change when we hit the reality you describe
>>> >>> where `./app` IS the root.
>>> >>>
>>> >>> What you are really saying this is a transition step until such time
>>> >>> as `./app` becomes top level and things return to the same as they
>>>are
>>> >>> today but we do not require native bits to be revisioned.
>>>Essentially
>>> >>> this is an aesthetic forcing function to get back to the original
>>> >>> structure. =P
>>> >>>
>>> >>> This is a very complicated way to achieve the goal of native bits
>>> >>> being build artifacts. A goal I share, many do, and I think we can
>>> >>> achieve it by NOT breaking things today.
>>> >>>
>>> >>>
>>> >>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson
>>> >>><br...@chromium.org>
>>> >>> wrote:
>>> >>> > cd app
>>> >>> > git init
>>> >>> >
>>> >>> > Now my app directory - everything that makes this app mine and
>>>isn't
>>> >>> just a
>>> >>> > cordova-cli artifact - is version controlled. I can easily check
>>>out
>>> >>>a
>>> >>> new
>>> >>> > copy with a cordova create ...; rm -rf app; git clone https://
>>> >>> .../myrepo.git
>>> >>> > app
>>> >>> >
>>> >>> > Once we have app-level dependencies (which is planned
>>>regardless), I
>>> >>>can
>>> >>> > add cordova fetch-deps or whatever we decide the command should
>>>be,
>>> >>>and
>>> >>> now
>>> >>> > my app is fully set up. No need to juggle .gitignore or anything
>>> >>>else.
>>> >>> It's
>>> >>> > hardly a killer feature, but I think it is an improvement.
>>> >>> >
>>> >>> > Michal asked what change we would regret more a year from now. I
>>> >>>think
>>> >>> this
>>> >>> > style makes the separation of CLI artifacts and my app more clear,
>>> >>>and
>>> >>> if
>>> >>> > we add more pieces to either it won't require changing people's
>>> >>> .gitignore
>>> >>> > files or knowing about the architecture.
>>> >>> >
>>> >>> > Braden
>>> >>> >
>>> >>> >
>>> >>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
>>> >>> >
>>> >>> >> I want to be very clear that my tone here is emotionless! I'm
>>> >>>totally
>>> >>> >> indifferent.
>>> >>> >>
>>> >>> >> Now, please explain: how is a new directory make version control
>>> >>> >> easier? I don't buy it.
>>> >>> >>
>>> >>> >>
>>> >>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
>>> >>> braden@chromium.org>
>>> >>> >> wrote:
>>> >>> >> > The change is not purely aesthetic; it means that the "my app"
>>> >>> portions
>>> >>> >> of
>>> >>> >> > the structure are now contained in a single directory, and
>>>easier
>>> >>>to
>>> >>> >> > version control.
>>> >>> >> >
>>> >>> >> > This change gets more expensive every day. If we're ever going
>>>to
>>> >>>do
>>> >>> it,
>>> >>> >> it
>>> >>> >> > should be done now, I believe.
>>> >>> >> >
>>> >>> >> > It seems like the (not universally supported) consensus from
>>>the
>>> >>> first
>>> >>> >> pass
>>> >>> >> > at this thread was to keep the app/ dir but have automatic
>>> >>>detection
>>> >>> and
>>> >>> >> > ask-then-automatic conversion.
>>> >>> >> >
>>> >>> >> > If that approach is still acceptable, I will implement that
>>> >>>support
>>> >>> today
>>> >>> >> > before we tag CLI for 2.8.
>>> >>> >> >
>>> >>> >> > Braden
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny
>>> >>><mm...@chromium.org>
>>> >>> >> wrote:
>>> >>> >> >
>>> >>> >> >> Fil, good summary, thanks for that.  I also agree with your
>>> >>> proposal.
>>> >>> >> >>  Would it be possible to just support both options starting
>>>now,
>>> >>>and
>>> >>> >> >> "deprecate" www/ at the top level in 3.0?
>>> >>> >> >>
>>> >>> >> >> Brian, this isn't just aesthetics, but its true that either
>>> >>>option
>>> >>> can,
>>> >>> >> >> with varying difficulty, be made to work for all use cases.
>>> >>> >> >>
>>> >>> >> >> Migration path is trivial but will be paid by all users,
>>>still,
>>> >>> >> workflows
>>> >>> >> >> will change completely with 3.0 anyway, this being the least
>>>of
>>> >>>the
>>> >>> >> >> changes.  Which decision is more likely to be regretted a year
>>> >>>from
>>> >>> now?
>>> >>> >> >>
>>> >>> >> >> -Michal
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
>>> >>> agrieve@chromium.org
>>> >>> >> >> >wrote:
>>> >>> >> >>
>>> >>> >> >> > I don't really think this directory change is a big deal. We
>>> >>>break
>>> >>> >> things
>>> >>> >> >> > in almost every release (e.g. loading pages of http), yet
>>>we're
>>> >>> >> having so
>>> >>> >> >> > much debate over alpha tool.
>>> >>> >> >> >
>>> >>> >> >> > The migration path is: mkdir app && git mv www merges app &&
>>> >>>git
>>> >>> mv
>>> >>> >> >> > app/www/config.xml app
>>> >>> >> >> >
>>> >>> >> >> > I think the least amount of work here is to just
>>>console.log an
>>> >>> error
>>> >>> >> >> > message with this command if the app/ directory is not
>>>found.
>>> >>> >> >> >
>>> >>> >> >> >
>>> >>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>>> >>> >> >> > <to...@devgeeks.org>wrote:
>>> >>> >> >> >
>>> >>> >> >> > > Is it bad that I both agree vehemently with Brian's
>>>calling
>>> >>>it
>>> >>> not
>>> >>> >> >> > > beneficial enough to justify, but also really really like
>>>the
>>> >>> >> proposed
>>> >>> >> >> > > structure better that the current one? hehe.
>>> >>> >> >> > >
>>> >>> >> >> > > *soŠ conflicted...*
>>> >>> >> >> > >
>>> >>> >> >> > > - tommy
>>> >>> >> >> > >
>>> >>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io>
>>>wrote:
>>> >>> >> >> > >
>>> >>> >> >> > > > There are two paths. I argue there is no functional
>>>benefit
>>> >>> and
>>> >>> >> that
>>> >>> >> >> > > > this change is purely aesthetic. Aesthetics are
>>>important
>>> >>>but
>>> >>> I'd
>>> >>> >> >> > > > argue folder structure is the last part of the developer
>>> >>> >> aesthetics
>>> >>> >> >> we
>>> >>> >> >> > > > should worry about and especially not beneficial enough
>>>to
>>> >>> >> justify a
>>> >>> >> >> > > > breaking change.
>>> >>> >> >> > > >
>>> >>> >> >> > > > Today:
>>> >>> >> >> > > >
>>> >>> >> >> > > > ./
>>> >>> >> >> > > > |- merges/
>>> >>> >> >> > > > |- platforms/
>>> >>> >> >> > > > |- plugins/
>>> >>> >> >> > > > '- www/
>>> >>> >> >> > > >    |- index.html
>>> >>> >> >> > > >    '- config.xml
>>> >>> >> >> > > >
>>> >>> >> >> > > > Proposed:
>>> >>> >> >> > > >
>>> >>> >> >> > > > ./
>>> >>> >> >> > > > |- platforms/
>>> >>> >> >> > > > |- plugins/
>>> >>> >> >> > > > '- app/
>>> >>> >> >> > > >    |- merges/
>>> >>> >> >> > > >    |- www/
>>> >>> >> >> > > >    |       '- index.html
>>> >>> >> >> > > >    '- config.xml
>>> >>> >> >> > > >
>>> >>> >> >> > > >
>>> >>> >> >> > > >
>>> >>> >> >> > > >
>>> >>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj
>>><fi...@adobe.com>
>>> >>> wrote:
>>> >>> >> >> > > >> I'm reviving this discussion re: additional app/
>>>folder in
>>> >>> the
>>> >>> >> >> > > >> cli-generated project structure.
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> To recap, there were two main discussions:
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> A)
>>> >>> >> >> > > >>
>>> >>> >> >> > >
>>> >>> >> >> >
>>> >>> >> >>
>>> >>> >>
>>> >>>
>>> >>>
>>> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76
>>> >>>xli
>>> >>> >> >> > > >> hsfjmvwtoi+state:results
>>> >>> >> >> > > >> B)
>>> >>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> Arguments for moving to app/:
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> - easier to version control relevant /
>>>non-build-artifact
>>> >>>app
>>> >>> >> bits
>>> >>> >> >> > > >> - aesthetics
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> Arguments against it:
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> - we break shit for users
>>> >>> >> >> > > >> - config.xml location and PhoneGap Build compatibility
>>> >>>(but I
>>> >>> >> don't
>>> >>> >> >> > see
>>> >>> >> >> > > >> this as a valid argument against. This is an easy
>>>problem
>>> >>>to
>>> >>> >> solve
>>> >>> >> >> for
>>> >>> >> >> > > us
>>> >>> >> >> > > >> Adobe folk and the tooling can handle the trivial
>>>steps of
>>> >>> going
>>> >>> >> up
>>> >>> >> >> > one
>>> >>> >> >> > > >> directory to grab the right file before interfacing
>>>with
>>> >>> Build)
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> Also worth noting: people we're not against it for
>>> >>> architectural
>>> >>> >> >> > > reasons,
>>> >>> >> >> > > >> in fact, most people were favorable for the change to
>>> >>>app/.
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli
>>> >>> work, I
>>> >>> >> >> feel I
>>> >>> >> >> > > >> have a good grasp of both projects and the direction
>>>they
>>> >>>are
>>> >>> >> going,
>>> >>> >> >> > > here
>>> >>> >> >> > > >> is my suggestion on how to move forward with this:
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge
>>> >>>future
>>> >>> work
>>> >>> >> >> in,
>>> >>> >> >> > > will
>>> >>> >> >> > > >> revert to the old /www-based structure, then
>>> >>> >> >> > > >> 2. In 3.0 we make the change, where landing such a
>>> >>>breaking
>>> >>> >> change
>>> >>> >> >> is
>>> >>> >> >> > > >> easier and we'll have a bunch of press/noise about the
>>> >>> release
>>> >>> >> out
>>> >>> >> >> > there
>>> >>> >> >> > > >> too so communicating this change would be easier.
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> If there are any other arguments for/against the app/
>>> >>>based
>>> >>> >> >> structure,
>>> >>> >> >> > > now
>>> >>> >> >> > > >> is the time to bring it up. We can give this some more
>>> >>>time
>>> >>> to
>>> >>> >> bake,
>>> >>> >> >> > but
>>> >>> >> >> > > >> after 2.8 is released, I'd like to call a vote on
>>>whether
>>> >>>we
>>> >>> >> should
>>> >>> >> >> > move
>>> >>> >> >> > > >> to this structure or not in 3.0.
>>> >>> >> >> > > >>
>>> >>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny"
>>><mm...@chromium.org>
>>> >>> wrote:
>>> >>> >> >> > > >>
>>> >>> >> >> > > >>> I should also add.  I appreciate that this is a
>>>change,
>>> >>>and
>>> >>> >> every
>>> >>> >> >> > > change
>>> >>> >> >> > > >>> has some learning overhead and we shouldn't stuff
>>> >>>everything
>>> >>> >> >> possible
>>> >>> >> >> > > in
>>> >>> >> >> > > >>> all the time.
>>> >>> >> >> > > >>>
>>> >>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we
>>> >>> should do
>>> >>> >> the
>>> >>> >> >> > big
>>> >>> >> >> > > >>> re-org all at once, so lets decide this now in a way
>>>we
>>> >>>wont
>>> >>> >> >> regret.
>>> >>> >> >> > > >>> Thats
>>> >>> >> >> > > >>> why we are being picky, I guess.  I like knowing that
>>>the
>>> >>> root
>>> >>> >> of
>>> >>> >> >> the
>>> >>> >> >> > > >>> project has cordova-only artifacts and your app-repo
>>>is
>>> >>> just a
>>> >>> >> >> > > >>> subdirectory
>>> >>> >> >> > > >>> somewhere.  Then, the exact location and exact
>>>contents
>>> >>>are
>>> >>> way
>>> >>> >> >> more
>>> >>> >> >> > > >>> flexible.
>>> >>> >> >> > > >>>
>>> >>> >> >> > > >>> -Michal
>>> >>> >> >> > > >>>
>>> >>> >> >> > > >>>
>>> >>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>>> >>> >> >> mmocny@chromium.org>
>>> >>> >> >> > > >>> wrote:
>>> >>> >> >> > > >>>
>>> >>> >> >> > > >>>> 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
>>> >>> >> >> > > >>>> <ag...@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 <
>>> >>> >> >> > > agrieve@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 <
>>> >>> >> timkim85@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.kadri@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.Wolf@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"
>>> >>><pu...@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 <
>>> >>> >> >> > > >>>>> braden@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
>>> >>> >> >> > > >>>>> <fi...@adobe.com>
>>> >>> >> >> > > >>>>>>> wrote:
>>> >>> >> >> > > >>>>>>>>>>>>>
>>> >>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
>>> >>> existing
>>> >>> >> >> > > >>>>> users?
>>> >>> >> >> > > >>>>>>>>>>>>>>
>>> >>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>>> >>> >> >> > > >>>>> braden@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
>>> >>> >> >> > > >>>>>>>>
>>> >>> >> >> > > >>>>>>>
>>> >>> >> >> > > >>>>>>
>>> >>> >> >> > > >>>>>
>>> >>> >> >> > > >>>>
>>> >>> >> >> > > >>>>
>>> >>> >> >> > > >>
>>> >>> >> >> > >
>>> >>> >> >> > >
>>> >>> >> >> >
>>> >>> >> >>
>>> >>> >>
>>> >>>
>>> >>
>>> >>
>>>
>>>
>

Re: New directory structure in cordova-cli's future branch

[Filip Maj <fi...@adobe.com>]

So for the sake of moving the RC release along, Michal/Braden/Andrew are
you guys cool if we:

A) revert to www/ as root folder
B) proceed with 2.8.0rc1 tagging
C) continue with this discussion to try to get to a resolution. Worst-case
we call a vote next week?

On 5/23/13 10:56 AM, "Michal Mocny" <mm...@chromium.org> wrote:

>Fil, that sounds extremely sensible.
>
>
>On Thu, May 23, 2013 at 12:32 PM, Filip Maj <fi...@adobe.com> wrote:
>
>> https://npmjs.org/package/cordova
>>
>>
>> While CLI is not a documented flow, it is deployed and has > 1000
>> downloads per month.
>>
>> That's my only concern: not fucking those people over.
>>
>> I'm in favor of that structure I just don't want it to change without
>> warning in this next release. Ideally set up deprecation messages, be
>> noisy about the change, and sure, possibly supporting a transitioning
>> automatically in our tooling, and then land it in full and remove
>> deprecation messages about it in 3.0.
>>
>> On 5/23/13 9:27 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>>
>> >Clarification of typing mistake, below..
>> >
>> >Also, curious why this breaks things in the first place?  I thought
>>this
>> >is
>> >the first time we are releasing these tools?  The current create script
>> >workflow is totally different, and I know there is a npm package for
>> >cordova cli already, but that was never a promoted flow (matter of
>>fact,
>> >why was it released? Are we supporting current users of that, is that
>>it?)
>> >
>> >-Michal
>> >
>> >On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mm...@chromium.org>
>> >wrote:
>> >
>> >> Brian,
>> >> I do not really understand your previous point, but I'll take a stab.
>> >>
>> >> First some clarification:  I think there are two logical "roots", (1)
>> >>the
>> >> root of your web app (holds merges/ and www/ and maybe more), and (2)
>> >>the
>> >> root of your cordova workspace (holds platforms/ plugins/ and maybe
>> >>more).
>> >>
>> >> With the app/ folder, (1) is a subdirectory (2).  With the current
>> >> situation, they overlap inside the same folder.
>> >>
>> >> I think it should be a goal to version control, share, and perhaps
>> >>bundle
>> >> auxiliary resources with app/'s.
>> >> I think it should also be a goal to not limit the future structure of
>> >>the
>> >> cordova workspace (ie, build artifacts).
>> >>
>> >> The current situation makes these goals harder.
>> >>
>> >> As one data point, our team here has a workflow where we share
>>several
>> >> apps (containing only the contents(2)), and we share the common
>>plugins
>> >>we
>> >> work on.
>> >> The contents of (1) are never committed, shared, etc, and are just
>> >> recreated on a regular basis as cordova versions change and as we
>>test
>> >>for
>> >> different platforms.  Sidenote: yes, I have multiple different
>>cordova
>> >> workspaces pointing to one common app to test with different
>>versions.
>> >>  This is a bit of a cordova-developer necessity, but it would be
>> >> interesting if external devs could trial out new cordova releases on
>>the
>> >> side, trivially..
>> >>
>> >Sigh, of course I got the numbers reversed here.. my bad.  Of course I
>> >mean
>> >we only commit (1).
>> >
>> >
>> >>
>> >>
>> >> So, like you Brian, we are just trying to get all the
>> >>requirements/wishes
>> >> on the table so we can make a conscious decision here.  It looks like
>> >>you
>> >> are not seeing sufficient motivation for making the change, and we
>>are
>> >>not
>> >> seeing any reason to not make it.
>> >>
>> >> Another observation: the transition path even easier than we have
>> >>outlined
>> >> above.
>> >>
>> >> If your existing project is:
>> >> - app_name/
>> >>  - platforms/
>> >>  - plugins/
>> >>  - www/
>> >>  - merges/
>> >>
>> >> All you need to do is rm -rf platforms/ plugins/ www/config.xml --
>>which
>> >> you need to do anyway to upgrade to 3.0 -- create a new config.xml at
>> >>the
>> >> root and you now have a shareable app, and you can create as many
>> >>cordova
>> >> different workspaces using it as you want.
>> >>
>> >> -Michal
>> >>
>> >>
>> >> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote:
>> >>
>> >>> Not buying that either. The `./app` directory lives in the root so
>> >>> everything will have to change when we hit the reality you describe
>> >>> where `./app` IS the root.
>> >>>
>> >>> What you are really saying this is a transition step until such time
>> >>> as `./app` becomes top level and things return to the same as they
>>are
>> >>> today but we do not require native bits to be revisioned.
>>Essentially
>> >>> this is an aesthetic forcing function to get back to the original
>> >>> structure. =P
>> >>>
>> >>> This is a very complicated way to achieve the goal of native bits
>> >>> being build artifacts. A goal I share, many do, and I think we can
>> >>> achieve it by NOT breaking things today.
>> >>>
>> >>>
>> >>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson
>> >>><br...@chromium.org>
>> >>> wrote:
>> >>> > cd app
>> >>> > git init
>> >>> >
>> >>> > Now my app directory - everything that makes this app mine and
>>isn't
>> >>> just a
>> >>> > cordova-cli artifact - is version controlled. I can easily check
>>out
>> >>>a
>> >>> new
>> >>> > copy with a cordova create ...; rm -rf app; git clone https://
>> >>> .../myrepo.git
>> >>> > app
>> >>> >
>> >>> > Once we have app-level dependencies (which is planned
>>regardless), I
>> >>>can
>> >>> > add cordova fetch-deps or whatever we decide the command should
>>be,
>> >>>and
>> >>> now
>> >>> > my app is fully set up. No need to juggle .gitignore or anything
>> >>>else.
>> >>> It's
>> >>> > hardly a killer feature, but I think it is an improvement.
>> >>> >
>> >>> > Michal asked what change we would regret more a year from now. I
>> >>>think
>> >>> this
>> >>> > style makes the separation of CLI artifacts and my app more clear,
>> >>>and
>> >>> if
>> >>> > we add more pieces to either it won't require changing people's
>> >>> .gitignore
>> >>> > files or knowing about the architecture.
>> >>> >
>> >>> > Braden
>> >>> >
>> >>> >
>> >>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
>> >>> >
>> >>> >> I want to be very clear that my tone here is emotionless! I'm
>> >>>totally
>> >>> >> indifferent.
>> >>> >>
>> >>> >> Now, please explain: how is a new directory make version control
>> >>> >> easier? I don't buy it.
>> >>> >>
>> >>> >>
>> >>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
>> >>> braden@chromium.org>
>> >>> >> wrote:
>> >>> >> > The change is not purely aesthetic; it means that the "my app"
>> >>> portions
>> >>> >> of
>> >>> >> > the structure are now contained in a single directory, and
>>easier
>> >>>to
>> >>> >> > version control.
>> >>> >> >
>> >>> >> > This change gets more expensive every day. If we're ever going
>>to
>> >>>do
>> >>> it,
>> >>> >> it
>> >>> >> > should be done now, I believe.
>> >>> >> >
>> >>> >> > It seems like the (not universally supported) consensus from
>>the
>> >>> first
>> >>> >> pass
>> >>> >> > at this thread was to keep the app/ dir but have automatic
>> >>>detection
>> >>> and
>> >>> >> > ask-then-automatic conversion.
>> >>> >> >
>> >>> >> > If that approach is still acceptable, I will implement that
>> >>>support
>> >>> today
>> >>> >> > before we tag CLI for 2.8.
>> >>> >> >
>> >>> >> > Braden
>> >>> >> >
>> >>> >> >
>> >>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny
>> >>><mm...@chromium.org>
>> >>> >> wrote:
>> >>> >> >
>> >>> >> >> Fil, good summary, thanks for that.  I also agree with your
>> >>> proposal.
>> >>> >> >>  Would it be possible to just support both options starting
>>now,
>> >>>and
>> >>> >> >> "deprecate" www/ at the top level in 3.0?
>> >>> >> >>
>> >>> >> >> Brian, this isn't just aesthetics, but its true that either
>> >>>option
>> >>> can,
>> >>> >> >> with varying difficulty, be made to work for all use cases.
>> >>> >> >>
>> >>> >> >> Migration path is trivial but will be paid by all users,
>>still,
>> >>> >> workflows
>> >>> >> >> will change completely with 3.0 anyway, this being the least
>>of
>> >>>the
>> >>> >> >> changes.  Which decision is more likely to be regretted a year
>> >>>from
>> >>> now?
>> >>> >> >>
>> >>> >> >> -Michal
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
>> >>> agrieve@chromium.org
>> >>> >> >> >wrote:
>> >>> >> >>
>> >>> >> >> > I don't really think this directory change is a big deal. We
>> >>>break
>> >>> >> things
>> >>> >> >> > in almost every release (e.g. loading pages of http), yet
>>we're
>> >>> >> having so
>> >>> >> >> > much debate over alpha tool.
>> >>> >> >> >
>> >>> >> >> > The migration path is: mkdir app && git mv www merges app &&
>> >>>git
>> >>> mv
>> >>> >> >> > app/www/config.xml app
>> >>> >> >> >
>> >>> >> >> > I think the least amount of work here is to just
>>console.log an
>> >>> error
>> >>> >> >> > message with this command if the app/ directory is not
>>found.
>> >>> >> >> >
>> >>> >> >> >
>> >>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>> >>> >> >> > <to...@devgeeks.org>wrote:
>> >>> >> >> >
>> >>> >> >> > > Is it bad that I both agree vehemently with Brian's
>>calling
>> >>>it
>> >>> not
>> >>> >> >> > > beneficial enough to justify, but also really really like
>>the
>> >>> >> proposed
>> >>> >> >> > > structure better that the current one? hehe.
>> >>> >> >> > >
>> >>> >> >> > > *soŠ conflicted...*
>> >>> >> >> > >
>> >>> >> >> > > - tommy
>> >>> >> >> > >
>> >>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io>
>>wrote:
>> >>> >> >> > >
>> >>> >> >> > > > There are two paths. I argue there is no functional
>>benefit
>> >>> and
>> >>> >> that
>> >>> >> >> > > > this change is purely aesthetic. Aesthetics are
>>important
>> >>>but
>> >>> I'd
>> >>> >> >> > > > argue folder structure is the last part of the developer
>> >>> >> aesthetics
>> >>> >> >> we
>> >>> >> >> > > > should worry about and especially not beneficial enough
>>to
>> >>> >> justify a
>> >>> >> >> > > > breaking change.
>> >>> >> >> > > >
>> >>> >> >> > > > Today:
>> >>> >> >> > > >
>> >>> >> >> > > > ./
>> >>> >> >> > > > |- merges/
>> >>> >> >> > > > |- platforms/
>> >>> >> >> > > > |- plugins/
>> >>> >> >> > > > '- www/
>> >>> >> >> > > >    |- index.html
>> >>> >> >> > > >    '- config.xml
>> >>> >> >> > > >
>> >>> >> >> > > > Proposed:
>> >>> >> >> > > >
>> >>> >> >> > > > ./
>> >>> >> >> > > > |- platforms/
>> >>> >> >> > > > |- plugins/
>> >>> >> >> > > > '- app/
>> >>> >> >> > > >    |- merges/
>> >>> >> >> > > >    |- www/
>> >>> >> >> > > >    |       '- index.html
>> >>> >> >> > > >    '- config.xml
>> >>> >> >> > > >
>> >>> >> >> > > >
>> >>> >> >> > > >
>> >>> >> >> > > >
>> >>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj
>><fi...@adobe.com>
>> >>> wrote:
>> >>> >> >> > > >> I'm reviving this discussion re: additional app/
>>folder in
>> >>> the
>> >>> >> >> > > >> cli-generated project structure.
>> >>> >> >> > > >>
>> >>> >> >> > > >> To recap, there were two main discussions:
>> >>> >> >> > > >>
>> >>> >> >> > > >> A)
>> >>> >> >> > > >>
>> >>> >> >> > >
>> >>> >> >> >
>> >>> >> >>
>> >>> >>
>> >>>
>> >>>
>> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76
>> >>>xli
>> >>> >> >> > > >> hsfjmvwtoi+state:results
>> >>> >> >> > > >> B)
>> >>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>> >>> >> >> > > >>
>> >>> >> >> > > >> Arguments for moving to app/:
>> >>> >> >> > > >>
>> >>> >> >> > > >> - easier to version control relevant /
>>non-build-artifact
>> >>>app
>> >>> >> bits
>> >>> >> >> > > >> - aesthetics
>> >>> >> >> > > >>
>> >>> >> >> > > >> Arguments against it:
>> >>> >> >> > > >>
>> >>> >> >> > > >> - we break shit for users
>> >>> >> >> > > >> - config.xml location and PhoneGap Build compatibility
>> >>>(but I
>> >>> >> don't
>> >>> >> >> > see
>> >>> >> >> > > >> this as a valid argument against. This is an easy
>>problem
>> >>>to
>> >>> >> solve
>> >>> >> >> for
>> >>> >> >> > > us
>> >>> >> >> > > >> Adobe folk and the tooling can handle the trivial
>>steps of
>> >>> going
>> >>> >> up
>> >>> >> >> > one
>> >>> >> >> > > >> directory to grab the right file before interfacing
>>with
>> >>> Build)
>> >>> >> >> > > >>
>> >>> >> >> > > >> Also worth noting: people we're not against it for
>> >>> architectural
>> >>> >> >> > > reasons,
>> >>> >> >> > > >> in fact, most people were favorable for the change to
>> >>>app/.
>> >>> >> >> > > >>
>> >>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli
>> >>> work, I
>> >>> >> >> feel I
>> >>> >> >> > > >> have a good grasp of both projects and the direction
>>they
>> >>>are
>> >>> >> going,
>> >>> >> >> > > here
>> >>> >> >> > > >> is my suggestion on how to move forward with this:
>> >>> >> >> > > >>
>> >>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge
>> >>>future
>> >>> work
>> >>> >> >> in,
>> >>> >> >> > > will
>> >>> >> >> > > >> revert to the old /www-based structure, then
>> >>> >> >> > > >> 2. In 3.0 we make the change, where landing such a
>> >>>breaking
>> >>> >> change
>> >>> >> >> is
>> >>> >> >> > > >> easier and we'll have a bunch of press/noise about the
>> >>> release
>> >>> >> out
>> >>> >> >> > there
>> >>> >> >> > > >> too so communicating this change would be easier.
>> >>> >> >> > > >>
>> >>> >> >> > > >> If there are any other arguments for/against the app/
>> >>>based
>> >>> >> >> structure,
>> >>> >> >> > > now
>> >>> >> >> > > >> is the time to bring it up. We can give this some more
>> >>>time
>> >>> to
>> >>> >> bake,
>> >>> >> >> > but
>> >>> >> >> > > >> after 2.8 is released, I'd like to call a vote on
>>whether
>> >>>we
>> >>> >> should
>> >>> >> >> > move
>> >>> >> >> > > >> to this structure or not in 3.0.
>> >>> >> >> > > >>
>> >>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny"
>><mm...@chromium.org>
>> >>> wrote:
>> >>> >> >> > > >>
>> >>> >> >> > > >>> I should also add.  I appreciate that this is a
>>change,
>> >>>and
>> >>> >> every
>> >>> >> >> > > change
>> >>> >> >> > > >>> has some learning overhead and we shouldn't stuff
>> >>>everything
>> >>> >> >> possible
>> >>> >> >> > > in
>> >>> >> >> > > >>> all the time.
>> >>> >> >> > > >>>
>> >>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we
>> >>> should do
>> >>> >> the
>> >>> >> >> > big
>> >>> >> >> > > >>> re-org all at once, so lets decide this now in a way
>>we
>> >>>wont
>> >>> >> >> regret.
>> >>> >> >> > > >>> Thats
>> >>> >> >> > > >>> why we are being picky, I guess.  I like knowing that
>>the
>> >>> root
>> >>> >> of
>> >>> >> >> the
>> >>> >> >> > > >>> project has cordova-only artifacts and your app-repo
>>is
>> >>> just a
>> >>> >> >> > > >>> subdirectory
>> >>> >> >> > > >>> somewhere.  Then, the exact location and exact
>>contents
>> >>>are
>> >>> way
>> >>> >> >> more
>> >>> >> >> > > >>> flexible.
>> >>> >> >> > > >>>
>> >>> >> >> > > >>> -Michal
>> >>> >> >> > > >>>
>> >>> >> >> > > >>>
>> >>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>> >>> >> >> mmocny@chromium.org>
>> >>> >> >> > > >>> wrote:
>> >>> >> >> > > >>>
>> >>> >> >> > > >>>> 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
>> >>> >> >> > > >>>> <ag...@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 <
>> >>> >> >> > > agrieve@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 <
>> >>> >> timkim85@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.kadri@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.Wolf@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"
>> >>><pu...@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 <
>> >>> >> >> > > >>>>> braden@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
>> >>> >> >> > > >>>>> <fi...@adobe.com>
>> >>> >> >> > > >>>>>>> wrote:
>> >>> >> >> > > >>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
>> >>> existing
>> >>> >> >> > > >>>>> users?
>> >>> >> >> > > >>>>>>>>>>>>>>
>> >>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>> >>> >> >> > > >>>>> braden@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
>> >>> >> >> > > >>>>>>>>
>> >>> >> >> > > >>>>>>>
>> >>> >> >> > > >>>>>>
>> >>> >> >> > > >>>>>
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>>>
>> >>> >> >> > > >>
>> >>> >> >> > >
>> >>> >> >> > >
>> >>> >> >> >
>> >>> >> >>
>> >>> >>
>> >>>
>> >>
>> >>
>>
>>

Re: New directory structure in cordova-cli's future branch

[Michal Mocny <mm...@chromium.org>]

Fil, that sounds extremely sensible.


On Thu, May 23, 2013 at 12:32 PM, Filip Maj <fi...@adobe.com> wrote:

> https://npmjs.org/package/cordova
>
>
> While CLI is not a documented flow, it is deployed and has > 1000
> downloads per month.
>
> That's my only concern: not fucking those people over.
>
> I'm in favor of that structure I just don't want it to change without
> warning in this next release. Ideally set up deprecation messages, be
> noisy about the change, and sure, possibly supporting a transitioning
> automatically in our tooling, and then land it in full and remove
> deprecation messages about it in 3.0.
>
> On 5/23/13 9:27 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>
> >Clarification of typing mistake, below..
> >
> >Also, curious why this breaks things in the first place?  I thought this
> >is
> >the first time we are releasing these tools?  The current create script
> >workflow is totally different, and I know there is a npm package for
> >cordova cli already, but that was never a promoted flow (matter of fact,
> >why was it released? Are we supporting current users of that, is that it?)
> >
> >-Michal
> >
> >On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mm...@chromium.org>
> >wrote:
> >
> >> Brian,
> >> I do not really understand your previous point, but I'll take a stab.
> >>
> >> First some clarification:  I think there are two logical "roots", (1)
> >>the
> >> root of your web app (holds merges/ and www/ and maybe more), and (2)
> >>the
> >> root of your cordova workspace (holds platforms/ plugins/ and maybe
> >>more).
> >>
> >> With the app/ folder, (1) is a subdirectory (2).  With the current
> >> situation, they overlap inside the same folder.
> >>
> >> I think it should be a goal to version control, share, and perhaps
> >>bundle
> >> auxiliary resources with app/'s.
> >> I think it should also be a goal to not limit the future structure of
> >>the
> >> cordova workspace (ie, build artifacts).
> >>
> >> The current situation makes these goals harder.
> >>
> >> As one data point, our team here has a workflow where we share several
> >> apps (containing only the contents(2)), and we share the common plugins
> >>we
> >> work on.
> >> The contents of (1) are never committed, shared, etc, and are just
> >> recreated on a regular basis as cordova versions change and as we test
> >>for
> >> different platforms.  Sidenote: yes, I have multiple different cordova
> >> workspaces pointing to one common app to test with different versions.
> >>  This is a bit of a cordova-developer necessity, but it would be
> >> interesting if external devs could trial out new cordova releases on the
> >> side, trivially..
> >>
> >Sigh, of course I got the numbers reversed here.. my bad.  Of course I
> >mean
> >we only commit (1).
> >
> >
> >>
> >>
> >> So, like you Brian, we are just trying to get all the
> >>requirements/wishes
> >> on the table so we can make a conscious decision here.  It looks like
> >>you
> >> are not seeing sufficient motivation for making the change, and we are
> >>not
> >> seeing any reason to not make it.
> >>
> >> Another observation: the transition path even easier than we have
> >>outlined
> >> above.
> >>
> >> If your existing project is:
> >> - app_name/
> >>  - platforms/
> >>  - plugins/
> >>  - www/
> >>  - merges/
> >>
> >> All you need to do is rm -rf platforms/ plugins/ www/config.xml -- which
> >> you need to do anyway to upgrade to 3.0 -- create a new config.xml at
> >>the
> >> root and you now have a shareable app, and you can create as many
> >>cordova
> >> different workspaces using it as you want.
> >>
> >> -Michal
> >>
> >>
> >> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote:
> >>
> >>> Not buying that either. The `./app` directory lives in the root so
> >>> everything will have to change when we hit the reality you describe
> >>> where `./app` IS the root.
> >>>
> >>> What you are really saying this is a transition step until such time
> >>> as `./app` becomes top level and things return to the same as they are
> >>> today but we do not require native bits to be revisioned. Essentially
> >>> this is an aesthetic forcing function to get back to the original
> >>> structure. =P
> >>>
> >>> This is a very complicated way to achieve the goal of native bits
> >>> being build artifacts. A goal I share, many do, and I think we can
> >>> achieve it by NOT breaking things today.
> >>>
> >>>
> >>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson
> >>><br...@chromium.org>
> >>> wrote:
> >>> > cd app
> >>> > git init
> >>> >
> >>> > Now my app directory - everything that makes this app mine and isn't
> >>> just a
> >>> > cordova-cli artifact - is version controlled. I can easily check out
> >>>a
> >>> new
> >>> > copy with a cordova create ...; rm -rf app; git clone https://
> >>> .../myrepo.git
> >>> > app
> >>> >
> >>> > Once we have app-level dependencies (which is planned regardless), I
> >>>can
> >>> > add cordova fetch-deps or whatever we decide the command should be,
> >>>and
> >>> now
> >>> > my app is fully set up. No need to juggle .gitignore or anything
> >>>else.
> >>> It's
> >>> > hardly a killer feature, but I think it is an improvement.
> >>> >
> >>> > Michal asked what change we would regret more a year from now. I
> >>>think
> >>> this
> >>> > style makes the separation of CLI artifacts and my app more clear,
> >>>and
> >>> if
> >>> > we add more pieces to either it won't require changing people's
> >>> .gitignore
> >>> > files or knowing about the architecture.
> >>> >
> >>> > Braden
> >>> >
> >>> >
> >>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
> >>> >
> >>> >> I want to be very clear that my tone here is emotionless! I'm
> >>>totally
> >>> >> indifferent.
> >>> >>
> >>> >> Now, please explain: how is a new directory make version control
> >>> >> easier? I don't buy it.
> >>> >>
> >>> >>
> >>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
> >>> braden@chromium.org>
> >>> >> wrote:
> >>> >> > The change is not purely aesthetic; it means that the "my app"
> >>> portions
> >>> >> of
> >>> >> > the structure are now contained in a single directory, and easier
> >>>to
> >>> >> > version control.
> >>> >> >
> >>> >> > This change gets more expensive every day. If we're ever going to
> >>>do
> >>> it,
> >>> >> it
> >>> >> > should be done now, I believe.
> >>> >> >
> >>> >> > It seems like the (not universally supported) consensus from the
> >>> first
> >>> >> pass
> >>> >> > at this thread was to keep the app/ dir but have automatic
> >>>detection
> >>> and
> >>> >> > ask-then-automatic conversion.
> >>> >> >
> >>> >> > If that approach is still acceptable, I will implement that
> >>>support
> >>> today
> >>> >> > before we tag CLI for 2.8.
> >>> >> >
> >>> >> > Braden
> >>> >> >
> >>> >> >
> >>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny
> >>><mm...@chromium.org>
> >>> >> wrote:
> >>> >> >
> >>> >> >> Fil, good summary, thanks for that.  I also agree with your
> >>> proposal.
> >>> >> >>  Would it be possible to just support both options starting now,
> >>>and
> >>> >> >> "deprecate" www/ at the top level in 3.0?
> >>> >> >>
> >>> >> >> Brian, this isn't just aesthetics, but its true that either
> >>>option
> >>> can,
> >>> >> >> with varying difficulty, be made to work for all use cases.
> >>> >> >>
> >>> >> >> Migration path is trivial but will be paid by all users, still,
> >>> >> workflows
> >>> >> >> will change completely with 3.0 anyway, this being the least of
> >>>the
> >>> >> >> changes.  Which decision is more likely to be regretted a year
> >>>from
> >>> now?
> >>> >> >>
> >>> >> >> -Michal
> >>> >> >>
> >>> >> >>
> >>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
> >>> agrieve@chromium.org
> >>> >> >> >wrote:
> >>> >> >>
> >>> >> >> > I don't really think this directory change is a big deal. We
> >>>break
> >>> >> things
> >>> >> >> > in almost every release (e.g. loading pages of http), yet we're
> >>> >> having so
> >>> >> >> > much debate over alpha tool.
> >>> >> >> >
> >>> >> >> > The migration path is: mkdir app && git mv www merges app &&
> >>>git
> >>> mv
> >>> >> >> > app/www/config.xml app
> >>> >> >> >
> >>> >> >> > I think the least amount of work here is to just console.log an
> >>> error
> >>> >> >> > message with this command if the app/ directory is not found.
> >>> >> >> >
> >>> >> >> >
> >>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
> >>> >> >> > <to...@devgeeks.org>wrote:
> >>> >> >> >
> >>> >> >> > > Is it bad that I both agree vehemently with Brian's calling
> >>>it
> >>> not
> >>> >> >> > > beneficial enough to justify, but also really really like the
> >>> >> proposed
> >>> >> >> > > structure better that the current one? hehe.
> >>> >> >> > >
> >>> >> >> > > *soŠ conflicted...*
> >>> >> >> > >
> >>> >> >> > > - tommy
> >>> >> >> > >
> >>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
> >>> >> >> > >
> >>> >> >> > > > There are two paths. I argue there is no functional benefit
> >>> and
> >>> >> that
> >>> >> >> > > > this change is purely aesthetic. Aesthetics are important
> >>>but
> >>> I'd
> >>> >> >> > > > argue folder structure is the last part of the developer
> >>> >> aesthetics
> >>> >> >> we
> >>> >> >> > > > should worry about and especially not beneficial enough to
> >>> >> justify a
> >>> >> >> > > > breaking change.
> >>> >> >> > > >
> >>> >> >> > > > Today:
> >>> >> >> > > >
> >>> >> >> > > > ./
> >>> >> >> > > > |- merges/
> >>> >> >> > > > |- platforms/
> >>> >> >> > > > |- plugins/
> >>> >> >> > > > '- www/
> >>> >> >> > > >    |- index.html
> >>> >> >> > > >    '- config.xml
> >>> >> >> > > >
> >>> >> >> > > > Proposed:
> >>> >> >> > > >
> >>> >> >> > > > ./
> >>> >> >> > > > |- platforms/
> >>> >> >> > > > |- plugins/
> >>> >> >> > > > '- app/
> >>> >> >> > > >    |- merges/
> >>> >> >> > > >    |- www/
> >>> >> >> > > >    |       '- index.html
> >>> >> >> > > >    '- config.xml
> >>> >> >> > > >
> >>> >> >> > > >
> >>> >> >> > > >
> >>> >> >> > > >
> >>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com>
> >>> wrote:
> >>> >> >> > > >> I'm reviving this discussion re: additional app/ folder in
> >>> the
> >>> >> >> > > >> cli-generated project structure.
> >>> >> >> > > >>
> >>> >> >> > > >> To recap, there were two main discussions:
> >>> >> >> > > >>
> >>> >> >> > > >> A)
> >>> >> >> > > >>
> >>> >> >> > >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> >>>
> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76
> >>>xli
> >>> >> >> > > >> hsfjmvwtoi+state:results
> >>> >> >> > > >> B)
> >>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
> >>> >> >> > > >>
> >>> >> >> > > >> Arguments for moving to app/:
> >>> >> >> > > >>
> >>> >> >> > > >> - easier to version control relevant / non-build-artifact
> >>>app
> >>> >> bits
> >>> >> >> > > >> - aesthetics
> >>> >> >> > > >>
> >>> >> >> > > >> Arguments against it:
> >>> >> >> > > >>
> >>> >> >> > > >> - we break shit for users
> >>> >> >> > > >> - config.xml location and PhoneGap Build compatibility
> >>>(but I
> >>> >> don't
> >>> >> >> > see
> >>> >> >> > > >> this as a valid argument against. This is an easy problem
> >>>to
> >>> >> solve
> >>> >> >> for
> >>> >> >> > > us
> >>> >> >> > > >> Adobe folk and the tooling can handle the trivial steps of
> >>> going
> >>> >> up
> >>> >> >> > one
> >>> >> >> > > >> directory to grab the right file before interfacing with
> >>> Build)
> >>> >> >> > > >>
> >>> >> >> > > >> Also worth noting: people we're not against it for
> >>> architectural
> >>> >> >> > > reasons,
> >>> >> >> > > >> in fact, most people were favorable for the change to
> >>>app/.
> >>> >> >> > > >>
> >>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli
> >>> work, I
> >>> >> >> feel I
> >>> >> >> > > >> have a good grasp of both projects and the direction they
> >>>are
> >>> >> going,
> >>> >> >> > > here
> >>> >> >> > > >> is my suggestion on how to move forward with this:
> >>> >> >> > > >>
> >>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge
> >>>future
> >>> work
> >>> >> >> in,
> >>> >> >> > > will
> >>> >> >> > > >> revert to the old /www-based structure, then
> >>> >> >> > > >> 2. In 3.0 we make the change, where landing such a
> >>>breaking
> >>> >> change
> >>> >> >> is
> >>> >> >> > > >> easier and we'll have a bunch of press/noise about the
> >>> release
> >>> >> out
> >>> >> >> > there
> >>> >> >> > > >> too so communicating this change would be easier.
> >>> >> >> > > >>
> >>> >> >> > > >> If there are any other arguments for/against the app/
> >>>based
> >>> >> >> structure,
> >>> >> >> > > now
> >>> >> >> > > >> is the time to bring it up. We can give this some more
> >>>time
> >>> to
> >>> >> bake,
> >>> >> >> > but
> >>> >> >> > > >> after 2.8 is released, I'd like to call a vote on whether
> >>>we
> >>> >> should
> >>> >> >> > move
> >>> >> >> > > >> to this structure or not in 3.0.
> >>> >> >> > > >>
> >>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org>
> >>> wrote:
> >>> >> >> > > >>
> >>> >> >> > > >>> I should also add.  I appreciate that this is a change,
> >>>and
> >>> >> every
> >>> >> >> > > change
> >>> >> >> > > >>> has some learning overhead and we shouldn't stuff
> >>>everything
> >>> >> >> possible
> >>> >> >> > > in
> >>> >> >> > > >>> all the time.
> >>> >> >> > > >>>
> >>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we
> >>> should do
> >>> >> the
> >>> >> >> > big
> >>> >> >> > > >>> re-org all at once, so lets decide this now in a way we
> >>>wont
> >>> >> >> regret.
> >>> >> >> > > >>> Thats
> >>> >> >> > > >>> why we are being picky, I guess.  I like knowing that the
> >>> root
> >>> >> of
> >>> >> >> the
> >>> >> >> > > >>> project has cordova-only artifacts and your app-repo is
> >>> just a
> >>> >> >> > > >>> subdirectory
> >>> >> >> > > >>> somewhere.  Then, the exact location and exact contents
> >>>are
> >>> way
> >>> >> >> more
> >>> >> >> > > >>> flexible.
> >>> >> >> > > >>>
> >>> >> >> > > >>> -Michal
> >>> >> >> > > >>>
> >>> >> >> > > >>>
> >>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
> >>> >> >> mmocny@chromium.org>
> >>> >> >> > > >>> wrote:
> >>> >> >> > > >>>
> >>> >> >> > > >>>> 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
> >>> >> >> > > >>>> <ag...@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 <
> >>> >> >> > > agrieve@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 <
> >>> >> timkim85@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.kadri@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.Wolf@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"
> >>><pu...@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 <
> >>> >> >> > > >>>>> braden@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
> >>> >> >> > > >>>>> <fi...@adobe.com>
> >>> >> >> > > >>>>>>> wrote:
> >>> >> >> > > >>>>>>>>>>>>>
> >>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
> >>> existing
> >>> >> >> > > >>>>> users?
> >>> >> >> > > >>>>>>>>>>>>>>
> >>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> >>> >> >> > > >>>>> braden@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
> >>> >> >> > > >>>>>>>>
> >>> >> >> > > >>>>>>>
> >>> >> >> > > >>>>>>
> >>> >> >> > > >>>>>
> >>> >> >> > > >>>>
> >>> >> >> > > >>>>
> >>> >> >> > > >>
> >>> >> >> > >
> >>> >> >> > >
> >>> >> >> >
> >>> >> >>
> >>> >>
> >>>
> >>
> >>
>
>

Re: New directory structure in cordova-cli's future branch

[Michael Wolf <Mi...@Cynergy.com>]

+1
to making a change in 3.0.  As a user I would expect major changes and
wouldn't be bothered by changes at that time.  I would also add that this
isn't just a break for users of the cli, but also for users who create
their own build systems.

mw

On 5/23/13 12:32 PM, "Filip Maj" <fi...@adobe.com> wrote:

>https://npmjs.org/package/cordova
>
>
>While CLI is not a documented flow, it is deployed and has > 1000
>downloads per month.
>
>That's my only concern: not fucking those people over.
>
>I'm in favor of that structure I just don't want it to change without
>warning in this next release. Ideally set up deprecation messages, be
>noisy about the change, and sure, possibly supporting a transitioning
>automatically in our tooling, and then land it in full and remove
>deprecation messages about it in 3.0.
>
>On 5/23/13 9:27 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>
>>Clarification of typing mistake, below..
>>
>>Also, curious why this breaks things in the first place?  I thought this
>>is
>>the first time we are releasing these tools?  The current create script
>>workflow is totally different, and I know there is a npm package for
>>cordova cli already, but that was never a promoted flow (matter of fact,
>>why was it released? Are we supporting current users of that, is that
>>it?)
>>
>>-Michal
>>
>>On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mm...@chromium.org>
>>wrote:
>>
>>> Brian,
>>> I do not really understand your previous point, but I'll take a stab.
>>>
>>> First some clarification:  I think there are two logical "roots", (1)
>>>the
>>> root of your web app (holds merges/ and www/ and maybe more), and (2)
>>>the
>>> root of your cordova workspace (holds platforms/ plugins/ and maybe
>>>more).
>>>
>>> With the app/ folder, (1) is a subdirectory (2).  With the current
>>> situation, they overlap inside the same folder.
>>>
>>> I think it should be a goal to version control, share, and perhaps
>>>bundle
>>> auxiliary resources with app/'s.
>>> I think it should also be a goal to not limit the future structure of
>>>the
>>> cordova workspace (ie, build artifacts).
>>>
>>> The current situation makes these goals harder.
>>>
>>> As one data point, our team here has a workflow where we share several
>>> apps (containing only the contents(2)), and we share the common plugins
>>>we
>>> work on.
>>> The contents of (1) are never committed, shared, etc, and are just
>>> recreated on a regular basis as cordova versions change and as we test
>>>for
>>> different platforms.  Sidenote: yes, I have multiple different cordova
>>> workspaces pointing to one common app to test with different versions.
>>>  This is a bit of a cordova-developer necessity, but it would be
>>> interesting if external devs could trial out new cordova releases on
>>>the
>>> side, trivially..
>>>
>>Sigh, of course I got the numbers reversed here.. my bad.  Of course I
>>mean
>>we only commit (1).
>>
>>
>>>
>>>
>>> So, like you Brian, we are just trying to get all the
>>>requirements/wishes
>>> on the table so we can make a conscious decision here.  It looks like
>>>you
>>> are not seeing sufficient motivation for making the change, and we are
>>>not
>>> seeing any reason to not make it.
>>>
>>> Another observation: the transition path even easier than we have
>>>outlined
>>> above.
>>>
>>> If your existing project is:
>>> - app_name/
>>>  - platforms/
>>>  - plugins/
>>>  - www/
>>>  - merges/
>>>
>>> All you need to do is rm -rf platforms/ plugins/ www/config.xml --
>>>which
>>> you need to do anyway to upgrade to 3.0 -- create a new config.xml at
>>>the
>>> root and you now have a shareable app, and you can create as many
>>>cordova
>>> different workspaces using it as you want.
>>>
>>> -Michal
>>>
>>>
>>> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote:
>>>
>>>> Not buying that either. The `./app` directory lives in the root so
>>>> everything will have to change when we hit the reality you describe
>>>> where `./app` IS the root.
>>>>
>>>> What you are really saying this is a transition step until such time
>>>> as `./app` becomes top level and things return to the same as they are
>>>> today but we do not require native bits to be revisioned. Essentially
>>>> this is an aesthetic forcing function to get back to the original
>>>> structure. =P
>>>>
>>>> This is a very complicated way to achieve the goal of native bits
>>>> being build artifacts. A goal I share, many do, and I think we can
>>>> achieve it by NOT breaking things today.
>>>>
>>>>
>>>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson
>>>><br...@chromium.org>
>>>> wrote:
>>>> > cd app
>>>> > git init
>>>> >
>>>> > Now my app directory - everything that makes this app mine and isn't
>>>> just a
>>>> > cordova-cli artifact - is version controlled. I can easily check out
>>>>a
>>>> new
>>>> > copy with a cordova create ...; rm -rf app; git clone https://
>>>> .../myrepo.git
>>>> > app
>>>> >
>>>> > Once we have app-level dependencies (which is planned regardless), I
>>>>can
>>>> > add cordova fetch-deps or whatever we decide the command should be,
>>>>and
>>>> now
>>>> > my app is fully set up. No need to juggle .gitignore or anything
>>>>else.
>>>> It's
>>>> > hardly a killer feature, but I think it is an improvement.
>>>> >
>>>> > Michal asked what change we would regret more a year from now. I
>>>>think
>>>> this
>>>> > style makes the separation of CLI artifacts and my app more clear,
>>>>and
>>>> if
>>>> > we add more pieces to either it won't require changing people's
>>>> .gitignore
>>>> > files or knowing about the architecture.
>>>> >
>>>> > Braden
>>>> >
>>>> >
>>>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
>>>> >
>>>> >> I want to be very clear that my tone here is emotionless! I'm
>>>>totally
>>>> >> indifferent.
>>>> >>
>>>> >> Now, please explain: how is a new directory make version control
>>>> >> easier? I don't buy it.
>>>> >>
>>>> >>
>>>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
>>>> braden@chromium.org>
>>>> >> wrote:
>>>> >> > The change is not purely aesthetic; it means that the "my app"
>>>> portions
>>>> >> of
>>>> >> > the structure are now contained in a single directory, and easier
>>>>to
>>>> >> > version control.
>>>> >> >
>>>> >> > This change gets more expensive every day. If we're ever going to
>>>>do
>>>> it,
>>>> >> it
>>>> >> > should be done now, I believe.
>>>> >> >
>>>> >> > It seems like the (not universally supported) consensus from the
>>>> first
>>>> >> pass
>>>> >> > at this thread was to keep the app/ dir but have automatic
>>>>detection
>>>> and
>>>> >> > ask-then-automatic conversion.
>>>> >> >
>>>> >> > If that approach is still acceptable, I will implement that
>>>>support
>>>> today
>>>> >> > before we tag CLI for 2.8.
>>>> >> >
>>>> >> > Braden
>>>> >> >
>>>> >> >
>>>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny
>>>><mm...@chromium.org>
>>>> >> wrote:
>>>> >> >
>>>> >> >> Fil, good summary, thanks for that.  I also agree with your
>>>> proposal.
>>>> >> >>  Would it be possible to just support both options starting now,
>>>>and
>>>> >> >> "deprecate" www/ at the top level in 3.0?
>>>> >> >>
>>>> >> >> Brian, this isn't just aesthetics, but its true that either
>>>>option
>>>> can,
>>>> >> >> with varying difficulty, be made to work for all use cases.
>>>> >> >>
>>>> >> >> Migration path is trivial but will be paid by all users, still,
>>>> >> workflows
>>>> >> >> will change completely with 3.0 anyway, this being the least of
>>>>the
>>>> >> >> changes.  Which decision is more likely to be regretted a year
>>>>from
>>>> now?
>>>> >> >>
>>>> >> >> -Michal
>>>> >> >>
>>>> >> >>
>>>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
>>>> agrieve@chromium.org
>>>> >> >> >wrote:
>>>> >> >>
>>>> >> >> > I don't really think this directory change is a big deal. We
>>>>break
>>>> >> things
>>>> >> >> > in almost every release (e.g. loading pages of http), yet
>>>>we're
>>>> >> having so
>>>> >> >> > much debate over alpha tool.
>>>> >> >> >
>>>> >> >> > The migration path is: mkdir app && git mv www merges app &&
>>>>git
>>>> mv
>>>> >> >> > app/www/config.xml app
>>>> >> >> >
>>>> >> >> > I think the least amount of work here is to just console.log
>>>>an
>>>> error
>>>> >> >> > message with this command if the app/ directory is not found.
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>>>> >> >> > <to...@devgeeks.org>wrote:
>>>> >> >> >
>>>> >> >> > > Is it bad that I both agree vehemently with Brian's calling
>>>>it
>>>> not
>>>> >> >> > > beneficial enough to justify, but also really really like
>>>>the
>>>> >> proposed
>>>> >> >> > > structure better that the current one? hehe.
>>>> >> >> > >
>>>> >> >> > > *soŠ conflicted...*
>>>> >> >> > >
>>>> >> >> > > - tommy
>>>> >> >> > >
>>>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
>>>> >> >> > >
>>>> >> >> > > > There are two paths. I argue there is no functional
>>>>benefit
>>>> and
>>>> >> that
>>>> >> >> > > > this change is purely aesthetic. Aesthetics are important
>>>>but
>>>> I'd
>>>> >> >> > > > argue folder structure is the last part of the developer
>>>> >> aesthetics
>>>> >> >> we
>>>> >> >> > > > should worry about and especially not beneficial enough to
>>>> >> justify a
>>>> >> >> > > > breaking change.
>>>> >> >> > > >
>>>> >> >> > > > Today:
>>>> >> >> > > >
>>>> >> >> > > > ./
>>>> >> >> > > > |- merges/
>>>> >> >> > > > |- platforms/
>>>> >> >> > > > |- plugins/
>>>> >> >> > > > '- www/
>>>> >> >> > > >    |- index.html
>>>> >> >> > > >    '- config.xml
>>>> >> >> > > >
>>>> >> >> > > > Proposed:
>>>> >> >> > > >
>>>> >> >> > > > ./
>>>> >> >> > > > |- platforms/
>>>> >> >> > > > |- plugins/
>>>> >> >> > > > '- app/
>>>> >> >> > > >    |- merges/
>>>> >> >> > > >    |- www/
>>>> >> >> > > >    |       '- index.html
>>>> >> >> > > >    '- config.xml
>>>> >> >> > > >
>>>> >> >> > > >
>>>> >> >> > > >
>>>> >> >> > > >
>>>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com>
>>>> wrote:
>>>> >> >> > > >> I'm reviving this discussion re: additional app/ folder
>>>>in
>>>> the
>>>> >> >> > > >> cli-generated project structure.
>>>> >> >> > > >>
>>>> >> >> > > >> To recap, there were two main discussions:
>>>> >> >> > > >>
>>>> >> >> > > >> A)
>>>> >> >> > > >>
>>>> >> >> > >
>>>> >> >> >
>>>> >> >>
>>>> >>
>>>>
>>>>http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j7
>>>>6
>>>>xli
>>>> >> >> > > >> hsfjmvwtoi+state:results
>>>> >> >> > > >> B)
>>>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>>>> >> >> > > >>
>>>> >> >> > > >> Arguments for moving to app/:
>>>> >> >> > > >>
>>>> >> >> > > >> - easier to version control relevant / non-build-artifact
>>>>app
>>>> >> bits
>>>> >> >> > > >> - aesthetics
>>>> >> >> > > >>
>>>> >> >> > > >> Arguments against it:
>>>> >> >> > > >>
>>>> >> >> > > >> - we break shit for users
>>>> >> >> > > >> - config.xml location and PhoneGap Build compatibility
>>>>(but I
>>>> >> don't
>>>> >> >> > see
>>>> >> >> > > >> this as a valid argument against. This is an easy problem
>>>>to
>>>> >> solve
>>>> >> >> for
>>>> >> >> > > us
>>>> >> >> > > >> Adobe folk and the tooling can handle the trivial steps
>>>>of
>>>> going
>>>> >> up
>>>> >> >> > one
>>>> >> >> > > >> directory to grab the right file before interfacing with
>>>> Build)
>>>> >> >> > > >>
>>>> >> >> > > >> Also worth noting: people we're not against it for
>>>> architectural
>>>> >> >> > > reasons,
>>>> >> >> > > >> in fact, most people were favorable for the change to
>>>>app/.
>>>> >> >> > > >>
>>>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli
>>>> work, I
>>>> >> >> feel I
>>>> >> >> > > >> have a good grasp of both projects and the direction they
>>>>are
>>>> >> going,
>>>> >> >> > > here
>>>> >> >> > > >> is my suggestion on how to move forward with this:
>>>> >> >> > > >>
>>>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge
>>>>future
>>>> work
>>>> >> >> in,
>>>> >> >> > > will
>>>> >> >> > > >> revert to the old /www-based structure, then
>>>> >> >> > > >> 2. In 3.0 we make the change, where landing such a
>>>>breaking
>>>> >> change
>>>> >> >> is
>>>> >> >> > > >> easier and we'll have a bunch of press/noise about the
>>>> release
>>>> >> out
>>>> >> >> > there
>>>> >> >> > > >> too so communicating this change would be easier.
>>>> >> >> > > >>
>>>> >> >> > > >> If there are any other arguments for/against the app/
>>>>based
>>>> >> >> structure,
>>>> >> >> > > now
>>>> >> >> > > >> is the time to bring it up. We can give this some more
>>>>time
>>>> to
>>>> >> bake,
>>>> >> >> > but
>>>> >> >> > > >> after 2.8 is released, I'd like to call a vote on whether
>>>>we
>>>> >> should
>>>> >> >> > move
>>>> >> >> > > >> to this structure or not in 3.0.
>>>> >> >> > > >>
>>>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org>
>>>> wrote:
>>>> >> >> > > >>
>>>> >> >> > > >>> I should also add.  I appreciate that this is a change,
>>>>and
>>>> >> every
>>>> >> >> > > change
>>>> >> >> > > >>> has some learning overhead and we shouldn't stuff
>>>>everything
>>>> >> >> possible
>>>> >> >> > > in
>>>> >> >> > > >>> all the time.
>>>> >> >> > > >>>
>>>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we
>>>> should do
>>>> >> the
>>>> >> >> > big
>>>> >> >> > > >>> re-org all at once, so lets decide this now in a way we
>>>>wont
>>>> >> >> regret.
>>>> >> >> > > >>> Thats
>>>> >> >> > > >>> why we are being picky, I guess.  I like knowing that
>>>>the
>>>> root
>>>> >> of
>>>> >> >> the
>>>> >> >> > > >>> project has cordova-only artifacts and your app-repo is
>>>> just a
>>>> >> >> > > >>> subdirectory
>>>> >> >> > > >>> somewhere.  Then, the exact location and exact contents
>>>>are
>>>> way
>>>> >> >> more
>>>> >> >> > > >>> flexible.
>>>> >> >> > > >>>
>>>> >> >> > > >>> -Michal
>>>> >> >> > > >>>
>>>> >> >> > > >>>
>>>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>>>> >> >> mmocny@chromium.org>
>>>> >> >> > > >>> wrote:
>>>> >> >> > > >>>
>>>> >> >> > > >>>> 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
>>>> >> >> > > >>>> <ag...@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 <
>>>> >> >> > > agrieve@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 <
>>>> >> timkim85@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.kadri@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.Wolf@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"
>>>><pu...@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 <
>>>> >> >> > > >>>>> braden@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
>>>> >> >> > > >>>>> <fi...@adobe.com>
>>>> >> >> > > >>>>>>> wrote:
>>>> >> >> > > >>>>>>>>>>>>>
>>>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
>>>> existing
>>>> >> >> > > >>>>> users?
>>>> >> >> > > >>>>>>>>>>>>>>
>>>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>>>> >> >> > > >>>>> braden@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
>>>> >> >> > > >>>>>>>>
>>>> >> >> > > >>>>>>>
>>>> >> >> > > >>>>>>
>>>> >> >> > > >>>>>
>>>> >> >> > > >>>>
>>>> >> >> > > >>>>
>>>> >> >> > > >>
>>>> >> >> > >
>>>> >> >> > >
>>>> >> >> >
>>>> >> >>
>>>> >>
>>>>
>>>
>>>
>

Re: New directory structure in cordova-cli's future branch

[Filip Maj <fi...@adobe.com>]

https://npmjs.org/package/cordova


While CLI is not a documented flow, it is deployed and has > 1000
downloads per month.

That's my only concern: not fucking those people over.

I'm in favor of that structure I just don't want it to change without
warning in this next release. Ideally set up deprecation messages, be
noisy about the change, and sure, possibly supporting a transitioning
automatically in our tooling, and then land it in full and remove
deprecation messages about it in 3.0.

On 5/23/13 9:27 AM, "Michal Mocny" <mm...@chromium.org> wrote:

>Clarification of typing mistake, below..
>
>Also, curious why this breaks things in the first place?  I thought this
>is
>the first time we are releasing these tools?  The current create script
>workflow is totally different, and I know there is a npm package for
>cordova cli already, but that was never a promoted flow (matter of fact,
>why was it released? Are we supporting current users of that, is that it?)
>
>-Michal
>
>On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mm...@chromium.org>
>wrote:
>
>> Brian,
>> I do not really understand your previous point, but I'll take a stab.
>>
>> First some clarification:  I think there are two logical "roots", (1)
>>the
>> root of your web app (holds merges/ and www/ and maybe more), and (2)
>>the
>> root of your cordova workspace (holds platforms/ plugins/ and maybe
>>more).
>>
>> With the app/ folder, (1) is a subdirectory (2).  With the current
>> situation, they overlap inside the same folder.
>>
>> I think it should be a goal to version control, share, and perhaps
>>bundle
>> auxiliary resources with app/'s.
>> I think it should also be a goal to not limit the future structure of
>>the
>> cordova workspace (ie, build artifacts).
>>
>> The current situation makes these goals harder.
>>
>> As one data point, our team here has a workflow where we share several
>> apps (containing only the contents(2)), and we share the common plugins
>>we
>> work on.
>> The contents of (1) are never committed, shared, etc, and are just
>> recreated on a regular basis as cordova versions change and as we test
>>for
>> different platforms.  Sidenote: yes, I have multiple different cordova
>> workspaces pointing to one common app to test with different versions.
>>  This is a bit of a cordova-developer necessity, but it would be
>> interesting if external devs could trial out new cordova releases on the
>> side, trivially..
>>
>Sigh, of course I got the numbers reversed here.. my bad.  Of course I
>mean
>we only commit (1).
>
>
>>
>>
>> So, like you Brian, we are just trying to get all the
>>requirements/wishes
>> on the table so we can make a conscious decision here.  It looks like
>>you
>> are not seeing sufficient motivation for making the change, and we are
>>not
>> seeing any reason to not make it.
>>
>> Another observation: the transition path even easier than we have
>>outlined
>> above.
>>
>> If your existing project is:
>> - app_name/
>>  - platforms/
>>  - plugins/
>>  - www/
>>  - merges/
>>
>> All you need to do is rm -rf platforms/ plugins/ www/config.xml -- which
>> you need to do anyway to upgrade to 3.0 -- create a new config.xml at
>>the
>> root and you now have a shareable app, and you can create as many
>>cordova
>> different workspaces using it as you want.
>>
>> -Michal
>>
>>
>> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote:
>>
>>> Not buying that either. The `./app` directory lives in the root so
>>> everything will have to change when we hit the reality you describe
>>> where `./app` IS the root.
>>>
>>> What you are really saying this is a transition step until such time
>>> as `./app` becomes top level and things return to the same as they are
>>> today but we do not require native bits to be revisioned. Essentially
>>> this is an aesthetic forcing function to get back to the original
>>> structure. =P
>>>
>>> This is a very complicated way to achieve the goal of native bits
>>> being build artifacts. A goal I share, many do, and I think we can
>>> achieve it by NOT breaking things today.
>>>
>>>
>>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson
>>><br...@chromium.org>
>>> wrote:
>>> > cd app
>>> > git init
>>> >
>>> > Now my app directory - everything that makes this app mine and isn't
>>> just a
>>> > cordova-cli artifact - is version controlled. I can easily check out
>>>a
>>> new
>>> > copy with a cordova create ...; rm -rf app; git clone https://
>>> .../myrepo.git
>>> > app
>>> >
>>> > Once we have app-level dependencies (which is planned regardless), I
>>>can
>>> > add cordova fetch-deps or whatever we decide the command should be,
>>>and
>>> now
>>> > my app is fully set up. No need to juggle .gitignore or anything
>>>else.
>>> It's
>>> > hardly a killer feature, but I think it is an improvement.
>>> >
>>> > Michal asked what change we would regret more a year from now. I
>>>think
>>> this
>>> > style makes the separation of CLI artifacts and my app more clear,
>>>and
>>> if
>>> > we add more pieces to either it won't require changing people's
>>> .gitignore
>>> > files or knowing about the architecture.
>>> >
>>> > Braden
>>> >
>>> >
>>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
>>> >
>>> >> I want to be very clear that my tone here is emotionless! I'm
>>>totally
>>> >> indifferent.
>>> >>
>>> >> Now, please explain: how is a new directory make version control
>>> >> easier? I don't buy it.
>>> >>
>>> >>
>>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
>>> braden@chromium.org>
>>> >> wrote:
>>> >> > The change is not purely aesthetic; it means that the "my app"
>>> portions
>>> >> of
>>> >> > the structure are now contained in a single directory, and easier
>>>to
>>> >> > version control.
>>> >> >
>>> >> > This change gets more expensive every day. If we're ever going to
>>>do
>>> it,
>>> >> it
>>> >> > should be done now, I believe.
>>> >> >
>>> >> > It seems like the (not universally supported) consensus from the
>>> first
>>> >> pass
>>> >> > at this thread was to keep the app/ dir but have automatic
>>>detection
>>> and
>>> >> > ask-then-automatic conversion.
>>> >> >
>>> >> > If that approach is still acceptable, I will implement that
>>>support
>>> today
>>> >> > before we tag CLI for 2.8.
>>> >> >
>>> >> > Braden
>>> >> >
>>> >> >
>>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny
>>><mm...@chromium.org>
>>> >> wrote:
>>> >> >
>>> >> >> Fil, good summary, thanks for that.  I also agree with your
>>> proposal.
>>> >> >>  Would it be possible to just support both options starting now,
>>>and
>>> >> >> "deprecate" www/ at the top level in 3.0?
>>> >> >>
>>> >> >> Brian, this isn't just aesthetics, but its true that either
>>>option
>>> can,
>>> >> >> with varying difficulty, be made to work for all use cases.
>>> >> >>
>>> >> >> Migration path is trivial but will be paid by all users, still,
>>> >> workflows
>>> >> >> will change completely with 3.0 anyway, this being the least of
>>>the
>>> >> >> changes.  Which decision is more likely to be regretted a year
>>>from
>>> now?
>>> >> >>
>>> >> >> -Michal
>>> >> >>
>>> >> >>
>>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
>>> agrieve@chromium.org
>>> >> >> >wrote:
>>> >> >>
>>> >> >> > I don't really think this directory change is a big deal. We
>>>break
>>> >> things
>>> >> >> > in almost every release (e.g. loading pages of http), yet we're
>>> >> having so
>>> >> >> > much debate over alpha tool.
>>> >> >> >
>>> >> >> > The migration path is: mkdir app && git mv www merges app &&
>>>git
>>> mv
>>> >> >> > app/www/config.xml app
>>> >> >> >
>>> >> >> > I think the least amount of work here is to just console.log an
>>> error
>>> >> >> > message with this command if the app/ directory is not found.
>>> >> >> >
>>> >> >> >
>>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>>> >> >> > <to...@devgeeks.org>wrote:
>>> >> >> >
>>> >> >> > > Is it bad that I both agree vehemently with Brian's calling
>>>it
>>> not
>>> >> >> > > beneficial enough to justify, but also really really like the
>>> >> proposed
>>> >> >> > > structure better that the current one? hehe.
>>> >> >> > >
>>> >> >> > > *soŠ conflicted...*
>>> >> >> > >
>>> >> >> > > - tommy
>>> >> >> > >
>>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
>>> >> >> > >
>>> >> >> > > > There are two paths. I argue there is no functional benefit
>>> and
>>> >> that
>>> >> >> > > > this change is purely aesthetic. Aesthetics are important
>>>but
>>> I'd
>>> >> >> > > > argue folder structure is the last part of the developer
>>> >> aesthetics
>>> >> >> we
>>> >> >> > > > should worry about and especially not beneficial enough to
>>> >> justify a
>>> >> >> > > > breaking change.
>>> >> >> > > >
>>> >> >> > > > Today:
>>> >> >> > > >
>>> >> >> > > > ./
>>> >> >> > > > |- merges/
>>> >> >> > > > |- platforms/
>>> >> >> > > > |- plugins/
>>> >> >> > > > '- www/
>>> >> >> > > >    |- index.html
>>> >> >> > > >    '- config.xml
>>> >> >> > > >
>>> >> >> > > > Proposed:
>>> >> >> > > >
>>> >> >> > > > ./
>>> >> >> > > > |- platforms/
>>> >> >> > > > |- plugins/
>>> >> >> > > > '- app/
>>> >> >> > > >    |- merges/
>>> >> >> > > >    |- www/
>>> >> >> > > >    |       '- index.html
>>> >> >> > > >    '- config.xml
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com>
>>> wrote:
>>> >> >> > > >> I'm reviving this discussion re: additional app/ folder in
>>> the
>>> >> >> > > >> cli-generated project structure.
>>> >> >> > > >>
>>> >> >> > > >> To recap, there were two main discussions:
>>> >> >> > > >>
>>> >> >> > > >> A)
>>> >> >> > > >>
>>> >> >> > >
>>> >> >> >
>>> >> >>
>>> >>
>>>
>>>http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76
>>>xli
>>> >> >> > > >> hsfjmvwtoi+state:results
>>> >> >> > > >> B)
>>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>>> >> >> > > >>
>>> >> >> > > >> Arguments for moving to app/:
>>> >> >> > > >>
>>> >> >> > > >> - easier to version control relevant / non-build-artifact
>>>app
>>> >> bits
>>> >> >> > > >> - aesthetics
>>> >> >> > > >>
>>> >> >> > > >> Arguments against it:
>>> >> >> > > >>
>>> >> >> > > >> - we break shit for users
>>> >> >> > > >> - config.xml location and PhoneGap Build compatibility
>>>(but I
>>> >> don't
>>> >> >> > see
>>> >> >> > > >> this as a valid argument against. This is an easy problem
>>>to
>>> >> solve
>>> >> >> for
>>> >> >> > > us
>>> >> >> > > >> Adobe folk and the tooling can handle the trivial steps of
>>> going
>>> >> up
>>> >> >> > one
>>> >> >> > > >> directory to grab the right file before interfacing with
>>> Build)
>>> >> >> > > >>
>>> >> >> > > >> Also worth noting: people we're not against it for
>>> architectural
>>> >> >> > > reasons,
>>> >> >> > > >> in fact, most people were favorable for the change to
>>>app/.
>>> >> >> > > >>
>>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli
>>> work, I
>>> >> >> feel I
>>> >> >> > > >> have a good grasp of both projects and the direction they
>>>are
>>> >> going,
>>> >> >> > > here
>>> >> >> > > >> is my suggestion on how to move forward with this:
>>> >> >> > > >>
>>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge
>>>future
>>> work
>>> >> >> in,
>>> >> >> > > will
>>> >> >> > > >> revert to the old /www-based structure, then
>>> >> >> > > >> 2. In 3.0 we make the change, where landing such a
>>>breaking
>>> >> change
>>> >> >> is
>>> >> >> > > >> easier and we'll have a bunch of press/noise about the
>>> release
>>> >> out
>>> >> >> > there
>>> >> >> > > >> too so communicating this change would be easier.
>>> >> >> > > >>
>>> >> >> > > >> If there are any other arguments for/against the app/
>>>based
>>> >> >> structure,
>>> >> >> > > now
>>> >> >> > > >> is the time to bring it up. We can give this some more
>>>time
>>> to
>>> >> bake,
>>> >> >> > but
>>> >> >> > > >> after 2.8 is released, I'd like to call a vote on whether
>>>we
>>> >> should
>>> >> >> > move
>>> >> >> > > >> to this structure or not in 3.0.
>>> >> >> > > >>
>>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org>
>>> wrote:
>>> >> >> > > >>
>>> >> >> > > >>> I should also add.  I appreciate that this is a change,
>>>and
>>> >> every
>>> >> >> > > change
>>> >> >> > > >>> has some learning overhead and we shouldn't stuff
>>>everything
>>> >> >> possible
>>> >> >> > > in
>>> >> >> > > >>> all the time.
>>> >> >> > > >>>
>>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we
>>> should do
>>> >> the
>>> >> >> > big
>>> >> >> > > >>> re-org all at once, so lets decide this now in a way we
>>>wont
>>> >> >> regret.
>>> >> >> > > >>> Thats
>>> >> >> > > >>> why we are being picky, I guess.  I like knowing that the
>>> root
>>> >> of
>>> >> >> the
>>> >> >> > > >>> project has cordova-only artifacts and your app-repo is
>>> just a
>>> >> >> > > >>> subdirectory
>>> >> >> > > >>> somewhere.  Then, the exact location and exact contents
>>>are
>>> way
>>> >> >> more
>>> >> >> > > >>> flexible.
>>> >> >> > > >>>
>>> >> >> > > >>> -Michal
>>> >> >> > > >>>
>>> >> >> > > >>>
>>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>>> >> >> mmocny@chromium.org>
>>> >> >> > > >>> wrote:
>>> >> >> > > >>>
>>> >> >> > > >>>> 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
>>> >> >> > > >>>> <ag...@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 <
>>> >> >> > > agrieve@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 <
>>> >> timkim85@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.kadri@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.Wolf@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"
>>><pu...@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 <
>>> >> >> > > >>>>> braden@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
>>> >> >> > > >>>>> <fi...@adobe.com>
>>> >> >> > > >>>>>>> wrote:
>>> >> >> > > >>>>>>>>>>>>>
>>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
>>> existing
>>> >> >> > > >>>>> users?
>>> >> >> > > >>>>>>>>>>>>>>
>>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>>> >> >> > > >>>>> braden@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
>>> >> >> > > >>>>>>>>
>>> >> >> > > >>>>>>>
>>> >> >> > > >>>>>>
>>> >> >> > > >>>>>
>>> >> >> > > >>>>
>>> >> >> > > >>>>
>>> >> >> > > >>
>>> >> >> > >
>>> >> >> > >
>>> >> >> >
>>> >> >>
>>> >>
>>>
>>
>>

Re: New directory structure in cordova-cli's future branch

[Michal Mocny <mm...@chromium.org>]

Clarification of typing mistake, below..

Also, curious why this breaks things in the first place?  I thought this is
the first time we are releasing these tools?  The current create script
workflow is totally different, and I know there is a npm package for
cordova cli already, but that was never a promoted flow (matter of fact,
why was it released? Are we supporting current users of that, is that it?)

-Michal

On Thu, May 23, 2013 at 12:22 PM, Michal Mocny <mm...@chromium.org> wrote:

> Brian,
> I do not really understand your previous point, but I'll take a stab.
>
> First some clarification:  I think there are two logical "roots", (1) the
> root of your web app (holds merges/ and www/ and maybe more), and (2) the
> root of your cordova workspace (holds platforms/ plugins/ and maybe more).
>
> With the app/ folder, (1) is a subdirectory (2).  With the current
> situation, they overlap inside the same folder.
>
> I think it should be a goal to version control, share, and perhaps bundle
> auxiliary resources with app/'s.
> I think it should also be a goal to not limit the future structure of the
> cordova workspace (ie, build artifacts).
>
> The current situation makes these goals harder.
>
> As one data point, our team here has a workflow where we share several
> apps (containing only the contents(2)), and we share the common plugins we
> work on.
> The contents of (1) are never committed, shared, etc, and are just
> recreated on a regular basis as cordova versions change and as we test for
> different platforms.  Sidenote: yes, I have multiple different cordova
> workspaces pointing to one common app to test with different versions.
>  This is a bit of a cordova-developer necessity, but it would be
> interesting if external devs could trial out new cordova releases on the
> side, trivially..
>
Sigh, of course I got the numbers reversed here.. my bad.  Of course I mean
we only commit (1).


>
>
> So, like you Brian, we are just trying to get all the requirements/wishes
> on the table so we can make a conscious decision here.  It looks like you
> are not seeing sufficient motivation for making the change, and we are not
> seeing any reason to not make it.
>
> Another observation: the transition path even easier than we have outlined
> above.
>
> If your existing project is:
> - app_name/
>  - platforms/
>  - plugins/
>  - www/
>  - merges/
>
> All you need to do is rm -rf platforms/ plugins/ www/config.xml -- which
> you need to do anyway to upgrade to 3.0 -- create a new config.xml at the
> root and you now have a shareable app, and you can create as many cordova
> different workspaces using it as you want.
>
> -Michal
>
>
> On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> Not buying that either. The `./app` directory lives in the root so
>> everything will have to change when we hit the reality you describe
>> where `./app` IS the root.
>>
>> What you are really saying this is a transition step until such time
>> as `./app` becomes top level and things return to the same as they are
>> today but we do not require native bits to be revisioned. Essentially
>> this is an aesthetic forcing function to get back to the original
>> structure. =P
>>
>> This is a very complicated way to achieve the goal of native bits
>> being build artifacts. A goal I share, many do, and I think we can
>> achieve it by NOT breaking things today.
>>
>>
>> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson <br...@chromium.org>
>> wrote:
>> > cd app
>> > git init
>> >
>> > Now my app directory - everything that makes this app mine and isn't
>> just a
>> > cordova-cli artifact - is version controlled. I can easily check out a
>> new
>> > copy with a cordova create ...; rm -rf app; git clone https://
>> .../myrepo.git
>> > app
>> >
>> > Once we have app-level dependencies (which is planned regardless), I can
>> > add cordova fetch-deps or whatever we decide the command should be, and
>> now
>> > my app is fully set up. No need to juggle .gitignore or anything else.
>> It's
>> > hardly a killer feature, but I think it is an improvement.
>> >
>> > Michal asked what change we would regret more a year from now. I think
>> this
>> > style makes the separation of CLI artifacts and my app more clear, and
>> if
>> > we add more pieces to either it won't require changing people's
>> .gitignore
>> > files or knowing about the architecture.
>> >
>> > Braden
>> >
>> >
>> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
>> >
>> >> I want to be very clear that my tone here is emotionless! I'm totally
>> >> indifferent.
>> >>
>> >> Now, please explain: how is a new directory make version control
>> >> easier? I don't buy it.
>> >>
>> >>
>> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
>> braden@chromium.org>
>> >> wrote:
>> >> > The change is not purely aesthetic; it means that the "my app"
>> portions
>> >> of
>> >> > the structure are now contained in a single directory, and easier to
>> >> > version control.
>> >> >
>> >> > This change gets more expensive every day. If we're ever going to do
>> it,
>> >> it
>> >> > should be done now, I believe.
>> >> >
>> >> > It seems like the (not universally supported) consensus from the
>> first
>> >> pass
>> >> > at this thread was to keep the app/ dir but have automatic detection
>> and
>> >> > ask-then-automatic conversion.
>> >> >
>> >> > If that approach is still acceptable, I will implement that support
>> today
>> >> > before we tag CLI for 2.8.
>> >> >
>> >> > Braden
>> >> >
>> >> >
>> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny <mm...@chromium.org>
>> >> wrote:
>> >> >
>> >> >> Fil, good summary, thanks for that.  I also agree with your
>> proposal.
>> >> >>  Would it be possible to just support both options starting now, and
>> >> >> "deprecate" www/ at the top level in 3.0?
>> >> >>
>> >> >> Brian, this isn't just aesthetics, but its true that either option
>> can,
>> >> >> with varying difficulty, be made to work for all use cases.
>> >> >>
>> >> >> Migration path is trivial but will be paid by all users, still,
>> >> workflows
>> >> >> will change completely with 3.0 anyway, this being the least of the
>> >> >> changes.  Which decision is more likely to be regretted a year from
>> now?
>> >> >>
>> >> >> -Michal
>> >> >>
>> >> >>
>> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
>> agrieve@chromium.org
>> >> >> >wrote:
>> >> >>
>> >> >> > I don't really think this directory change is a big deal. We break
>> >> things
>> >> >> > in almost every release (e.g. loading pages of http), yet we're
>> >> having so
>> >> >> > much debate over alpha tool.
>> >> >> >
>> >> >> > The migration path is: mkdir app && git mv www merges app && git
>> mv
>> >> >> > app/www/config.xml app
>> >> >> >
>> >> >> > I think the least amount of work here is to just console.log an
>> error
>> >> >> > message with this command if the app/ directory is not found.
>> >> >> >
>> >> >> >
>> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>> >> >> > <to...@devgeeks.org>wrote:
>> >> >> >
>> >> >> > > Is it bad that I both agree vehemently with Brian's calling it
>> not
>> >> >> > > beneficial enough to justify, but also really really like the
>> >> proposed
>> >> >> > > structure better that the current one? hehe.
>> >> >> > >
>> >> >> > > *so… conflicted...*
>> >> >> > >
>> >> >> > > - tommy
>> >> >> > >
>> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
>> >> >> > >
>> >> >> > > > There are two paths. I argue there is no functional benefit
>> and
>> >> that
>> >> >> > > > this change is purely aesthetic. Aesthetics are important but
>> I'd
>> >> >> > > > argue folder structure is the last part of the developer
>> >> aesthetics
>> >> >> we
>> >> >> > > > should worry about and especially not beneficial enough to
>> >> justify a
>> >> >> > > > breaking change.
>> >> >> > > >
>> >> >> > > > Today:
>> >> >> > > >
>> >> >> > > > ./
>> >> >> > > > |- merges/
>> >> >> > > > |- platforms/
>> >> >> > > > |- plugins/
>> >> >> > > > '- www/
>> >> >> > > >    |- index.html
>> >> >> > > >    '- config.xml
>> >> >> > > >
>> >> >> > > > Proposed:
>> >> >> > > >
>> >> >> > > > ./
>> >> >> > > > |- platforms/
>> >> >> > > > |- plugins/
>> >> >> > > > '- app/
>> >> >> > > >    |- merges/
>> >> >> > > >    |- www/
>> >> >> > > >    |       '- index.html
>> >> >> > > >    '- config.xml
>> >> >> > > >
>> >> >> > > >
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com>
>> wrote:
>> >> >> > > >> I'm reviving this discussion re: additional app/ folder in
>> the
>> >> >> > > >> cli-generated project structure.
>> >> >> > > >>
>> >> >> > > >> To recap, there were two main discussions:
>> >> >> > > >>
>> >> >> > > >> A)
>> >> >> > > >>
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
>> >> >> > > >> hsfjmvwtoi+state:results
>> >> >> > > >> B)
>> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>> >> >> > > >>
>> >> >> > > >> Arguments for moving to app/:
>> >> >> > > >>
>> >> >> > > >> - easier to version control relevant / non-build-artifact app
>> >> bits
>> >> >> > > >> - aesthetics
>> >> >> > > >>
>> >> >> > > >> Arguments against it:
>> >> >> > > >>
>> >> >> > > >> - we break shit for users
>> >> >> > > >> - config.xml location and PhoneGap Build compatibility (but I
>> >> don't
>> >> >> > see
>> >> >> > > >> this as a valid argument against. This is an easy problem to
>> >> solve
>> >> >> for
>> >> >> > > us
>> >> >> > > >> Adobe folk and the tooling can handle the trivial steps of
>> going
>> >> up
>> >> >> > one
>> >> >> > > >> directory to grab the right file before interfacing with
>> Build)
>> >> >> > > >>
>> >> >> > > >> Also worth noting: people we're not against it for
>> architectural
>> >> >> > > reasons,
>> >> >> > > >> in fact, most people were favorable for the change to app/.
>> >> >> > > >>
>> >> >> > > >> So, with plugman stabilizing and my focus moving to cli
>> work, I
>> >> >> feel I
>> >> >> > > >> have a good grasp of both projects and the direction they are
>> >> going,
>> >> >> > > here
>> >> >> > > >> is my suggestion on how to move forward with this:
>> >> >> > > >>
>> >> >> > > >> 1. cordova-cli's master branch, which will soon merge future
>> work
>> >> >> in,
>> >> >> > > will
>> >> >> > > >> revert to the old /www-based structure, then
>> >> >> > > >> 2. In 3.0 we make the change, where landing such a breaking
>> >> change
>> >> >> is
>> >> >> > > >> easier and we'll have a bunch of press/noise about the
>> release
>> >> out
>> >> >> > there
>> >> >> > > >> too so communicating this change would be easier.
>> >> >> > > >>
>> >> >> > > >> If there are any other arguments for/against the app/ based
>> >> >> structure,
>> >> >> > > now
>> >> >> > > >> is the time to bring it up. We can give this some more time
>> to
>> >> bake,
>> >> >> > but
>> >> >> > > >> after 2.8 is released, I'd like to call a vote on whether we
>> >> should
>> >> >> > move
>> >> >> > > >> to this structure or not in 3.0.
>> >> >> > > >>
>> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org>
>> wrote:
>> >> >> > > >>
>> >> >> > > >>> I should also add.  I appreciate that this is a change, and
>> >> every
>> >> >> > > change
>> >> >> > > >>> has some learning overhead and we shouldn't stuff everything
>> >> >> possible
>> >> >> > > in
>> >> >> > > >>> all the time.
>> >> >> > > >>>
>> >> >> > > >>> However, I think 3.0 and cli are a big change, and we
>> should do
>> >> the
>> >> >> > big
>> >> >> > > >>> re-org all at once, so lets decide this now in a way we wont
>> >> >> regret.
>> >> >> > > >>> Thats
>> >> >> > > >>> why we are being picky, I guess.  I like knowing that the
>> root
>> >> of
>> >> >> the
>> >> >> > > >>> project has cordova-only artifacts and your app-repo is
>> just a
>> >> >> > > >>> subdirectory
>> >> >> > > >>> somewhere.  Then, the exact location and exact contents are
>> way
>> >> >> more
>> >> >> > > >>> flexible.
>> >> >> > > >>>
>> >> >> > > >>> -Michal
>> >> >> > > >>>
>> >> >> > > >>>
>> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>> >> >> mmocny@chromium.org>
>> >> >> > > >>> wrote:
>> >> >> > > >>>
>> >> >> > > >>>> 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
>> >> >> > > >>>> <ag...@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 <
>> >> >> > > agrieve@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 <
>> >> timkim85@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.kadri@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.Wolf@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" <pu...@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 <
>> >> >> > > >>>>> braden@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
>> >> >> > > >>>>> <fi...@adobe.com>
>> >> >> > > >>>>>>> wrote:
>> >> >> > > >>>>>>>>>>>>>
>> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
>> existing
>> >> >> > > >>>>> users?
>> >> >> > > >>>>>>>>>>>>>>
>> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>> >> >> > > >>>>> braden@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
>> >> >> > > >>>>>>>>
>> >> >> > > >>>>>>>
>> >> >> > > >>>>>>
>> >> >> > > >>>>>
>> >> >> > > >>>>
>> >> >> > > >>>>
>> >> >> > > >>
>> >> >> > >
>> >> >> > >
>> >> >> >
>> >> >>
>> >>
>>
>
>

Re: New directory structure in cordova-cli's future branch

[Michal Mocny <mm...@chromium.org>]

Brian,
I do not really understand your previous point, but I'll take a stab.

First some clarification:  I think there are two logical "roots", (1) the
root of your web app (holds merges/ and www/ and maybe more), and (2) the
root of your cordova workspace (holds platforms/ plugins/ and maybe more).

With the app/ folder, (1) is a subdirectory (2).  With the current
situation, they overlap inside the same folder.

I think it should be a goal to version control, share, and perhaps bundle
auxiliary resources with app/'s.
I think it should also be a goal to not limit the future structure of the
cordova workspace (ie, build artifacts).

The current situation makes these goals harder.

As one data point, our team here has a workflow where we share several apps
(containing only the contents(2)), and we share the common plugins we work
on.
The contents of (1) are never committed, shared, etc, and are just
recreated on a regular basis as cordova versions change and as we test for
different platforms.  Sidenote: yes, I have multiple different cordova
workspaces pointing to one common app to test with different versions.
 This is a bit of a cordova-developer necessity, but it would be
interesting if external devs could trial out new cordova releases on the
side, trivially..


So, like you Brian, we are just trying to get all the requirements/wishes
on the table so we can make a conscious decision here.  It looks like you
are not seeing sufficient motivation for making the change, and we are not
seeing any reason to not make it.

Another observation: the transition path even easier than we have outlined
above.

If your existing project is:
- app_name/
 - platforms/
 - plugins/
 - www/
 - merges/

All you need to do is rm -rf platforms/ plugins/ www/config.xml -- which
you need to do anyway to upgrade to 3.0 -- create a new config.xml at the
root and you now have a shareable app, and you can create as many cordova
different workspaces using it as you want.

-Michal


On Thu, May 23, 2013 at 11:47 AM, Brian LeRoux <b...@brian.io> wrote:

> Not buying that either. The `./app` directory lives in the root so
> everything will have to change when we hit the reality you describe
> where `./app` IS the root.
>
> What you are really saying this is a transition step until such time
> as `./app` becomes top level and things return to the same as they are
> today but we do not require native bits to be revisioned. Essentially
> this is an aesthetic forcing function to get back to the original
> structure. =P
>
> This is a very complicated way to achieve the goal of native bits
> being build artifacts. A goal I share, many do, and I think we can
> achieve it by NOT breaking things today.
>
>
> On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson <br...@chromium.org>
> wrote:
> > cd app
> > git init
> >
> > Now my app directory - everything that makes this app mine and isn't
> just a
> > cordova-cli artifact - is version controlled. I can easily check out a
> new
> > copy with a cordova create ...; rm -rf app; git clone https://
> .../myrepo.git
> > app
> >
> > Once we have app-level dependencies (which is planned regardless), I can
> > add cordova fetch-deps or whatever we decide the command should be, and
> now
> > my app is fully set up. No need to juggle .gitignore or anything else.
> It's
> > hardly a killer feature, but I think it is an improvement.
> >
> > Michal asked what change we would regret more a year from now. I think
> this
> > style makes the separation of CLI artifacts and my app more clear, and if
> > we add more pieces to either it won't require changing people's
> .gitignore
> > files or knowing about the architecture.
> >
> > Braden
> >
> >
> > On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> >> I want to be very clear that my tone here is emotionless! I'm totally
> >> indifferent.
> >>
> >> Now, please explain: how is a new directory make version control
> >> easier? I don't buy it.
> >>
> >>
> >> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <
> braden@chromium.org>
> >> wrote:
> >> > The change is not purely aesthetic; it means that the "my app"
> portions
> >> of
> >> > the structure are now contained in a single directory, and easier to
> >> > version control.
> >> >
> >> > This change gets more expensive every day. If we're ever going to do
> it,
> >> it
> >> > should be done now, I believe.
> >> >
> >> > It seems like the (not universally supported) consensus from the first
> >> pass
> >> > at this thread was to keep the app/ dir but have automatic detection
> and
> >> > ask-then-automatic conversion.
> >> >
> >> > If that approach is still acceptable, I will implement that support
> today
> >> > before we tag CLI for 2.8.
> >> >
> >> > Braden
> >> >
> >> >
> >> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny <mm...@chromium.org>
> >> wrote:
> >> >
> >> >> Fil, good summary, thanks for that.  I also agree with your proposal.
> >> >>  Would it be possible to just support both options starting now, and
> >> >> "deprecate" www/ at the top level in 3.0?
> >> >>
> >> >> Brian, this isn't just aesthetics, but its true that either option
> can,
> >> >> with varying difficulty, be made to work for all use cases.
> >> >>
> >> >> Migration path is trivial but will be paid by all users, still,
> >> workflows
> >> >> will change completely with 3.0 anyway, this being the least of the
> >> >> changes.  Which decision is more likely to be regretted a year from
> now?
> >> >>
> >> >> -Michal
> >> >>
> >> >>
> >> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <
> agrieve@chromium.org
> >> >> >wrote:
> >> >>
> >> >> > I don't really think this directory change is a big deal. We break
> >> things
> >> >> > in almost every release (e.g. loading pages of http), yet we're
> >> having so
> >> >> > much debate over alpha tool.
> >> >> >
> >> >> > The migration path is: mkdir app && git mv www merges app && git mv
> >> >> > app/www/config.xml app
> >> >> >
> >> >> > I think the least amount of work here is to just console.log an
> error
> >> >> > message with this command if the app/ directory is not found.
> >> >> >
> >> >> >
> >> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
> >> >> > <to...@devgeeks.org>wrote:
> >> >> >
> >> >> > > Is it bad that I both agree vehemently with Brian's calling it
> not
> >> >> > > beneficial enough to justify, but also really really like the
> >> proposed
> >> >> > > structure better that the current one? hehe.
> >> >> > >
> >> >> > > *so… conflicted...*
> >> >> > >
> >> >> > > - tommy
> >> >> > >
> >> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
> >> >> > >
> >> >> > > > There are two paths. I argue there is no functional benefit and
> >> that
> >> >> > > > this change is purely aesthetic. Aesthetics are important but
> I'd
> >> >> > > > argue folder structure is the last part of the developer
> >> aesthetics
> >> >> we
> >> >> > > > should worry about and especially not beneficial enough to
> >> justify a
> >> >> > > > breaking change.
> >> >> > > >
> >> >> > > > Today:
> >> >> > > >
> >> >> > > > ./
> >> >> > > > |- merges/
> >> >> > > > |- platforms/
> >> >> > > > |- plugins/
> >> >> > > > '- www/
> >> >> > > >    |- index.html
> >> >> > > >    '- config.xml
> >> >> > > >
> >> >> > > > Proposed:
> >> >> > > >
> >> >> > > > ./
> >> >> > > > |- platforms/
> >> >> > > > |- plugins/
> >> >> > > > '- app/
> >> >> > > >    |- merges/
> >> >> > > >    |- www/
> >> >> > > >    |       '- index.html
> >> >> > > >    '- config.xml
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > >
> >> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com>
> wrote:
> >> >> > > >> I'm reviving this discussion re: additional app/ folder in the
> >> >> > > >> cli-generated project structure.
> >> >> > > >>
> >> >> > > >> To recap, there were two main discussions:
> >> >> > > >>
> >> >> > > >> A)
> >> >> > > >>
> >> >> > >
> >> >> >
> >> >>
> >>
> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
> >> >> > > >> hsfjmvwtoi+state:results
> >> >> > > >> B)
> >> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
> >> >> > > >>
> >> >> > > >> Arguments for moving to app/:
> >> >> > > >>
> >> >> > > >> - easier to version control relevant / non-build-artifact app
> >> bits
> >> >> > > >> - aesthetics
> >> >> > > >>
> >> >> > > >> Arguments against it:
> >> >> > > >>
> >> >> > > >> - we break shit for users
> >> >> > > >> - config.xml location and PhoneGap Build compatibility (but I
> >> don't
> >> >> > see
> >> >> > > >> this as a valid argument against. This is an easy problem to
> >> solve
> >> >> for
> >> >> > > us
> >> >> > > >> Adobe folk and the tooling can handle the trivial steps of
> going
> >> up
> >> >> > one
> >> >> > > >> directory to grab the right file before interfacing with
> Build)
> >> >> > > >>
> >> >> > > >> Also worth noting: people we're not against it for
> architectural
> >> >> > > reasons,
> >> >> > > >> in fact, most people were favorable for the change to app/.
> >> >> > > >>
> >> >> > > >> So, with plugman stabilizing and my focus moving to cli work,
> I
> >> >> feel I
> >> >> > > >> have a good grasp of both projects and the direction they are
> >> going,
> >> >> > > here
> >> >> > > >> is my suggestion on how to move forward with this:
> >> >> > > >>
> >> >> > > >> 1. cordova-cli's master branch, which will soon merge future
> work
> >> >> in,
> >> >> > > will
> >> >> > > >> revert to the old /www-based structure, then
> >> >> > > >> 2. In 3.0 we make the change, where landing such a breaking
> >> change
> >> >> is
> >> >> > > >> easier and we'll have a bunch of press/noise about the release
> >> out
> >> >> > there
> >> >> > > >> too so communicating this change would be easier.
> >> >> > > >>
> >> >> > > >> If there are any other arguments for/against the app/ based
> >> >> structure,
> >> >> > > now
> >> >> > > >> is the time to bring it up. We can give this some more time to
> >> bake,
> >> >> > but
> >> >> > > >> after 2.8 is released, I'd like to call a vote on whether we
> >> should
> >> >> > move
> >> >> > > >> to this structure or not in 3.0.
> >> >> > > >>
> >> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org>
> wrote:
> >> >> > > >>
> >> >> > > >>> I should also add.  I appreciate that this is a change, and
> >> every
> >> >> > > change
> >> >> > > >>> has some learning overhead and we shouldn't stuff everything
> >> >> possible
> >> >> > > in
> >> >> > > >>> all the time.
> >> >> > > >>>
> >> >> > > >>> However, I think 3.0 and cli are a big change, and we should
> do
> >> the
> >> >> > big
> >> >> > > >>> re-org all at once, so lets decide this now in a way we wont
> >> >> regret.
> >> >> > > >>> Thats
> >> >> > > >>> why we are being picky, I guess.  I like knowing that the
> root
> >> of
> >> >> the
> >> >> > > >>> project has cordova-only artifacts and your app-repo is just
> a
> >> >> > > >>> subdirectory
> >> >> > > >>> somewhere.  Then, the exact location and exact contents are
> way
> >> >> more
> >> >> > > >>> flexible.
> >> >> > > >>>
> >> >> > > >>> -Michal
> >> >> > > >>>
> >> >> > > >>>
> >> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
> >> >> mmocny@chromium.org>
> >> >> > > >>> wrote:
> >> >> > > >>>
> >> >> > > >>>> 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
> >> >> > > >>>> <ag...@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 <
> >> >> > > agrieve@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 <
> >> timkim85@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.kadri@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.Wolf@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" <pu...@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 <
> >> >> > > >>>>> braden@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
> >> >> > > >>>>> <fi...@adobe.com>
> >> >> > > >>>>>>> wrote:
> >> >> > > >>>>>>>>>>>>>
> >> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
> existing
> >> >> > > >>>>> users?
> >> >> > > >>>>>>>>>>>>>>
> >> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> >> >> > > >>>>> braden@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
> >> >> > > >>>>>>>>
> >> >> > > >>>>>>>
> >> >> > > >>>>>>
> >> >> > > >>>>>
> >> >> > > >>>>
> >> >> > > >>>>
> >> >> > > >>
> >> >> > >
> >> >> > >
> >> >> >
> >> >>
> >>
>

Re: New directory structure in cordova-cli's future branch

[Michael Wolf <Mi...@Cynergy.com>]

Also this is assuming your making no changes to Platforms, and I among
others often make changes to the native containers, which then must be
checked in.

mw

On 5/23/13 11:47 AM, "Brian LeRoux" <b...@brian.io> wrote:

>Not buying that either. The `./app` directory lives in the root so
>everything will have to change when we hit the reality you describe
>where `./app` IS the root.
>
>What you are really saying this is a transition step until such time
>as `./app` becomes top level and things return to the same as they are
>today but we do not require native bits to be revisioned. Essentially
>this is an aesthetic forcing function to get back to the original
>structure. =P
>
>This is a very complicated way to achieve the goal of native bits
>being build artifacts. A goal I share, many do, and I think we can
>achieve it by NOT breaking things today.
>
>
>On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson <br...@chromium.org>
>wrote:
>> cd app
>> git init
>>
>> Now my app directory - everything that makes this app mine and isn't
>>just a
>> cordova-cli artifact - is version controlled. I can easily check out a
>>new
>> copy with a cordova create ...; rm -rf app; git clone
>>https://.../myrepo.git
>> app
>>
>> Once we have app-level dependencies (which is planned regardless), I can
>> add cordova fetch-deps or whatever we decide the command should be, and
>>now
>> my app is fully set up. No need to juggle .gitignore or anything else.
>>It's
>> hardly a killer feature, but I think it is an improvement.
>>
>> Michal asked what change we would regret more a year from now. I think
>>this
>> style makes the separation of CLI artifacts and my app more clear, and
>>if
>> we add more pieces to either it won't require changing people's
>>.gitignore
>> files or knowing about the architecture.
>>
>> Braden
>>
>>
>> On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
>>
>>> I want to be very clear that my tone here is emotionless! I'm totally
>>> indifferent.
>>>
>>> Now, please explain: how is a new directory make version control
>>> easier? I don't buy it.
>>>
>>>
>>> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson
>>><br...@chromium.org>
>>> wrote:
>>> > The change is not purely aesthetic; it means that the "my app"
>>>portions
>>> of
>>> > the structure are now contained in a single directory, and easier to
>>> > version control.
>>> >
>>> > This change gets more expensive every day. If we're ever going to do
>>>it,
>>> it
>>> > should be done now, I believe.
>>> >
>>> > It seems like the (not universally supported) consensus from the
>>>first
>>> pass
>>> > at this thread was to keep the app/ dir but have automatic detection
>>>and
>>> > ask-then-automatic conversion.
>>> >
>>> > If that approach is still acceptable, I will implement that support
>>>today
>>> > before we tag CLI for 2.8.
>>> >
>>> > Braden
>>> >
>>> >
>>> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>> >
>>> >> Fil, good summary, thanks for that.  I also agree with your
>>>proposal.
>>> >>  Would it be possible to just support both options starting now, and
>>> >> "deprecate" www/ at the top level in 3.0?
>>> >>
>>> >> Brian, this isn't just aesthetics, but its true that either option
>>>can,
>>> >> with varying difficulty, be made to work for all use cases.
>>> >>
>>> >> Migration path is trivial but will be paid by all users, still,
>>> workflows
>>> >> will change completely with 3.0 anyway, this being the least of the
>>> >> changes.  Which decision is more likely to be regretted a year from
>>>now?
>>> >>
>>> >> -Michal
>>> >>
>>> >>
>>> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve
>>><agrieve@chromium.org
>>> >> >wrote:
>>> >>
>>> >> > I don't really think this directory change is a big deal. We break
>>> things
>>> >> > in almost every release (e.g. loading pages of http), yet we're
>>> having so
>>> >> > much debate over alpha tool.
>>> >> >
>>> >> > The migration path is: mkdir app && git mv www merges app && git
>>>mv
>>> >> > app/www/config.xml app
>>> >> >
>>> >> > I think the least amount of work here is to just console.log an
>>>error
>>> >> > message with this command if the app/ directory is not found.
>>> >> >
>>> >> >
>>> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>>> >> > <to...@devgeeks.org>wrote:
>>> >> >
>>> >> > > Is it bad that I both agree vehemently with Brian's calling it
>>>not
>>> >> > > beneficial enough to justify, but also really really like the
>>> proposed
>>> >> > > structure better that the current one? hehe.
>>> >> > >
>>> >> > > *soŠ conflicted...*
>>> >> > >
>>> >> > > - tommy
>>> >> > >
>>> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
>>> >> > >
>>> >> > > > There are two paths. I argue there is no functional benefit
>>>and
>>> that
>>> >> > > > this change is purely aesthetic. Aesthetics are important but
>>>I'd
>>> >> > > > argue folder structure is the last part of the developer
>>> aesthetics
>>> >> we
>>> >> > > > should worry about and especially not beneficial enough to
>>> justify a
>>> >> > > > breaking change.
>>> >> > > >
>>> >> > > > Today:
>>> >> > > >
>>> >> > > > ./
>>> >> > > > |- merges/
>>> >> > > > |- platforms/
>>> >> > > > |- plugins/
>>> >> > > > '- www/
>>> >> > > >    |- index.html
>>> >> > > >    '- config.xml
>>> >> > > >
>>> >> > > > Proposed:
>>> >> > > >
>>> >> > > > ./
>>> >> > > > |- platforms/
>>> >> > > > |- plugins/
>>> >> > > > '- app/
>>> >> > > >    |- merges/
>>> >> > > >    |- www/
>>> >> > > >    |       '- index.html
>>> >> > > >    '- config.xml
>>> >> > > >
>>> >> > > >
>>> >> > > >
>>> >> > > >
>>> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com>
>>>wrote:
>>> >> > > >> I'm reviving this discussion re: additional app/ folder in
>>>the
>>> >> > > >> cli-generated project structure.
>>> >> > > >>
>>> >> > > >> To recap, there were two main discussions:
>>> >> > > >>
>>> >> > > >> A)
>>> >> > > >>
>>> >> > >
>>> >> >
>>> >>
>>>
>>>http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76
>>>xli
>>> >> > > >> hsfjmvwtoi+state:results
>>> >> > > >> B)
>>> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>>> >> > > >>
>>> >> > > >> Arguments for moving to app/:
>>> >> > > >>
>>> >> > > >> - easier to version control relevant / non-build-artifact app
>>> bits
>>> >> > > >> - aesthetics
>>> >> > > >>
>>> >> > > >> Arguments against it:
>>> >> > > >>
>>> >> > > >> - we break shit for users
>>> >> > > >> - config.xml location and PhoneGap Build compatibility (but I
>>> don't
>>> >> > see
>>> >> > > >> this as a valid argument against. This is an easy problem to
>>> solve
>>> >> for
>>> >> > > us
>>> >> > > >> Adobe folk and the tooling can handle the trivial steps of
>>>going
>>> up
>>> >> > one
>>> >> > > >> directory to grab the right file before interfacing with
>>>Build)
>>> >> > > >>
>>> >> > > >> Also worth noting: people we're not against it for
>>>architectural
>>> >> > > reasons,
>>> >> > > >> in fact, most people were favorable for the change to app/.
>>> >> > > >>
>>> >> > > >> So, with plugman stabilizing and my focus moving to cli
>>>work, I
>>> >> feel I
>>> >> > > >> have a good grasp of both projects and the direction they are
>>> going,
>>> >> > > here
>>> >> > > >> is my suggestion on how to move forward with this:
>>> >> > > >>
>>> >> > > >> 1. cordova-cli's master branch, which will soon merge future
>>>work
>>> >> in,
>>> >> > > will
>>> >> > > >> revert to the old /www-based structure, then
>>> >> > > >> 2. In 3.0 we make the change, where landing such a breaking
>>> change
>>> >> is
>>> >> > > >> easier and we'll have a bunch of press/noise about the
>>>release
>>> out
>>> >> > there
>>> >> > > >> too so communicating this change would be easier.
>>> >> > > >>
>>> >> > > >> If there are any other arguments for/against the app/ based
>>> >> structure,
>>> >> > > now
>>> >> > > >> is the time to bring it up. We can give this some more time
>>>to
>>> bake,
>>> >> > but
>>> >> > > >> after 2.8 is released, I'd like to call a vote on whether we
>>> should
>>> >> > move
>>> >> > > >> to this structure or not in 3.0.
>>> >> > > >>
>>> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org>
>>>wrote:
>>> >> > > >>
>>> >> > > >>> I should also add.  I appreciate that this is a change, and
>>> every
>>> >> > > change
>>> >> > > >>> has some learning overhead and we shouldn't stuff everything
>>> >> possible
>>> >> > > in
>>> >> > > >>> all the time.
>>> >> > > >>>
>>> >> > > >>> However, I think 3.0 and cli are a big change, and we
>>>should do
>>> the
>>> >> > big
>>> >> > > >>> re-org all at once, so lets decide this now in a way we wont
>>> >> regret.
>>> >> > > >>> Thats
>>> >> > > >>> why we are being picky, I guess.  I like knowing that the
>>>root
>>> of
>>> >> the
>>> >> > > >>> project has cordova-only artifacts and your app-repo is
>>>just a
>>> >> > > >>> subdirectory
>>> >> > > >>> somewhere.  Then, the exact location and exact contents are
>>>way
>>> >> more
>>> >> > > >>> flexible.
>>> >> > > >>>
>>> >> > > >>> -Michal
>>> >> > > >>>
>>> >> > > >>>
>>> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>>> >> mmocny@chromium.org>
>>> >> > > >>> wrote:
>>> >> > > >>>
>>> >> > > >>>> 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
>>> >> > > >>>> <ag...@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 <
>>> >> > > agrieve@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 <
>>> timkim85@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
>>><an...@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.Wolf@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" <pu...@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 <
>>> >> > > >>>>> braden@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
>>> >> > > >>>>> <fi...@adobe.com>
>>> >> > > >>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> How will we communicate this change to our
>>>existing
>>> >> > > >>>>> users?
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>>> >> > > >>>>> braden@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
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>
>>> >> > > >>>>>>
>>> >> > > >>>>>
>>> >> > > >>>>
>>> >> > > >>>>
>>> >> > > >>
>>> >> > >
>>> >> > >
>>> >> >
>>> >>
>>>

Re: New directory structure in cordova-cli's future branch

[Brian LeRoux <b...@brian.io>]

Not buying that either. The `./app` directory lives in the root so
everything will have to change when we hit the reality you describe
where `./app` IS the root.

What you are really saying this is a transition step until such time
as `./app` becomes top level and things return to the same as they are
today but we do not require native bits to be revisioned. Essentially
this is an aesthetic forcing function to get back to the original
structure. =P

This is a very complicated way to achieve the goal of native bits
being build artifacts. A goal I share, many do, and I think we can
achieve it by NOT breaking things today.


On Thu, May 23, 2013 at 8:21 AM, Braden Shepherdson <br...@chromium.org> wrote:
> cd app
> git init
>
> Now my app directory - everything that makes this app mine and isn't just a
> cordova-cli artifact - is version controlled. I can easily check out a new
> copy with a cordova create ...; rm -rf app; git clone https://.../myrepo.git
> app
>
> Once we have app-level dependencies (which is planned regardless), I can
> add cordova fetch-deps or whatever we decide the command should be, and now
> my app is fully set up. No need to juggle .gitignore or anything else. It's
> hardly a killer feature, but I think it is an improvement.
>
> Michal asked what change we would regret more a year from now. I think this
> style makes the separation of CLI artifacts and my app more clear, and if
> we add more pieces to either it won't require changing people's .gitignore
> files or knowing about the architecture.
>
> Braden
>
>
> On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:
>
>> I want to be very clear that my tone here is emotionless! I'm totally
>> indifferent.
>>
>> Now, please explain: how is a new directory make version control
>> easier? I don't buy it.
>>
>>
>> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <br...@chromium.org>
>> wrote:
>> > The change is not purely aesthetic; it means that the "my app" portions
>> of
>> > the structure are now contained in a single directory, and easier to
>> > version control.
>> >
>> > This change gets more expensive every day. If we're ever going to do it,
>> it
>> > should be done now, I believe.
>> >
>> > It seems like the (not universally supported) consensus from the first
>> pass
>> > at this thread was to keep the app/ dir but have automatic detection and
>> > ask-then-automatic conversion.
>> >
>> > If that approach is still acceptable, I will implement that support today
>> > before we tag CLI for 2.8.
>> >
>> > Braden
>> >
>> >
>> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny <mm...@chromium.org>
>> wrote:
>> >
>> >> Fil, good summary, thanks for that.  I also agree with your proposal.
>> >>  Would it be possible to just support both options starting now, and
>> >> "deprecate" www/ at the top level in 3.0?
>> >>
>> >> Brian, this isn't just aesthetics, but its true that either option can,
>> >> with varying difficulty, be made to work for all use cases.
>> >>
>> >> Migration path is trivial but will be paid by all users, still,
>> workflows
>> >> will change completely with 3.0 anyway, this being the least of the
>> >> changes.  Which decision is more likely to be regretted a year from now?
>> >>
>> >> -Michal
>> >>
>> >>
>> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <agrieve@chromium.org
>> >> >wrote:
>> >>
>> >> > I don't really think this directory change is a big deal. We break
>> things
>> >> > in almost every release (e.g. loading pages of http), yet we're
>> having so
>> >> > much debate over alpha tool.
>> >> >
>> >> > The migration path is: mkdir app && git mv www merges app && git mv
>> >> > app/www/config.xml app
>> >> >
>> >> > I think the least amount of work here is to just console.log an error
>> >> > message with this command if the app/ directory is not found.
>> >> >
>> >> >
>> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>> >> > <to...@devgeeks.org>wrote:
>> >> >
>> >> > > Is it bad that I both agree vehemently with Brian's calling it not
>> >> > > beneficial enough to justify, but also really really like the
>> proposed
>> >> > > structure better that the current one? hehe.
>> >> > >
>> >> > > *so… conflicted...*
>> >> > >
>> >> > > - tommy
>> >> > >
>> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
>> >> > >
>> >> > > > There are two paths. I argue there is no functional benefit and
>> that
>> >> > > > this change is purely aesthetic. Aesthetics are important but I'd
>> >> > > > argue folder structure is the last part of the developer
>> aesthetics
>> >> we
>> >> > > > should worry about and especially not beneficial enough to
>> justify a
>> >> > > > breaking change.
>> >> > > >
>> >> > > > Today:
>> >> > > >
>> >> > > > ./
>> >> > > > |- merges/
>> >> > > > |- platforms/
>> >> > > > |- plugins/
>> >> > > > '- www/
>> >> > > >    |- index.html
>> >> > > >    '- config.xml
>> >> > > >
>> >> > > > Proposed:
>> >> > > >
>> >> > > > ./
>> >> > > > |- platforms/
>> >> > > > |- plugins/
>> >> > > > '- app/
>> >> > > >    |- merges/
>> >> > > >    |- www/
>> >> > > >    |       '- index.html
>> >> > > >    '- config.xml
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com> wrote:
>> >> > > >> I'm reviving this discussion re: additional app/ folder in the
>> >> > > >> cli-generated project structure.
>> >> > > >>
>> >> > > >> To recap, there were two main discussions:
>> >> > > >>
>> >> > > >> A)
>> >> > > >>
>> >> > >
>> >> >
>> >>
>> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
>> >> > > >> hsfjmvwtoi+state:results
>> >> > > >> B)
>> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>> >> > > >>
>> >> > > >> Arguments for moving to app/:
>> >> > > >>
>> >> > > >> - easier to version control relevant / non-build-artifact app
>> bits
>> >> > > >> - aesthetics
>> >> > > >>
>> >> > > >> Arguments against it:
>> >> > > >>
>> >> > > >> - we break shit for users
>> >> > > >> - config.xml location and PhoneGap Build compatibility (but I
>> don't
>> >> > see
>> >> > > >> this as a valid argument against. This is an easy problem to
>> solve
>> >> for
>> >> > > us
>> >> > > >> Adobe folk and the tooling can handle the trivial steps of going
>> up
>> >> > one
>> >> > > >> directory to grab the right file before interfacing with Build)
>> >> > > >>
>> >> > > >> Also worth noting: people we're not against it for architectural
>> >> > > reasons,
>> >> > > >> in fact, most people were favorable for the change to app/.
>> >> > > >>
>> >> > > >> So, with plugman stabilizing and my focus moving to cli work, I
>> >> feel I
>> >> > > >> have a good grasp of both projects and the direction they are
>> going,
>> >> > > here
>> >> > > >> is my suggestion on how to move forward with this:
>> >> > > >>
>> >> > > >> 1. cordova-cli's master branch, which will soon merge future work
>> >> in,
>> >> > > will
>> >> > > >> revert to the old /www-based structure, then
>> >> > > >> 2. In 3.0 we make the change, where landing such a breaking
>> change
>> >> is
>> >> > > >> easier and we'll have a bunch of press/noise about the release
>> out
>> >> > there
>> >> > > >> too so communicating this change would be easier.
>> >> > > >>
>> >> > > >> If there are any other arguments for/against the app/ based
>> >> structure,
>> >> > > now
>> >> > > >> is the time to bring it up. We can give this some more time to
>> bake,
>> >> > but
>> >> > > >> after 2.8 is released, I'd like to call a vote on whether we
>> should
>> >> > move
>> >> > > >> to this structure or not in 3.0.
>> >> > > >>
>> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>> >> > > >>
>> >> > > >>> I should also add.  I appreciate that this is a change, and
>> every
>> >> > > change
>> >> > > >>> has some learning overhead and we shouldn't stuff everything
>> >> possible
>> >> > > in
>> >> > > >>> all the time.
>> >> > > >>>
>> >> > > >>> However, I think 3.0 and cli are a big change, and we should do
>> the
>> >> > big
>> >> > > >>> re-org all at once, so lets decide this now in a way we wont
>> >> regret.
>> >> > > >>> Thats
>> >> > > >>> why we are being picky, I guess.  I like knowing that the root
>> of
>> >> the
>> >> > > >>> project has cordova-only artifacts and your app-repo is just a
>> >> > > >>> subdirectory
>> >> > > >>> somewhere.  Then, the exact location and exact contents are way
>> >> more
>> >> > > >>> flexible.
>> >> > > >>>
>> >> > > >>> -Michal
>> >> > > >>>
>> >> > > >>>
>> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>> >> mmocny@chromium.org>
>> >> > > >>> wrote:
>> >> > > >>>
>> >> > > >>>> 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
>> >> > > >>>> <ag...@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 <
>> >> > > agrieve@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 <
>> timkim85@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 <an...@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.Wolf@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" <pu...@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 <
>> >> > > >>>>> braden@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
>> >> > > >>>>> <fi...@adobe.com>
>> >> > > >>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>> How will we communicate this change to our existing
>> >> > > >>>>> users?
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>> >> > > >>>>> braden@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
>> >> > > >>>>>>>>
>> >> > > >>>>>>>
>> >> > > >>>>>>
>> >> > > >>>>>
>> >> > > >>>>
>> >> > > >>>>
>> >> > > >>
>> >> > >
>> >> > >
>> >> >
>> >>
>>

Re: New directory structure in cordova-cli's future branch

[Braden Shepherdson <br...@chromium.org>]

cd app
git init

Now my app directory - everything that makes this app mine and isn't just a
cordova-cli artifact - is version controlled. I can easily check out a new
copy with a cordova create ...; rm -rf app; git clone https://.../myrepo.git
app

Once we have app-level dependencies (which is planned regardless), I can
add cordova fetch-deps or whatever we decide the command should be, and now
my app is fully set up. No need to juggle .gitignore or anything else. It's
hardly a killer feature, but I think it is an improvement.

Michal asked what change we would regret more a year from now. I think this
style makes the separation of CLI artifacts and my app more clear, and if
we add more pieces to either it won't require changing people's .gitignore
files or knowing about the architecture.

Braden


On Thu, May 23, 2013 at 11:15 AM, Brian LeRoux <b...@brian.io> wrote:

> I want to be very clear that my tone here is emotionless! I'm totally
> indifferent.
>
> Now, please explain: how is a new directory make version control
> easier? I don't buy it.
>
>
> On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <br...@chromium.org>
> wrote:
> > The change is not purely aesthetic; it means that the "my app" portions
> of
> > the structure are now contained in a single directory, and easier to
> > version control.
> >
> > This change gets more expensive every day. If we're ever going to do it,
> it
> > should be done now, I believe.
> >
> > It seems like the (not universally supported) consensus from the first
> pass
> > at this thread was to keep the app/ dir but have automatic detection and
> > ask-then-automatic conversion.
> >
> > If that approach is still acceptable, I will implement that support today
> > before we tag CLI for 2.8.
> >
> > Braden
> >
> >
> > On Thu, May 23, 2013 at 12:30 AM, Michal Mocny <mm...@chromium.org>
> wrote:
> >
> >> Fil, good summary, thanks for that.  I also agree with your proposal.
> >>  Would it be possible to just support both options starting now, and
> >> "deprecate" www/ at the top level in 3.0?
> >>
> >> Brian, this isn't just aesthetics, but its true that either option can,
> >> with varying difficulty, be made to work for all use cases.
> >>
> >> Migration path is trivial but will be paid by all users, still,
> workflows
> >> will change completely with 3.0 anyway, this being the least of the
> >> changes.  Which decision is more likely to be regretted a year from now?
> >>
> >> -Michal
> >>
> >>
> >> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <agrieve@chromium.org
> >> >wrote:
> >>
> >> > I don't really think this directory change is a big deal. We break
> things
> >> > in almost every release (e.g. loading pages of http), yet we're
> having so
> >> > much debate over alpha tool.
> >> >
> >> > The migration path is: mkdir app && git mv www merges app && git mv
> >> > app/www/config.xml app
> >> >
> >> > I think the least amount of work here is to just console.log an error
> >> > message with this command if the app/ directory is not found.
> >> >
> >> >
> >> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
> >> > <to...@devgeeks.org>wrote:
> >> >
> >> > > Is it bad that I both agree vehemently with Brian's calling it not
> >> > > beneficial enough to justify, but also really really like the
> proposed
> >> > > structure better that the current one? hehe.
> >> > >
> >> > > *so… conflicted...*
> >> > >
> >> > > - tommy
> >> > >
> >> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
> >> > >
> >> > > > There are two paths. I argue there is no functional benefit and
> that
> >> > > > this change is purely aesthetic. Aesthetics are important but I'd
> >> > > > argue folder structure is the last part of the developer
> aesthetics
> >> we
> >> > > > should worry about and especially not beneficial enough to
> justify a
> >> > > > breaking change.
> >> > > >
> >> > > > Today:
> >> > > >
> >> > > > ./
> >> > > > |- merges/
> >> > > > |- platforms/
> >> > > > |- plugins/
> >> > > > '- www/
> >> > > >    |- index.html
> >> > > >    '- config.xml
> >> > > >
> >> > > > Proposed:
> >> > > >
> >> > > > ./
> >> > > > |- platforms/
> >> > > > |- plugins/
> >> > > > '- app/
> >> > > >    |- merges/
> >> > > >    |- www/
> >> > > >    |       '- index.html
> >> > > >    '- config.xml
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com> wrote:
> >> > > >> I'm reviving this discussion re: additional app/ folder in the
> >> > > >> cli-generated project structure.
> >> > > >>
> >> > > >> To recap, there were two main discussions:
> >> > > >>
> >> > > >> A)
> >> > > >>
> >> > >
> >> >
> >>
> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
> >> > > >> hsfjmvwtoi+state:results
> >> > > >> B)
> http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
> >> > > >>
> >> > > >> Arguments for moving to app/:
> >> > > >>
> >> > > >> - easier to version control relevant / non-build-artifact app
> bits
> >> > > >> - aesthetics
> >> > > >>
> >> > > >> Arguments against it:
> >> > > >>
> >> > > >> - we break shit for users
> >> > > >> - config.xml location and PhoneGap Build compatibility (but I
> don't
> >> > see
> >> > > >> this as a valid argument against. This is an easy problem to
> solve
> >> for
> >> > > us
> >> > > >> Adobe folk and the tooling can handle the trivial steps of going
> up
> >> > one
> >> > > >> directory to grab the right file before interfacing with Build)
> >> > > >>
> >> > > >> Also worth noting: people we're not against it for architectural
> >> > > reasons,
> >> > > >> in fact, most people were favorable for the change to app/.
> >> > > >>
> >> > > >> So, with plugman stabilizing and my focus moving to cli work, I
> >> feel I
> >> > > >> have a good grasp of both projects and the direction they are
> going,
> >> > > here
> >> > > >> is my suggestion on how to move forward with this:
> >> > > >>
> >> > > >> 1. cordova-cli's master branch, which will soon merge future work
> >> in,
> >> > > will
> >> > > >> revert to the old /www-based structure, then
> >> > > >> 2. In 3.0 we make the change, where landing such a breaking
> change
> >> is
> >> > > >> easier and we'll have a bunch of press/noise about the release
> out
> >> > there
> >> > > >> too so communicating this change would be easier.
> >> > > >>
> >> > > >> If there are any other arguments for/against the app/ based
> >> structure,
> >> > > now
> >> > > >> is the time to bring it up. We can give this some more time to
> bake,
> >> > but
> >> > > >> after 2.8 is released, I'd like to call a vote on whether we
> should
> >> > move
> >> > > >> to this structure or not in 3.0.
> >> > > >>
> >> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> >> > > >>
> >> > > >>> I should also add.  I appreciate that this is a change, and
> every
> >> > > change
> >> > > >>> has some learning overhead and we shouldn't stuff everything
> >> possible
> >> > > in
> >> > > >>> all the time.
> >> > > >>>
> >> > > >>> However, I think 3.0 and cli are a big change, and we should do
> the
> >> > big
> >> > > >>> re-org all at once, so lets decide this now in a way we wont
> >> regret.
> >> > > >>> Thats
> >> > > >>> why we are being picky, I guess.  I like knowing that the root
> of
> >> the
> >> > > >>> project has cordova-only artifacts and your app-repo is just a
> >> > > >>> subdirectory
> >> > > >>> somewhere.  Then, the exact location and exact contents are way
> >> more
> >> > > >>> flexible.
> >> > > >>>
> >> > > >>> -Michal
> >> > > >>>
> >> > > >>>
> >> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
> >> mmocny@chromium.org>
> >> > > >>> wrote:
> >> > > >>>
> >> > > >>>> 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
> >> > > >>>> <ag...@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 <
> >> > > agrieve@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 <
> timkim85@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 <an...@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.Wolf@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" <pu...@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 <
> >> > > >>>>> braden@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
> >> > > >>>>> <fi...@adobe.com>
> >> > > >>>>>>> wrote:
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>> How will we communicate this change to our existing
> >> > > >>>>> users?
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> >> > > >>>>> braden@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
> >> > > >>>>>>>>
> >> > > >>>>>>>
> >> > > >>>>>>
> >> > > >>>>>
> >> > > >>>>
> >> > > >>>>
> >> > > >>
> >> > >
> >> > >
> >> >
> >>
>

Re: New directory structure in cordova-cli's future branch

[Brian LeRoux <b...@brian.io>]

I want to be very clear that my tone here is emotionless! I'm totally
indifferent.

Now, please explain: how is a new directory make version control
easier? I don't buy it.


On Thu, May 23, 2013 at 8:02 AM, Braden Shepherdson <br...@chromium.org> wrote:
> The change is not purely aesthetic; it means that the "my app" portions of
> the structure are now contained in a single directory, and easier to
> version control.
>
> This change gets more expensive every day. If we're ever going to do it, it
> should be done now, I believe.
>
> It seems like the (not universally supported) consensus from the first pass
> at this thread was to keep the app/ dir but have automatic detection and
> ask-then-automatic conversion.
>
> If that approach is still acceptable, I will implement that support today
> before we tag CLI for 2.8.
>
> Braden
>
>
> On Thu, May 23, 2013 at 12:30 AM, Michal Mocny <mm...@chromium.org> wrote:
>
>> Fil, good summary, thanks for that.  I also agree with your proposal.
>>  Would it be possible to just support both options starting now, and
>> "deprecate" www/ at the top level in 3.0?
>>
>> Brian, this isn't just aesthetics, but its true that either option can,
>> with varying difficulty, be made to work for all use cases.
>>
>> Migration path is trivial but will be paid by all users, still, workflows
>> will change completely with 3.0 anyway, this being the least of the
>> changes.  Which decision is more likely to be regretted a year from now?
>>
>> -Michal
>>
>>
>> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <agrieve@chromium.org
>> >wrote:
>>
>> > I don't really think this directory change is a big deal. We break things
>> > in almost every release (e.g. loading pages of http), yet we're having so
>> > much debate over alpha tool.
>> >
>> > The migration path is: mkdir app && git mv www merges app && git mv
>> > app/www/config.xml app
>> >
>> > I think the least amount of work here is to just console.log an error
>> > message with this command if the app/ directory is not found.
>> >
>> >
>> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
>> > <to...@devgeeks.org>wrote:
>> >
>> > > Is it bad that I both agree vehemently with Brian's calling it not
>> > > beneficial enough to justify, but also really really like the proposed
>> > > structure better that the current one? hehe.
>> > >
>> > > *so… conflicted...*
>> > >
>> > > - tommy
>> > >
>> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
>> > >
>> > > > There are two paths. I argue there is no functional benefit and that
>> > > > this change is purely aesthetic. Aesthetics are important but I'd
>> > > > argue folder structure is the last part of the developer aesthetics
>> we
>> > > > should worry about and especially not beneficial enough to justify a
>> > > > breaking change.
>> > > >
>> > > > Today:
>> > > >
>> > > > ./
>> > > > |- merges/
>> > > > |- platforms/
>> > > > |- plugins/
>> > > > '- www/
>> > > >    |- index.html
>> > > >    '- config.xml
>> > > >
>> > > > Proposed:
>> > > >
>> > > > ./
>> > > > |- platforms/
>> > > > |- plugins/
>> > > > '- app/
>> > > >    |- merges/
>> > > >    |- www/
>> > > >    |       '- index.html
>> > > >    '- config.xml
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com> wrote:
>> > > >> I'm reviving this discussion re: additional app/ folder in the
>> > > >> cli-generated project structure.
>> > > >>
>> > > >> To recap, there were two main discussions:
>> > > >>
>> > > >> A)
>> > > >>
>> > >
>> >
>> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
>> > > >> hsfjmvwtoi+state:results
>> > > >> B) http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>> > > >>
>> > > >> Arguments for moving to app/:
>> > > >>
>> > > >> - easier to version control relevant / non-build-artifact app bits
>> > > >> - aesthetics
>> > > >>
>> > > >> Arguments against it:
>> > > >>
>> > > >> - we break shit for users
>> > > >> - config.xml location and PhoneGap Build compatibility (but I don't
>> > see
>> > > >> this as a valid argument against. This is an easy problem to solve
>> for
>> > > us
>> > > >> Adobe folk and the tooling can handle the trivial steps of going up
>> > one
>> > > >> directory to grab the right file before interfacing with Build)
>> > > >>
>> > > >> Also worth noting: people we're not against it for architectural
>> > > reasons,
>> > > >> in fact, most people were favorable for the change to app/.
>> > > >>
>> > > >> So, with plugman stabilizing and my focus moving to cli work, I
>> feel I
>> > > >> have a good grasp of both projects and the direction they are going,
>> > > here
>> > > >> is my suggestion on how to move forward with this:
>> > > >>
>> > > >> 1. cordova-cli's master branch, which will soon merge future work
>> in,
>> > > will
>> > > >> revert to the old /www-based structure, then
>> > > >> 2. In 3.0 we make the change, where landing such a breaking change
>> is
>> > > >> easier and we'll have a bunch of press/noise about the release out
>> > there
>> > > >> too so communicating this change would be easier.
>> > > >>
>> > > >> If there are any other arguments for/against the app/ based
>> structure,
>> > > now
>> > > >> is the time to bring it up. We can give this some more time to bake,
>> > but
>> > > >> after 2.8 is released, I'd like to call a vote on whether we should
>> > move
>> > > >> to this structure or not in 3.0.
>> > > >>
>> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>> > > >>
>> > > >>> I should also add.  I appreciate that this is a change, and every
>> > > change
>> > > >>> has some learning overhead and we shouldn't stuff everything
>> possible
>> > > in
>> > > >>> all the time.
>> > > >>>
>> > > >>> However, I think 3.0 and cli are a big change, and we should do the
>> > big
>> > > >>> re-org all at once, so lets decide this now in a way we wont
>> regret.
>> > > >>> Thats
>> > > >>> why we are being picky, I guess.  I like knowing that the root of
>> the
>> > > >>> project has cordova-only artifacts and your app-repo is just a
>> > > >>> subdirectory
>> > > >>> somewhere.  Then, the exact location and exact contents are way
>> more
>> > > >>> flexible.
>> > > >>>
>> > > >>> -Michal
>> > > >>>
>> > > >>>
>> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
>> mmocny@chromium.org>
>> > > >>> wrote:
>> > > >>>
>> > > >>>> 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
>> > > >>>> <ag...@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 <
>> > > agrieve@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 <ti...@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 <an...@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.Wolf@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" <pu...@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 <
>> > > >>>>> braden@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
>> > > >>>>> <fi...@adobe.com>
>> > > >>>>>>> wrote:
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> How will we communicate this change to our existing
>> > > >>>>> users?
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>> > > >>>>> braden@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
>> > > >>>>>>>>
>> > > >>>>>>>
>> > > >>>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>>
>> > > >>
>> > >
>> > >
>> >
>>

Re: New directory structure in cordova-cli's future branch

[Braden Shepherdson <br...@chromium.org>]

The change is not purely aesthetic; it means that the "my app" portions of
the structure are now contained in a single directory, and easier to
version control.

This change gets more expensive every day. If we're ever going to do it, it
should be done now, I believe.

It seems like the (not universally supported) consensus from the first pass
at this thread was to keep the app/ dir but have automatic detection and
ask-then-automatic conversion.

If that approach is still acceptable, I will implement that support today
before we tag CLI for 2.8.

Braden


On Thu, May 23, 2013 at 12:30 AM, Michal Mocny <mm...@chromium.org> wrote:

> Fil, good summary, thanks for that.  I also agree with your proposal.
>  Would it be possible to just support both options starting now, and
> "deprecate" www/ at the top level in 3.0?
>
> Brian, this isn't just aesthetics, but its true that either option can,
> with varying difficulty, be made to work for all use cases.
>
> Migration path is trivial but will be paid by all users, still, workflows
> will change completely with 3.0 anyway, this being the least of the
> changes.  Which decision is more likely to be regretted a year from now?
>
> -Michal
>
>
> On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <agrieve@chromium.org
> >wrote:
>
> > I don't really think this directory change is a big deal. We break things
> > in almost every release (e.g. loading pages of http), yet we're having so
> > much debate over alpha tool.
> >
> > The migration path is: mkdir app && git mv www merges app && git mv
> > app/www/config.xml app
> >
> > I think the least amount of work here is to just console.log an error
> > message with this command if the app/ directory is not found.
> >
> >
> > On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
> > <to...@devgeeks.org>wrote:
> >
> > > Is it bad that I both agree vehemently with Brian's calling it not
> > > beneficial enough to justify, but also really really like the proposed
> > > structure better that the current one? hehe.
> > >
> > > *so… conflicted...*
> > >
> > > - tommy
> > >
> > > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
> > >
> > > > There are two paths. I argue there is no functional benefit and that
> > > > this change is purely aesthetic. Aesthetics are important but I'd
> > > > argue folder structure is the last part of the developer aesthetics
> we
> > > > should worry about and especially not beneficial enough to justify a
> > > > breaking change.
> > > >
> > > > Today:
> > > >
> > > > ./
> > > > |- merges/
> > > > |- platforms/
> > > > |- plugins/
> > > > '- www/
> > > >    |- index.html
> > > >    '- config.xml
> > > >
> > > > Proposed:
> > > >
> > > > ./
> > > > |- platforms/
> > > > |- plugins/
> > > > '- app/
> > > >    |- merges/
> > > >    |- www/
> > > >    |       '- index.html
> > > >    '- config.xml
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com> wrote:
> > > >> I'm reviving this discussion re: additional app/ folder in the
> > > >> cli-generated project structure.
> > > >>
> > > >> To recap, there were two main discussions:
> > > >>
> > > >> A)
> > > >>
> > >
> >
> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
> > > >> hsfjmvwtoi+state:results
> > > >> B) http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
> > > >>
> > > >> Arguments for moving to app/:
> > > >>
> > > >> - easier to version control relevant / non-build-artifact app bits
> > > >> - aesthetics
> > > >>
> > > >> Arguments against it:
> > > >>
> > > >> - we break shit for users
> > > >> - config.xml location and PhoneGap Build compatibility (but I don't
> > see
> > > >> this as a valid argument against. This is an easy problem to solve
> for
> > > us
> > > >> Adobe folk and the tooling can handle the trivial steps of going up
> > one
> > > >> directory to grab the right file before interfacing with Build)
> > > >>
> > > >> Also worth noting: people we're not against it for architectural
> > > reasons,
> > > >> in fact, most people were favorable for the change to app/.
> > > >>
> > > >> So, with plugman stabilizing and my focus moving to cli work, I
> feel I
> > > >> have a good grasp of both projects and the direction they are going,
> > > here
> > > >> is my suggestion on how to move forward with this:
> > > >>
> > > >> 1. cordova-cli's master branch, which will soon merge future work
> in,
> > > will
> > > >> revert to the old /www-based structure, then
> > > >> 2. In 3.0 we make the change, where landing such a breaking change
> is
> > > >> easier and we'll have a bunch of press/noise about the release out
> > there
> > > >> too so communicating this change would be easier.
> > > >>
> > > >> If there are any other arguments for/against the app/ based
> structure,
> > > now
> > > >> is the time to bring it up. We can give this some more time to bake,
> > but
> > > >> after 2.8 is released, I'd like to call a vote on whether we should
> > move
> > > >> to this structure or not in 3.0.
> > > >>
> > > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> > > >>
> > > >>> I should also add.  I appreciate that this is a change, and every
> > > change
> > > >>> has some learning overhead and we shouldn't stuff everything
> possible
> > > in
> > > >>> all the time.
> > > >>>
> > > >>> However, I think 3.0 and cli are a big change, and we should do the
> > big
> > > >>> re-org all at once, so lets decide this now in a way we wont
> regret.
> > > >>> Thats
> > > >>> why we are being picky, I guess.  I like knowing that the root of
> the
> > > >>> project has cordova-only artifacts and your app-repo is just a
> > > >>> subdirectory
> > > >>> somewhere.  Then, the exact location and exact contents are way
> more
> > > >>> flexible.
> > > >>>
> > > >>> -Michal
> > > >>>
> > > >>>
> > > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <
> mmocny@chromium.org>
> > > >>> wrote:
> > > >>>
> > > >>>> 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
> > > >>>> <ag...@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 <
> > > agrieve@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 <ti...@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 <an...@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.Wolf@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" <pu...@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 <
> > > >>>>> braden@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
> > > >>>>> <fi...@adobe.com>
> > > >>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> How will we communicate this change to our existing
> > > >>>>> users?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> > > >>>>> braden@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
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>
> > >
> > >
> >
>

Re: New directory structure in cordova-cli's future branch

[Michal Mocny <mm...@chromium.org>]

Fil, good summary, thanks for that.  I also agree with your proposal.
 Would it be possible to just support both options starting now, and
"deprecate" www/ at the top level in 3.0?

Brian, this isn't just aesthetics, but its true that either option can,
with varying difficulty, be made to work for all use cases.

Migration path is trivial but will be paid by all users, still, workflows
will change completely with 3.0 anyway, this being the least of the
changes.  Which decision is more likely to be regretted a year from now?

-Michal


On Wed, May 22, 2013 at 10:11 PM, Andrew Grieve <ag...@chromium.org>wrote:

> I don't really think this directory change is a big deal. We break things
> in almost every release (e.g. loading pages of http), yet we're having so
> much debate over alpha tool.
>
> The migration path is: mkdir app && git mv www merges app && git mv
> app/www/config.xml app
>
> I think the least amount of work here is to just console.log an error
> message with this command if the app/ directory is not found.
>
>
> On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
> <to...@devgeeks.org>wrote:
>
> > Is it bad that I both agree vehemently with Brian's calling it not
> > beneficial enough to justify, but also really really like the proposed
> > structure better that the current one? hehe.
> >
> > *so… conflicted...*
> >
> > - tommy
> >
> > On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > There are two paths. I argue there is no functional benefit and that
> > > this change is purely aesthetic. Aesthetics are important but I'd
> > > argue folder structure is the last part of the developer aesthetics we
> > > should worry about and especially not beneficial enough to justify a
> > > breaking change.
> > >
> > > Today:
> > >
> > > ./
> > > |- merges/
> > > |- platforms/
> > > |- plugins/
> > > '- www/
> > >    |- index.html
> > >    '- config.xml
> > >
> > > Proposed:
> > >
> > > ./
> > > |- platforms/
> > > |- plugins/
> > > '- app/
> > >    |- merges/
> > >    |- www/
> > >    |       '- index.html
> > >    '- config.xml
> > >
> > >
> > >
> > >
> > > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com> wrote:
> > >> I'm reviving this discussion re: additional app/ folder in the
> > >> cli-generated project structure.
> > >>
> > >> To recap, there were two main discussions:
> > >>
> > >> A)
> > >>
> >
> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
> > >> hsfjmvwtoi+state:results
> > >> B) http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
> > >>
> > >> Arguments for moving to app/:
> > >>
> > >> - easier to version control relevant / non-build-artifact app bits
> > >> - aesthetics
> > >>
> > >> Arguments against it:
> > >>
> > >> - we break shit for users
> > >> - config.xml location and PhoneGap Build compatibility (but I don't
> see
> > >> this as a valid argument against. This is an easy problem to solve for
> > us
> > >> Adobe folk and the tooling can handle the trivial steps of going up
> one
> > >> directory to grab the right file before interfacing with Build)
> > >>
> > >> Also worth noting: people we're not against it for architectural
> > reasons,
> > >> in fact, most people were favorable for the change to app/.
> > >>
> > >> So, with plugman stabilizing and my focus moving to cli work, I feel I
> > >> have a good grasp of both projects and the direction they are going,
> > here
> > >> is my suggestion on how to move forward with this:
> > >>
> > >> 1. cordova-cli's master branch, which will soon merge future work in,
> > will
> > >> revert to the old /www-based structure, then
> > >> 2. In 3.0 we make the change, where landing such a breaking change is
> > >> easier and we'll have a bunch of press/noise about the release out
> there
> > >> too so communicating this change would be easier.
> > >>
> > >> If there are any other arguments for/against the app/ based structure,
> > now
> > >> is the time to bring it up. We can give this some more time to bake,
> but
> > >> after 2.8 is released, I'd like to call a vote on whether we should
> move
> > >> to this structure or not in 3.0.
> > >>
> > >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> > >>
> > >>> I should also add.  I appreciate that this is a change, and every
> > change
> > >>> has some learning overhead and we shouldn't stuff everything possible
> > in
> > >>> all the time.
> > >>>
> > >>> However, I think 3.0 and cli are a big change, and we should do the
> big
> > >>> re-org all at once, so lets decide this now in a way we wont regret.
> > >>> Thats
> > >>> why we are being picky, I guess.  I like knowing that the root of the
> > >>> project has cordova-only artifacts and your app-repo is just a
> > >>> subdirectory
> > >>> somewhere.  Then, the exact location and exact contents are way more
> > >>> flexible.
> > >>>
> > >>> -Michal
> > >>>
> > >>>
> > >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <mm...@chromium.org>
> > >>> wrote:
> > >>>
> > >>>> 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
> > >>>> <ag...@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 <
> > agrieve@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 <ti...@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 <an...@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.Wolf@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" <pu...@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 <
> > >>>>> braden@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
> > >>>>> <fi...@adobe.com>
> > >>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> How will we communicate this change to our existing
> > >>>>> users?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> > >>>>> braden@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
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>
> >
> >
>

Re: New directory structure in cordova-cli's future branch

[Andrew Grieve <ag...@chromium.org>]

I don't really think this directory change is a big deal. We break things
in almost every release (e.g. loading pages of http), yet we're having so
much debate over alpha tool.

The migration path is: mkdir app && git mv www merges app && git mv
app/www/config.xml app

I think the least amount of work here is to just console.log an error
message with this command if the app/ directory is not found.


On Wed, May 22, 2013 at 9:28 PM, Tommy-Carlos Williams
<to...@devgeeks.org>wrote:

> Is it bad that I both agree vehemently with Brian's calling it not
> beneficial enough to justify, but also really really like the proposed
> structure better that the current one? hehe.
>
> *so… conflicted...*
>
> - tommy
>
> On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:
>
> > There are two paths. I argue there is no functional benefit and that
> > this change is purely aesthetic. Aesthetics are important but I'd
> > argue folder structure is the last part of the developer aesthetics we
> > should worry about and especially not beneficial enough to justify a
> > breaking change.
> >
> > Today:
> >
> > ./
> > |- merges/
> > |- platforms/
> > |- plugins/
> > '- www/
> >    |- index.html
> >    '- config.xml
> >
> > Proposed:
> >
> > ./
> > |- platforms/
> > |- plugins/
> > '- app/
> >    |- merges/
> >    |- www/
> >    |       '- index.html
> >    '- config.xml
> >
> >
> >
> >
> > On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com> wrote:
> >> I'm reviving this discussion re: additional app/ folder in the
> >> cli-generated project structure.
> >>
> >> To recap, there were two main discussions:
> >>
> >> A)
> >>
> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
> >> hsfjmvwtoi+state:results
> >> B) http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
> >>
> >> Arguments for moving to app/:
> >>
> >> - easier to version control relevant / non-build-artifact app bits
> >> - aesthetics
> >>
> >> Arguments against it:
> >>
> >> - we break shit for users
> >> - config.xml location and PhoneGap Build compatibility (but I don't see
> >> this as a valid argument against. This is an easy problem to solve for
> us
> >> Adobe folk and the tooling can handle the trivial steps of going up one
> >> directory to grab the right file before interfacing with Build)
> >>
> >> Also worth noting: people we're not against it for architectural
> reasons,
> >> in fact, most people were favorable for the change to app/.
> >>
> >> So, with plugman stabilizing and my focus moving to cli work, I feel I
> >> have a good grasp of both projects and the direction they are going,
> here
> >> is my suggestion on how to move forward with this:
> >>
> >> 1. cordova-cli's master branch, which will soon merge future work in,
> will
> >> revert to the old /www-based structure, then
> >> 2. In 3.0 we make the change, where landing such a breaking change is
> >> easier and we'll have a bunch of press/noise about the release out there
> >> too so communicating this change would be easier.
> >>
> >> If there are any other arguments for/against the app/ based structure,
> now
> >> is the time to bring it up. We can give this some more time to bake, but
> >> after 2.8 is released, I'd like to call a vote on whether we should move
> >> to this structure or not in 3.0.
> >>
> >> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:
> >>
> >>> I should also add.  I appreciate that this is a change, and every
> change
> >>> has some learning overhead and we shouldn't stuff everything possible
> in
> >>> all the time.
> >>>
> >>> However, I think 3.0 and cli are a big change, and we should do the big
> >>> re-org all at once, so lets decide this now in a way we wont regret.
> >>> Thats
> >>> why we are being picky, I guess.  I like knowing that the root of the
> >>> project has cordova-only artifacts and your app-repo is just a
> >>> subdirectory
> >>> somewhere.  Then, the exact location and exact contents are way more
> >>> flexible.
> >>>
> >>> -Michal
> >>>
> >>>
> >>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <mm...@chromium.org>
> >>> wrote:
> >>>
> >>>> 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
> >>>> <ag...@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 <
> agrieve@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 <ti...@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 <an...@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.Wolf@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" <pu...@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 <
> >>>>> braden@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
> >>>>> <fi...@adobe.com>
> >>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> How will we communicate this change to our existing
> >>>>> users?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
> >>>>> braden@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
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
>
>

Re: New directory structure in cordova-cli's future branch

[Tommy-Carlos Williams <to...@devgeeks.org>]

Is it bad that I both agree vehemently with Brian's calling it not beneficial enough to justify, but also really really like the proposed structure better that the current one? hehe.

*so… conflicted...*

- tommy

On 23/05/2013, at 7:35 AM, Brian LeRoux <b...@brian.io> wrote:

> There are two paths. I argue there is no functional benefit and that
> this change is purely aesthetic. Aesthetics are important but I'd
> argue folder structure is the last part of the developer aesthetics we
> should worry about and especially not beneficial enough to justify a
> breaking change.
> 
> Today:
> 
> ./
> |- merges/
> |- platforms/
> |- plugins/
> '- www/
>    |- index.html
>    '- config.xml
> 
> Proposed:
> 
> ./
> |- platforms/
> |- plugins/
> '- app/
>    |- merges/
>    |- www/
>    |       '- index.html
>    '- config.xml
> 
> 
> 
> 
> On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com> wrote:
>> I'm reviving this discussion re: additional app/ folder in the
>> cli-generated project structure.
>> 
>> To recap, there were two main discussions:
>> 
>> A)
>> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
>> hsfjmvwtoi+state:results
>> B) http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>> 
>> Arguments for moving to app/:
>> 
>> - easier to version control relevant / non-build-artifact app bits
>> - aesthetics
>> 
>> Arguments against it:
>> 
>> - we break shit for users
>> - config.xml location and PhoneGap Build compatibility (but I don't see
>> this as a valid argument against. This is an easy problem to solve for us
>> Adobe folk and the tooling can handle the trivial steps of going up one
>> directory to grab the right file before interfacing with Build)
>> 
>> Also worth noting: people we're not against it for architectural reasons,
>> in fact, most people were favorable for the change to app/.
>> 
>> So, with plugman stabilizing and my focus moving to cli work, I feel I
>> have a good grasp of both projects and the direction they are going, here
>> is my suggestion on how to move forward with this:
>> 
>> 1. cordova-cli's master branch, which will soon merge future work in, will
>> revert to the old /www-based structure, then
>> 2. In 3.0 we make the change, where landing such a breaking change is
>> easier and we'll have a bunch of press/noise about the release out there
>> too so communicating this change would be easier.
>> 
>> If there are any other arguments for/against the app/ based structure, now
>> is the time to bring it up. We can give this some more time to bake, but
>> after 2.8 is released, I'd like to call a vote on whether we should move
>> to this structure or not in 3.0.
>> 
>> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>> 
>>> I should also add.  I appreciate that this is a change, and every change
>>> has some learning overhead and we shouldn't stuff everything possible in
>>> all the time.
>>> 
>>> However, I think 3.0 and cli are a big change, and we should do the big
>>> re-org all at once, so lets decide this now in a way we wont regret.
>>> Thats
>>> why we are being picky, I guess.  I like knowing that the root of the
>>> project has cordova-only artifacts and your app-repo is just a
>>> subdirectory
>>> somewhere.  Then, the exact location and exact contents are way more
>>> flexible.
>>> 
>>> -Michal
>>> 
>>> 
>>> On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <mm...@chromium.org>
>>> wrote:
>>> 
>>>> 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
>>>> <ag...@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 <agrieve@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 <ti...@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 <an...@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.Wolf@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" <pu...@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 <
>>>>> braden@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
>>>>> <fi...@adobe.com>
>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> How will we communicate this change to our existing
>>>>> users?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>>>>> braden@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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 

Re: New directory structure in cordova-cli's future branch

[Brian LeRoux <b...@brian.io>]

There are two paths. I argue there is no functional benefit and that
this change is purely aesthetic. Aesthetics are important but I'd
argue folder structure is the last part of the developer aesthetics we
should worry about and especially not beneficial enough to justify a
breaking change.

Today:

./
|- merges/
|- platforms/
|- plugins/
'- www/
    |- index.html
    '- config.xml

Proposed:

./
|- platforms/
|- plugins/
'- app/
    |- merges/
    |- www/
    |       '- index.html
    '- config.xml




On Wed, May 22, 2013 at 1:47 PM, Filip Maj <fi...@adobe.com> wrote:
> I'm reviving this discussion re: additional app/ folder in the
> cli-generated project structure.
>
> To recap, there were two main discussions:
>
> A)
> http://apache.markmail.org/thread/syo24cwvhpkxqfdm#query:+page:1+mid:j76xli
> hsfjmvwtoi+state:results
> B) http://www.mail-archive.com/dev@cordova.apache.org/msg05775.html
>
> Arguments for moving to app/:
>
>  - easier to version control relevant / non-build-artifact app bits
>  - aesthetics
>
> Arguments against it:
>
>  - we break shit for users
>  - config.xml location and PhoneGap Build compatibility (but I don't see
> this as a valid argument against. This is an easy problem to solve for us
> Adobe folk and the tooling can handle the trivial steps of going up one
> directory to grab the right file before interfacing with Build)
>
> Also worth noting: people we're not against it for architectural reasons,
> in fact, most people were favorable for the change to app/.
>
> So, with plugman stabilizing and my focus moving to cli work, I feel I
> have a good grasp of both projects and the direction they are going, here
> is my suggestion on how to move forward with this:
>
> 1. cordova-cli's master branch, which will soon merge future work in, will
> revert to the old /www-based structure, then
> 2. In 3.0 we make the change, where landing such a breaking change is
> easier and we'll have a bunch of press/noise about the release out there
> too so communicating this change would be easier.
>
> If there are any other arguments for/against the app/ based structure, now
> is the time to bring it up. We can give this some more time to bake, but
> after 2.8 is released, I'd like to call a vote on whether we should move
> to this structure or not in 3.0.
>
> On 4/16/13 8:31 AM, "Michal Mocny" <mm...@chromium.org> wrote:
>
>>I should also add.  I appreciate that this is a change, and every change
>>has some learning overhead and we shouldn't stuff everything possible in
>>all the time.
>>
>>However, I think 3.0 and cli are a big change, and we should do the big
>>re-org all at once, so lets decide this now in a way we wont regret.
>>Thats
>>why we are being picky, I guess.  I like knowing that the root of the
>>project has cordova-only artifacts and your app-repo is just a
>>subdirectory
>>somewhere.  Then, the exact location and exact contents are way more
>>flexible.
>>
>>-Michal
>>
>>
>>On Tue, Apr 16, 2013 at 11:18 AM, Michal Mocny <mm...@chromium.org>
>>wrote:
>>
>>> 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
>>><ag...@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 <agrieve@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 <ti...@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 <an...@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.Wolf@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" <pu...@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 <
>>>> braden@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
>>>><fi...@adobe.com>
>>>> > > wrote:
>>>> > > > > > >> >
>>>> > > > > > >> >> How will we communicate this change to our existing
>>>>users?
>>>> > > > > > >> >>
>>>> > > > > > >> >> On 4/9/13 5:22 PM, "Braden Shepherdson" <
>>>> braden@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
>>>> > > >
>>>> > >
>>>> >
>>>>
>>>
>>>
>