cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Plugin / Platform mismatch problems
Date Tue, 30 Jul 2013 01:00:59 GMT
Compatibility with npm sounds great and I fully support it.

We still need to be conscious of old plugin.xml compatibility, though

Interesting thing there is putting plugman or cordova-cli into plugins'
package.json as dependencies, which would give you all tools you need to
do cool things like auto-installation

On 7/29/13 4:55 PM, "Brian LeRoux" <> wrote:

>Ya, the Node characters in this story that I'm talking w/ are dshaw,
>mikeal, izs, and joemccann. All pushing we go this route and YES its
>super easier than it sounds. =P
>Agree on discovery getting a little harder but this isn't an exclusive
>move but rather an additive operation. That is to say, they want us to
>have a compatibility but in no way are saying we use the npm registry
>for our core plugins.
>So: package.json, install, and uninstall are the tricks to this pony.
>I think we can easily get consensus for moving to package.json using
>our current technique. I'll talk to them further about the
>install/uninstall business.
>The next version of Node will be shipping w/ the npm registry included
>so this is actually rather cool for us as the install would become:
>install node.
>On Mon, Jul 29, 2013 at 7:41 PM, Anis KADRI <> wrote:
>> I spoke with @dshaw about this and told him why it was (currently) not
>> an option for Cordova.
>> Specifically (un)install actions and dependency management are
>> different. It seems like a a lot of overhead to get npm to do what
>> plugman (un)install does.
>> Everything else is pretty much the same and moving from plugin.xml to
>> package.json won't hurt us I don't think. I guess we wouldn't be able
>> to do XSLTs to validate documents but...other than that it would be a
>> logical move.
>> The other thing too is that npm is mainly for nodejs and/or javascript
>> packages and getting Cordova plugins in there can make search and
>> discovery harder. There are currently 36,472 NPMs as of this writing.
>> The counter-argument to this is that there are npm modules that use
>> native codes to execute. Some of them even require some third-party
>> interpreters (Ruby, Python, etc...).
>> On Mon, Jul 29, 2013 at 4:28 PM, Brian LeRoux <> wrote:
>>> I have a parallel conversation rolling w/ the node guys and they're
>>> hoping to convince us to move everything to the npm registry itself.
>>> (Or at least be compatible to do so.)
>>> I think this is a worthwhile goal but it does mean:
>>> - plugin.xml gets either deprecated for package.json or we continue
>>> tool that impedance mismatch
>>> - install on the npm side needs to learn about cordova (yes issac is
>>> open to this!)
>>> Did I miss anything Anis?
>>> Thoughts [larger group]?
>>> On Mon, Jul 29, 2013 at 6:06 PM, Anis KADRI <>
>>>> Agree.
>>>> For the last point. There is a <keywords> tag added to the spec to
>>>> facilitate search. Has to be added by plugin author.
>>>> I am going to drop the current names for the registry and republish
>>>> them with the new convention. Unless anyone has any objections. We'll
>>>> implement that prefixing right after.
>>>> On Mon, Jul 29, 2013 at 2:55 PM, Filip Maj <> wrote:
>>>>> I think what would work is:
>>>>> - use ids to uniquely identify
>>>>> - prepending org.apache.cordova.core or w/e our core plugin
>>>>>namespace is
>>>>> as a fallback attempt to match makes sense
>>>>> - finally, for discovery/searching, we should do searches vs a
>>>>> <description> field and do our best to enforce good descriptions
>>>>> plugins being submitted to the apache cordova registry
>>>>> On 7/29/13 1:13 PM, "Anis KADRI" <> wrote:
>>>>>>Right but npm registry uses JSON not XML. I think prefixing core
>>>>>>plugins when no package name is provided is a good idea.
>>>>>>On Mon, Jul 29, 2013 at 1:08 PM, Marcel Kinard <>
>>>>>>> That could be accomplished with XSLT. And XPath has basic query
>>>>>>>capability. James Jong and I have skills in those.
>>>>>>> On Jul 26, 2013, at 2:19 PM, Filip Maj <>
>>>>>>>> Ahh yeah. Some kind of at-publish-time conversion of certain
>>>>>>>> fields to json fields?
>>>>>>>> On 7/26/13 10:27 AM, "Anis KADRI" <>
>>>>>>>>> I think XML is not a query friendly language. I suggest
we add an
>>>>>>>>> engine field initially and then add fields as we need
them. I
>>>>>>>>> we won't be needing the bulk of plugin.xml in the registry.
>>>>>>>>>have to
>>>>>>>>> experiment with custom fields still but it seems possible.
I will
>>>>>>>>> report back sometime today.

View raw message