cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [Android] Need a solution to config.xml and AndroidManifest.xml feature requests
Date Tue, 05 Apr 2016 22:51:34 GMT
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.macdonald@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 <csantana23@gmail.com>
> wrote:
>
> > Simon, I was not able to find a JIRA, I created a new JIRA [1] to enhance
> > plugin.xml to allow <config-file> to add attributes
> >
> > [1]: https://issues.apache.org/jira/browse/CB-11023
> >
> >
> > On Wed, Mar 23, 2016 at 11:30 AM Simon MacDonald <
> > simon.macdonald@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 <csantana23@gmail.com>
> > > wrote:
> > >
> > > > I agree to enable config.xml to be able to set or override using
> > > > config-file (i.e. any xml file including strings.xml)
> > > > I also think that adding support in config.xml and plugin.xml to edit
> > > > attributes is very helpful, this is exactly what we are doing for one
> > of
> > > > our plugin to add the attribute android:name for <application> and
it
> > > was a
> > > > pain, and I think we still have problems doing it from
> > > > before_plugin_install hook, it would be easier from plugin.xml
> > > >
> > > >
> > > >
> > > > On Tue, Mar 22, 2016 at 10:55 AM julio cesar sanchez <
> > > > jcesarmobile@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.kofman@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.macdonald@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 <
> > > > > > > jcesarmobile@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.macdonald@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
<
> > > > > > panarasi@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" <purplecabbage@gmail.com>
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > >I like having the same xml fragments
in config.xml as we
> > use
> > > > in
> > > > > > > > > plugin.xml
> > > > > > > > > > >
> > > > > > > > > > ><platform name="android">
> > > > > > > > > > >    <config-file target="AndroidManifest.xml"
> > > > > > > > > > >parent="/manifest/application">
> > > > > > > > > > >        <activity android:name="
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=com.foo.Foo&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MPgaRi3qGueHAnmnV6tXJyRlIzQIu6gHxeYTnpiKR9c%3d
> > > > > > > > > > "
> > > > > > > > > > >android:label="@string/app_name">
> > > > > > > > > > >            <intent-filter>
> > > > > > > > > > >            </intent-filter>
> > > > > > > > > > >        </activity>
> > > > > > > > > > >    </config-file>
> > > > > > > > > > ></platform>
> > > > > > > > > > >
> > > > > > > > > > >We will need to address precedence,
as a plugin.xml and
> > > > > config.xml
> > > > > > > can
> > > > > > > > > > >disagree.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >> On Mar 21, 2016, at 12:46 PM, Shazron
<
> > shazron@gmail.com>
> > > > > > wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> Continuing on Simon's point, we
already have
> duplication
> > > of
> > > > > > > entries
> > > > > > > > > > >> for preference tags in
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissues.apache.org%2fjira%2fbrowse%2fCB-9264&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Amj46nGpbpE3scp6sjDw1FemeGton2Hu6YSyQqZNT4M%3d
> > > > > > > > > > >> and a post-processing step does
the removal of dupes.
> > Not
> > > > sure
> > > > > > if
> > > > > > > > this
> > > > > > > > > > >> removal method would be adequate
(as long as the
> desired
> > > tag
> > > > > to
> > > > > > > > > > >> express is written to the config
file *last*)
> > > > > > > > > > >>
> > > > > > > > > > >> On Mon, Mar 21, 2016 at 3:41 PM,
Simon MacDonald
> > > > > > > > > > >> <simon.macdonald@gmail.com>
wrote:
> > > > > > > > > > >>> I agree the config-file is
the way to go but we need
> to
> > > go
> > > > > one
> > > > > > > step
> > > > > > > > > > more
> > > > > > > > > > >>> and enable the changing of
attributes in the config
> > file
> > > > > > instead
> > > > > > > of
> > > > > > > > > > just
> > > > > > > > > > >>> adding lines to AndroidManifest.xml.
For instance,
> the
> > > > first
> > > > > > bug
> > > > > > > > > > CB-10894
> > > > > > > > > > >>> talks about adding a preference
for screen sizes.
> > > > > > > > > > >>>
> > > > > > > > > > >>> The default AndroidManifest.xml
that is created with
> > > > Cordova
> > > > > > > > Android
> > > > > > > > > > will
> > > > > > > > > > >>> add the line:
> > > > > > > > > > >>>
> > > > > > > > > > >>>    <supports-screens android:anyDensity="true"
> > > > > > > > > > >android:largeScreens="true"
> > > > > > > > > > >>> android:normalScreens="true"
> android:resizeable="true"
> > > > > > > > > > >>> android:smallScreens="true"
> > android:xlargeScreens="true"
> > > />
> > > > > > > > > > >>>
> > > > > > > > > > >>> and if you want to make smallScreens="false"
you have
> > no
> > > > way
> > > > > of
> > > > > > > > doing
> > > > > > > > > > it
> > > > > > > > > > >as
> > > > > > > > > > >>> it adds a duplicate line if
you are using the
> > config-file
> > > > way
> > > > > > of
> > > > > > > > > doing
> > > > > > > > > > >>> things. We really need attribute
level granularity in
> > the
> > > > > > > > config-file
> > > > > > > > > > >tag.
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>>
> > > > > > > > > > >>> Simon Mac Donald
> > > > > > > > > > >>>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fhi.im%2fsimonmacdonald&data=01%7c01%7cpanarasi%40microsoft.com%7c79eba6a8336a4e77391d08d3521b3bd2%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2fTHN2714ZxbZ7blck0JpCvz2U%2fLEFSzVDQP2mTLSMm8%3d
> > > > > > > > > > >>>
> > > > > > > > > > >>> On Mon, Mar 21, 2016 at 4:52
PM, Richard Knoll <
> > > > > > > > > riknoll@microsoft.com>
> > > > > > > > > > >>> wrote:
> > > > > > > > > > >>>
> > > > > > > > > > >>>> I agree that config-file
is the way to go. After an
> > > > offline
> > > > > > > > > discussion
> > > > > > > > > > >>>> with Nikhil, Parashu, and
Jason, one question that
> > came
> > > up
> > > > > was
> > > > > > > > > whether
> > > > > > > > > > >all
> > > > > > > > > > >>>> of this native config stuff
belongs in config.xml or
> > > > should
> > > > > be
> > > > > > > > > > separated
> > > > > > > > > > >>>> out. One idea would be
to define separate files for
> > each
> > > > > > > > > configuration
> > > > > > > > > > >file
> > > > > > > > > > >>>> you wish to modify (something
like
> > > > > AndroidManifest.merge.xml).
> > > > > > > > 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.kofman@gmail.com
> ]
> > > > > > > > > > >>>> Sent: Monday, March 21,
2016 1:39 PM
> > > > > > > > > > >>>> To: dev@cordova.apache.org
> > > > > > > > > > >>>> Subject: Re: [Android]
Need a solution to config.xml
> > and
> > > > > > > > > > >>>> AndroidManifest.xml feature
requests
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> Hello all,
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> I agree with Julio that
it is less confusing
> keeping
> > > the
> > > > > same
> > > > > > > > > > mecanism
> > > > > > > > > > >>>> that the one it already
exists with the plugin.xml.
> > > > > > > > > > >>>> Le 21 mars 2016 19:17,
"julio cesar sanchez" <
> > > > > > > > > jcesarmobile@gmail.com>
> > > > > > > > > > a
> > > > > > > > > > >>>> é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 <
> > > > > > > panarasi@microsoft.com
> > > > > > > > >:
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>> Given that we are
now using Gradle for builds,
> could
> > > > these
> > > > > > > > simply
> > > > > > > > > be
> > > > > > > > > > >>>>>> gradle sub-projects
that define an
> > > AndroidManifest.xml,
> > > > > that
> > > > > > > > gets
> > > > > > > > > > >>>>>> merged during Android
build ? One way could be to
> > > > support
> > > > > > > > > specifying
> > > > > > > > > > >>>>>> "sub-projects"
in config.xml, and these changes
> get
> > > > picked
> > > > > > up.
> > > > > > > > > Would
> > > > > > > > > > >>>>>> it work for all
cases ?
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> -----Original Message-----
> > > > > > > > > > >>>>>> From: Joe Bowser
[mailto:bowserj@gmail.com]
> > > > > > > > > > >>>>>> Sent: Monday, March
21, 2016 10:07 AM
> > > > > > > > > > >>>>>> To: dev <dev@cordova.apache.org>
> > > > > > > > > > >>>>>> Subject: [Android]
Need a solution to config.xml
> and
> > > > > > > > > > >>>>>> AndroidManifest.xml
feature requests
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> Hey
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> So, if you've been
paying attention to the JIRA,
> > we've
> > > > > been
> > > > > > > > > getting
> > > > > > > > > > >>>>>> slammed with a
ton of feature requests/bugs
> > regarding
> > > > the
> > > > > > > > Android
> > > > > > > > > > >>>>> Manifest
> > > > > > > > > > >>>>>> where people want
to add a 1:1 mapping between the
> > two
> > > > XML
> > > > > > > > files.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> The thing is that
it's getting out of control, and
> > we
> > > > need
> > > > > > to
> > > > > > > > > find a
> > > > > > > > > > >>>>>> better solution
to this problem.  I'm not sure
> what
> > a
> > > > > better
> > > > > > > > > > >>>>>> solution to this
is, but if you want to see some
> of
> > > the
> > > > > > issues
> > > > > > > > > that
> > > > > > > > > > >>>>>> are related to
this, here's a small list:
> > > > > > > > > > >>>>>
> > > > > > > > > >
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > > > > >>>>> s.apache.org
> > > > > > > > > >
> %2fjira%2fbrowse%2fCB-10894&data=01%7c01%7cpanarasi%40micr
> > > > > > > > > > >>>>> osoft.com
> > > > > > > > > >
> > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > > > > > > >>>>>
> > > > > > > > > >
> > > > > > >
> > > >
> cd011db47%7c1&sdata=f3qD84Rx%2bc%2bDzryeeXDCIX%2bhrCk%2boM%2f26%2fT5OA
> > > > > > > > > > >>>>> y9RMA%3d
> > > > > > > > > > >>>>>
> > > > > > > > > >
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > > > > >>>>> s.apache.org
> > > > > > > > > >
> %2fjira%2fbrowse%2fCB-10917&data=01%7c01%7cpanarasi%40micr
> > > > > > > > > > >>>>> osoft.com
> > > > > > > > > >
> > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > > > > > > >>>>>
> > > > > > > > > >
> > > > > > >
> > > >
> cd011db47%7c1&sdata=I1ycCL25rWlN4uTU%2fPXFBkv1PYXrDeX6dF6%2fMzyNSbE%3d
> > > > > > > > > > >>>>>
> > > > > > > > > >
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > > > > >>>>> s.apache.org
> > > > > > > > > >
> %2fjira%2fbrowse%2fCB-8159&data=01%7c01%7cpanarasi%40micro
> > > > > > > > > > >>>>> soft.com
> > > > > > > > > >
> > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > > > > > > > > > >>>>>
> > > > > > > > >
> > > > >
> d011db47%7c1&sdata=HS3ZRL%2fxY%2fJWZo5eMQPGFO6BS2W03z13va8NV7sZpjo%3d
> > > > > > > > > > >>>>>
> > > > > > > > > >
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > > > > >>>>> s.apache.org
> > > > > > > > > >
> %2fjira%2fbrowse%2fCB-10755&data=01%7c01%7cpanarasi%40micr
> > > > > > > > > > >>>>> osoft.com
> > > > > > > > > >
> > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7
> > > > > > > > > > >>>>>
> > > > > > > > >
> > > > >
> cd011db47%7c1&sdata=PeZms4TWbWqHInf%2fnYYbL3e5o9aB3Ijcl8fQxoUmsgU%3d
> > > > > > > > > > >>>>>
> > > > > > > > > >
> > > > > > >
> > > >
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fissue
> > > > > > > > > > >>>>> s.apache.org
> > > > > > > > > >
> %2fjira%2fbrowse%2fCB-8976&data=01%7c01%7cpanarasi%40micro
> > > > > > > > > > >>>>> soft.com
> > > > > > > > > >
> > > %7c4430fe17c9d94a96f19608d351ab4028%7c72f988bf86f141af91ab2d7c
> > > > > > > > > > >>>>>
> > > > > > >
> d011db47%7c1&sdata=4VoysIEst8o7k3kvkyYu9MeBDF8VZ3q7aG6oLcoCN2w%3d
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> All of these are
either indirectly or directly
> > related
> > > > to
> > > > > > the
> > > > > > > > > > >>>>>> AndroidManifest,
and it's clear that if we just
> > > allowed
> > > > > > people
> > > > > > > > to
> > > > > > > > > > >>>>>> edit an AndroidManifest,
or at least allow
> portions
> > of
> > > > it
> > > > > to
> > > > > > > be
> > > > > > > > > > >>>>>> immutable, we
> > > > > > > > > > >>>>> would
> > > > > > > > > > >>>>>> be better off.
 Obviously, plugins that install
