I agree that config-file is the way to go. After an offline discussion with Nikhil, Parashu, and Jason, one question that came up was whether all of this native config stuff belongs in config.xml or should be separated out. One idea would be to define separate files for each configuration file you wish to modify (something like AndroidManifest.merge.xml). Those files would follow the same format as the config-file tag and you could add entries to build.json or config.xml specifying what native config each file modifies. It breaks from how we do it in plugin.xml, but it prevents having gigantic config.xml files that are mostly composed of native fragments. The current config file mixing that we do is somewhat messy. Thoughts?
Richard -----Original Message----- From: Alexis Kofman [mailto:[email protected]] Sent: Monday, March 21, 2016 1:39 PM To: [email protected] Subject: Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests Hello all, I agree with Julio that it is less confusing keeping the same mecanism that the one it already exists with the plugin.xml. Le 21 mars 2016 19:17, "julio cesar sanchez" <[email protected]> a écrit : > I think we should add the config-file tag to the config.xml. > It's already implemented on the plugin.xml. It allows you to modify > the AndroidManifest.xml or the info.plist when you install a plugin. > But the number of plugins that just modify the AndroidManifest.xml or > info.plist is increasing, I think that should be on the config.xml too. > > So we don't duplicate anything with our own tags, we just let them add > whatever they want from the config-file tag. > And if something can't be edited from the config-file tag, we tell > them to create a hook. > > Phonegap build uses the config-file tag on the config.xml to allow > their users to edit the AndroidManifest.xml and the info.plist > > @Parashuram idea might work on android, but I think we should have > something that can be used on all the platforms > > > > 2016-03-21 18:40 GMT+01:00 Parashuram N <[email protected]>: > > > Given that we are now using Gradle for builds, could these simply be > > gradle sub-projects that define an AndroidManifest.xml, that gets > > merged during Android build ? One way could be to support specifying > > "sub-projects" in config.xml, and these changes get picked up. Would > > it work for all cases ? > > > > -----Original Message----- > > From: Joe Bowser [mailto:[email protected]] > > Sent: Monday, March 21, 2016 10:07 AM > > To: dev <[email protected]> > > Subject: [Android] Need a solution to config.xml and > > AndroidManifest.xml feature requests > > > > Hey > > > > So, if you've been paying attention to the JIRA, we've been getting > > slammed with a ton of feature requests/bugs regarding the Android > Manifest > > where people want to add a 1:1 mapping between the two XML files. > > > > The thing is that it's getting out of control, and we need to find a > > better solution to this problem. I'm not sure what a better > > solution to this is, but if you want to see some of the issues that > > are related to this, here's a small list: > > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue > s.apache.org%2fjira%2fbrowse%2fCB-10894&data=01%7c01%7cpanarasi%40micr > osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7 > cd011db47%7c1&sdata=f3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5OA > y9RMA%3d > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue > s.apache.org%2fjira%2fbrowse%2fCB-10917&data=01%7c01%7cpanarasi%40micr > osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7 > cd011db47%7c1&sdata=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue > s.apache.org%2fjira%2fbrowse%2fCB-8159&data=01%7c01%7cpanarasi%40micro > soft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c > d011db47%7c1&sdata=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue > s.apache.org%2fjira%2fbrowse%2fCB-10755&data=01%7c01%7cpanarasi%40micr > osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7 > cd011db47%7c1&sdata=PeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue > s.apache.org%2fjira%2fbrowse%2fCB-8976&data=01%7c01%7cpanarasi%40micro > soft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c > d011db47%7c1&sdata=4VoysIEst8o7k3kvkyYu9MeBDF8VZ3q7aG6oLcoCN2w%3d > > > > All of these are either indirectly or directly related to the > > AndroidManifest, and it's clear that if we just allowed people to > > edit an AndroidManifest, or at least allow portions of it to be > > immutable, we > would > > be better off. Obviously, plugins that install third-party > > activities > and > > content providers would have to edit the manifest, but I think that > things > > are getting out of hand with the things that people want to control > > from config.xml. > > > > What do people think? Does anyone have a good solution to this problem? > > Are we really abstracting anything out by duplicating the same > > config in our own config.xml? > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
