Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Steven Gill]

Hey Everyone!

So I decided to dig into this and wanted to summarize my findings. Please
correct me if I'm wrong.

1)  is a new tag that allows us to *merge* or *overwrite*
elements in config files. it only supports editing *one* element per block
of edit-config. If you need multiple edits, you will have to use multiple
edit-configs.

edit-config is available in plugin.xml and soon to be available in
config.xml.

For plugins, edit-config can handle conflicts with other plugin's
edit-config tags. It does this by warning the user about the conflict and
not installing the plugin. It recommends users use --force when installing
to give preference to the new plugin's edit-config tag. Tags that are
overwritten or merged will store a copy of the original in platform.json,
so we can easily revert back if we need to.

For config.xml, edit-config takes precedence over plugin's edit-config.
This way, a user can override a change a plugin is trying to make. There is
*no* ability to *revert* edit-config changes. Essentially need to rm and
add the platform.

2)  is used in plugin.xml to *add* new elements to config
files. No reverting. Can add *multiple* lines at once. Not available in
config.xml

The crazy thing is, this discussion started out as a way for users to
*add* elements
to their config files from config.xml. So we really need to add config-file
support to config.xml. New issue for this:
https://issues.apache.org/jira/browse/CB-11968. Anyone want to work on it?

In the future, lets try to bring a summary like this back to the list and
have a cordova-discuss thread about it.

* original discussion (not merged):
https://github.com/apache/cordova-lib/pull/432
* edit-config plugin.xml pr + discussion (merged & shipped):
https://github.com/apache/cordova-lib/pull/449
* edit-config config.xml pr + discussion (about to merge):
https://github.com/apache/cordova-lib/pull/492 &
https://github.com/apache/cordova-lib/pull/493
* issues: (edit-config plugin.xml)
https://issues.apache.org/jira/browse/CB-11023 & (edit-config config.xml)
https://issues.apache.org/jira/browse/CB-11908 & (config-file config.xml)
https://issues.apache.org/jira/browse/CB-11968







On Fri, Sep 2, 2016 at 6:16 PM, Simon MacDonald 
wrote:

> I'm confused what's not being covered? The edit-config tag which can be
> used from either plugin.xml or config.xml should be able to add new tags
> into an xml document as well as edit existing tags/attributes in an xml
> document.
>
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
> On Fri, Sep 2, 2016 at 5:00 PM, Joe Bowser  wrote:
>
> > Reviving this thread:
> >
> > So, it seems that a lot of us thought that the plugin.xml changes would
> fix
> > our problem, in fact they haven't because of what Julio just mentioned.
> > Right now a lot of the PRs that we're getting are to add extra settings.
> > I'm tempted to just merge them since we still don't have a solution to
> > this.  Does someone want to come up with something, or should I just do
> it.
> >
> > On Thu, Jul 21, 2016 at 2:34 PM, julio cesar sanchez <
> > jcesarmob...@gmail.com
> > > wrote:
> >
> > > That issue is about adding an attribute to an existing element of the
> > > AndroidManifest from plugin.xml, this topic is about adding the whole
> > > functionality of writing/editing the .xml/.plist files from config.xml
> > > instead of using a "silly" plugin
> > >
> > > 2016-07-21 23:24 GMT+02:00 Jesse :
> > >
> > > > CB-11023 is what it was submitted under. afaik
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > @purplecabbage
> > > > risingj.com
> > > >
> > > > On Thu, Jul 21, 2016 at 2:22 PM, julio cesar sanchez <
> > > > jcesarmob...@gmail.com
> > > > > wrote:
> > > >
> > > > > We still don't have an issue for this, right?
> > > > >
> > > > > I've been searching and found those three:
> > > > >
> > > > > https://issues.apache.org/jira/browse/CB-7232 (iOS)
> > > > > https://issues.apache.org/jira/browse/CB-11604 (Android)
> > > > > https://issues.apache.org/jira/browse/CB-10832 (Windows)
> > > > >
> > > > >
> > > > >
> > > > > 2016-04-29 17:13 GMT+02:00 Karen Tran :
> > > > >
> > > > > > Can I get someone to review my PR?
> > > > > > https://github.com/apache/cordova-lib/pull/432
> > > > > >
> > > > > > Thanks,
> > > > > > Karen Tran
> > > > > >
> > > > > > On Thu, Apr 21, 2016 at 11:02 AM, Vladimir Kotikov (Akvelon) <
> > > > > > v-vlk...@microsoft.com> wrote:
> > > > > >
> > > > > > > Exactly. Multiple tags is also possible with this syntax.
> > > > > > >
> > > > > > > -
> > > > > > > Best regards, Vladimir
> > > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > > > > > Sent: Thursday, April 21, 2016 5:20 PM
> > > > > > > To: dev@cordova.apache.org
> > > > > > > Subject: Re: [Android] Need a solution to config.xml and
> > > > > > > AndroidManifest.xml feature requests
> > > > > > >
> > > > > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Simon MacDonald]

I'm confused what's not being covered? The edit-config tag which can be
used from either plugin.xml or config.xml should be able to add new tags
into an xml document as well as edit existing tags/attributes in an xml
document.


Simon Mac Donald
http://hi.im/simonmacdonald

On Fri, Sep 2, 2016 at 5:00 PM, Joe Bowser  wrote:

