incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Gill <stevengil...@gmail.com>
Subject Re: Plugins: Packaging/Installation/Manifests and whatnot
Date Tue, 07 Feb 2012 00:58:33 GMT
This sounds awesome Andrew!

On Mon, Feb 6, 2012 at 4:48 PM, Andrew Lunny <alunny@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 <fil@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.
> >
> > ;/
> >
>

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