I would call that an "annoyer". if you download nodejs right now, it doens't work.
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 > >
