cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: New directory structure in cordova-cli's future branch
Date Thu, 23 May 2013 18:31:58 GMT
+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 <fil@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" <mmocny@chromium.org> wrote:
>
>>Fil, that sounds extremely sensible.
>>
>>
>>On Thu, May 23, 2013 at 12:32 PM, Filip Maj <fil@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" <mmocny@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 <mmocny@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
>>> >>><braden@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
>>> >>><mmocny@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
>>> >>> >> >> > <tommy@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
>>><fil@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"
>>><mmocny@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
>>> >>> >> >> > > >>>> <agrieve@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"
>>> >>><purplecabbage@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
>>> >>> >> >> > > >>>>>>>>>>> <tommy@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
>>> >>> >> >> > > >>>>> <fil@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
>>> >>> >> >> > > >>>>>>>>
>>> >>> >> >> > > >>>>>>>
>>> >>> >> >> > > >>>>>>
>>> >>> >> >> > > >>>>>
>>> >>> >> >> > > >>>>
>>> >>> >> >> > > >>>>
>>> >>> >> >> > > >>
>>> >>> >> >> > >
>>> >>> >> >> > >
>>> >>> >> >> >
>>> >>> >> >>
>>> >>> >>
>>> >>>
>>> >>
>>> >>
>>>
>>>
>

Mime
View raw message