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 Tue, 16 Apr 2013 13:19:41 GMT
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