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" <[email protected]> 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 <[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 >> >> >>>> >> >> >>>> >> >> >> >> >> >> >> >> >>
