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
On Mon, Jan 13, 2014 at 8:11 AM, David Kemp drk...@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
The current state is that it must still live within .cordova.
I'm hoping that 99% of people won't care about the file, so it being a
bit hidden isn't the most horrible thing. I'm open to talk about
rejiggering, but just didn't think this move was important enough to
make without more holistic
ya lets have a f2f hangout
I'll start a fresh thread for that
On Mon, Jan 13, 2014 at 6:40 AM, Michal Mocny mmo...@chromium.org wrote:
On Mon, Jan 13, 2014 at 8:11 AM, David Kemp drk...@google.com wrote:
Config.json is a strange beast. Its not a build artifact because you
optionally
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
On Fri, Jan 10, 2014 at 8:58 PM, Andrew Grieve agri...@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
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
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 mmo...@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
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)
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 agri...@chromium.org wrote:
Just spoke with Ian and I now understand his point about
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).
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.
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 agri...@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,
What cordova.json has that config.xml doesn't, is that you can set the
location of platforms with it through:
{
id:org.apache.mobilespec,
name:mobilespec,
lib: {
android: {
uri: /Users/agrieve/git/cordova/cordova-android,
version: dev,
id: cordova-android-dev
},
Are the platform locations set by Cordova CLI already? I know phonegap does
it and I actually wish to add it to Cordova CLI as well [1] but I thought
it was not implemented on CLI.
[1] https://issues.apache.org/jira/browse/CB-5218
In any case, engine info can go into cordova.xml.
--
Gorkem
On
currently, it's never written, but it is read when you do a platform add
On Thu, Jan 2, 2014 at 12:12 PM, Gorkem Ercan gorkem.er...@gmail.comwrote:
Are the platform locations set by Cordova CLI already? I know phonegap does
it and I actually wish to add it to Cordova CLI as well [1] but I
On Thu, Jan 2, 2014 at 10:22 AM, Andrew Grieve agri...@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
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?
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
Considering http://wiki.apache.org/cordova/ConfigurationFiles I'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.er...@gmail.comwrote:
I think what I will
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
I really like being able to set the source location on a per-project basis,
but maybe we should just change it to a command-line flag instead of a
config.json setting?
e.g.
cordova platform add android --source=my/dev/version/cordova-android
On Thu, Jan 2, 2014 at 3:31 PM, Gorkem Ercan
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
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.
Thanks for the feedback!
I don't think we should move files around automatically because it could
mess with people's source control.
I think using old versions of CLI with newer projects can't be supported,
but we can certainly (and I think have been) supporting using newer
versions of CLI with
Proposal:
For CLI projects:
- Use ./cordova.json if it exists, otherwise use .cordova/config.json
- Use ./hooks/* if it exists, otherwise use .cordova/hooks/*
- Change the project template to use ./cordova.json instead of
.cordova/config.json
Reasons:
- We want users to put .cordova into source
CLI searches for the .cordova folder from the current working directory up to
the root. What will be the new approach? Searching for the cordova.json and
.cordova for compatibility?
While I do agree on the change I don't really like the if folder exists or
config exists approach thingy, can't
ya this makes way more sense: I like it Andrew
On Mon, Dec 30, 2013 at 1:07 PM, Andrew Grieve agri...@chromium.org wrote:
Proposal:
For CLI projects:
- Use ./cordova.json if it exists, otherwise use .cordova/config.json
- Use ./hooks/* if it exists, otherwise use .cordova/hooks/*
- Change
28 matches
Mail list logo
