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 17:46:59 GMT
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
> From: Andrew Lunny <<>>
> Reply-To: "<>" <<>>
> To: Default User Nam <<>>
> Cc: "<>"
> Subject: Re: Plugin Format and Spec
> On 11 June 2012 13:50, Filip Maj <<>> wrote:
> Nice work Andrew! I suggest taking this and moving to a cordova wiki page
> (assuming all committers are on board to adopting this as the basis for a
> 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 plugins").
> Is target-dir necessary for the <source-file> element? For Java files, the
> 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 config
> 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" <<>>
>>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 programmatic
>>installation of Cordova plugins.
>>I've now written up a spec for the format that pluginstall uses - I think
>>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