You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Andrew Lunny <al...@gmail.com> on 2012/01/24 02:10:22 UTC
Plugins: Packaging/Installation/Manifests and whatnot
Hi all,
As I mentioned on the call last week, I have been working on some tooling
for programmatically installing Cordova plugins into projects, as well as a
format for defining what tasks a particular plugin needs accomplished. I
have a couple of early protoypes that I'd like some feedback on.
The first is a cross-platform structure for the ChildBrowser plugin, that
can be seen here:
https://github.com/alunny/phonegap-plugins/tree/crossplatform/CrossPlatform/ChildBrowser
including an XML-based manifest, here
https://github.com/alunny/phonegap-plugins/blob/crossplatform/CrossPlatform/ChildBrowser/plugin.xml
A couple of notes:
* it is Android only because the installation tool I've been working on
only supports Android at present
* the manifest is in XML because so are most of the config formats we're
dealing with (AndroidManifest, App-Info.plist, config.xml). Having an XML
manifest makes it easy to include, say, extra permission tags to be
included on Android, with XPath selectors to say where they should go in
the target document
* in most cases, it would be preferable for JavaScript files to be
cross-platform compatible; however, the format is flexible enough to allow
`asset` nodes to be children of `platform` nodes, and thus platform-specific
* the format was written from the perspective of a plugin-consumer, rather
than a plugin-author, so it's missing anything inessential for writing a
consumer tool (no author tags, no license tags)
* the directory structure is, of course, up for bikeshedding
I have written a small library that programmatically installs plugins based
on this file format, that can be found here:
https://github.com/alunny/pluginstall
or installed locally via
npm install -g pluginstall
Writing such tools is trivially easy for Android plugins (aside from
Node.js not having very good pure JavaScript XML libraries); it could
probably be translated into an ant task. For iOS, it would be necessary to
parse xcodeproj files, which is a little more involved - I am working on a
node.js based parser for that, to enhance the `pluginstall` tools.
A couple of open issues:
* the current format doesn't have a mechanism for specifying that one
plugin depends on another, which will be necessary
* there's no way to specify a dependency on an external library - for
example, a separate framework on iOS. I will investigate options as I begin
work on the iOS side of the code.
Looking forward to feedback,
Andrew
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Andrew Lunny <al...@gmail.com>.
On 8 February 2012 15:37, Patrick Mueller <pm...@gmail.com> wrote:
>
> My thinking is that rather than a `pluginstall` command (which is kinda
> confusing - "plug-install" or "plugin-stall"), we have a `cordova` command
> with subcommands like:
>
> add-platform [ios|android|...]
> add-plugin phonegap-plugins/ChildBrowser
> remove-plugin cordova/camera
> ...
>
> Seems like your "project" should know what platforms have been added to it
> (via add-platform), so that info doesn't need to be passed into for
> commands like add-plugin. Also note that "plugins" should be
> phonegap-plugins plugins, as well as base plugins like camera.
>
Yep - at this stage the goal has been to modify native projects
programmatically, which is a hairy enough goal (mostly down to incidental
complexity) to deserve its own effort. Things like the format of the CLI
haven't received much attention.
>
> Which repo should we start working on the `cordova` command? Please not
> another repo; maybe cordova-js (or whatever we call it)?
>
>
A Cordova command/binary deserves its own thread - I'll start that now.
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Patrick Mueller <pm...@gmail.com>.
On Wed, Feb 8, 2012 at 17:47, Andrew Lunny <al...@gmail.com> wrote:
> Update - quick screencast showing usage available here:
> http://youtu.be/HOs9nuzhxR4
This is awesome.
My thinking is that rather than a `pluginstall` command (which is kinda
confusing - "plug-install" or "plugin-stall"), we have a `cordova` command
with subcommands like:
add-platform [ios|android|...]
add-plugin phonegap-plugins/ChildBrowser
remove-plugin cordova/camera
...
Seems like your "project" should know what platforms have been added to it
(via add-platform), so that info doesn't need to be passed into for
commands like add-plugin. Also note that "plugins" should be
phonegap-plugins plugins, as well as base plugins like camera.
Which repo should we start working on the `cordova` command? Please not
another repo; maybe cordova-js (or whatever we call it)?
Great to see these initial steps though! Encouraging!
--
Patrick Mueller
http://muellerware.org
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Shazron <sh...@gmail.com>.
Great stuff. Cordova users are going to be plugin-happy installing
everything once we get all this packaged up and going!
On Wed, Feb 8, 2012 at 2:47 PM, Andrew Lunny <al...@gmail.com> wrote:
> Update - quick screencast showing usage available here:
> http://youtu.be/HOs9nuzhxR4
>
> (apologies for the iShowU HD watermark, and it logging every vim keystore)
>
> On 6 February 2012 17:46, Brian LeRoux <b...@brian.io> wrote:
>
>> fantastic stuff andrew; looking forward to seeing how the childbrowser
>> plugin package itself evolves
>>
>> On Mon, Feb 6, 2012 at 4:58 PM, Steven Gill <st...@gmail.com>
>> wrote:
>> > This sounds awesome Andrew!
>> >
>> > On Mon, Feb 6, 2012 at 4:48 PM, Andrew Lunny <al...@gmail.com> wrote:
>> >
>> >> Update: The pluginstall script - https://github.com/alunny/pluginstall-
>> >> now installs (simple) iOS plugins as well as Android.
>> >>
>> >> There are three steps to installing an iOS plugin:
>> >> 1. move some files around
>> >> 2. modify the PhoneGap.plist file
>> >> 3. modify the XCode project file (App.xcodeproj/project.pbxproj)
>> >>
>> >> 1 and 2 are trivial (although the Node library for manipulating plist
>> files
>> >> does need some love).
>> >>
>> >> 3 right now depends on a separate library I've developed -
>> >> https://github.com/alunny/node-xcode - that parses an XCode project
>> file
>> >> into a JavaScript object. This object can then be easily modified, and
>> >> written back out. The node-xcode project is not very mature, and will
>> need
>> >> enhancements to deal with the full range of PhoneGap plugins.
>> >>
>> >> My next step is to modify a fork of the ChildBrowser plugin, to allow
>> for
>> >> cross-platform deployment of the same JavaScript file (there are some
>> >> fiddly inconsistencies between Android and iOS there). I'll then have a
>> >> screencast/demo available of how the whole process works.
>> >>
>> >> On 24 January 2012 13:19, Filip Maj <fi...@adobe.com> wrote:
>> >>
>> >> >
>> >> > On 24 January 2012 09:55, Filip Maj <fil@adobe.com<mailto:
>> fil@adobe.com
>> >> >>
>> >> > wrote:
>> >> >
>> >> > Can you explain the two <asset> nodes in your example plugins.xml ?
>> What
>> >> > is the difference between the two elements? Lines 8-9.
>> >> >
>> >> > "The first tag is pointing to the js file, the second to a directory
>> also
>> >> > called "childbrowser" that needs to be moved into the project's www
>> >> > directory."
>> >> >
>> >> > Gotcha!
>> >> >
>> >> >
>> >> > >...
>> >> > >A couple of open issues:
>> >> > >* the current format doesn't have a mechanism for specifying that one
>> >> > >plugin depends on another, which will be necessary
>> >> > >* there's no way to specify a dependency on an external library - for
>> >> > >example, a separate framework on iOS. I will investigate options as I
>> >> > >begin
>> >> > >work on the iOS side of the code.
>> >> >
>> >> > Could we use what mechanisms already exist in package.json to figure
>> this
>> >> > out? Maybe add an extension to this? It'd be nice to be able to
>> feature
>> >> > phonegap plugins and other tools in NPM, and it seems we're going the
>> >> > route of node anyways for our CLI stuff.
>> >> >
>> >> >
>> >> > It's definitely something we should feel out as phonegap-js and the
>> >> plugin
>> >> > tooling progress, particularly for plugin distribution. I think having
>> >> this
>> >> > kind of manifest file and a package.json is not out of the question,
>> if
>> >> > they're doing two very different things.
>> >> >
>> >> > At this stage, I'm focused on the plugin installation - with the
>> >> > assumption that all the code is available locally. If you assume all
>> the
>> >> > code is there on the filesystem, package.json and the npm
>> infrastructure
>> >> > don't really benefit us. The goal right now is to encode all this
>> >> > information:
>> >> >
>> >> >
>> >> >
>> >>
>> https://github.com/phonegap/phonegap-plugins/blob/master/Android/ChildBrowser/README.md
>> >> >
>> >> > in a format that can easily be manipulated by software and humans.
>> >> >
>> >> > ^^ This is key. I'm thinking some extensions to either xml/json
>> format we
>> >> > end up on over what's already "in place" (a la NPM or even a similar
>> sort
>> >> > of extensions employed by Nodejitsu).
>> >> >
>> >> > It'd be a little ugly to have two config files in the root of the
>> plugin,
>> >> > but it keeps things simple (non-intertwined), especially while we're
>> >> > prototyping this stuff.
>> >> >
>> >> > That's my concern, is that if we go down the rabbit hole without
>> thinking
>> >> > about all the aspects of the cordova project this affects we could
>> end up
>> >> > with a sub-par solution.
>> >> >
>> >> > ;/
>> >> >
>> >>
>>
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Andrew Lunny <al...@gmail.com>.
Update - quick screencast showing usage available here:
http://youtu.be/HOs9nuzhxR4
(apologies for the iShowU HD watermark, and it logging every vim keystore)
On 6 February 2012 17:46, Brian LeRoux <b...@brian.io> wrote:
> fantastic stuff andrew; looking forward to seeing how the childbrowser
> plugin package itself evolves
>
> On Mon, Feb 6, 2012 at 4:58 PM, Steven Gill <st...@gmail.com>
> wrote:
> > This sounds awesome Andrew!
> >
> > On Mon, Feb 6, 2012 at 4:48 PM, Andrew Lunny <al...@gmail.com> wrote:
> >
> >> Update: The pluginstall script - https://github.com/alunny/pluginstall-
> >> now installs (simple) iOS plugins as well as Android.
> >>
> >> There are three steps to installing an iOS plugin:
> >> 1. move some files around
> >> 2. modify the PhoneGap.plist file
> >> 3. modify the XCode project file (App.xcodeproj/project.pbxproj)
> >>
> >> 1 and 2 are trivial (although the Node library for manipulating plist
> files
> >> does need some love).
> >>
> >> 3 right now depends on a separate library I've developed -
> >> https://github.com/alunny/node-xcode - that parses an XCode project
> file
> >> into a JavaScript object. This object can then be easily modified, and
> >> written back out. The node-xcode project is not very mature, and will
> need
> >> enhancements to deal with the full range of PhoneGap plugins.
> >>
> >> My next step is to modify a fork of the ChildBrowser plugin, to allow
> for
> >> cross-platform deployment of the same JavaScript file (there are some
> >> fiddly inconsistencies between Android and iOS there). I'll then have a
> >> screencast/demo available of how the whole process works.
> >>
> >> On 24 January 2012 13:19, Filip Maj <fi...@adobe.com> wrote:
> >>
> >> >
> >> > On 24 January 2012 09:55, Filip Maj <fil@adobe.com<mailto:
> fil@adobe.com
> >> >>
> >> > wrote:
> >> >
> >> > Can you explain the two <asset> nodes in your example plugins.xml ?
> What
> >> > is the difference between the two elements? Lines 8-9.
> >> >
> >> > "The first tag is pointing to the js file, the second to a directory
> also
> >> > called "childbrowser" that needs to be moved into the project's www
> >> > directory."
> >> >
> >> > Gotcha!
> >> >
> >> >
> >> > >...
> >> > >A couple of open issues:
> >> > >* the current format doesn't have a mechanism for specifying that one
> >> > >plugin depends on another, which will be necessary
> >> > >* there's no way to specify a dependency on an external library - for
> >> > >example, a separate framework on iOS. I will investigate options as I
> >> > >begin
> >> > >work on the iOS side of the code.
> >> >
> >> > Could we use what mechanisms already exist in package.json to figure
> this
> >> > out? Maybe add an extension to this? It'd be nice to be able to
> feature
> >> > phonegap plugins and other tools in NPM, and it seems we're going the
> >> > route of node anyways for our CLI stuff.
> >> >
> >> >
> >> > It's definitely something we should feel out as phonegap-js and the
> >> plugin
> >> > tooling progress, particularly for plugin distribution. I think having
> >> this
> >> > kind of manifest file and a package.json is not out of the question,
> if
> >> > they're doing two very different things.
> >> >
> >> > At this stage, I'm focused on the plugin installation - with the
> >> > assumption that all the code is available locally. If you assume all
> the
> >> > code is there on the filesystem, package.json and the npm
> infrastructure
> >> > don't really benefit us. The goal right now is to encode all this
> >> > information:
> >> >
> >> >
> >> >
> >>
> https://github.com/phonegap/phonegap-plugins/blob/master/Android/ChildBrowser/README.md
> >> >
> >> > in a format that can easily be manipulated by software and humans.
> >> >
> >> > ^^ This is key. I'm thinking some extensions to either xml/json
> format we
> >> > end up on over what's already "in place" (a la NPM or even a similar
> sort
> >> > of extensions employed by Nodejitsu).
> >> >
> >> > It'd be a little ugly to have two config files in the root of the
> plugin,
> >> > but it keeps things simple (non-intertwined), especially while we're
> >> > prototyping this stuff.
> >> >
> >> > That's my concern, is that if we go down the rabbit hole without
> thinking
> >> > about all the aspects of the cordova project this affects we could
> end up
> >> > with a sub-par solution.
> >> >
> >> > ;/
> >> >
> >>
>
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Brian LeRoux <b...@brian.io>.
fantastic stuff andrew; looking forward to seeing how the childbrowser
plugin package itself evolves
On Mon, Feb 6, 2012 at 4:58 PM, Steven Gill <st...@gmail.com> wrote:
> This sounds awesome Andrew!
>
> On Mon, Feb 6, 2012 at 4:48 PM, Andrew Lunny <al...@gmail.com> wrote:
>
>> Update: The pluginstall script - https://github.com/alunny/pluginstall -
>> now installs (simple) iOS plugins as well as Android.
>>
>> There are three steps to installing an iOS plugin:
>> 1. move some files around
>> 2. modify the PhoneGap.plist file
>> 3. modify the XCode project file (App.xcodeproj/project.pbxproj)
>>
>> 1 and 2 are trivial (although the Node library for manipulating plist files
>> does need some love).
>>
>> 3 right now depends on a separate library I've developed -
>> https://github.com/alunny/node-xcode - that parses an XCode project file
>> into a JavaScript object. This object can then be easily modified, and
>> written back out. The node-xcode project is not very mature, and will need
>> enhancements to deal with the full range of PhoneGap plugins.
>>
>> My next step is to modify a fork of the ChildBrowser plugin, to allow for
>> cross-platform deployment of the same JavaScript file (there are some
>> fiddly inconsistencies between Android and iOS there). I'll then have a
>> screencast/demo available of how the whole process works.
>>
>> On 24 January 2012 13:19, Filip Maj <fi...@adobe.com> wrote:
>>
>> >
>> > On 24 January 2012 09:55, Filip Maj <fil@adobe.com<mailto:fil@adobe.com
>> >>
>> > wrote:
>> >
>> > Can you explain the two <asset> nodes in your example plugins.xml ? What
>> > is the difference between the two elements? Lines 8-9.
>> >
>> > "The first tag is pointing to the js file, the second to a directory also
>> > called "childbrowser" that needs to be moved into the project's www
>> > directory."
>> >
>> > Gotcha!
>> >
>> >
>> > >...
>> > >A couple of open issues:
>> > >* the current format doesn't have a mechanism for specifying that one
>> > >plugin depends on another, which will be necessary
>> > >* there's no way to specify a dependency on an external library - for
>> > >example, a separate framework on iOS. I will investigate options as I
>> > >begin
>> > >work on the iOS side of the code.
>> >
>> > Could we use what mechanisms already exist in package.json to figure this
>> > out? Maybe add an extension to this? It'd be nice to be able to feature
>> > phonegap plugins and other tools in NPM, and it seems we're going the
>> > route of node anyways for our CLI stuff.
>> >
>> >
>> > It's definitely something we should feel out as phonegap-js and the
>> plugin
>> > tooling progress, particularly for plugin distribution. I think having
>> this
>> > kind of manifest file and a package.json is not out of the question, if
>> > they're doing two very different things.
>> >
>> > At this stage, I'm focused on the plugin installation - with the
>> > assumption that all the code is available locally. If you assume all the
>> > code is there on the filesystem, package.json and the npm infrastructure
>> > don't really benefit us. The goal right now is to encode all this
>> > information:
>> >
>> >
>> >
>> https://github.com/phonegap/phonegap-plugins/blob/master/Android/ChildBrowser/README.md
>> >
>> > in a format that can easily be manipulated by software and humans.
>> >
>> > ^^ This is key. I'm thinking some extensions to either xml/json format we
>> > end up on over what's already "in place" (a la NPM or even a similar sort
>> > of extensions employed by Nodejitsu).
>> >
>> > It'd be a little ugly to have two config files in the root of the plugin,
>> > but it keeps things simple (non-intertwined), especially while we're
>> > prototyping this stuff.
>> >
>> > That's my concern, is that if we go down the rabbit hole without thinking
>> > about all the aspects of the cordova project this affects we could end up
>> > with a sub-par solution.
>> >
>> > ;/
>> >
>>
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Steven Gill <st...@gmail.com>.
This sounds awesome Andrew!
On Mon, Feb 6, 2012 at 4:48 PM, Andrew Lunny <al...@gmail.com> wrote:
> Update: The pluginstall script - https://github.com/alunny/pluginstall -
> now installs (simple) iOS plugins as well as Android.
>
> There are three steps to installing an iOS plugin:
> 1. move some files around
> 2. modify the PhoneGap.plist file
> 3. modify the XCode project file (App.xcodeproj/project.pbxproj)
>
> 1 and 2 are trivial (although the Node library for manipulating plist files
> does need some love).
>
> 3 right now depends on a separate library I've developed -
> https://github.com/alunny/node-xcode - that parses an XCode project file
> into a JavaScript object. This object can then be easily modified, and
> written back out. The node-xcode project is not very mature, and will need
> enhancements to deal with the full range of PhoneGap plugins.
>
> My next step is to modify a fork of the ChildBrowser plugin, to allow for
> cross-platform deployment of the same JavaScript file (there are some
> fiddly inconsistencies between Android and iOS there). I'll then have a
> screencast/demo available of how the whole process works.
>
> On 24 January 2012 13:19, Filip Maj <fi...@adobe.com> wrote:
>
> >
> > On 24 January 2012 09:55, Filip Maj <fil@adobe.com<mailto:fil@adobe.com
> >>
> > wrote:
> >
> > Can you explain the two <asset> nodes in your example plugins.xml ? What
> > is the difference between the two elements? Lines 8-9.
> >
> > "The first tag is pointing to the js file, the second to a directory also
> > called "childbrowser" that needs to be moved into the project's www
> > directory."
> >
> > Gotcha!
> >
> >
> > >...
> > >A couple of open issues:
> > >* the current format doesn't have a mechanism for specifying that one
> > >plugin depends on another, which will be necessary
> > >* there's no way to specify a dependency on an external library - for
> > >example, a separate framework on iOS. I will investigate options as I
> > >begin
> > >work on the iOS side of the code.
> >
> > Could we use what mechanisms already exist in package.json to figure this
> > out? Maybe add an extension to this? It'd be nice to be able to feature
> > phonegap plugins and other tools in NPM, and it seems we're going the
> > route of node anyways for our CLI stuff.
> >
> >
> > It's definitely something we should feel out as phonegap-js and the
> plugin
> > tooling progress, particularly for plugin distribution. I think having
> this
> > kind of manifest file and a package.json is not out of the question, if
> > they're doing two very different things.
> >
> > At this stage, I'm focused on the plugin installation - with the
> > assumption that all the code is available locally. If you assume all the
> > code is there on the filesystem, package.json and the npm infrastructure
> > don't really benefit us. The goal right now is to encode all this
> > information:
> >
> >
> >
> https://github.com/phonegap/phonegap-plugins/blob/master/Android/ChildBrowser/README.md
> >
> > in a format that can easily be manipulated by software and humans.
> >
> > ^^ This is key. I'm thinking some extensions to either xml/json format we
> > end up on over what's already "in place" (a la NPM or even a similar sort
> > of extensions employed by Nodejitsu).
> >
> > It'd be a little ugly to have two config files in the root of the plugin,
> > but it keeps things simple (non-intertwined), especially while we're
> > prototyping this stuff.
> >
> > That's my concern, is that if we go down the rabbit hole without thinking
> > about all the aspects of the cordova project this affects we could end up
> > with a sub-par solution.
> >
> > ;/
> >
>
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Andrew Lunny <al...@gmail.com>.
Update: The pluginstall script - https://github.com/alunny/pluginstall -
now installs (simple) iOS plugins as well as Android.
There are three steps to installing an iOS plugin:
1. move some files around
2. modify the PhoneGap.plist file
3. modify the XCode project file (App.xcodeproj/project.pbxproj)
1 and 2 are trivial (although the Node library for manipulating plist files
does need some love).
3 right now depends on a separate library I've developed -
https://github.com/alunny/node-xcode - that parses an XCode project file
into a JavaScript object. This object can then be easily modified, and
written back out. The node-xcode project is not very mature, and will need
enhancements to deal with the full range of PhoneGap plugins.
My next step is to modify a fork of the ChildBrowser plugin, to allow for
cross-platform deployment of the same JavaScript file (there are some
fiddly inconsistencies between Android and iOS there). I'll then have a
screencast/demo available of how the whole process works.
On 24 January 2012 13:19, Filip Maj <fi...@adobe.com> wrote:
>
> On 24 January 2012 09:55, Filip Maj <fi...@adobe.com>>
> wrote:
>
> Can you explain the two <asset> nodes in your example plugins.xml ? What
> is the difference between the two elements? Lines 8-9.
>
> "The first tag is pointing to the js file, the second to a directory also
> called "childbrowser" that needs to be moved into the project's www
> directory."
>
> Gotcha!
>
>
> >...
> >A couple of open issues:
> >* the current format doesn't have a mechanism for specifying that one
> >plugin depends on another, which will be necessary
> >* there's no way to specify a dependency on an external library - for
> >example, a separate framework on iOS. I will investigate options as I
> >begin
> >work on the iOS side of the code.
>
> Could we use what mechanisms already exist in package.json to figure this
> out? Maybe add an extension to this? It'd be nice to be able to feature
> phonegap plugins and other tools in NPM, and it seems we're going the
> route of node anyways for our CLI stuff.
>
>
> It's definitely something we should feel out as phonegap-js and the plugin
> tooling progress, particularly for plugin distribution. I think having this
> kind of manifest file and a package.json is not out of the question, if
> they're doing two very different things.
>
> At this stage, I'm focused on the plugin installation - with the
> assumption that all the code is available locally. If you assume all the
> code is there on the filesystem, package.json and the npm infrastructure
> don't really benefit us. The goal right now is to encode all this
> information:
>
>
> https://github.com/phonegap/phonegap-plugins/blob/master/Android/ChildBrowser/README.md
>
> in a format that can easily be manipulated by software and humans.
>
> ^^ This is key. I'm thinking some extensions to either xml/json format we
> end up on over what's already "in place" (a la NPM or even a similar sort
> of extensions employed by Nodejitsu).
>
> It'd be a little ugly to have two config files in the root of the plugin,
> but it keeps things simple (non-intertwined), especially while we're
> prototyping this stuff.
>
> That's my concern, is that if we go down the rabbit hole without thinking
> about all the aspects of the cordova project this affects we could end up
> with a sub-par solution.
>
> ;/
>
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Filip Maj <fi...@adobe.com>.
On 24 January 2012 09:55, Filip Maj <fi...@adobe.com>> wrote:
Can you explain the two <asset> nodes in your example plugins.xml ? What
is the difference between the two elements? Lines 8-9.
"The first tag is pointing to the js file, the second to a directory also called "childbrowser" that needs to be moved into the project's www directory."
Gotcha!
>...
>A couple of open issues:
>* the current format doesn't have a mechanism for specifying that one
>plugin depends on another, which will be necessary
>* there's no way to specify a dependency on an external library - for
>example, a separate framework on iOS. I will investigate options as I
>begin
>work on the iOS side of the code.
Could we use what mechanisms already exist in package.json to figure this
out? Maybe add an extension to this? It'd be nice to be able to feature
phonegap plugins and other tools in NPM, and it seems we're going the
route of node anyways for our CLI stuff.
It's definitely something we should feel out as phonegap-js and the plugin tooling progress, particularly for plugin distribution. I think having this kind of manifest file and a package.json is not out of the question, if they're doing two very different things.
At this stage, I'm focused on the plugin installation - with the assumption that all the code is available locally. If you assume all the code is there on the filesystem, package.json and the npm infrastructure don't really benefit us. The goal right now is to encode all this information:
https://github.com/phonegap/phonegap-plugins/blob/master/Android/ChildBrowser/README.md
in a format that can easily be manipulated by software and humans.
^^ This is key. I'm thinking some extensions to either xml/json format we end up on over what's already "in place" (a la NPM or even a similar sort of extensions employed by Nodejitsu).
It'd be a little ugly to have two config files in the root of the plugin, but it keeps things simple (non-intertwined), especially while we're prototyping this stuff.
That's my concern, is that if we go down the rabbit hole without thinking about all the aspects of the cordova project this affects we could end up with a sub-par solution.
;/
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Andrew Lunny <al...@gmail.com>.
On 24 January 2012 09:55, Filip Maj <fi...@adobe.com> wrote:
>
>
> Can you explain the two <asset> nodes in your example plugins.xml ? What
> is the difference between the two elements? Lines 8-9.
>
The first tag is pointing to the js file, the second to a directory also
called "childbrowser" that needs to be moved into the project's www
directory.
>
> >...
> >A couple of open issues:
> >* the current format doesn't have a mechanism for specifying that one
> >plugin depends on another, which will be necessary
> >* there's no way to specify a dependency on an external library - for
> >example, a separate framework on iOS. I will investigate options as I
> >begin
> >work on the iOS side of the code.
>
> Could we use what mechanisms already exist in package.json to figure this
> out? Maybe add an extension to this? It'd be nice to be able to feature
> phonegap plugins and other tools in NPM, and it seems we're going the
> route of node anyways for our CLI stuff.
>
>
It's definitely something we should feel out as phonegap-js and the plugin
tooling progress, particularly for plugin distribution. I think having this
kind of manifest file and a package.json is not out of the question, if
they're doing two very different things.
At this stage, I'm focused on the plugin installation - with the assumption
that all the code is available locally. If you assume all the code is there
on the filesystem, package.json and the npm infrastructure don't really
benefit us. The goal right now is to encode all this information:
https://github.com/phonegap/phonegap-plugins/blob/master/Android/ChildBrowser/README.md
in a format that can easily be manipulated by software and humans.
It'd be a little ugly to have two config files in the root of the plugin,
but it keeps things simple (non-intertwined), especially while we're
prototyping this stuff.
Re: Plugins: Packaging/Installation/Manifests and whatnot
Posted by Filip Maj <fi...@adobe.com>.
Hey Andrew,
Nice work. A few of my thoughts in-line.
>* the manifest is in XML because so are most of the config formats we're
>dealing with (AndroidManifest, App-Info.plist, config.xml). Having an XML
>manifest makes it easy to include, say, extra permission tags to be
>included on Android, with XPath selectors to say where they should go in
>the target document
Gord and I have a similar TODO in the cordova-js project, to figure out
some kind of packaging format for plugins. It's relevant to both of our
projects. Gord was thinking a package.json-like format; perhaps we could
consolidate requirements from both of our projects to come up with a spec
that satisfies both of our needs? I like how the native side of plugins
are figured out in your XML format, as well as the integration into the
native manifest formats.
>* in most cases, it would be preferable for JavaScript files to be
>cross-platform compatible; however, the format is flexible enough to allow
>`asset` nodes to be children of `platform` nodes, and thus
>platform-specific
Can you explain the two <asset> nodes in your example plugins.xml ? What
is the difference between the two elements? Lines 8-9.
>...
>A couple of open issues:
>* the current format doesn't have a mechanism for specifying that one
>plugin depends on another, which will be necessary
>* there's no way to specify a dependency on an external library - for
>example, a separate framework on iOS. I will investigate options as I
>begin
>work on the iOS side of the code.
Could we use what mechanisms already exist in package.json to figure this
out? Maybe add an extension to this? It'd be nice to be able to feature
phonegap plugins and other tools in NPM, and it seems we're going the
route of node anyways for our CLI stuff.