> Reviving this thread:
>
> So, it seems that a lot of us thought that the plugin.xml changes would fix
> our problem, in fact they haven't because of what Julio just mentioned.
> Right now a lot of the PRs that we're getting are to add extra settings.
> I'm tempted to just merge them since we still don't have a solution to
> this.  Does someone want to come up with something, or should I just do it.
>
> On Thu, Jul 21, 2016 at 2:34 PM, julio cesar sanchez <
> jcesarmob...@gmail.com
> > wrote:
>
> > That issue is about adding an attribute to an existing element of the
> > AndroidManifest from plugin.xml, this topic is about adding the whole
> > functionality of writing/editing the .xml/.plist files from config.xml
> > instead of using a "silly" plugin
> >
> > 2016-07-21 23:24 GMT+02:00 Jesse :
> >
> > > CB-11023 is what it was submitted under. afaik
> > >
> > >
> > >
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > > On Thu, Jul 21, 2016 at 2:22 PM, julio cesar sanchez <
> > > jcesarmob...@gmail.com
> > > > wrote:
> > >
> > > > We still don't have an issue for this, right?
> > > >
> > > > I've been searching and found those three:
> > > >
> > > > https://issues.apache.org/jira/browse/CB-7232 (iOS)
> > > > https://issues.apache.org/jira/browse/CB-11604 (Android)
> > > > https://issues.apache.org/jira/browse/CB-10832 (Windows)
> > > >
> > > >
> > > >
> > > > 2016-04-29 17:13 GMT+02:00 Karen Tran :
> > > >
> > > > > Can I get someone to review my PR?
> > > > > https://github.com/apache/cordova-lib/pull/432
> > > > >
> > > > > Thanks,
> > > > > Karen Tran
> > > > >
> > > > > On Thu, Apr 21, 2016 at 11:02 AM, Vladimir Kotikov (Akvelon) <
> > > > > v-vlk...@microsoft.com> wrote:
> > > > >
> > > > > > Exactly. Multiple tags is also possible with this syntax.
> > > > > >
> > > > > > -
> > > > > > Best regards, Vladimir
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > > > > Sent: Thursday, April 21, 2016 5:20 PM
> > > > > > To: dev@cordova.apache.org
> > > > > > Subject: Re: [Android] Need a solution to config.xml and
> > > > > > AndroidManifest.xml feature requests
> > > > > >
> > > > > > @Vladimir, in your suggestion, is this what you were going for?
> > Being
> > > > > able
> > > > > > to add multiple attributes to any direct children node of the
> > parent?
> > > > > >
> > > > > >  > > > attr="true">
> > > > > >  > > > > android:debuggable="true"
> > > > > > />
> > > > > >  
> > > > > >
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Karen Tran
> > > > > >
> > > > > > On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
> > > > > > v-vlk...@microsoft.com> wrote:
> > > > > >
> > > > > > > Another proposal about syntax which allows to specify multiple
> > > > > > > attributes at once and does not require parsing attributes from
> > > plain
> > > > > > text:
> > > > > > >
> > > > > > >  > > > > attr="true">
> > > > > > > 
> > 
> > > > > > >
> > > > > > > Also I've took a quick look at the implementation and it looks
> > good
> > > > > > > apart from one minor issue - when we're grafting attributes we
> > > > > > > probably do not need to create an element to graft attributes
> to
> > if
> > > > it
> > > > > > > doesn't exist, otherwise after adding and then removing  the
> > plugin
> > > > > > > created xml element will remain in modified file.
> > > > > > >
> > > > > > > -
> > > > > > > Best regards, Vladimir
> > > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> > > > > > > Sent: Thursday, April 21, 2016 3:24 AM
> > > > > > > To: dev@cordova.apache.org
> > > > > > > Subject: RE: [Android] Need a solution to config.xml and
> > > > > > > AndroidManifest.xml feature requests
> > > > > > >
> > > > > > > Oh great! I have not taken a close look at the implementation
> > > itself.
> > > > > > > Perhaps you already had some of this in mind.
> > > > > > >
> > > > > > > As for the syntax for changing attributes, I would recommend
> > > > something
> > > > > > > like this:
> > > > > > >
> > > > > > >  > > > > parent="/manifest/application"
> > > > > > > attributeName="android:name" attirbuteValue="MyApplication"/>
> > > > > > >
> > > > > > > Also, we should always prioritize config.xml edits over
> > plugin.xml
> > > > > > > (giving the end developer the full control). In case of
> > conflicts,
> > > > > > > between plugins & config.xml we should warn and mention which
> one
> > > we
> > > > > > > picked (config.xml)
> > > > > > >
> > > > > > > Thanks,

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Joe Bowser]

Reviving this thread:

So, it seems that a lot of us thought that the plugin.xml changes would fix
our problem, in fact they haven't because of what Julio just mentioned.
Right now a lot of the PRs that we're getting are to add extra settings.
I'm tempted to just merge them since we still don't have a solution to
this.  Does someone want to come up with something, or should I just do it.

On Thu, Jul 21, 2016 at 2:34 PM, julio cesar sanchez  wrote:

> That issue is about adding an attribute to an existing element of the
> AndroidManifest from plugin.xml, this topic is about adding the whole
> functionality of writing/editing the .xml/.plist files from config.xml
> instead of using a "silly" plugin
>
> 2016-07-21 23:24 GMT+02:00 Jesse :
>
> > CB-11023 is what it was submitted under. afaik
> >
> >
> >
> >
> >
> > @purplecabbage
> > risingj.com
> >
> > On Thu, Jul 21, 2016 at 2:22 PM, julio cesar sanchez <
> > jcesarmob...@gmail.com
> > > wrote:
> >
> > > We still don't have an issue for this, right?
> > >
> > > I've been searching and found those three:
> > >
> > > https://issues.apache.org/jira/browse/CB-7232 (iOS)
> > > https://issues.apache.org/jira/browse/CB-11604 (Android)
> > > https://issues.apache.org/jira/browse/CB-10832 (Windows)
> > >
> > >
> > >
> > > 2016-04-29 17:13 GMT+02:00 Karen Tran :
> > >
> > > > Can I get someone to review my PR?
> > > > https://github.com/apache/cordova-lib/pull/432
> > > >
> > > > Thanks,
> > > > Karen Tran
> > > >
> > > > On Thu, Apr 21, 2016 at 11:02 AM, Vladimir Kotikov (Akvelon) <
> > > > v-vlk...@microsoft.com> wrote:
> > > >
> > > > > Exactly. Multiple tags is also possible with this syntax.
> > > > >
> > > > > -
> > > > > Best regards, Vladimir
> > > > >
> > > > > -Original Message-
> > > > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > > > Sent: Thursday, April 21, 2016 5:20 PM
> > > > > To: dev@cordova.apache.org
> > > > > Subject: Re: [Android] Need a solution to config.xml and
> > > > > AndroidManifest.xml feature requests
> > > > >
> > > > > @Vladimir, in your suggestion, is this what you were going for?
> Being
> > > > able
> > > > > to add multiple attributes to any direct children node of the
> parent?
> > > > >
> > > > >  > > attr="true">
> > > > >  > > > android:debuggable="true"
> > > > > />
> > > > >  
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > > Karen Tran
> > > > >
> > > > > On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
> > > > > v-vlk...@microsoft.com> wrote:
> > > > >
> > > > > > Another proposal about syntax which allows to specify multiple
> > > > > > attributes at once and does not require parsing attributes from
> > plain
> > > > > text:
> > > > > >
> > > > > >  > > > attr="true">
> > > > > > 
> 
> > > > > >
> > > > > > Also I've took a quick look at the implementation and it looks
> good
> > > > > > apart from one minor issue - when we're grafting attributes we
> > > > > > probably do not need to create an element to graft attributes to
> if
> > > it
> > > > > > doesn't exist, otherwise after adding and then removing  the
> plugin
> > > > > > created xml element will remain in modified file.
> > > > > >
> > > > > > -
> > > > > > Best regards, Vladimir
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> > > > > > Sent: Thursday, April 21, 2016 3:24 AM
> > > > > > To: dev@cordova.apache.org
> > > > > > Subject: RE: [Android] Need a solution to config.xml and
> > > > > > AndroidManifest.xml feature requests
> > > > > >
> > > > > > Oh great! I have not taken a close look at the implementation
> > itself.
> > > > > > Perhaps you already had some of this in mind.
> > > > > >
> > > > > > As for the syntax for changing attributes, I would recommend
> > > something
> > > > > > like this:
> > > > > >
> > > > > >  > > > parent="/manifest/application"
> > > > > > attributeName="android:name" attirbuteValue="MyApplication"/>
> > > > > >
> > > > > > Also, we should always prioritize config.xml edits over
> plugin.xml
> > > > > > (giving the end developer the full control). In case of
> conflicts,
> > > > > > between plugins & config.xml we should warn and mention which one
> > we
> > > > > > picked (config.xml)
> > > > > >
> > > > > > Thanks,
> > > > > > Nikhil
> > > > > >
> > > > > > -Original Message-
> > > > > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > > > > Sent: Wednesday, April 20, 2016 12:40 PM
> > > > > > To: dev@cordova.apache.org
> > > > > > Subject: Re: [Android] Need a solution to config.xml and
> > > > > > AndroidManifest.xml feature requests
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I made an attempt at the functionality of being able to add
> > > attributes
> > > > > > with the config-file tag. It's not completed yet, but I wanted to
> > get
> > > > > > some review before I proceed.
> > > > > > With my changes, 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[julio cesar sanchez]

