Yep, 0.6.8. $ node -v v0.6.8
On 6/25/12 4:32 PM, "Jesse" <[email protected]> wrote: >0.6.8 ? Is your toaster unplugged Fil? >I am in windows and running without issue : >$ node -v => v0.6.18 > > >On Mon, Jun 25, 2012 at 4:29 PM, Filip Maj <[email protected]> wrote: > >> I wouldn¹t call that a blocker.. >> >> Pluginstall works fine with node 0.6.8 too. >> >> I was using 0.6.6, some dependencies in pluginstall require at least >>node >> 0.6.7, so I upgraded to 0.6.8. Works fine. >> >> On 6/25/12 3:59 PM, "Shazron" <[email protected]> wrote: >> >> >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-shri >> >>nkwrap/ >> >> >> >> >> >> 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 >> >> > > >-- >@purplecabbage >risingj.com
