incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lunny <alu...@gmail.com>
Subject Re: Plugin Format and Spec
Date Tue, 12 Jun 2012 17:54:37 GMT
On 11 June 2012 13:50, Filip Maj <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> 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