incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 18:16:15 GMT
Biggest question is how to document. My thinking is that we want to
specify the PluginPackage so that PluginInstall works. So the docs
would read like this:

# Plugin Author Guide

- plugin package format
- native api
--- ios
--- android
--- blackberry
--- windowsphone
--- bada
- js api

Thoughts? (If this looks good I will update the issue.)

On Mon, Jun 25, 2012 at 10:50 AM, Filip Maj <> wrote:
> Hah Michael and I were just talking about that..
> I will send a pull request to Andrew's draft spec
> On 6/25/12 10:46 AM, "Brian LeRoux" <> wrote:
>>npm does this w/ an 'engines' attribute on package.json
>>On Mon, Jun 25, 2012 at 10:26 AM, Filip Maj <> wrote:
>>> One more thing that came to mind is how to support different versions
>>>of Cordova? Any ideas?
>>> From: Andrew Lunny <<>>
>>> Reply-To: "<>"
>>> To: Default User Nam <<>>
>>> Cc:
>>> Subject: Re: Plugin Format and Spec
>>> On 11 June 2012 13:50, Filip Maj <<>>
>>> Nice work Andrew! I suggest taking this and moving to a cordova wiki
>>> (assuming all committers are on board to adopting this as the basis for
>>> plugin spec)
>>> A link on the Cordova wiki is probably the best place to start - we can
>>>get some more feedback from plugin authors and app developers (i.e. keep
>>>this as "a way to write plugins" rather than "the official way to write
>>> Is target-dir necessary for the <source-file> element? For Java files,
>>> tooling could take a peak inside the .java file and extract out the
>>> package name from the file, no? Phonegap build already does this doesn't
>>> it?
>>> PhoneGap Build did do this, but no longer supports uploading arbitrary
>>>Java files. Only plugins with a manifest are supported.
>>> I'm torn - one of the goals of this format is to make it as easy as
>>>possible to write tools that use it as possible. Right now, a tool reads
>>>one file (plugin.xml) and moves source files (ignoring config files for
>>>the moment). I'd prefer it wasn't "read one file, then read each .java
>>>file to discover where to move it".
>>> One option is to use the id attribute on the top-level plugin element
>>>to resolve the path, but that doesn't handle the case where different
>>>Java files will have different paths. I wonder if there are more complex
>>>plugins around we can try to convert to see where the pain points are.
>>> Adding the ability to modify existing parts of a native platform's
>>> document to the <config-file> portion might be needed.. Although Ive yet
>>> to dig up a use case. Will dig around more.
>>> Agreed - also things like target OS/SDK versions may be required by
>>>certain plugins (i.e. this plugin uses an iOS 6 API, so we need to
>>>update your project to iOS 6). Probably the best approach there is to
>>>warn/prompt the user before proceeding.
>>> +1 agree that <resource-file> and <header-file> is redundant. Tooling
>>> should be able to distinguish this so merging with <source-file> makes
>>> lot of sense.
>>> Looking good!
>>> On 6/8/12 6:40 PM, "Andrew Lunny"
>>><<>> wrote:
>>>>Hi all,
>>>>I've posted to this list before about pluginstall[1], the tool I've
>>>>developed as part of working on PhoneGap Build and requiring
>>>>installation of Cordova plugins.
>>>>I've now written up a spec for the format that pluginstall uses - I
>>>>it's generally useful for Cordova plugin installation and manipulation.
>>>>spec is available on GitHub:
>>>>Issues and/or pull requests and/or forks welcome.

View raw message