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