> > > > > third-party
> > > > > > > > > > >>>>>> activities
> > > > > > > > > > >>>>> and
> > > > > > > > > > >>>>>> content providers
would have to edit the manifest,
> > > but I
> > > > > > think
> > > > > > > > > that
> > > > > > > > > > >>>>> things
> > > > > > > > > > >>>>>> are getting out
of hand with the things that
> people
> > > want
> > > > > to
> > > > > > > > > control
> > > > > > > > > > >>>>>> from config.xml.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> What do people
think? Does anyone have a good
> > solution
> > > > to
> > > > > > this
> > > > > > > > > > >problem?
> > > > > > > > > > >>>>>> Are we really abstracting
anything out by
> > duplicating
> > > > the
> > > > > > same
> > > > > > > > > > >>>>>> config in our own
config.xml?
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>
> > > > > > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > > > > > > >>>> To unsubscribe, e-mail:
> > > > dev-unsubscribe@cordova.apache.org
> > > > > > > > > > >>>> For additional commands,
e-mail:
> > > > > dev-help@cordova.apache.org
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > > > >> To unsubscribe, e-mail:
> > > dev-unsubscribe@cordova.apache.org
> > > > > > > > > > >> For additional commands, e-mail:
> > > > dev-help@cordova.apache.org
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alexis Kofman
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message