Agreed fil, but are we planning on doing that for future releases ? If yes that YAH we should support versions and the solution you described is certainly an option. But if I were a plugin developer, I would not want to update it every month to keep up with Cordova releases. I don't disagree that there could be an Cordova version in the manifest file that allows plugin developers to target a specific version of Cordova (which would mean that the plugin was tested with that version but might also work with newer versions).
On Mon, Jun 25, 2012 at 1:33 PM, Filip Maj <[email protected]> wrote: > Yes, it has changed every month. Pretty much every minor revision from 1.0 > to 1.9 has changed the API (at least on Android). > > On 6/25/12 1:26 PM, "Anis KADRI" <[email protected]> wrote: > > >Right but does the plugin interface change every month too ? A plugin that > >works with Cordova 1.x.x is not supposed to work with Cordova 1.y.y ? > > > >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 > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > >
