I would love to but I have a few other things to handle first. If someone else picks it up before I get to it then that's cool with me.
Simon Mac Donald http://hi.im/simonmacdonald On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana <csantan...@gmail.com> wrote: > Oh so it means you don't want to work on the code :-p > > > On Tue, Apr 5, 2016 at 6:50 PM Simon MacDonald <simon.macdon...@gmail.com> > wrote: > > > Thanks, I put a watch on that. > > > > > > Simon Mac Donald > > http://hi.im/simonmacdonald > > > > On Tue, Apr 5, 2016 at 6:48 PM, Carlos Santana <csantan...@gmail.com> > > wrote: > > > > > Simon, I was not able to find a JIRA, I created a new JIRA [1] to > enhance > > > plugin.xml to allow <config-file> to add attributes > > > > > > [1]: https://issues.apache.org/jira/browse/CB-11023 > > > > > > > > > On Wed, Mar 23, 2016 at 11:30 AM Simon MacDonald < > > > simon.macdon...@gmail.com> > > > wrote: > > > > > > > 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 < > csantan...@gmail.com> > > > > 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 < > > > > > jcesarmob...@gmail.com> > > > > > 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 < > alexis.kof...@gmail.com > > >: > > > > > > > > > > > > > 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 < > > > > > > > simon.macdon...@gmail.com> > > > > > > > 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 < > > > > > > > > jcesarmob...@gmail.com > > > > > > > > > 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 < > > > > > > simon.macdon...@gmail.com > > > > > > > >: > > > > > > > > > > > > > > > > > > > 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 < > > > > > > > panar...@microsoft.com> > > > > > > > > > > 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" <purplecabb...@gmail.com > > > > > > 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 < > > > shaz...@gmail.com> > > > > > > > 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 > > > > > > > > > > > >> <simon.macdon...@gmail.com> 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 < > > > > > > > > > > rikn...@microsoft.com> > > > > > > > > > > > >>> 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: > alexis.kof...@gmail.com > > ] > > > > > > > > > > > >>>> Sent: Monday, March 21, 2016 1:39 PM > > > > > > > > > > > >>>> To: dev@cordova.apache.org > > > > > > > > > > > >>>> 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" < > > > > > > > > > > jcesarmob...@gmail.com> > > > > > > > > > > > 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 < > > > > > > > > panar...@microsoft.com > > > > > > > > > >: > > > > > > > > > > > >>>>> > > > > > > > > > > > >>>>>> 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:bows...@gmail.com] > > > > > > > > > > > >>>>>> Sent: Monday, March 21, 2016 10:07 AM > > > > > > > > > > > >>>>>> To: dev <dev@cordova.apache.org> > > > > > > > > > > > >>>>>> 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: > > > > > dev-unsubscr...@cordova.apache.org > > > > > > > > > > > >>>> For additional commands, e-mail: > > > > > > dev-h...@cordova.apache.org > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > >> To unsubscribe, e-mail: > > > > dev-unsubscr...@cordova.apache.org > > > > > > > > > > > >> For additional commands, e-mail: > > > > > dev-h...@cordova.apache.org > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Alexis Kofman > > > > > > > > > > > > > > > > > > > > > > > > > > > >