That issue is about adding an attribute to an existing element of the
AndroidManifest from plugin.xml, this topic is about adding the whole
functionality of writing/editing the .xml/.plist files from config.xml
instead of using a "silly" plugin

2016-07-21 23:24 GMT+02:00 Jesse :

> CB-11023 is what it was submitted under. afaik
>
>
>
>
>
> @purplecabbage
> risingj.com
>
> On Thu, Jul 21, 2016 at 2:22 PM, julio cesar sanchez <
> jcesarmob...@gmail.com
> > wrote:
>
> > We still don't have an issue for this, right?
> >
> > I've been searching and found those three:
> >
> > https://issues.apache.org/jira/browse/CB-7232 (iOS)
> > https://issues.apache.org/jira/browse/CB-11604 (Android)
> > https://issues.apache.org/jira/browse/CB-10832 (Windows)
> >
> >
> >
> > 2016-04-29 17:13 GMT+02:00 Karen Tran :
> >
> > > Can I get someone to review my PR?
> > > https://github.com/apache/cordova-lib/pull/432
> > >
> > > Thanks,
> > > Karen Tran
> > >
> > > On Thu, Apr 21, 2016 at 11:02 AM, Vladimir Kotikov (Akvelon) <
> > > v-vlk...@microsoft.com> wrote:
> > >
> > > > Exactly. Multiple tags is also possible with this syntax.
> > > >
> > > > -
> > > > Best regards, Vladimir
> > > >
> > > > -Original Message-
> > > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > > Sent: Thursday, April 21, 2016 5:20 PM
> > > > To: dev@cordova.apache.org
> > > > Subject: Re: [Android] Need a solution to config.xml and
> > > > AndroidManifest.xml feature requests
> > > >
> > > > @Vladimir, in your suggestion, is this what you were going for? Being
> > > able
> > > > to add multiple attributes to any direct children node of the parent?
> > > >
> > > >  > attr="true">
> > > >  > > android:debuggable="true"
> > > > />
> > > >  
> > > >
> > > >
> > > >
> > > > Regards,
> > > > Karen Tran
> > > >
> > > > On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
> > > > v-vlk...@microsoft.com> wrote:
> > > >
> > > > > Another proposal about syntax which allows to specify multiple
> > > > > attributes at once and does not require parsing attributes from
> plain
> > > > text:
> > > > >
> > > > >  > > attr="true">
> > > > >  
> > > > >
> > > > > Also I've took a quick look at the implementation and it looks good
> > > > > apart from one minor issue - when we're grafting attributes we
> > > > > probably do not need to create an element to graft attributes to if
> > it
> > > > > doesn't exist, otherwise after adding and then removing  the plugin
> > > > > created xml element will remain in modified file.
> > > > >
> > > > > -
> > > > > Best regards, Vladimir
> > > > >
> > > > > -Original Message-
> > > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> > > > > Sent: Thursday, April 21, 2016 3:24 AM
> > > > > To: dev@cordova.apache.org
> > > > > Subject: RE: [Android] Need a solution to config.xml and
> > > > > AndroidManifest.xml feature requests
> > > > >
> > > > > Oh great! I have not taken a close look at the implementation
> itself.
> > > > > Perhaps you already had some of this in mind.
> > > > >
> > > > > As for the syntax for changing attributes, I would recommend
> > something
> > > > > like this:
> > > > >
> > > > >  > > parent="/manifest/application"
> > > > > attributeName="android:name" attirbuteValue="MyApplication"/>
> > > > >
> > > > > Also, we should always prioritize config.xml edits over plugin.xml
> > > > > (giving the end developer the full control). In case of conflicts,
> > > > > between plugins & config.xml we should warn and mention which one
> we
> > > > > picked (config.xml)
> > > > >
> > > > > Thanks,
> > > > > Nikhil
> > > > >
> > > > > -Original Message-
> > > > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > > > Sent: Wednesday, April 20, 2016 12:40 PM
> > > > > To: dev@cordova.apache.org
> > > > > Subject: Re: [Android] Need a solution to config.xml and
> > > > > AndroidManifest.xml feature requests
> > > > >
> > > > > Hi,
> > > > >
> > > > > I made an attempt at the functionality of being able to add
> > attributes
> > > > > with the config-file tag. It's not completed yet, but I wanted to
> get
> > > > > some review before I proceed.
> > > > > With my changes, you can add an attribute through the config-file
> tag
> > > > > in plugin.xml when the plugin is added, and when the plugin is
> > > > > removed, the attribute will get removed.
> > > > > https://github.com/ktop/cordova-lib/tree/cb-11023
> > > > >
> > > > > This is what the tag looks like:
> > > > > * > > > > parent="/manifest/application" attr="true">*
> > > > > *android:name="MyApplication"*
> > > > >
> > > > > **
> > > > >
> > > > > Added *attr* attribute to let Config-File know that we want to add
> an
> > > > > attribute. Default should be false and will expect an element
> rather
> > > > > than an attribute.
> > > > >
> > > > > One issue I have is that it can only add 1 attribute per
> config-file
> > > tag.
> > > > > This 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Jesse]

CB-11023 is what it was submitted under. afaik





@purplecabbage
risingj.com

On Thu, Jul 21, 2016 at 2:22 PM, julio cesar sanchez  wrote:

