incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <>
Subject Re: Plugins: Packaging/Installation/Manifests and whatnot
Date Tue, 24 Jan 2012 21:19:53 GMT

On 24 January 2012 09:55, Filip Maj <<>> 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
>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

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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message