Return-Path: 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 598D9116A6 for ; Sun, 12 May 2013 18:32:10 +0000 (UTC) Received: (qmail 20148 invoked by uid 500); 12 May 2013 18:32:10 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 20116 invoked by uid 500); 12 May 2013 18:32:09 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 20096 invoked by uid 99); 12 May 2013 18:32:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 May 2013 18:32:09 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=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.25 as permitted sender) Received: from [64.18.1.25] (HELO exprod6og110.obsmtp.com) (64.18.1.25) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 12 May 2013 18:32:03 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUY/gDeGcbsQuomdxS3A6HknhE7P1t4Nn@postini.com; Sun, 12 May 2013 11:31:43 PDT Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r4CIVe99029274 for ; Sun, 12 May 2013 11:31:41 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r4CIVdAV009083 for ; Sun, 12 May 2013 11:31:39 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Sun, 12 May 2013 11:31:39 -0700 From: Filip Maj To: "dev@cordova.apache.org" Date: Sun, 12 May 2013 11:31:38 -0700 Subject: Re: Changes to config.xml Thread-Topic: Changes to config.xml Thread-Index: Ac5PPvC5pDPH9n05Q2mFqdL4cBQEYQ== Message-ID: In-Reply-To: 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 I'll clarify why it fails and what we can do to change this behavior and mitigate difficulty migrating plugin manifest files moving forward. The issue is that a plugin.xml needs to specify, at a minimum, how it injects itself into config.xml to hook the native code associated with the plugin into cordova's bootup. Example: The above plugin.xml bit says "graft the contents of the element into the file config.xml at the Xpath selector 'plugins'." One thing that happened with the move over to instead of inside config.xml is that there is no longer a element. This is why plugin installation fails with plugman: the Xpath selector cannot be resolved. The plugin manifests are already growing unnecessarily because of changes we are introducing into the underlying project. Take a look at the oldest plugin in use on PhoneGap Build, ChildBrowser, to see that the manifest contains several different elements to address the changing configuration surface in cordova [1]. Related to this, moving from a root element in config.xml to a root element caused similar issues (but was mitigated by adding support for wildcard Xpaths, I.e. /*/plugins). I see a couple of options but they require further thought: - the plugin.xml spec currently has, as a requirement, to throw an error if the Xpath selector cannot be resolved. With the element gone, any plugin.xml that has config.xml as the target and "plugins" as the selector will fail. We can leave an empty element in the config.xml for backwards compatibility in this case. What will happen, though, if the same plugin entry is added into both and ? - we can change the behavior of throwing an error if the Xpath selector fails to resolve (and simply ignore), but this doesn't solve the underlying problem. Hope that helps with understanding. [1]=20 https://github.com/phonegap-build/ChildBrowser/blob/master/plugin.xml#L22-L 32 On 5/11/13 6:12 PM, "Joe Bowser" wrote: >Does this break the plugin or plugman? It shouldn't break the plugin >if the class is properly specified. > >On Fri, May 10, 2013 at 6:30 PM, Steven Gill >wrote: >> Hey All, >> >> I noticed Andrew made some config.xml changes to help bring it up to >>widget >> spec [1]. I wanted to make sure this was brought to the attention of >>plugin >> makers. >> >> As Andrew states "This unifies the config.xml used by iOS and Android. >>Now >> tags can be used to add plugins. The changes are >>non-intrusive so >> the older versions of the config.xml can still be used after this >>change. >> The value of a param named "ios-package" determines the class for the >> plugin. Also changes the config.xml with the unified one on the project >> template" >> >> I also wanted people to be aware that this seems like it will break >>plugins >> out there. It isn't a huge deal with 3.0.0 looming. People just need to >> update their plugin.xml files. The device motion plugin [2] I am >>working on >> errors out when trying to install using plugman now. This is due to >>switch >> to . >> >> -Steve >> >> [1] https://issues.apache.org/jira/browse/CB-1108 >> [2] >>=20 >>https://git-wip-us.apache.org/repos/asf?p=3Dcordova-plugin-device-motion.= gi >>t