> We still don't have an issue for this, right?
>
> I've been searching and found those three:
>
> https://issues.apache.org/jira/browse/CB-7232 (iOS)
> https://issues.apache.org/jira/browse/CB-11604 (Android)
> https://issues.apache.org/jira/browse/CB-10832 (Windows)
>
>
>
> 2016-04-29 17:13 GMT+02:00 Karen Tran :
>
> > Can I get someone to review my PR?
> > https://github.com/apache/cordova-lib/pull/432
> >
> > Thanks,
> > Karen Tran
> >
> > On Thu, Apr 21, 2016 at 11:02 AM, Vladimir Kotikov (Akvelon) <
> > v-vlk...@microsoft.com> wrote:
> >
> > > Exactly. Multiple tags is also possible with this syntax.
> > >
> > > -
> > > Best regards, Vladimir
> > >
> > > -Original Message-
> > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > Sent: Thursday, April 21, 2016 5:20 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: [Android] Need a solution to config.xml and
> > > AndroidManifest.xml feature requests
> > >
> > > @Vladimir, in your suggestion, is this what you were going for? Being
> > able
> > > to add multiple attributes to any direct children node of the parent?
> > >
> > >  attr="true">
> > >  > android:debuggable="true"
> > > />
> > >  
> > >
> > >
> > >
> > > Regards,
> > > Karen Tran
> > >
> > > On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
> > > v-vlk...@microsoft.com> wrote:
> > >
> > > > Another proposal about syntax which allows to specify multiple
> > > > attributes at once and does not require parsing attributes from plain
> > > text:
> > > >
> > > >  > attr="true">
> > > >  
> > > >
> > > > Also I've took a quick look at the implementation and it looks good
> > > > apart from one minor issue - when we're grafting attributes we
> > > > probably do not need to create an element to graft attributes to if
> it
> > > > doesn't exist, otherwise after adding and then removing  the plugin
> > > > created xml element will remain in modified file.
> > > >
> > > > -
> > > > Best regards, Vladimir
> > > >
> > > > -Original Message-
> > > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> > > > Sent: Thursday, April 21, 2016 3:24 AM
> > > > To: dev@cordova.apache.org
> > > > Subject: RE: [Android] Need a solution to config.xml and
> > > > AndroidManifest.xml feature requests
> > > >
> > > > Oh great! I have not taken a close look at the implementation itself.
> > > > Perhaps you already had some of this in mind.
> > > >
> > > > As for the syntax for changing attributes, I would recommend
> something
> > > > like this:
> > > >
> > > >  > parent="/manifest/application"
> > > > attributeName="android:name" attirbuteValue="MyApplication"/>
> > > >
> > > > Also, we should always prioritize config.xml edits over plugin.xml
> > > > (giving the end developer the full control). In case of conflicts,
> > > > between plugins & config.xml we should warn and mention which one we
> > > > picked (config.xml)
> > > >
> > > > Thanks,
> > > > Nikhil
> > > >
> > > > -Original Message-
> > > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > > Sent: Wednesday, April 20, 2016 12:40 PM
> > > > To: dev@cordova.apache.org
> > > > Subject: Re: [Android] Need a solution to config.xml and
> > > > AndroidManifest.xml feature requests
> > > >
> > > > Hi,
> > > >
> > > > I made an attempt at the functionality of being able to add
> attributes
> > > > with the config-file tag. It's not completed yet, but I wanted to get
> > > > some review before I proceed.
> > > > With my changes, you can add an attribute through the config-file tag
> > > > in plugin.xml when the plugin is added, and when the plugin is
> > > > removed, the attribute will get removed.
> > > > https://github.com/ktop/cordova-lib/tree/cb-11023
> > > >
> > > > This is what the tag looks like:
> > > > * > > > parent="/manifest/application" attr="true">*
> > > > *android:name="MyApplication"*
> > > >
> > > > **
> > > >
> > > > Added *attr* attribute to let Config-File know that we want to add an
> > > > attribute. Default should be false and will expect an element rather
> > > > than an attribute.
> > > >
> > > > One issue I have is that it can only add 1 attribute per config-file
> > tag.
> > > > This is the part that I still need to fix.
> > > >
> > > > Can someone review what I have so far?
> > > >
> > > > Thanks,
> > > > Karen
> > > >
> > > > On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald
> > > >  > > > >
> > > > wrote:
> > > >
> > > > > 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
> > > > >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.i
> > > > > m%
> > > > > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[julio cesar sanchez]

We still don't have an issue for this, right?

I've been searching and found those three:

https://issues.apache.org/jira/browse/CB-7232 (iOS)
https://issues.apache.org/jira/browse/CB-11604 (Android)
https://issues.apache.org/jira/browse/CB-10832 (Windows)



2016-04-29 17:13 GMT+02:00 Karen Tran :

> Can I get someone to review my PR?
> https://github.com/apache/cordova-lib/pull/432
>
> Thanks,
> Karen Tran
>
> On Thu, Apr 21, 2016 at 11:02 AM, Vladimir Kotikov (Akvelon) <
> v-vlk...@microsoft.com> wrote:
>
> > Exactly. Multiple tags is also possible with this syntax.
> >
> > -
> > Best regards, Vladimir
> >
> > -Original Message-
> > From: Karen Tran [mailto:ktop...@gmail.com]
> > Sent: Thursday, April 21, 2016 5:20 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] Need a solution to config.xml and
> > AndroidManifest.xml feature requests
> >
> > @Vladimir, in your suggestion, is this what you were going for? Being
> able
> > to add multiple attributes to any direct children node of the parent?
> >
> > 
> >  android:debuggable="true"
> > />
> >  
> >
> >
> >
> > Regards,
> > Karen Tran
> >
> > On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
> > v-vlk...@microsoft.com> wrote:
> >
> > > Another proposal about syntax which allows to specify multiple
> > > attributes at once and does not require parsing attributes from plain
> > text:
> > >
> > >  attr="true">
> > >  
> > >
> > > Also I've took a quick look at the implementation and it looks good
> > > apart from one minor issue - when we're grafting attributes we
> > > probably do not need to create an element to graft attributes to if it
> > > doesn't exist, otherwise after adding and then removing  the plugin
> > > created xml element will remain in modified file.
> > >
> > > -
> > > Best regards, Vladimir
> > >
> > > -Original Message-
> > > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> > > Sent: Thursday, April 21, 2016 3:24 AM
> > > To: dev@cordova.apache.org
> > > Subject: RE: [Android] Need a solution to config.xml and
> > > AndroidManifest.xml feature requests
> > >
> > > Oh great! I have not taken a close look at the implementation itself.
> > > Perhaps you already had some of this in mind.
> > >
> > > As for the syntax for changing attributes, I would recommend something
> > > like this:
> > >
> > >  parent="/manifest/application"
> > > attributeName="android:name" attirbuteValue="MyApplication"/>
> > >
> > > Also, we should always prioritize config.xml edits over plugin.xml
> > > (giving the end developer the full control). In case of conflicts,
> > > between plugins & config.xml we should warn and mention which one we
> > > picked (config.xml)
> > >
> > > Thanks,
> > > Nikhil
> > >
> > > -Original Message-
> > > From: Karen Tran [mailto:ktop...@gmail.com]
> > > Sent: Wednesday, April 20, 2016 12:40 PM
> > > To: dev@cordova.apache.org
> > > Subject: Re: [Android] Need a solution to config.xml and
> > > AndroidManifest.xml feature requests
> > >
> > > Hi,
> > >
> > > I made an attempt at the functionality of being able to add attributes
> > > with the config-file tag. It's not completed yet, but I wanted to get
> > > some review before I proceed.
> > > With my changes, you can add an attribute through the config-file tag
> > > in plugin.xml when the plugin is added, and when the plugin is
> > > removed, the attribute will get removed.
> > > https://github.com/ktop/cordova-lib/tree/cb-11023
> > >
> > > This is what the tag looks like:
> > > * > > parent="/manifest/application" attr="true">*
> > > *android:name="MyApplication"*
> > >
> > > **
> > >
> > > Added *attr* attribute to let Config-File know that we want to add an
> > > attribute. Default should be false and will expect an element rather
> > > than an attribute.
> > >
> > > One issue I have is that it can only add 1 attribute per config-file
> tag.
> > > This is the part that I still need to fix.
> > >
> > > Can someone review what I have so far?
> > >
> > > Thanks,
> > > Karen
> > >
> > > On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald
> > >  > > >
> > > wrote:
> > >
> > > > 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
> > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.i
> > > > m%
> > > > 2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2d
> > > > ae
> > > > 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1=T
> > > > vJ lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > > >
> > > > On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana
> > > > 
> > > > 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 <
> > > > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Karen Tran]

Can I get someone to review my PR?
https://github.com/apache/cordova-lib/pull/432

Thanks,
Karen Tran

