cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: Moving .cordova/config.json -> cordova.json
Date Mon, 13 Jan 2014 14:40:14 GMT
On Mon, Jan 13, 2014 at 8:11 AM, David Kemp <drkemp@google.com> wrote:

> Config.json is a strange beast. Its not a build artifact because you
> optionally create it to configure your project. Its used by Medic to force
> the use of the locally available platfrom libs, and Medic has to create it.
> It has always seemed strange to hide a configuration file in a hidden
> directlory. Now its one step worse because the hidden directory might not
> even be there.
> Could we just get his thing out into the open?
>

Lets discuss that at the next meetup?  Seems like this whole config file
topic is the top subject matter, and maybe there is a better overall
approach here.


>
>
>
> On Fri, Jan 10, 2014 at 10:19 PM, Michal Mocny <mmocny@chromium.org>
> wrote:
>
> > On Fri, Jan 10, 2014 at 8:58 PM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > I've finished working on this for now and have marked the bug as
> > > fixed. The commits are all attached to
> > > https://issues.apache.org/jira/browse/CB-4910.
> > >
> > > What I've done is:
> > > 1. config.xml:
> > >  - defaults to the root instead of within www/.
> > >  - We still read www/config.xml if the file doesn't exist at the root.
> > >  - The template will put in at the root now though.
> > > 2. hooks/ now live in a directory in the root instead of within
> .cordova
> > >  - The code will run all hooks found in .cordova/hooks as well as
> hooks/
> > >  - The create template now creates the directory in the root.
> > >
> >
> > Are hooks something popular enough that we should be creating by default?
> >  I do like that its self documenting and discoverable this way, but its
> > also adding some cognitive load for those just starting out with their
> > first project.  I'm not opposed at all, just asking.
> >
> >  - The create template no longer creates an empty directory for each
> > > hook type and instead adds a README.md to the hooks/
> > >    - Reason for this is that git doesn't commit empty dirs, so the
> > > empty subdirs are lost when committing to git anyways.
> > > 3. The .cordova/config.json:
> > >  - Has not moved.
> > >  - No longer contains the id and name used when creating the project
> > > (they weren't used anyways)
> > >  - Will not be written if it doesn't contain anything (which is the
> > > default)
> > >  - This means the .cordova/ directory now does not exist by default.
> > >
> >
> > ..but if I wanted a config.json for some reason, I would need to create a
> > .cordova, or can it exist inside the root as well?
> >
> >
> > > 4. Updated the README.md to reflect the new project structure
> > >
> > > In terms of promoting the change, I think it'll be enough to mention
> > > the change in the next tools release blog post.
> > >
> > > On Mon, Jan 6, 2014 at 12:07 PM, Brian LeRoux <b@brian.io> wrote:
> > > > ya agreed, we should aim to do something early Feb once everyone is
> > back
> > > > into the the flow
> > > >
> > > >
> > > > On Mon, Jan 6, 2014 at 11:59 AM, Michal Mocny <mmocny@chromium.org>
> > > wrote:
> > > >
> > > >> If we don't add a config.json by default, we need a new strategy for
> > > >> looking up paths for the root.
> > > >>
> > > >> I don't like naming the top-level config "config.xml", but after
> some
> > > >> thoughts on it, I don't think we should rename it just right now.
> >  There
> > > >> are a lot of changes that would need to go along with that rename
> for
> > > it to
> > > >> make any sense.  I also agree with Brian that what we really need
is
> > to
> > > >> step back and consider an entirely better solution rather than
> > something
> > > >> incremental.  Perhaps this is good subject matter for the next
> > hangout /
> > > >> meet-up.
> > > >>
> > > >> -Michal
> > > >>
> > > >>
> > > >> On Fri, Jan 3, 2014 at 2:43 PM, Brian LeRoux <b@brian.io> wrote:
> > > >>
> > > >> > probably a good idea for the moment / at some we will have a
> config
> > > file
> > > >> > reckoning!
> > > >> >
> > > >> >
> > > >> > On Fri, Jan 3, 2014 at 11:34 AM, Andrew Grieve <
> > agrieve@chromium.org>
> > > >> > wrote:
> > > >> >
> > > >> > > Okay, yeah, reading that back to myself and it seems like
a bad
> > idea
> > > >> > > (config.xml->app.xml). Probably would just add to confusion.
> > > >> > >
> > > >> > > So, top-level config.xml and top-level cordova.json.
> > > >> > >
> > > >> > > Maybe I could add to this that we don't create a cordova.json
by
> > > >> default,
> > > >> > > since 99% most people shouldn't need it.
> > > >> > >
> > > >> > >
> > > >> > > On Fri, Jan 3, 2014 at 2:31 PM, Brian LeRoux <b@brian.io>
> wrote:
> > > >> > >
> > > >> > > > actually, let me put this another way: I support
> > > .cordova/config.json
> > > >> > ->
> > > >> > > > cordova.json but I am not really interested in changing
the
> name
> > > of
> > > >> > > > ./www/config.xml to ./www/app.xml
> > > >> > > >
> > > >> > > > ...feels to me we could consolidate this entire sitation
with
> a
> > > >> single
> > > >> > > well
> > > >> > > > crafted configuration file (at the top level). ideally
we have
> > > more
> > > >> > > > convention than configuration. feels like we have too
many
> > > footguns
> > > >> to
> > > >> > > ease
> > > >> > > > our personal dev workflows as is than consideration
for people
> > > >> actually
> > > >> > > > building apps.
> > > >> > > >
> > > >> > > >
> > > >> > > > On Fri, Jan 3, 2014 at 11:25 AM, Brian LeRoux <b@brian.io>
> > wrote:
> > > >> > > >
> > > >> > > > > Sorry, I completely do not understand this at
all. The
> > proposal
> > > is
> > > >> to
> > > >> > > > > change the name of config.xml to ease confusions
and add a
> new
> > > top
> > > >> > > level
> > > >> > > > > config file?
> > > >> > > > >
> > > >> > > > >
> > > >> > > > > On Fri, Jan 3, 2014 at 11:15 AM, Andrew Grieve
<
> > > >> agrieve@chromium.org
> > > >> > > > >wrote:
> > > >> > > > >
> > > >> > > > >> Just spoke with Ian and I now understand his
point about
> > > >> > cordova.json
> > > >> > > > >> being
> > > >> > > > >> for build environment, whereas config.xml
is for
> application
> > > >> things.
> > > >> > > > >>
> > > >> > > > >> So, do think it'd be bad to have a cordova.json
and a
> > > config.xml
> > > >> > right
> > > >> > > > >> next
> > > >> > > > >> to each other.
> > > >> > > > >>
> > > >> > > > >> How about:
> > > >> > > > >>
> > > >> > > > >> config.xml -> app.xml
> > > >> > > > >>  - This will (hopefully) ease confusion about
CLI's
> > config.xml
> > > vs.
> > > >> > > > >> platforms/ config.xml files.
> > > >> > > > >>  - E.g. we're adding icon & splashscreen
support to CLI's
> > > >> > config.xml,
> > > >> > > > but
> > > >> > > > >> not for non-CLI config.xml files
> > > >> > > > >>  - E.g. app.xml and plugin.xml is where you
make edits,
> > > config.xml
> > > >> > is
> > > >> > > > >> what's read at runtime.
> > > >> > > > >>
> > > >> > > > >> .cordova/config.json -> cordova.json
> > > >> > > > >>
> > > >> > > > >> Also - JIRA for this is
> > > >> > https://issues.apache.org/jira/browse/CB-4910
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > > >>
> > > >> > > > >> On Thu, Jan 2, 2014 at 4:10 PM, Brian LeRoux
<b@brian.io>
> > > wrote:
> > > >> > > > >>
> > > >> > > > >> > I understood and read it too Gorkem.
> > > >> > > > >> >
> > > >> > > > >> > I was (poorly) suggesting we look at
the issue of
> > > configuration
> > > >> > in a
> > > >> > > > >> > complete view. Due to backwards compatibility
we will be
> > > adding
> > > >> a
> > > >> > > new
> > > >> > > > >> file
> > > >> > > > >> > and the code to support the old file
will be around a
> > while.
> > > >> > > > >> >
> > > >> > > > >> > We can probably roll a whole lot more
into a single file.
> > > What
> > > >> I"m
> > > >> > > not
> > > >> > > > >> sure
> > > >> > > > >> > about is what should and should not be.
> > > >> > > > >> >
> > > >> > > > >> >
> > > >> > > > >> > On Thu, Jan 2, 2014 at 12:31 PM, Gorkem
Ercan <
> > > >> > > gorkem.ercan@gmail.com
> > > >> > > > >> > >wrote:
> > > >> > > > >> >
> > > >> > > > >> > >
> > > >> > > > >> > > Reducing the number of configuration
files is actually
> > the
> > > >> goal
> > > >> > > > here.
> > > >> > > > >> > >
> > > >> > > > >> > > The abstraction is not a new one.
It already exists and
> > it
> > > is
> > > >> > part
> > > >> > > > of
> > > >> > > > >> the
> > > >> > > > >> > > $PROJECT/.cordova/config.json.
> > > >> > > > >> > > I am suggesting to move it to
> $HOME/.cordova/config.json
> > so
> > > >> that
> > > >> > > we
> > > >> > > > no
> > > >> > > > >> > > longer need the
> > > >> > > > >> > > $PROJECT/.cordova/config.json and
have only the
> > > cordova.xml to
> > > >> > > carry
> > > >> > > > >> > > project specific
> > > >> > > > >> > > properties.
> > > >> > > > >> > > --
> > > >> > > > >> > > Gorkem
> > > >> > > > >> > >
> > > >> > > > >> > >
> > > >> > > > >> > > On Thu, Jan 02, 2014 at 12:16:57PM
-0800, Brian LeRoux
> > > wrote:
> > > >> > > > >> > > > Considering
> > > >> > http://wiki.apache.org/cordova/ConfigurationFilesI'm
> > > >> > > > >> not
> > > >> > > > >> > > sure
> > > >> > > > >> > > > we want more config either.
> > > >> > > > >> > > >
> > > >> > > > >> > > > Perhaps we need to think more
comprehensively rather
> > than
> > > >> > > > proposing
> > > >> > > > >> > more
> > > >> > > > >> > > > abstractions.
> > > >> > > > >> > > >
> > > >> > > > >> > > >
> > > >> > > > >> > > > On Thu, Jan 2, 2014 at 11:15
AM, Gorkem Ercan <
> > > >> > > > >> gorkem.ercan@gmail.com
> > > >> > > > >> > > >wrote:
> > > >> > > > >> > > >
> > > >> > > > >> > > > >
> > > >> > > > >> > > > > I think what I will describe
here is more that what
> > CLI
> > > >> > > provides
> > > >> > > > >> > today.
> > > >> > > > >> > > > >
> > > >> > > > >> > > > > An engine/lib has a version,
id and a uri. On most
> > > cases,
> > > >> > you
> > > >> > > > only
> > > >> > > > >> > care
> > > >> > > > >> > > > > about the
> > > >> > > > >> > > > > id and uri and assume
that the tools that you work
> > with
> > > >> > > already
> > > >> > > > >> knows
> > > >> > > > >> > > how
> > > >> > > > >> > > > > to
> > > >> > > > >> > > > > resolve the id and version
to a location. In the
> case
> > > of
> > > >> CLI
> > > >> > > an
> > > >> > > > >> > engine
> > > >> > > > >> > > > > with id: cordova
> > > >> > > > >> > > > > and version:3.1.0 should
be resolved to
> > > >> > > > >> > > ~/.cordova/lib/ios/cordova/3.1.0
.
> > > >> > > > >> > > > > If we have a
> > > >> > > > >> > > > > uri defined that actually
means we want to
> overwrite
> > > the
> > > >> > > default
> > > >> > > > >> > > location
> > > >> > > > >> > > > > for the engine.
> > > >> > > > >> > > > > I think this redirection
should be per engine not
> per
> > > >> > project
> > > >> > > > and
> > > >> > > > >> > > should
> > > >> > > > >> > > > > be located as part of
> > > >> > > > >> > > > > CLI's configuration
> > > >> > > > >> > > > > --
> > > >> > > > >> > > > > Gorkem
> > > >> > > > >> > > > >
> > > >> > > > >> > > > > On Thu, Jan 02, 2014 at
01:28:12PM -0500, Andrew
> > Grieve
> > > >> > wrote:
> > > >> > > > >> > > > > > Hmm, good point about
absolute paths.
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > > I think if you're
using an override there though,
> > > that
> > > >> you
> > > >> > > > could
> > > >> > > > >> > set
> > > >> > > > >> > > it
> > > >> > > > >> > > > > to
> > > >> > > > >> > > > > > a relative path for
shared projects. Same thing
> > with
> > > >> > plugin
> > > >> > > > >> search
> > > >> > > > >> > > paths.
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > > I think it'll be
confusing to have a
> "cordova.xml"
> > as
> > > >> well
> > > >> > > as
> > > >> > > > a
> > > >> > > > >> > > > > > "cordova.json" file
right in the root.
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > > WDYT? Other options?
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > > On Thu, Jan 2, 2014
at 1:06 PM, Ian Clelland <
> > > >> > > > >> > iclelland@chromium.org
> > > >> > > > >> > > >
> > > >> > > > >> > > > > wrote:
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > > > On Thu, Jan
2, 2014 at 10:22 AM, Andrew Grieve
> <
> > > >> > > > >> > > agrieve@chromium.org>
> > > >> > > > >> > > > > > > wrote:
> > > >> > > > >> > > > > > >
> > > >> > > > >> > > > > > > > What cordova.json
has that config.xml
> doesn't,
> > is
> > > >> that
> > > >> > > you
> > > >> > > > >> can
> > > >> > > > >> > > set
> > > >> > > > >> > > > > the
> > > >> > > > >> > > > > > > > location
of platforms with it through:
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > >
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > > > That said,
I like your idea of having one
> > > top-level
> > > >> > > config
> > > >> > > > >> file
> > > >> > > > >> > > > > instead
> > > >> > > > >> > > > > > > of
> > > >> > > > >> > > > > > > > two. I
don't see why we couldn't just put
> these
> > > same
> > > >> > > > >> settings
> > > >> > > > >> > > into a
> > > >> > > > >> > > > > > > > "cordova.xml".
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > >
> > > >> > > > >> > > > > > > Wouldn't this
make it impossible to share
> project
> > > >> > > > >> configuration
> > > >> > > > >> > > between
> > > >> > > > >> > > > > > > developers?
If your /Users/agrieve/.../ paths
> are
> > > in
> > > >> > your
> > > >> > > > >> config
> > > >> > > > >> > > xml,
> > > >> > > > >> > > > > > > you're going
to have a bad time putting that in
> > > >> version
> > > >> > > > >> control.
> > > >> > > > >> > > > > > >
> > > >> > > > >> > > > > > > -1 on having
a single file to manage both
> > > application
> > > >> > > config
> > > >> > > > >> and
> > > >> > > > >> > > > > > > build-environment
config.
> > > >> > > > >> > > > > > >
> > > >> > > > >> > > > > > > +1 to the way
I read Gorkem's original
> > suggestion,
> > > >> which
> > > >> > > was
> > > >> > > > >> to
> > > >> > > > >> > > > > coordinate
> > > >> > > > >> > > > > > > the move of
the two files into a single issue
> and
> > > take
> > > >> > > care
> > > >> > > > >> of it
> > > >> > > > >> > > all
> > > >> > > > >> > > > > at
> > > >> > > > >> > > > > > > once.
> > > >> > > > >> > > > > > >
> > > >> > > > >> > > > > > >
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > > > On Wed,
Jan 1, 2014 at 5:05 PM, Gorkem Ercan
> <
> > > >> > > > >> > > gorkem.ercan@gmail.com
> > > >> > > > >> > > > > >
> > > >> > > > >> > > > > > > > wrote:
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > > > > There
is also another proposal to move
> > > config.xml
> > > >> > out
> > > >> > > of
> > > >> > > > >> www.
> > > >> > > > >> > > Can
> > > >> > > > >> > > > > we
> > > >> > > > >> > > > > > > > merge
> > > >> > > > >> > > > > > > > > this
two moves and
> > > >> > > > >> > > > > > > > > 1.
remove .cordova
> > > >> > > > >> > > > > > > > > 2.
remove config.json
> > > >> > > > >> > > > > > > > > 3.
move config.xml to root
> > > >> > > > >> > > > > > > > > 4.
rename config.xml to cordova.xml
> > > >> > > > >> > > > > > > > >
> > > >> > > > >> > > > > > > > > AFAIK
config,json does not carry any
> > > information
> > > >> > that
> > > >> > > is
> > > >> > > > >> not
> > > >> > > > >> > > > > already
> > > >> > > > >> > > > > > > > > available
on the config.xml. Since .cordova
> > is
> > > >> > > > basically a
> > > >> > > > >> > > marker
> > > >> > > > >> > > > > for
> > > >> > > > >> > > > > > > CLI
> > > >> > > > >> > > > > > > > > for
the root of an app I think renaming
> > > config.xml
> > > >> > > > should
> > > >> > > > >> > > provide
> > > >> > > > >> > > > > the
> > > >> > > > >> > > > > > > > same
> > > >> > > > >> > > > > > > > > functionality.
> > > >> > > > >> > > > > > > > > --
> > > >> > > > >> > > > > > > > > Gorkem
> > > >> > > > >> > > > > > > > >
> > > >> > > > >> > > > > > > > >
> > > >> > > > >> > > > > > > >
> > > >> > > > >> > > > > > >
> > > >> > > > >> > > > >
> > > >> > > > >> > >
> > > >> > > > >> >
> > > >> > > > >>
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message