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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> wrote: > >> >> > >> >>>npm does this w/ an 'engines' attribute on package.json > >> >>> > >> >>>On Mon, Jun 25, 2012 at 10:26 AM, Filip Maj <[email protected]> wrote: > >> >>>> One more thing that came to mind is how to support different > >>versions > >> >>>>of Cordova? Any ideas? > >> >>>> > >> >>>> From: Andrew Lunny <[email protected]<mailto:[email protected]>> > >> >>>> Reply-To: "[email protected]<mailto:[email protected]>" > >> >>>><[email protected]<mailto:[email protected]>> > >> >>>> To: Default User Nam <[email protected]<mailto:[email protected]>> > >> >>>> Cc: > >> >>>>"[email protected]<mailto: > >> [email protected] > >> >>>>.o > >> >>>>rg>" > >> >>>><[email protected]<mailto: > >> [email protected] > >> >>>>.o > >> >>>>rg>> > >> >>>> Subject: Re: Plugin Format and Spec > >> >>>> > >> >>>> > >> >>>> > >> >>>> On 11 June 2012 13:50, Filip Maj > >><[email protected]<mailto:[email protected] > >> >> > >> >>>>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" > >> >>>><[email protected]<mailto:[email protected]>> 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 > >> >>>> > >> >>>> > >> >> > >> > >> > >
