version number in the manifest so users have a sense of where it should work; deprecation policy, etc on the cordova side
On Mon, Jun 25, 2012 at 1:18 PM, Filip Maj <[email protected]> wrote: > 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 >>> >> >>>> >>> >> >>>> >>> >> >> >>> >> >>> >> >>> >>> >
