pluginstall blocker: https://github.com/alunny/node-xcode/issues/3 https://issues.apache.org/jira/browse/CB-631
Only works with node 0.6.17 On Mon, Jun 25, 2012 at 2:09 PM, Jesse <[email protected]> wrote: > We could use an 'engine' type specification similar to npm : > "engine": "node >= 0.4.1" > > http://blog.nodejs.org/2012/02/27/managing-node-js-dependencies-with-shrinkwrap/ > > > On Mon, Jun 25, 2012 at 2:02 PM, Filip Maj <[email protected]> wrote: > >> Ideally, I would think we do NOT plan on doing that post-2.0. That said, >> our current deprecation policy, last I checked, was "6 months from now", >> which does not guarantee that the API will not change between minor >> revisions. >> >> Thus, the conversation turns back to project versioning and deprecation. >> >> Mike and I spoke about this this morning. I think both of us support the >> idea of moving to semantic versioning for 2.0 and beyond. >> >> On 6/25/12 1:45 PM, "Anis KADRI" <[email protected]> wrote: >> >> >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 >> >> >> >> >> >>>> >> >> >> >> >> >>>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > > -- > @purplecabbage > risingj.com
