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. - 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. 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 <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 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 <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, 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 < >> agri...@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.er...@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.er...@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 < >> > > > >> > iclell...@chromium.org >> > > > >> > > > >> > > > >> > > > > wrote: >> > > > >> > > > > > >> > > > >> > > > > > > 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 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.er...@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 >> > > > >> > > > > > > > > >> > > > >> > > > > > > > > >> > > > >> > > > > > > > >> > > > >> > > > > > > >> > > > >> > > > > >> > > > >> > > >> > > > >> > >> > > > >> >> > > > > >> > > > > >> > > > >> > > >> > >>
