incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin Format and Spec
Date Mon, 25 Jun 2012 17:26:43 GMT
One more thing that came to mind is how to support different versions of Cordova? Any ideas?

From: Andrew Lunny <alunny@gmail.com<mailto:alunny@gmail.com>>
Reply-To: "alunny@gmail.com<mailto:alunny@gmail.com>" <alunny@gmail.com<mailto:alunny@gmail.com>>
To: Default User Nam <fil@adobe.com<mailto:fil@adobe.com>>
Cc: "callback-dev@incubator.apache.org<mailto:callback-dev@incubator.apache.org>" <callback-dev@incubator.apache.org<mailto:callback-dev@incubator.apache.org>>
Subject: Re: Plugin Format and Spec



On 11 June 2012 13:50, Filip Maj <fil@adobe.com<mailto:fil@adobe.com>> 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" <alunny@gmail.com<mailto:alunny@gmail.com>>
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 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.
>The
>spec is available on GitHub:
>https://github.com/alunny/cordova-plugin-spec
>
>Issues and/or pull requests and/or forks welcome.
>
>Cheers,
>Andrew
>
>[1] https://github.com/alunny/pluginstall



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message