So for Android's case you are thinking the order of precedence should be: config.xml plugin.xml AndroidManifest.xml // created by the "cordova" cli
Then if config.xml overrides something that one of the plugins depends on then the app won't build. I can actually get behind that proposal if I'm understanding you correctly. Simon Mac Donald http://hi.im/simonmacdonald On Tue, Mar 22, 2016 at 9:51 AM, julio cesar sanchez <[email protected] > wrote: > I think, if there is a conflict between config.xml and plugin.xml we should > not build. > > If we pick config.xml values, the plugins with conflicting values might not > work, and if we pick the plugin.xml values, the app might not work the way > the user wants. > > I think both options are bad, the user wants the plugin to work and to get > the values he manually added and both aren't possible if there are > conflicts. > > > 2016-03-22 13:28 GMT+01:00 Simon MacDonald <[email protected]>: > > > When it comes to the AndroidManifest if config.xml and plugin.xml > (possibly > > multiple plugin.xml's) disagree on the value of an attribute: > > > > - if the value is a boolean then it should default to 'false'. For > instance > > if it is an attribute like supports small screens if one plugin sets it > to > > false it should be false for or else the app may not build. > > - if the value is a integer then it should default to the highest integer > > provided. For instance minimum SDK version, again have to pick the > highest > > or the app won't build. > > - if the value is a string, damned if I know if there are conflicts in > > multiple plugin.xml files but plugin.xml should take precedence over > > config.xml. > > > > Sound reasonable? > > > > > > Simon Mac Donald > > http://hi.im/simonmacdonald > > > > On Tue, Mar 22, 2016 at 3:27 AM, Parashuram N <[email protected]> > > wrote: > > > > > The disagreement could also like in a “preference” specifying a value, > > > that is overwritten by this fragment. > > > > > > On 3/21/16, 11:28 PM, "Jesse" <[email protected]> wrote: > > > > > > >I like having the same xml fragments in config.xml as we use in > > plugin.xml > > > > > > > ><platform name="android"> > > > > <config-file target="AndroidManifest.xml" > > > >parent="/manifest/application"> > > > > <activity android:name=" > > > > > > https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d > > > " > > > >android:label="@string/app_name"> > > > > <intent-filter> > > > > </intent-filter> > > > > </activity> > > > > </config-file> > > > ></platform> > > > > > > > >We will need to address precedence, as a plugin.xml and config.xml can > > > >disagree. > > > > > > > > > > > > > > > >> On Mar 21, 2016, at 12:46 PM, Shazron <[email protected]> wrote: > > > >> > > > >> Continuing on Simon's point, we already have duplication of entries > > > >> for preference tags in > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-9264&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Amj46nGpbpE3scp6sjDw1FemeGton2Hu6YSyQqZNT4M%3d > > > >> and a post-processing step does the removal of dupes. Not sure if > this > > > >> removal method would be adequate (as long as the desired tag to > > > >> express is written to the config file *last*) > > > >> > > > >> On Mon, Mar 21, 2016 at 3:41 PM, Simon MacDonald > > > >> <[email protected]> wrote: > > > >>> I agree the config-file is the way to go but we need to go one step > > > more > > > >>> and enable the changing of attributes in the config file instead of > > > just > > > >>> adding lines to AndroidManifest.xml. For instance, the first bug > > > CB-10894 > > > >>> talks about adding a preference for screen sizes. > > > >>> > > > >>> The default AndroidManifest.xml that is created with Cordova > Android > > > will > > > >>> add the line: > > > >>> > > > >>> <supports-screens android:anyDensity="true" > > > >android:largeScreens="true" > > > >>> android:normalScreens="true" android:resizeable="true" > > > >>> android:smallScreens="true" android:xlargeScreens="true" /> > > > >>> > > > >>> and if you want to make smallScreens="false" you have no way of > doing > > > it > > > >as > > > >>> it adds a duplicate line if you are using the config-file way of > > doing > > > >>> things. We really need attribute level granularity in the > config-file > > > >tag. > > > >>> > > > >>> > > > >>> > > > >>> Simon Mac Donald > > > >>> > > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%2fsimonmacdonald&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fTHN2714ZxbZ7blck0JpCvz2U%2fLEFSzVDQP2mTLSMm8%3d > > > >>> > > > >>> On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll < > > [email protected]> > > > >>> wrote: > > > >>> > > > >>>> 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] > > > >> > > > >> > --------------------------------------------------------------------- > > > >> To unsubscribe, e-mail: [email protected] > > > >> For additional commands, e-mail: [email protected] > > > >> > > > > > > > > >
