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] >>rg>" >><[email protected]<mailto:[email protected] >>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 >> >>
