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] >>
