incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 17:50:19 GMT
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 a
>> 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