cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: New directory structure in cordova-cli's future branch
Date Thu, 23 May 2013 02:11:38 GMT
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: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" <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message