cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: config.xml refactoring
Date Wed, 28 Aug 2013 18:56:57 GMT
supporting platforms/ as generated content (aka "build artifact") is
certainly an ultimate goal, but only for the CLI workflow, and even then we
would love to suport fallback to sane actions when users don't see it that
way and do modify platforms/.

Second, a single config.xml shared for all platforms, modified directly by
the user maybe might be possible (may involve <platform> tags or just
whitelisted tag per platform), but I'm not sure thats really what we want:
* Plugins modify it anyway, so its not really the final version
* When we upgrade platforms we may want to add/remove/change default
values, so its better to separate platform defaults from user explicit
choices

-Michal

On Wed, Aug 28, 2013 at 2:30 PM, Gorkem Ercan <gorkem.ercan@gmail.com>wrote:

> We (JBoss Tools) have been playing with ideas on how to work with
> config.xml. One thing we do right now is to have only one config.xml file,
> we try to treat config.xml as a universal way of defining cordova
> applications. We do not have platform versions of config,xml (l think cli
> massages them per platform right now) but rather copy the config.xml to
> platform directory (I guess on CLI this would be at the prepare stage) . I
> think what the developer works with and what gets deployed in the
> application should be same. It prevents any surprises to developer when
> he/she is trying to debug a problem. I guess use case/requirement here is
> not to have config.xml differences between platforms.
>
> As a note we treat platforms/... directory as generated content (and
> regenerate them when needed).
> --
> Gorkem
>
>
> On Wed, Aug 28, 2013 at 1:49 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > So we have several bugs[1][2][3] about fixing the handling of config.xml
> > and of upgrading CLI projects. Upgrading platforms is hard because the
> user
> > might have been modifying files in the platforms/foo directory, and we
> > don't want to go overwriting them. Most of the time the file that's been
> > changed is the platform's config.xml.
> >
> > So we (the Google team) are working on a proposal for rearranging how we
> > handle config.xml files in order to make upgrades easier, and solving
> some
> > of these other problems (splash screens) easier. Also to make the CLI
> > tooling simpler, because currently the platform config.xml file is both
> the
> > input and output of several processes (mainly adding and removing
> plugins,
> > as well as cordova prepare).
> >
> > What we want to know, in writing this proposal is: what use-cases for the
> > config.xml files are there? There seem to be two:
> > 1. Not using CLI, just bin/create and maybe Plugman.
> > 2. Using CLI, and needing to upgrade smoothly from the 3.0 world to 3.1
> > with these changes to the files.
> >
> > Is there anything else we should be thinking about? If not, we'll have
> the
> > proposal sent around tomorrow.
> >
> >
> > Braden
> >
> > [1] https://issues.apache.org/jira/browse/CB-4624
> > [2] https://issues.apache.org/jira/browse/CB-3216
> > [3] https://issues.apache.org/jira/browse/CB-3571
> >
>

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