cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Jong <wjamesj...@gmail.com>
Subject Re: config.xml refactoring
Date Thu, 29 Aug 2013 14:09:56 GMT
Michal,

Yes.  That would be a fairly common scenario for non-CLI users.  I download a new Cordova
version and migrate my app.  In the development cycle, I may also want to have different versions
of the same app.  That could be because of different Cordova versions or even platform versions
(iOS 6 vs iOS 7).  Even using CLI, I am thinking I may still run multiple versions.  Right
now, mainly to keep a consistent version across the platforms & plug-ins.  Maybe that
will go away when we get the versioning strategy figured out.

-James Jong

On Aug 28, 2013, at 5:09 PM, Michal Mocny <mmocny@chromium.org> wrote:

> James,
> 
> I think that sounds like what we've been thinking -- but, why do you expect
> to need to copy something when doing an upgrade?  Is it because you think
> upgrade means re-creating a new workspace (which is kinda true right now)?
> We are hoping to support in-place upgrades, with no copies needed.
> 
> -Michal
> 
> 
> On Wed, Aug 28, 2013 at 4:34 PM, James Jong <wjamesjong@gmail.com> wrote:
> 
>> I think you have covered the common workflows.  Some developers will have
>> their own workflow but it should resemble the bin script method in the end.
>> 
>> What I'd like to see is the ability to have my app's user config.xml (1
>> per platform would be fine) and have defaults for what is not specified
>> there.  The user specified config.xml takes precedence.  So when I upgrade,
>> I just need to copy over the config.xml.
>> 
>> -James Jong
>> 
>> On Aug 28, 2013, at 2:56 PM, Michal Mocny <mmocny@chromium.org> wrote:
>> 
>>> 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
View raw message