It's definitely a blocker IMO. 0.8 is the latest shipped version, and it doesn't work with it. Maybe you'll disagree, but users will.
On Mon, Jun 25, 2012 at 4:36 PM, Filip Maj <[email protected]> wrote: > 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 >