On Thu, Apr 21, 2016 at 11:02 AM, Vladimir Kotikov (Akvelon) <
v-vlk...@microsoft.com> wrote:

> Exactly. Multiple tags is also possible with this syntax.
>
> -
> Best regards, Vladimir
>
> -Original Message-
> From: Karen Tran [mailto:ktop...@gmail.com]
> Sent: Thursday, April 21, 2016 5:20 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] Need a solution to config.xml and
> AndroidManifest.xml feature requests
>
> @Vladimir, in your suggestion, is this what you were going for? Being able
> to add multiple attributes to any direct children node of the parent?
>
> 
>  />
>  
>
>
>
> Regards,
> Karen Tran
>
> On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
> v-vlk...@microsoft.com> wrote:
>
> > Another proposal about syntax which allows to specify multiple
> > attributes at once and does not require parsing attributes from plain
> text:
> >
> > 
> >  
> >
> > Also I've took a quick look at the implementation and it looks good
> > apart from one minor issue - when we're grafting attributes we
> > probably do not need to create an element to graft attributes to if it
> > doesn't exist, otherwise after adding and then removing  the plugin
> > created xml element will remain in modified file.
> >
> > -
> > Best regards, Vladimir
> >
> > -Original Message-
> > From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> > Sent: Thursday, April 21, 2016 3:24 AM
> > To: dev@cordova.apache.org
> > Subject: RE: [Android] Need a solution to config.xml and
> > AndroidManifest.xml feature requests
> >
> > Oh great! I have not taken a close look at the implementation itself.
> > Perhaps you already had some of this in mind.
> >
> > As for the syntax for changing attributes, I would recommend something
> > like this:
> >
> >  > attributeName="android:name" attirbuteValue="MyApplication"/>
> >
> > Also, we should always prioritize config.xml edits over plugin.xml
> > (giving the end developer the full control). In case of conflicts,
> > between plugins & config.xml we should warn and mention which one we
> > picked (config.xml)
> >
> > Thanks,
> > Nikhil
> >
> > -Original Message-
> > From: Karen Tran [mailto:ktop...@gmail.com]
> > Sent: Wednesday, April 20, 2016 12:40 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [Android] Need a solution to config.xml and
> > AndroidManifest.xml feature requests
> >
> > Hi,
> >
> > I made an attempt at the functionality of being able to add attributes
> > with the config-file tag. It's not completed yet, but I wanted to get
> > some review before I proceed.
> > With my changes, you can add an attribute through the config-file tag
> > in plugin.xml when the plugin is added, and when the plugin is
> > removed, the attribute will get removed.
> > https://github.com/ktop/cordova-lib/tree/cb-11023
> >
> > This is what the tag looks like:
> > * > parent="/manifest/application" attr="true">*
> > *android:name="MyApplication"*
> >
> > **
> >
> > Added *attr* attribute to let Config-File know that we want to add an
> > attribute. Default should be false and will expect an element rather
> > than an attribute.
> >
> > One issue I have is that it can only add 1 attribute per config-file tag.
> > This is the part that I still need to fix.
> >
> > Can someone review what I have so far?
> >
> > Thanks,
> > Karen
> >
> > On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald
> >  > >
> > wrote:
> >
> > > 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
> > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.i
> > > m%
> > > 2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2d
> > > ae
> > > 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1=T
> > > vJ lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > >
> > > On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana
> > > 
> > > 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
> > > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f
> > > > > hi
> > > > > .im%2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c3
> > > > > 79
> > > > > bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47
> > > > > %7 c1=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > > > >
> > > > > On Tue, Apr 5, 2016 at 6:48 PM, Carlos Santana
> > > > > 
> > > > > wrote:
> > > > >
> > > > > > Simon, I was not able to find a JIRA, I created a new JIRA [1]
> > > > > > to
> > > > enhance
> > > > > > 

RE: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Vladimir Kotikov (Akvelon)]

Exactly. Multiple tags is also possible with this syntax.

-
Best regards, Vladimir

-Original Message-
From: Karen Tran [mailto:ktop...@gmail.com] 
Sent: Thursday, April 21, 2016 5:20 PM
To: dev@cordova.apache.org
Subject: Re: [Android] Need a solution to config.xml and AndroidManifest.xml 
feature requests

@Vladimir, in your suggestion, is this what you were going for? Being able to 
add multiple attributes to any direct children node of the parent?



 



Regards,
Karen Tran

On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) < 
v-vlk...@microsoft.com> wrote:

> Another proposal about syntax which allows to specify multiple 
> attributes at once and does not require parsing attributes from plain text:
>
> 
>  
>
> Also I've took a quick look at the implementation and it looks good 
> apart from one minor issue - when we're grafting attributes we 
> probably do not need to create an element to graft attributes to if it 
> doesn't exist, otherwise after adding and then removing  the plugin 
> created xml element will remain in modified file.
>
> -
> Best regards, Vladimir
>
> -Original Message-
> From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> Sent: Thursday, April 21, 2016 3:24 AM
> To: dev@cordova.apache.org
> Subject: RE: [Android] Need a solution to config.xml and 
> AndroidManifest.xml feature requests
>
> Oh great! I have not taken a close look at the implementation itself.
> Perhaps you already had some of this in mind.
>
> As for the syntax for changing attributes, I would recommend something 
> like this:
>
>  attributeName="android:name" attirbuteValue="MyApplication"/>
>
> Also, we should always prioritize config.xml edits over plugin.xml 
> (giving the end developer the full control). In case of conflicts, 
> between plugins & config.xml we should warn and mention which one we 
> picked (config.xml)
>
> Thanks,
> Nikhil
>
> -Original Message-
> From: Karen Tran [mailto:ktop...@gmail.com]
> Sent: Wednesday, April 20, 2016 12:40 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] Need a solution to config.xml and 
> AndroidManifest.xml feature requests
>
> Hi,
>
> I made an attempt at the functionality of being able to add attributes 
> with the config-file tag. It's not completed yet, but I wanted to get 
> some review before I proceed.
> With my changes, you can add an attribute through the config-file tag 
> in plugin.xml when the plugin is added, and when the plugin is 
> removed, the attribute will get removed.
> https://github.com/ktop/cordova-lib/tree/cb-11023
>
> This is what the tag looks like:
> * parent="/manifest/application" attr="true">*
> *android:name="MyApplication"*
>
> **
>
> Added *attr* attribute to let Config-File know that we want to add an 
> attribute. Default should be false and will expect an element rather 
> than an attribute.
>
> One issue I have is that it can only add 1 attribute per config-file tag.
> This is the part that I still need to fix.
>
> Can someone review what I have so far?
>
> Thanks,
> Karen
>
> On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald 
>  >
> wrote:
>
> > 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
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.i
> > m% 
> > 2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2d
> > ae 
> > 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1=T
> > vJ lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> >
> > On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana 
> > 
> > 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
> > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2f
> > > > hi
> > > > .im%2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c3
> > > > 79
> > > > bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47
> > > > %7 c1=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > > >
> > > > On Tue, Apr 5, 2016 at 6:48 PM, Carlos Santana 
> > > > 
> > > > wrote:
> > > >
> > > > > Simon, I was not able to find a JIRA, I created a new JIRA [1] 
> > > > > to
> > > enhance
> > > > > plugin.xml to allow  to add attributes
> > > > >
> > > > > [1]:
> > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f
> > > > > %2 
> > > > > fissues.apache.org%2fjira%2fbrowse%2fCB-11023=01%7c01%7cn
> > > > > ik
> > > > > hilkh%40microsoft.com%7c379bf4c2dae4454ee13008d369539a2b%7c72f
> > > > > 98
> > > > > 8bf86f141af91ab2d7cd011db47%7c1=qdtAQlq84gu4iot23V%2bdCy
> > > > > w4
> > > > > yAtardggCzFXJutYDzU%3d
> > > > >
> > > > >
> > > > > On 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Karen Tran]

