Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cordova iOS Cocoapods Integration for Cocoapods Plugins settings #1256

Open
yinzara opened this issue Sep 12, 2022 · 1 comment
Open

Cordova iOS Cocoapods Integration for Cocoapods Plugins settings #1256

yinzara opened this issue Sep 12, 2022 · 1 comment

Comments

@yinzara
Copy link

yinzara commented Sep 12, 2022

Feature Request

The "cocoapods" elements in the plugin.xml for the ios platform now allows you to modify the generation of the Podfile to include additional pods and sources.

However there is an element of the Podfile specification that is not supported by the current configuration: plugins
https://guides.cocoapods.org/syntax/podfile.html#plugin

This is necessary if your Pod is hosted by Artifactory as you need to use the cocoapods-art plugin to make the pod available to the build.

https://github.com/jfrog/cocoapods-art

This feature would be another config element "<plugin>" within the "<podspec>" element. It would need to support a "name" attribute and an "options" attribute similar to the "options" attribute of the "<pod>" element. Since every plugin could have their own custom options, there is no use in supporting specific options. Just a generic options attribute should be fine.

So for example

<podspec>
  <plugins>
    <plugin name="myPluginName" options=":sources => [ &apos;my_source&apos; ]"/>
    <plugin name="myOtherPlugin" />
  </plugins>
</podspec>

Would generate:

plugin 'myPluginName', :sources => [ 'my_source' ]
plugin 'myOtherPlugin'
@breautek
Copy link
Contributor

options=":sources => [ 'my_source' ]"/>

I think this would be incredibly tedious to author.. especially if there are several options involves or several values that needs to be set. Instead I think we should probably favour a more declarative approach and have a parser/reader build out the podfile string.

I don't really know enough about pods to suggest something that could be powerful enough to handle wide range of options, but given the :<optionName> => [ values...] syntax, it could look something like this:

<podspec>
  <plugins>
    <plugin name="myPluginName">
      <option name="sources">
        <!-- If pods supports different data types, then we could
              use more explicit tags like <string> or <number>, etc.
        -->
        <value>my_source</value>
        <value>my_other_source</value>
      </option>
    </plugin>
    <plugin name="myOtherPlugin" />
  </plugins>
</podspec>

I've made an assumption that option values are comma delimited strings, and I assume if there were more than one option, then they will be comma delimited as well, but the above would be a more declarative approach to handling the options so that you don't need to escape or make use of HTML entities for quotations or other potentially conflicting symbols, what do you think?

plugin 'myPluginName', :sources => [ 'my_source', 'my_other_source' ]
plugin 'myOtherPlugin'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants