Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAM1AYQCKkc9-CgUJ4VsMGqNTScUGhQVRexvEshnE=8O=z7z+1Q@mail.gmail.com>
References: 
 <CAOBL_k78kLKsvoZx_tJnbsQmHNf59tj9zeE0aaXRiXfweFr5LQ@mail.gmail.com>
	<BL2PR03MB116CAC7CCEDC87770004BF0D68F0@BL2PR03MB116.namprd03.prod.outlook.com>
	<CAG5ZNwUPDVVs+ZuiQaederDTK84zp3j-742HD+9bf38Cghs8Ww@mail.gmail.com>
	<CAEwLf1rS-Cq-stHGb92+mnsC3dkxMfQdeCo6ZZ_V1yc+CAHbKg@mail.gmail.com>
	<CY1PR03MB231358E34990A69024205319B08F0@CY1PR03MB2313.namprd03.prod.outlook.com>
	<CAM1AYQDTWFj-r3bfxREfAyExC3dRCWQvAbGCW2v5GtujsRqc-g@mail.gmail.com>
	<CAE6O_-YztPsenUefMqCiZWWdykS3FUZhnecw-Z9wsgv_ZmNiGw@mail.gmail.com>
	<CAKP6k2tsCUKSZ9=uyHoOiK_REhkVGfCnZyUv4B3nTe_qXQaqGw@mail.gmail.com>
	<0FBBFD29-7D6A-40F3-B682-E5DB13ADB801@microsoft.com>
	<CAM1AYQCKkc9-CgUJ4VsMGqNTScUGhQVRexvEshnE=8O=z7z+1Q@mail.gmail.com>
Date: Tue, 22 Mar 2016 14:51:33 +0100
Message-ID: 
 <CAG5ZNwWmj+-KZ=ibXHcL0wPuAUTt6jj2Z6H6r5q3xvtOTSEoFA@mail.gmail.com>
Subject: Re: [Android] Need a solution to config.xml and AndroidManifest.xml
 feature requests
From: julio cesar sanchez <jcesarmobile@gmail.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a113a6590daec4f052ea382a7

--001a113a6590daec4f052ea382a7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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.macdonald@gmail.com>:

> When it comes to the AndroidManifest if config.xml and plugin.xml (possib=
ly
> multiple plugin.xml's) disagree on the value of an attribute:
>
> - if the value is a boolean then it should default to 'false'. For instan=
ce
> if it is an attribute like supports small screens if one plugin sets it t=
o
> 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 highes=
t
> 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 <panarasi@microsoft.com>
> wrote:
>
> > The disagreement could also like in a =E2=80=9Cpreference=E2=80=9D spec=
ifying a value,
> > that is overwritten by this fragment.
> >
> > On 3/21/16, 11:28 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> >
> > >I like having the same xml fragments in config.xml as we use in
> plugin.xml
> > >
> > ><platform name=3D"android">
> > >    <config-file target=3D"AndroidManifest.xml"
> > >parent=3D"/manifest/application">
> > >        <activity android:name=3D"
> >
> https://na01.safelinks.protection.outlook.com/?url=3Dcom.foo.Foo&data=3D0=
1%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f9=
88bf86f141af91ab2d7cd011db47%7c1&sdata=3DMPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxe=
YTnpiKR9c%3d
> > "
> > >android:label=3D"@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 <shazron@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=3Dhttps%3a%2f%2fissues=
.apache.org%2fjira%2fbrowse%2fCB-9264&data=3D01%7c01%7cpanarasi%40microsoft=
.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%=
7c1&sdata=3DAmj46nGpbpE3scp6sjDw1FemeGton2Hu6YSyQqZNT4M%3d
> > >> and a post-processing step does the removal of dupes. Not sure if th=
is
> > >> 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.macdonald@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 Androi=
d
> > will
> > >>> add the line:
> > >>>
> > >>>    <supports-screens android:anyDensity=3D"true"
> > >android:largeScreens=3D"true"
> > >>> android:normalScreens=3D"true" android:resizeable=3D"true"
> > >>> android:smallScreens=3D"true" android:xlargeScreens=3D"true" />
> > >>>
> > >>> and if you want to make smallScreens=3D"false" you have no way of d=
oing
> > 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-fi=
le
> > >tag.
> > >>>
> > >>>
> > >>>
> > >>> Simon Mac Donald
> > >>>
> >
> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fhi.im%2=
fsimonmacdonald&data=3D01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e7=
7391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3D%2fTHN2714=
ZxbZ7blck0JpCvz2U%2fLEFSzVDQP2mTLSMm8%3d
> > >>>
> > >>> On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll <
> riknoll@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). Tho=
se
> > >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 preven=
ts
> > >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.kofman@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" <
> jcesarmobile@gmail.com>
> > a
> > >>>> =C3=A9crit :
> > >>>>
> > >>>>> 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 modi=
fy
> > >>>>> the AndroidManifest.xml or the info.plist when you install a
> plugin.
> > >>>>> But the number of plugins that just modify the AndroidManifest.xm=
l
> or
> > >>>>> info.plist is increasing, I think that should be on the config.xm=
l
> > too.
> > >>>>>
> > >>>>> So we don't duplicate anything with our own tags, we just let the=
m
> > add
> > >>>>> whatever they want from the config-file tag.
> > >>>>> And if something can't be edited from the config-file tag, we tel=
l
> > >>>>> them to create a hook.
> > >>>>>
> > >>>>> Phonegap build uses the config-file tag on the config.xml to allo=
w
> > >>>>> their users to edit the AndroidManifest.xml and the info.plist
> > >>>>>
> > >>>>> @Parashuram idea might work on android, but I think we should hav=
e
> > >>>>> something that can be used on all the platforms
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> 2016-03-21 18:40 GMT+01:00 Parashuram N <panarasi@microsoft.com>:
> > >>>>>
> > >>>>>> Given that we are now using Gradle for builds, could these simpl=
y
> be
> > >>>>>> gradle sub-projects that define an AndroidManifest.xml, that get=
s
> > >>>>>> 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:bowserj@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 Androi=
d
> > >>>>> 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=3Dhttps%3a%2f%2fissu=
e
> > >>>>> s.apache.org
> > %2fjira%2fbrowse%2fCB-10894&data=3D01%7c01%7cpanarasi%40micr
> > >>>>> osoft.com
> > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > >>>>>
> > cd011db47%7c1&sdata=3Df3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5O=
A
> > >>>>> y9RMA%3d
> > >>>>>
> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fissu=
e
> > >>>>> s.apache.org
> > %2fjira%2fbrowse%2fCB-10917&data=3D01%7c01%7cpanarasi%40micr
> > >>>>> osoft.com
> > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > >>>>>
> > cd011db47%7c1&sdata=3DI1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3=
d
> > >>>>>
> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fissu=
e
> > >>>>> s.apache.org
> > %2fjira%2fbrowse%2fCB-8159&data=3D01%7c01%7cpanarasi%40micro
> > >>>>> soft.com
> > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > >>>>>
> d011db47%7c1&sdata=3DHS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
> > >>>>>
> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fissu=
e
> > >>>>> s.apache.org
> > %2fjira%2fbrowse%2fCB-10755&data=3D01%7c01%7cpanarasi%40micr
> > >>>>> osoft.com
> > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > >>>>>
> cd011db47%7c1&sdata=3DPeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
> > >>>>>
> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fissu=
e
> > >>>>> s.apache.org
> > %2fjira%2fbrowse%2fCB-8976&data=3D01%7c01%7cpanarasi%40micro
> > >>>>> soft.com
> > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > >>>>> d011db47%7c1&sdata=3D4VoysIEst8o7k3kvkyYu9MeBDF8VZ3q7aG6oLcoCN2w%=
3d
> > >>>>>>
> > >>>>>> All of these are either indirectly or directly related to the
> > >>>>>> AndroidManifest, and it's clear that if we just allowed people t=
o
> > >>>>>> 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-unsubscribe@cordova.apache.org
> > >>>> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> > >> --------------------------------------------------------------------=
-
> > >> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > >> For additional commands, e-mail: dev-help@cordova.apache.org
> > >>
> >
> >
>

--001a113a6590daec4f052ea382a7--