@Vladimir, in your suggestion, is this what you were going for? Being able
to add multiple attributes to any direct children node of the parent?








Regards,
Karen Tran

On Thu, Apr 21, 2016 at 3:58 AM, Vladimir Kotikov (Akvelon) <
v-vlk...@microsoft.com> wrote:

> Another proposal about syntax which allows to specify multiple attributes
> at once and does not require parsing attributes from plain text:
>
> 
> 
> 
>
> Also I've took a quick look at the implementation and it looks good apart
> from one minor issue - when we're grafting attributes we probably do not
> need to create an element to graft attributes to if it doesn't exist,
> otherwise after adding and then removing  the plugin created xml element
> will remain in modified file.
>
> -
> Best regards, Vladimir
>
> -Original Message-
> From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com]
> Sent: Thursday, April 21, 2016 3:24 AM
> To: dev@cordova.apache.org
> Subject: RE: [Android] Need a solution to config.xml and
> AndroidManifest.xml feature requests
>
> Oh great! I have not taken a close look at the implementation itself.
> Perhaps you already had some of this in mind.
>
> As for the syntax for changing attributes, I would recommend something
> like this:
>
>  attributeName="android:name" attirbuteValue="MyApplication"/>
>
> Also, we should always prioritize config.xml edits over plugin.xml (giving
> the end developer the full control). In case of conflicts, between plugins
> & config.xml we should warn and mention which one we picked (config.xml)
>
> Thanks,
> Nikhil
>
> -Original Message-
> From: Karen Tran [mailto:ktop...@gmail.com]
> Sent: Wednesday, April 20, 2016 12:40 PM
> To: dev@cordova.apache.org
> Subject: Re: [Android] Need a solution to config.xml and
> AndroidManifest.xml feature requests
>
> Hi,
>
> I made an attempt at the functionality of being able to add attributes
> with the config-file tag. It's not completed yet, but I wanted to get some
> review before I proceed.
> With my changes, you can add an attribute through the config-file tag in
> plugin.xml when the plugin is added, and when the plugin is removed, the
> attribute will get removed.
> https://github.com/ktop/cordova-lib/tree/cb-11023
>
> This is what the tag looks like:
> * parent="/manifest/application" attr="true">*
> *android:name="MyApplication"*
>
> **
>
> Added *attr* attribute to let Config-File know that we want to add an
> attribute. Default should be false and will expect an element rather than
> an attribute.
>
> One issue I have is that it can only add 1 attribute per config-file tag.
> This is the part that I still need to fix.
>
> Can someone review what I have so far?
>
> Thanks,
> Karen
>
> On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald  >
> wrote:
>
> > 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
> > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%
> > 2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2dae
> > 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1=TvJ
> > lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> >
> > On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana 
> > 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
> > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi
> > > > .im%2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379
> > > > bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7
> > > > c1=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > > >
> > > > On Tue, Apr 5, 2016 at 6:48 PM, Carlos Santana
> > > > 
> > > > wrote:
> > > >
> > > > > Simon, I was not able to find a JIRA, I created a new JIRA [1]
> > > > > to
> > > enhance
> > > > > plugin.xml to allow  to add attributes
> > > > >
> > > > > [1]:
> > > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2
> > > > > fissues.apache.org%2fjira%2fbrowse%2fCB-11023=01%7c01%7cnik
> > > > > hilkh%40microsoft.com%7c379bf4c2dae4454ee13008d369539a2b%7c72f98
> > > > > 8bf86f141af91ab2d7cd011db47%7c1=qdtAQlq84gu4iot23V%2bdCyw4
> > > > > yAtardggCzFXJutYDzU%3d
> > > > >
> > > > >
> > > > > 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
> > > > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%
> > > > > > 

RE: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Vladimir Kotikov (Akvelon)]

Another proposal about syntax which allows to specify multiple attributes at 
once and does not require parsing attributes from plain text: 





Also I've took a quick look at the implementation and it looks good apart from 
one minor issue - when we're grafting attributes we probably do not need to 
create an element to graft attributes to if it doesn't exist, otherwise after 
adding and then removing  the plugin created xml element will remain in 
modified file.

-
Best regards, Vladimir

-Original Message-
From: Nikhil Khandelwal [mailto:nikhi...@microsoft.com] 
Sent: Thursday, April 21, 2016 3:24 AM
To: dev@cordova.apache.org
Subject: RE: [Android] Need a solution to config.xml and AndroidManifest.xml 
feature requests

Oh great! I have not taken a close look at the implementation itself. Perhaps 
you already had some of this in mind.

As for the syntax for changing attributes, I would recommend something like 
this:



Also, we should always prioritize config.xml edits over plugin.xml (giving the 
end developer the full control). In case of conflicts, between plugins & 
config.xml we should warn and mention which one we picked (config.xml)

Thanks,
Nikhil

-Original Message-
From: Karen Tran [mailto:ktop...@gmail.com]
Sent: Wednesday, April 20, 2016 12:40 PM
To: dev@cordova.apache.org
Subject: Re: [Android] Need a solution to config.xml and AndroidManifest.xml 
feature requests

Hi,

I made an attempt at the functionality of being able to add attributes with the 
config-file tag. It's not completed yet, but I wanted to get some review before 
I proceed.
With my changes, you can add an attribute through the config-file tag in 
plugin.xml when the plugin is added, and when the plugin is removed, the 
attribute will get removed.
https://github.com/ktop/cordova-lib/tree/cb-11023

This is what the tag looks like:
**
*android:name="MyApplication"*

**

Added *attr* attribute to let Config-File know that we want to add an 
attribute. Default should be false and will expect an element rather than an 
attribute.

One issue I have is that it can only add 1 attribute per config-file tag.
This is the part that I still need to fix.

Can someone review what I have so far?

Thanks,
Karen

On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald 
wrote:

> 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
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%
> 2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2dae
> 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1=TvJ
> lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
>
> On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana 
> 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
> > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi
> > > .im%2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379
> > > bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7
> > > c1=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > >
> > > On Tue, Apr 5, 2016 at 6:48 PM, Carlos Santana 
> > > 
> > > wrote:
> > >
> > > > Simon, I was not able to find a JIRA, I created a new JIRA [1] 
> > > > to
> > enhance
> > > > plugin.xml to allow  to add attributes
> > > >
> > > > [1]: 
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2
> > > > fissues.apache.org%2fjira%2fbrowse%2fCB-11023=01%7c01%7cnik
> > > > hilkh%40microsoft.com%7c379bf4c2dae4454ee13008d369539a2b%7c72f98
> > > > 8bf86f141af91ab2d7cd011db47%7c1=qdtAQlq84gu4iot23V%2bdCyw4
> > > > yAtardggCzFXJutYDzU%3d
> > > >
> > > >
> > > > 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
> > > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%
> > > > > 2fhi.im%2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.c
> > > > > om%7c379bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d
> > > > > 7cd011db47%7c1=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5Q
> > > > > ANRrH4%3d
> > > > >
> > > > > 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 
> > 

