incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lunny <alu...@gmail.com>
Subject Re: Plugins: Packaging/Installation/Manifests and whatnot
Date Tue, 24 Jan 2012 20:16:38 GMT
On 24 January 2012 09:55, Filip Maj <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.


>
> >...
> >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.

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