Return-Path: 
 <dev-return-22571-apmail-cordova-dev-archive=cordova.apache.org@cordova.apache.org>
X-Original-To: apmail-cordova-dev-archive@www.apache.org
Delivered-To: apmail-cordova-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id DE3F1F55B
	for <apmail-cordova-dev-archive@www.apache.org>;
 Wed, 17 Apr 2013 07:09:43 +0000 (UTC)
Received: (qmail 13531 invoked by uid 500); 17 Apr 2013 07:09:43 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 12903 invoked by uid 500); 17 Apr 2013 07:09:38 -0000
Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@cordova.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@cordova.apache.org>
List-Post: <mailto:dev@cordova.apache.org>
List-Id: <dev.cordova.apache.org>
Reply-To: dev@cordova.apache.org
Delivered-To: mailing list dev@cordova.apache.org
Received: (qmail 12857 invoked by uid 99); 17 Apr 2013 07:09:36 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Apr 2013 07:09:36 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.234 as permitted sender)
Received: from [64.18.1.234] (HELO exprod6og119.obsmtp.com) (64.18.1.234)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Apr 2013 07:09:31 +0000
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by
 exprod6ob119.postini.com ([64.18.5.12]) with SMTP
	ID DSNKUW5KlploarFzzGoAJ6MJstjEN2c4KC0J@postini.com;
 Wed, 17 Apr 2013 00:09:11 PDT
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com
 [193.104.215.14])
	by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
 r3H75w1v029248
	for <dev@cordova.apache.org>; Wed, 17 Apr 2013 00:05:59 -0700 (PDT)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121])
	by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id r3H74LGk023727
	for <dev@cordova.apache.org>; Wed, 17 Apr 2013 00:09:07 -0700 (PDT)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by
 nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 17 Apr 2013 00:09:02
 -0700
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Wed, 17 Apr 2013 00:08:59 -0700
Subject: plugman + plugin spec final q's
Thread-Topic: plugman + plugin spec final q's
Thread-Index: Ac47OnAwT3VQVqNhTm2R2z1pgNbr0Q==
Message-ID: <CD93989B.1D1E1%fil@adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.2.130206
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Checked: Checked by ClamAV on apache.org

Hey all,

I've done a review of the spec and updated it. Check it out at the README
in the plugman repo's future branch [1]. I've added the last bit to it:
<dependencies> and <dependency> elements. Here is an example:

    <dependencies>
        <dependency
url=3D"http://plugins.cordova.io/com.facebook.plugin/plugin.xml" />
        <dependency
url=3D"http://plugins.phonegap.com/com.adobe.omniture/plugin.xml"
version=3D"1.0.0" />
    </dependencies>


Dependencies are specified by providing a url and optionally some way of
describing what version of the plugin you want. The only constraint
imposed on plugin dependencies right now is only a single version of a
plugin can be installed in an app at the same time. I think this is good
enough, but wanted to let everyone know and give people time to comment.

Also did a bunch of updates/tweaks to the plugin.xml spec, made explicit
some failures (if there are file conflicts, error noisily, that kind of
stuff). I have a PluginTooling [2] wiki article up where I am doing my
best to summarize these various reqs/use cases floating around the list,
IRC, hangout discussions regarding plugin tooling development. If you have
anything to add there please do so!

Next, I have a few questions came up when I was going through the spec:

 - does <clobbers> and <merges> (specified in the JS symbol mapping
section of the plugin spec) create the objects on window if they do not
exist? I suppose this is more of a cordova.js question than a spec
question, but that behavior should be explicit in the spec.
 - native code <source-file> elements have a `target` attribute where you
specify where within the native project the native code should be copied
into. Is this necessary? For Java files, we could look at the package
declaration at the top to determine where to put it. If I'm not mistaken,
on iOS it doesn't matter where within the directory structure of a
cordova-ios project you put native code in. What is the situation for the
Windows (Phone) platforms, and for cordova-osx?
 - the spec currently only accounts for appending XML to specific parts of
XML-based configuration documents. Does anyone foresee an instance where
some manner of native or cordova-specific config munging OTHER than
appending would be necessary? Removal/modification of existing elements?
 - iOS specific: Do we need separate elements for <source-file>,
<resource-file> and <header-file>? Can we consolidate into one? The
current draft of the spec mentions that this may be an implementation
detail.

Finally, I have two questions/concerns about the command line interface
for plugman.

1. The --fetch operation seems to need a redundant --plugin flag, e.g.
plugman --fetch --plugin <url>. Shouldn't we just axe --plugin in this
case?
2. The API readme mentions --install and --uninstall flags but the docs
only show --fetch and --remove. Can we clarify this?

Thanks for everyone's input. I feel we're getting closer to shipping this
thing!

[1]=20
https://git-wip-us.apache.org/repos/asf?p=3Dcordova-plugman.git;a=3Dshortlo=
g;h=3D
refs/heads/future
[2] http://wiki.apache.org/cordova/PluginTooling