Return-Path: 
 <dev-return-21561-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 62C7F9894
	for <apmail-cordova-dev-archive@www.apache.org>;
 Thu, 14 Mar 2013 16:15:33 +0000 (UTC)
Received: (qmail 12108 invoked by uid 500); 14 Mar 2013 16:15:33 -0000
Delivered-To: apmail-cordova-dev-archive@cordova.apache.org
Received: (qmail 12008 invoked by uid 500); 14 Mar 2013 16:15:32 -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 11962 invoked by uid 99); 14 Mar 2013 16:15:31 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Mar 2013 16:15:31 +0000
X-ASF-Spam-Status: No, hits=-1.3 required=5.0
	tests=FRT_ADOBE2,RCVD_IN_DNSWL_MED,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of fil@adobe.com designates
 64.18.1.33 as permitted sender)
Received: from [64.18.1.33] (HELO exprod6og114.obsmtp.com) (64.18.1.33)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Mar 2013 16:15:25 +0000
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by
 exprod6ob114.postini.com ([64.18.5.12]) with SMTP
	ID DSNKUUH3idO8kVZYy2H2LXCR/qBI+ZyaATjo@postini.com;
 Thu, 14 Mar 2013 09:15:05 PDT
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51])
	by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
 r2EGBx1v026963
	for <dev@cordova.apache.org>; Thu, 14 Mar 2013 09:11:59 -0700 (PDT)
Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100])
	by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id
 r2EGF4AV021593
	for <dev@cordova.apache.org>; Thu, 14 Mar 2013 09:15:04 -0700 (PDT)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by
 nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Thu, 14 Mar 2013 09:15:04
 -0700
From: Filip Maj <fil@adobe.com>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Date: Thu, 14 Mar 2013 09:15:02 -0700
Subject: Re: A word about plugins
Thread-Topic: A word about plugins
Thread-Index: Ac4gzxZiko4t+L8ySomIC+sClWC/EA==
Message-ID: <CD6743C7.19E95%fil@adobe.com>
In-Reply-To: 
 <CAMk5LLkeAuGvp-TGDuo0qJw0Vtb8YXJwFE7vTbsiqB69UronpA@mail.gmail.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Virus-Checked: Checked by ClamAV on apache.org

I'm wary of creating an additional manifest..

What if we came up with a convention for storing each plugin's plugin.xml
within the native project structure that the plugin got installed into? It
IS extra space needed, but a few kb per plugin doesn't seem so bad (this
is just my na=EFve first-pass type of brainstorming for this stuff)

I see a few benefits:

- Can then use <plugin> or <feature> tags inside the config.xml to
determine which plugins are installed
- Can trace back to the plugin's plugin.xml file based on the name and/or
value in these tags (based on whatever convention we come up with storing
the .xml file, as I suggested above). This way on each plugin install or
removal, we can detect collisions.
- can use plugman on its own on a per-project basis
- since we can go from config.xml -> all the plugin.xmls, this gives us a
start at dependency management

Let's keep this train going! I feel we're getting somewhere here

On 3/14/13 7:35 AM, "Braden Shepherdson" <braden@chromium.org> wrote:

>I'm working on a high-level what-not-how sort of document for the whole
>plugin tools story, and this is something I keep coming back to. It's
>looking like we'll need to know what plugins are installed and where files
>have been placed where. This is important for uninstalling and also for
>updating the iOS project files.
>
>If we do need a manifest of that kind, it should absolutely be a shared
>format between plugman and cordova-cli. Or perhaps more precisely, for
>anything dealing at the level of files, cordova-cli should be calling
>plugman, which would deal with the files and update the manifest. I'm not
>thrilled about having such metadata, but it's hard to use the filesystem
>as
>the source of truth here.
>
>Thoughts?
>
>Braden
>
>
>On Thu, Mar 14, 2013 at 3:21 AM, Filip Maj <fil@adobe.com> wrote:
>
>> On 3/12/13 5:26 PM, "Andrew Grieve" <agrieve@chromium.org> wrote:
>>
>> >One possible solution: Have JS-only plugins add a <plugin> tag with a
>>name
>> >but no value.
>>
>> Thinking more generally here, as Anis said, the problem here is
>> dependencies. I think determining how aware plugman needs to be of the
>> project is important. Pretty sure plugman needs to:
>>
>> A) know which plugins are installed
>> B) able to get a reference to each plugin's config file, to be able to
>> warn of things like collisions
>>
>> Does this sound right?
>>
>>