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