RE: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Nikhil Khandelwal]

Oh great! I have not taken a close look at the implementation itself. Perhaps 
you already had some of this in mind.

As for the syntax for changing attributes, I would recommend something like 
this:



Also, we should always prioritize config.xml edits over plugin.xml (giving the 
end developer the full control). In case of conflicts, between plugins & 
config.xml we should warn and mention which one we picked (config.xml)

Thanks,
Nikhil

-Original Message-
From: Karen Tran [mailto:ktop...@gmail.com] 
Sent: Wednesday, April 20, 2016 12:40 PM
To: dev@cordova.apache.org
Subject: Re: [Android] Need a solution to config.xml and AndroidManifest.xml 
feature requests

Hi,

I made an attempt at the functionality of being able to add attributes with the 
config-file tag. It's not completed yet, but I wanted to get some review before 
I proceed.
With my changes, you can add an attribute through the config-file tag in 
plugin.xml when the plugin is added, and when the plugin is removed, the 
attribute will get removed.
https://github.com/ktop/cordova-lib/tree/cb-11023

This is what the tag looks like:
**
*android:name="MyApplication"*

**

Added *attr* attribute to let Config-File know that we want to add an 
attribute. Default should be false and will expect an element rather than an 
attribute.

One issue I have is that it can only add 1 attribute per config-file tag.
This is the part that I still need to fix.

Can someone review what I have so far?

Thanks,
Karen

On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald 
wrote:

> 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
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%
> 2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379bf4c2dae
> 4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7c1=TvJ
> lf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
>
> On Tue, Apr 5, 2016 at 6:51 PM, Carlos Santana 
> 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
> > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi
> > > .im%2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.com%7c379
> > > bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d7cd011db47%7
> > > c1=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5QANRrH4%3d
> > >
> > > On Tue, Apr 5, 2016 at 6:48 PM, Carlos Santana 
> > > 
> > > wrote:
> > >
> > > > Simon, I was not able to find a JIRA, I created a new JIRA [1] 
> > > > to
> > enhance
> > > > plugin.xml to allow  to add attributes
> > > >
> > > > [1]: 
> > > > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2
> > > > fissues.apache.org%2fjira%2fbrowse%2fCB-11023=01%7c01%7cnik
> > > > hilkh%40microsoft.com%7c379bf4c2dae4454ee13008d369539a2b%7c72f98
> > > > 8bf86f141af91ab2d7cd011db47%7c1=qdtAQlq84gu4iot23V%2bdCyw4
> > > > yAtardggCzFXJutYDzU%3d
> > > >
> > > >
> > > > 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
> > > > > https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%
> > > > > 2fhi.im%2fsimonmacdonald=01%7c01%7cnikhilkh%40microsoft.c
> > > > > om%7c379bf4c2dae4454ee13008d369539a2b%7c72f988bf86f141af91ab2d
> > > > > 7cd011db47%7c1=TvJlf2LDyl%2bfSbRMDPjmLe%2fMBQf7PnAzRao5Q
> > > > > ANRrH4%3d
> > > > >
> > > > > 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 
> > > > > > 
> 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 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Karen Tran]

Hi,

I made an attempt at the functionality of being able to add attributes with
the config-file tag. It's not completed yet, but I wanted to get some
review before I proceed.
With my changes, you can add an attribute through the config-file tag in
plugin.xml when the plugin is added, and when the plugin is removed, the
attribute will get removed.
https://github.com/ktop/cordova-lib/tree/cb-11023

This is what the tag looks like:
**
*android:name="MyApplication"*

**

Added *attr* attribute to let Config-File know that we want to add an
attribute. Default should be false and will expect an element rather than
an attribute.

One issue I have is that it can only add 1 attribute per config-file tag.
This is the part that I still need to fix.

Can someone review what I have so far?

Thanks,
Karen

On Tue, Apr 5, 2016 at 6:54 PM, Simon MacDonald 
wrote:

> 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 
> 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 
> > > wrote:
> > >
> > > > Simon, I was not able to find a JIRA, I created a new JIRA [1] to
> > enhance
> > > > plugin.xml to allow  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 
> 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
> > > > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Simon MacDonald]

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  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 
> 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 
> > wrote:
> >
> > > Simon, I was not able to find a JIRA, I created a new JIRA [1] to
> enhance
> > > plugin.xml to allow  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  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
> > > > > > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Alexis Kofman]

Haha, so you can merge all the waiting PR !!

On Wed, Apr 6, 2016 at 12:51 AM, Carlos Santana 
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 
> 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 
> > wrote:
> >
> > > Simon, I was not able to find a JIRA, I created a new JIRA [1] to
> enhance
> > > plugin.xml to allow  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  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
> > > > > > > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Carlos Santana]

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 
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 
> wrote:
>
> > Simon, I was not able to find a JIRA, I created a new JIRA [1] to enhance
> > plugin.xml to allow  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 
> > > 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  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  >:
> > > > >
> > > > > > 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 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Simon MacDonald]

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  wrote:

> Simon, I was not able to find a JIRA, I created a new JIRA [1] to enhance
> plugin.xml to allow  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 
> > 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  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 :
> > > >
> > > > > 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>
> > > > > > > > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Carlos Santana]

Simon, I was not able to find a JIRA, I created a new JIRA [1] to enhance
plugin.xml to allow  to add attributes

[1]: https://issues.apache.org/jira/browse/CB-11023


On Wed, Mar 23, 2016 at 11:30 AM Simon MacDonald 
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 
> 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  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 :
> > >
> > > > 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" 
> wrote:
> > > > > > > >
> > > > > > > > >I like having the same xml fragments in config.xml as we use
> > in
> > > > > > > plugin.xml
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > > > > > > > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Simon MacDonald]

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 
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  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 :
> >
> > > 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"  wrote:
> > > > > > >
> > > > > > > >I like having the same xml fragments in config.xml as we use
> in
> > > > > > plugin.xml
> > > > > > > >
> > > > > > > >
> > > > > > > > > > > > > > >parent="/manifest/application">
> > > > > > > >https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > > > > > > "
> > > > > > > >android:label="@string/app_name">
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >We will need to address precedence, as a plugin.xml and
> > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Carlos Santana]

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  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 
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 :
>
> > 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"  wrote:
> > > > > >
> > > > > > >I like having the same xml fragments in config.xml as we use in
> > > > > plugin.xml
> > > > > > >
> > > > > > >
> > > > > > > > > > > > >parent="/manifest/application">
> > > > > > >https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > > > > > "
> > > > > > >android:label="@string/app_name">
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >We will need to address precedence, as a plugin.xml and
> config.xml
> > > can
> > > > > > >disagree.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >> On Mar 21, 2016, at 12:46 PM, Shazron 
> > wrote:
> > > > > > >>
> > > > > > >> Continuing on Simon's point, we already have duplication of
> > > entries
> > > > > > >> for preference tags in
> > > > > >
> > > > >
> > > >
> > >
> >
> 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[julio cesar sanchez]

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 :

