I agree to enable config.xml to be able to set or override using config-file (i.e. any xml file including strings.xml) I also think that adding support in config.xml and plugin.xml to edit attributes is very helpful, this is exactly what we are doing for one of our plugin to add the attribute android:name for <application> and it was a pain, and I think we still have problems doing it from before_plugin_install hook, it would be easier from plugin.xml
On Tue, Mar 22, 2016 at 10:55 AM julio cesar sanchez <[email protected]> wrote: > Yes, Simon, that's my opinion, and we should show the conficting values and > the id of the plugin with the conficting values so the user knows he has to > change the values on the config.xml or remove the plugin. > > But we still will have problems if the plugin uses a hook to write values > instead of using the config-file tag > > 2016-03-22 15:11 GMT+01:00 Alexis Kofman <[email protected]>: > > > Maybe the configured values of the plugins are sometimes just default > > values that the user can override through the config.xml file. > > What about adding a flag indicating whether the value is overridable ? > My 2 > > cents ... > > > > On Tue, Mar 22, 2016 at 3:02 PM, Simon MacDonald < > > [email protected]> > > wrote: > > > > > 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] > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Alexis Kofman > > >
