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 20:18:47 GMT
You don't see any reason why plugins should support different versions of
cordova? Cordova gets released every month. This seems like a pretty
important thing to figure out IMO

On 6/25/12 1:12 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:

>I think we should agree on a spec (plugin package and plugin interface)
>and
>stick to it. As long as we don't break the plugin interface, I don't see
>any reason why plugins should support multiple versions of Cordova. If
>there are any, I'd love to hear them.
>
>On Mon, Jun 25, 2012 at 1:01 PM, Filip Maj <fil@adobe.com> wrote:
>
>> Back onto the versioning question..
>>
>> 1. Do we want to support different version of the cordova framework in
>> plugins, within a single repo, across versions that changed the
>> native/javascript plugin API?
>> 2. How?
>>
>> If the answer to (1) is yes, one idea for (2) might be nesting another
>> directory level in the all of the source directories that contains the
>> version number supported. For example:
>>
>> src/android/1.5.0/*.java
>> src/android/1.8.1/*.java
>> www/1.5.0/childbrowser.js
>> www/1.8.1/childbrowser.js
>>
>> Could get gnarly real quick though. Another, cleaner implementation in
>> terms of file system "noise" might be to employ a git branches
>> convention.. But that would enforce a git dependency.
>>
>> Just brainstorming / thinking out loud. Both are probably bad ideas :)
>>
>> On 6/25/12 11:41 AM, "Michael Brooks" <michael@michaelbrooks.ca> wrote:
>>
>> >We may also want to describe testing from JavaScript and Native.
>> >
>> >I would also like to see a repository called "cordova-plugin-template"
>> >that
>> >is a boilerplate to start writing any plugin. The idea is that users
>>start
>> >with something that works, with tests, and documentation boilerplate -
>> >perhaps it can be an echo plugin since that has a minimal footprint.
>> >
>> >On Mon, Jun 25, 2012 at 11:28 AM, Filip Maj <fil@adobe.com> wrote:
>> >
>> >> Looks great. I'll add some detail to the list you have here. I'd
>> >>recommend
>> >> tweaking the order a little bit; introducing the JS before the native
>> >>APIs.
>> >>
>> >> # Plugin Author Guide
>> >>
>> >> - plugin package format -> points to Andrew's plugin spec
>> >> - js api
>> >> --- basically documenting exec(). Service, action, callbacks,
>>arguments.
>> >> What about how arguments are translated from JS types (string,
>>number,
>> >> objects, etc) to native types for each platform?
>> >>
>> >> - native api
>> >> --- ios
>> >> --- android
>> >> --- blackberry
>> >> --- windowsphone
>> >> --- bada
>> >>
>> >>
>> >> On 6/25/12 11:16 AM, "Brian LeRoux" <b@brian.io> wrote:
>> >>
>> >> >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 <fil@adobe.com> 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" <b@brian.io> wrote:
>> >> >>
>> >> >>>npm does this w/ an 'engines' attribute on package.json
>> >> >>>
>> >> >>>On Mon, Jun 25, 2012 at 10:26 AM, Filip Maj <fil@adobe.com>
wrote:
>> >> >>>> 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
>> >> >>>>.o
>> >> >>>>rg>"
>> >> >>>><callback-dev@incubator.apache.org<mailto:
>> >> callback-dev@incubator.apache
>> >> >>>>.o
>> >> >>>>rg>>
>> >> >>>> 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
View raw message