Seems like editing attributes in a config-file is a wanted enhancement. Do we have a JIRA for it?
Simon Mac Donald http://hi.im/simonmacdonald On Tue, Mar 22, 2016 at 5:09 PM, Carlos Santana <[email protected]> wrote: > 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 > > > > > >
