The purpose of this proposal is to improve CocoaPods support by:
framework
tag usage of type="podspec"
plugin.xml
<podspec> <config> <source url="https://github.com/brightcove/BrightcoveSpecs.git" /> <source url="https://github.com/CocoaPods/Specs.git"/> </config> <pods use-frameworks="true"> <pod name="PromiseKit" /> <pod name="Foobar1" spec="~> 2.0.0" /> <pod name="Foobar2" git="git@github.com:hoge/foobar1.git" /> <pod name="Foobar3" git="git@github.com:hoge/foobar2.git" branch="next" /> <pod name="Foobar4" swift-version="4.1" /> <pod name="Foobar5" swift-version="3.0" /> <pods> </podspec>
<podspec>
<config>
<pods>
<config>
podspec
tag<source>
tag<pods>
podspec
taguse-frameworks
attribute, of which the default value is `` (empty). The value true
means to use.inhibit-all-warnings
attribute, of which the default value is `` (empty). The value true
means to use.<pod>
tag<source>
config
tagurl
attribute<pod>
pods
tagname
spec
tag
branch
commit
configurations
git
http
podspec
path
swift-version
options
The plugin.xml
fie contains:
<pod name="GoogleAnalytics" spec="~> 3.1" />
On prepare, the Podfile
file will become:
pod 'GoogleAnalytics', '~> 3.1'
The plugin.xml
fie contains:
<pod name="Alamofire" path="~/Documents/Alamofire" />
On prepare, the Podfile
file will become:
pod ‘Alamofire’, :path => ‘~/Documents/Alamofire’
The options
attribute value is written in a key-value pair system.
<pod name="Alamofire" options=":git => 'https://github.com/Alamofire/Alamofire.git', :tag => '3.1.1'" />
Because there are so many features that CocoaPods supplies, it would be difficult to keep track of all.
Some of them may also be less likely used over others for example:
:svn
) and its head (:head
):hg
):bzr
).pods.json
Since the current pods.json
file only records each library spec, it must be extended to support the ability to manage the settings of each pod.
{ "SwiftMessages": { "name": "SwiftMessages", "type": "podspec", "spec": "~> 4.1", "count": 1 } }
{ "declarations": { "use_frameworks!" : { "declaration": "use_frameworks!", "count": 1 }, "inhibit_all_warnings!": { "declaration": "inhibit_all_warnings!", "count": 1 } }, "sources": { "https://github.com/CocoaPods/Specs.git": { "source" : "https://github.com/CocoaPods/Specs.git", "count" : 1 }, … }, "libraries": { "SwiftMessages": { "name": "SwiftMessages", "type": "podspec", "spec": "~> 4.1", "swift-version": “4.1", "count": 1 } } }
To support the new ability, the pods.json
file will be broken into three primary sections.
Declarations Section The section will contain the overall Cocoapods declarations. For example: use-framework
.
Sources Section The source section will contain a list of known sources where pods come from. In some situations, a user may have their own private registry which contains private pods.
Libraries Section This section is identical to the original file with the added properties.
count
parameter in the new pods.json
file structure indicates the number of plugins having Podfile settings.Podfile
is modified according to this pods.json
file.count > 0
is added in Podfile.For example
pluginA has
<podspec> <pods> <pod name="Foobar1" spec="~> 2.0.0" /> <pods> </podspec>
pluginB has
<podspec> <pods> <pod name="Foobar1" spec="~> 3.0.0" /> <pods> </podspec>
If the developer adds pluginA and pluginB in this order, the resulting pods.json
becomes
{ "declarations": { }, "sources": { }, "libraries": { "Foobar1": { "name": "Foobar1", "type": "podspec", "spec": "~> 2.0.0", "count": 2 } } }
If there is an old pods.json
file in the project, the file should be automatically updated to the new pods.json.
When the developer removes a plugin, the corresponding count parameter is decreased. If the count becomes zero, the element is removed.
This new feature works only in plugin.xml
, not in config.xml
. This is for avoiding complexity. If we support config.xml
we should detect all changes of config.xml
every time when doing cordova prepare
and find differences with previous config.xml
settings to update pods.json
. This process becomes very complex like a config_munge in cordova-common
where count
does not seem to work well. Supporting only plugin.xml
is rather simple because we should check plugin add
and plugin rm
only.
The framework
tag with type="podspec"
is still available for the compatibility.
<framework src="SwiftMessages" type="podspec" spec="~> 4.1" />
Combining new and old formula in plugin.xml
will update Podfile.
In a later release, we can official remove the old formula compeltely.