I too am opposed to splitting up into multiple files. The existing config.xml should already be usable cross device without change.
<feature name="Device"> <param name="android-package" value="org.apache.cordova.device.Device" /> <param name="ios-package" value="CDVDevice" /> <param name="wp-package" value="Device"/> </feature> BlackBerry needs to make a small change to add it's own param.name, and plugman needs to be aware of all the available targets and combine the output from multiple <platform> tags. <content src="index.html"> is already cross device The access tags for whitelisting have some minor differences but there is an open issue for that already. [1] As far as the location of the file, I agree it would be nice if it was consistent, but I think we should worry first about the contents of the file being consistent, then the location. It does make sense for the file to sit in the www folder so that this folder is portable, and can be dropped in another location, however this expectation is already broken by the different cordova.js files. [1] https://issues.apache.org/jira/browse/CB-4093 @purplecabbage risingj.com On Thu, Sep 26, 2013 at 8:07 AM, Braden Shepherdson <[email protected]>wrote: > On Thu, Sep 26, 2013 at 11:03 AM, Joe Bowser <[email protected]> wrote: > > > On Thu, Sep 26, 2013 at 7:18 AM, Braden Shepherdson <[email protected] > > > > wrote: > > > I am strongly opposed to splitting into one file per platform. We want > to > > > support <platform> tags in config.xml, which will allow > platform-specific > > > content within the single config.xml. > > > > Agreed. I'm not sure if Android actually supports this. We should > > probably write some JUnit tests against a multi-platform config.xml to > > test this and make sure that our parser actually works well. > > > > > Let me clarify: I was talking about adding <platform> tags to CLI's > top-level www/config.xml. The actual entries would be extracted into that > platform's final config.xml, without a <platform> tag. > > > > > > > > > There are good reasons why the CLI moves the config.xml on some > > platforms. > > > On Android, it's really easy to load XML files from res/xml/foo.xml, so > > > that's where we put it. We should be deleting the > > > platforms/android/assets/www/config.xml though, since it's an unused > > > duplicate and confusing. > > > > > > > +1 on this as well. The problem is that the documentation covers the > > PhoneGap Build use case and the CLI use case, but not the stand-alone > > use case. We should document the stand-alone use case, since that's > > really for people who are detail-oriented, and are using things such > > as the CordovaWebView component. > > >
