Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of alunny@gmail.com designates
 74.125.82.43 as permitted sender)
MIME-Version: 1.0
Reply-To: alunny@gmail.com
In-Reply-To: <CB445FF1.3804%fil@adobe.com>
References: 
 <CAPihERSepG68SjfYHmirvU7fDUnycDHw94ZPTiYDfNjasPXe-g@mail.gmail.com>
	<CB445FF1.3804%fil@adobe.com>
Date: Mon, 6 Feb 2012 16:48:26 -0800
Message-ID: 
 <CAPihERR2Gct6=TAsV+BKO60opFkt+RjtvDmqJzQ7a9NHDBky1w@mail.gmail.com>
Subject: Re: Plugins: Packaging/Installation/Manifests and whatnot
From: Andrew Lunny <alunny@gmail.com>
To: callback-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=f46d043892c50dd30c04b85523e9

--f46d043892c50dd30c04b85523e9
Content-Type: text/plain; charset=ISO-8859-1

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

--f46d043892c50dd30c04b85523e9--