cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mefire O. <ommen...@microsoft.com>
Subject RE: platforms/plugins save and restore from config.xml
Date Wed, 14 Jan 2015 00:12:29 GMT
This PR adds support for git-urls to 'cordova platform add' : https://github.com/apache/cordova-lib/pull/148
Please, review.

Thanks,
Mefire

-----Original Message-----
From: Treggiari, Leo [mailto:leo.treggiari@intel.com] 
Sent: Tuesday, January 13, 2015 8:18 AM
To: dev@cordova.apache.org
Subject: RE: platforms/plugins save and restore from config.xml

I agree with always saving and automatically re-fetching sources and platforms when needed.
 With regards to the other conversation going on re: automatic add of a platform, I think
the CLI should automatically do things when it is reasonably unambiguous what the user wants
- e.g. if they explicitly say build for iOS then CLI adds the platform if it is needed.  If
you are on Windows and you say build for iOS, you get an error, which you would even if CLI
had allowed you to add the platform - e.g. for a cross platform, multi-developer scenario.

If save/restore are 'optional', then as others have pointed out, other problems cannot be
solved unless the user has used the save and restore command/options.  I don't want my IDE
to be saying:  "didn't I tell you that you need to use the save/restore command options if
you want to do any operations outside of the IDE!".

Leo

-----Original Message-----
From: agrieve@google.com [mailto:agrieve@google.com] On Behalf Of Andrew Grieve
Sent: Tuesday, January 13, 2015 6:57 AM
To: Gorkem Ercan
Cc: dev; Andrew Grieve; Michael Brooks
Subject: Re: platforms/plugins save and restore from config.xml

Saving all the time certainly would make this simpler. If we save all of the time, we can
also make uninstall a part of prepare. E.g. If users edits their config.xml and removes a
<plugin>, then prepare can detect that and plugman uninstall it before building. If
we don't always save, then editing your config.xml wouldn't be that meaningful unless you
delete & recreate platforms every time.

On Mon, Jan 12, 2015 at 10:29 PM, Gorkem Ercan <gorkem.ercan@gmail.com>
wrote:

>
>
> On 12 Jan 2015, at 22:09, Andrew Grieve wrote:
>
>  Related to this, but maybe can be discussed outside of the doc just fine:
>>
>> https://issues.apache.org/jira/browse/CB-4275
>>
>> Right now when we add a new platform, we do a for-each on directories 
>> within plugins/ and add them as well. This causes all plugins to wind 
>> up as top-level plugins even when they are dependent plugins on 
>> existing platforms.
>>
>> Having plugins listed in config.xml, I think it would make sense to 
>> change this logic to plugin add based on plugins within config.xml 
>> rather than directories that exist within plugins. We could 
>> potentially still add all of them if no plugins are listed in config.xml for backwards
compat.
>>
>>
> Related to that, I was looking at CB-8278[1] this bug not only causes 
> the variables to be lost also it causes the top-level plugin info to 
> vanish as well.
> We could also fix this problem easier too if we are saving plugins to 
> config.xml all the time. Which means no save command or --save.
>
> [1] https://issues.apache.org/jira/browse/CB-8278
>
>
>
>>
>> On Mon, Jan 12, 2015 at 9:19 PM, Andrew Grieve <agrieve@chromium.org>
>> wrote:
>>
>>  Thanks for putting the doc together. Added some comments to it.
>>>
>>> On Mon, Jan 12, 2015 at 5:39 PM, Mefire O. <ommenjik@microsoft.com>
>>> wrote:
>>>
>>>  Google docs link :
>>>> https://docs.google.com/document/d/1qKjhzSf48ybGg2GFZPtjXP8dkF4Z5
>>>> Jnc7FU41V3-jFc/edit
>>>>
>>>> Thanks,
>>>> Mefire
>>>>
>>>> -----Original Message-----
>>>> From: Mefire O. [mailto:ommenjik@microsoft.com]
>>>> Sent: Monday, January 12, 2015 2:12 PM
>>>> To: dev@cordova.apache.org
>>>> Cc: Michael Brooks
>>>> Subject: RE: platforms/plugins save and restore from config.xml
>>>>
>>>> Here's what I propose, let me know what you think :
>>>>
>>>> 'cordova platform add'
>>>>      * No -save flag, No 'autosave' setting in 
>>>> project_dir/.cordova/config.json
>>>>              1. 'cordova platform add android' => restores the 
>>>> android platform from config.xml. If config.xml doesn't have any 
>>>> android engine, falls back to using the pinned CLI version.
>>>>      * With -save flag or 'autosave' setting in 
>>>> project_dir/.cordova/config.json
>>>>              1. 'cordova platform add 
>>>> https://github.com/apache/cordova-android.git -save' => clones the 
>>>> git repo and adds the android platform to the project, then updates 
>>>> config.xml and point its version to the specified git-url.
>>>>              2. 'cordova platform add android@ 
>>>> https://github.com/apache/cordova-android.git -save' => clones the 
>>>> git repo and adds the android platform to the project, then updates 
>>>> config.xml and point its version to the specified git-url.
>>>>              3. 'cordova platform add C:/path/to/android/platform 
>>>> -save' => adds the android platform to the project, then updates 
>>>> config.xml and point its version to the specified folder location.
>>>>      * --Save flag is used in CLI-based workflows, and 'autosave'
>>>> (project_dir/.cordova/config.json) is used in IDE-based workflows.
>>>>
>>>> 'cordova save platforms'
>>>>      In its current behavior, 'cordova save platforms' retrieves 
>>>> all the platforms currently installed on the project, and saves 
>>>> them to config.xml. However, unlike 'cordova save plugins', it does 
>>>> not save the source of the platform (i.e: git-url, folder 
>>>> location), it only saves the version. This behavior is different 
>>>> from the one that 'cordova save plugins' implements.
>>>>      * 'cordova save platforms'  => it should retrieve the sources 
>>>> of all the installed platforms from .fetch.json, and save them in 
>>>> config.xml.
>>>> This requires making changes to the way that 'cordova platform add'
>>>> works,
>>>> it should always save the source in .fetch.json.
>>>>      * In case of conflict with the config.xml, 'cordova save 
>>>> platforms' should error out. The -force option shall be used if we 
>>>> want it to override config.xml content.
>>>>
>>>> 'cordova restore platforms'
>>>>      It reads the config.xml file and install all the platforms 
>>>> specified there.
>>>>
>>>> 'cordova save'
>>>>      Saves all installed platforms and plugins into config.xml
>>>>
>>>> 'cordova restore'
>>>>      Restores all platforms and plugins from config.xml. similar to 
>>>> 'npm install'.
>>>>
>>>> Here the link to the google docs :
>>>>
>>>> Thanks,
>>>> Mefire
>>>>
>>>> -----Original Message-----
>>>> From: Parashuram N (MS OPEN TECH) [mailto:panarasi@microsoft.com]
>>>> Sent: Friday, January 9, 2015 1:09 PM
>>>> To: dev@cordova.apache.org
>>>> Cc: Michael Brooks
>>>> Subject: Re: platforms/plugins save and restore from config.xml
>>>>
>>>> Regarding save - I think automatic save could be an issue for folks 
>>>> who want to "try out" experimental platforms, or pick up platforms 
>>>> from git URIs or master branches. What would happen in that case? 
>>>> May be that's is why npm --save exists in the first place.
>>>>
>>>> Where to save - For making progress, looks like we will also have 
>>>> to finalize if it will be persisted in config.xml or in 
>>>> package.json. Most IDEs will not use the --save option, but may 
>>>> choose to directly persist in the required file when a platform is 
>>>> added using a GUI.
>>>>
>>>> Regarding restore - automatic restore makes a lot of sense. Does 
>>>> mefire's PR not cover that ?
>>>>
>>>> From: Chuck Lantz<mailto:clantz@microsoft.com>
>>>> Sent: ?Friday?, ?January? ?9?, ?2015 ?12?:?43? ?PM
>>>> To: dev@cordova.apache.org<mailto:dev@cordova.apache.org>
>>>> Cc: Michael Brooks<mailto:mbrooks@adobe.com>
>>>>
>>>> +1 on automating.
>>>>
>>>> That's why Mefire's PR for platform add just uses the version 
>>>> information in config.xml if it is present.  I think the idea 
>>>> behind "--save" was to make this npm-like so that if a value is 
>>>> already in config.xml, then you can also update it by specifying a 
>>>> different version and "saving" it.
>>>> (Similar to how "npm install cordova@4.1.2 --save" would update 
>>>> package.json in the directory you're executing the command even if 
>>>> an earlier version was present). He mentioned the two PRs on the "--save"
>>>> for
>>>> platform earlier in the this thread.
>>>>
>>>> As an improvement it could just "save" by default if there is 
>>>> nothing present in config.xml.  Personally I'd always use "--save".  
>>>> I also agree what we do for platforms we should likely do for 
>>>> plugins too.
>>>>
>>>> Now, we had originally said in a hangout that "config.xml" should 
>>>> contain "app stuff" and that platform and plugin versions and 
>>>> preferences/params qualified as app stuff.  We could certainly go 
>>>> towards package.json (or something package.json-like) since that's 
>>>> really what we're trying to emulate here at the end of the day I 
>>>> think.  However, I also thought we said that config.xml was too 
>>>> engrained to move away from it (though clearly the web as a whole 
>>>> is moving towards the W3C app manifest).
>>>>
>>>> If we don't use config.xml, it definitely needs to be a document at 
>>>> the root level not under ".cordova" since you should clearly check 
>>>> it into source control and it shouldn't be hidden. It's details 
>>>> about the app not how the CLI should behave.
>>>>
>>>> -Chuck
>>>>
>>>> -----Original Message-----
>>>> From: Josh Soref [mailto:jsoref@blackberry.com]
>>>> Sent: Friday, January 9, 2015 11:26 AM
>>>> To: dev@cordova.apache.org
>>>> Cc: Michael Brooks
>>>> Subject: Re: platforms/plugins save and restore from config.xml
>>>>
>>>> Leo wrote:
>>>>
>>>>> I had asked some questions about save and restore a while back
>>>>>
>>>>
>>>>  One of my biggest questions was why would these commands be an option?
>>>>>
>>>>
>>>> I can't think of any reasons.
>>>>
>>>>  What I'm looking for, as soon as possible, is that Cordova 'project'
>>>>> metadata is stored logically and consistently so that the CLI and 
>>>>> multiple IDEs could simultaneously work on the same project and 
>>>>> know about what each other have done wrt. adding/removing 
>>>>> plugins/platforms/etc.
>>>>>
>>>>
>>>> Seems reasonable
>>>>
>>>>  Does removing experimental advance that goal or does it, as Michal
>>>>> says, put obstacles in the path of getting there by requiring long 
>>>>> term support of an incomplete and possibly confusing (more 
>>>>> options?) solution?
>>>>>
>>>>
>>>> I think Michal is right.
>>>>
>>>> It probably makes more sense to integrate the code behind 
>>>> save/restore into (platform|plugin) add and (something) so that it 
>>>> automatically just works.
>>>>
>>>> I'm not sure offhand what 'restore' would look like in a such a 
>>>> model though...
>>>> Also worth considering is the recent request for `cordova run 
>>>> not-installed-platform`
>>>>
>>>> `cordova run not-installed-platform` (CB-8283) should honor the 
>>>> values from `cordova platform save`
>>>>
>>>> That might be the replacement for 'restore', although it probably 
>>>> isn't ideal...
>>>>
>>>> -------------------------------------------------------------------
>>>> -- 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
>>>>
>>>>
>>>>
>>>
B KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB  [  X  ܚX KK[XZ[
 ] ][  X  ܚX P ܙݘK \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
 ] Z[ ܙݘK \X K ܙ B
Mime
View raw message