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