> 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  >:
> > >
> > > > 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"  wrote:
> > > > >
> > > > > >I like having the same xml fragments in config.xml as we use in
> > > > plugin.xml
> > > > > >
> > > > > >
> > > > > > > > > > >parent="/manifest/application">
> > > > > >https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > > > > "
> > > > > >android:label="@string/app_name">
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >We will need to address precedence, as a plugin.xml and config.xml
> > can
> > > > > >disagree.
> > > > > >
> > > > > >
> > > > > >
> > > > > >> On Mar 21, 2016, at 12:46 PM, Shazron 
> 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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=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
> > > > > >>  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 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Alexis Kofman]

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 
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 :
> >
> > > 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 
> > > 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"  wrote:
> > > >
> > > > >I like having the same xml fragments in config.xml as we use in
> > > plugin.xml
> > > > >
> > > > >
> > > > > > > > >parent="/manifest/application">
> > > > >https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > > > "
> > > > >android:label="@string/app_name">
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >We will need to address precedence, as a plugin.xml and config.xml
> can
> > > > >disagree.
> > > > >
> > > > >
> > > > >
> > > > >> On Mar 21, 2016, at 12:46 PM, Shazron  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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=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
> > > > >>  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:
> > > > >>>
> > > > >>> > > > >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
> > 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Simon MacDonald]

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  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 :
>
> > 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 
> > 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"  wrote:
> > >
> > > >I like having the same xml fragments in config.xml as we use in
> > plugin.xml
> > > >
> > > >
> > > > > > >parent="/manifest/application">
> > > >https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > > "
> > > >android:label="@string/app_name">
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >We will need to address precedence, as a plugin.xml and config.xml can
> > > >disagree.
> > > >
> > > >
> > > >
> > > >> On Mar 21, 2016, at 12:46 PM, Shazron  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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=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
> > > >>  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:
> > > >>>
> > > >>> > > >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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=%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 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[julio cesar sanchez]

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 :

> 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 
> 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"  wrote:
> >
> > >I like having the same xml fragments in config.xml as we use in
> plugin.xml
> > >
> > >
> > > > >parent="/manifest/application">
> > >https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > "
> > >android:label="@string/app_name">
> > >
> > >
> > >
> > >
> > >
> > >
> > >We will need to address precedence, as a plugin.xml and config.xml can
> > >disagree.
> > >
> > >
> > >
> > >> On Mar 21, 2016, at 12:46 PM, Shazron  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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=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
> > >>  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:
> > >>>
> > >>> > >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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=%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
> 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Simon MacDonald]

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 
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"  wrote:
>
> >I like having the same xml fragments in config.xml as we use in plugin.xml
> >
> >
> > >parent="/manifest/application">
> >https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> "
> >android:label="@string/app_name">
> >
> >
> >
> >
> >
> >
> >We will need to address precedence, as a plugin.xml and config.xml can
> >disagree.
> >
> >
> >
> >> On Mar 21, 2016, at 12:46 PM, Shazron  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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=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
> >>  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:
> >>>
> >>> >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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=%2fTHN2714ZxbZ7blck0JpCvz2U%2fLEFSzVDQP2mTLSMm8%3d
> >>>
> >>> On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll 
> >>> 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" 
> a
>  écrit :
> 
> > I think we should add the config-file tag 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Parashuram N]

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"  wrote:

>I like having the same xml fragments in config.xml as we use in plugin.xml
>
>
>parent="/manifest/application">
> android:name="https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d;
>android:label="@string/app_name">
>
>
>
>
>
>
>We will need to address precedence, as a plugin.xml and config.xml can
>disagree.
>
>
>
>> On Mar 21, 2016, at 12:46 PM, Shazron  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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=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
>>  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:
>>>
>>>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=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1=%2fTHN2714ZxbZ7blck0JpCvz2U%2fLEFSzVDQP2mTLSMm8%3d
>>>
>>> On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll 
>>> 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"  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 :
>
>> Given that we are now using Gradle for builds, could these simply be

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Jesse]

I like having the same xml fragments in config.xml as we use in plugin.xml










We will need to address precedence, as a plugin.xml and config.xml can
disagree.



> On Mar 21, 2016, at 12:46 PM, Shazron  wrote:
>
> Continuing on Simon's point, we already have duplication of entries
> for preference tags in https://issues.apache.org/jira/browse/CB-9264
> 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
>  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:
>>
>>> 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
>> http://hi.im/simonmacdonald
>>
>> On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll 
>> 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"  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 :

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

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Shazron]

Continuing on Simon's point, we already have duplication of entries
for preference tags in https://issues.apache.org/jira/browse/CB-9264
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
 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:
>
>  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
> http://hi.im/simonmacdonald
>
> On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll 
> 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"  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 :
>> >
>> > > 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 
>> > > 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=01%7c01%7cpanarasi%40micr
>> > osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
>> > cd011db47%7c1=f3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5OA
>> > y9RMA%3d
>> > >

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Simon MacDonald]

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:



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
http://hi.im/simonmacdonald

On Mon, Mar 21, 2016 at 4:52 PM, Richard Knoll 
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"  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 :
> >
> > > 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 
> > > 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=01%7c01%7cpanarasi%40micr
> > osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > cd011db47%7c1=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=01%7c01%7cpanarasi%40micr
> > osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > cd011db47%7c1=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d
> > >
> > >
> > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > s.apache.org%2fjira%2fbrowse%2fCB-8159=01%7c01%7cpanarasi%40micro
> > soft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > d011db47%7c1=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
> > >
> > >
> > 

RE: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Richard Knoll]

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"  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 :
>
> > 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 
> > 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=01%7c01%7cpanarasi%40micr
> osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> cd011db47%7c1=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=01%7c01%7cpanarasi%40micr
> osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> cd011db47%7c1=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> s.apache.org%2fjira%2fbrowse%2fCB-8159=01%7c01%7cpanarasi%40micro
> soft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> d011db47%7c1=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> s.apache.org%2fjira%2fbrowse%2fCB-10755=01%7c01%7cpanarasi%40micr
> osoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> cd011db47%7c1=PeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> s.apache.org%2fjira%2fbrowse%2fCB-8976=01%7c01%7cpanarasi%40micro
> soft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> d011db47%7c1=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 

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Alexis Kofman]

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"  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 :
>
> > 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 
> > 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%2fissues.apache.org%2fjira%2fbrowse%2fCB-10894=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=f3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5OAy9RMA%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10917=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-8159=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10755=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=PeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-8976=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=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?
> >
>

Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[julio cesar sanchez]

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 :

> 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 
> 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%2fissues.apache.org%2fjira%2fbrowse%2fCB-10894=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=f3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5OAy9RMA%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10917=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-8159=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10755=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=PeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-8976=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=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?
>

RE: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests

[Parashuram N]

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 
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%2fissues.apache.org%2fjira%2fbrowse%2fCB-10894=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=f3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5OAy9RMA%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10917=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-8159=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-10755=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=PeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-8976=01%7c01%7cpanarasi%40microsoft.com%7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7cd011db47%7c1=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?