cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Heifetz <jheif...@blackberry.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 17:53:25 GMT
Coming back to Braden's suggestion of specifying a url and id for plugin
dependency, I think this is the correct route, and would go further to
suggest the url is optional. I do not believe we should inherently tie
plugin dependency to the exact source. Thats why we have a discovery
system and multiple places to get a plugin from.

On 13-04-17 1:37 PM, "Filip Maj" <fil@adobe.com> wrote:

>Braden and I had a little chat on IRC about install/uninstall and calling
>prepare. We've agreed that having prepare as a separate command is useful
>(you tweak some plugin JS files, add more JS files, and want that
>reflected in your app), but also calling prepare automatically after an
>install and uninstall makes sense too (otherwise people using plugman will
>have to call prepare manually after calling install or uninstall).
>
>FTR, --prepare composes the cordova_plugins.json object that is read by
>cordova.js and handles injecting plugin JS into the app. It will also be
>responsible for handling permissions that plugins require and setting up
>platform manifests appropriately based on all installed plugins.
>
>On 4/17/13 10:25 AM, "Brian LeRoux" <b@brian.io> wrote:
>
>>Braden: you thinking that the config is canonical and then prepare
>>quietly
>>does the right thing based on that?
>>
>>(Agree less steps is exactly what we're going for here.)
>>
>>
>>On Wed, Apr 17, 2013 at 10:16 AM, Braden Shepherdson
>><braden@chromium.org>wrote:
>>
>>> Re: --install calling --prepare: no. It could, though, I suppose.
>>>
>>> Why not have --prepare handle the plugins rather than install/remove.
>>>We're
>>> trying to make less, not more, happen at install time. Someday I hope
>>> --install ceases to exist.
>>>
>>>
>>> On Wed, Apr 17, 2013 at 12:59 PM, Filip Maj <fil@adobe.com> wrote:
>>>
>>> > Max, yeah, at the top of the plugman readme (in both future and
>>>master I
>>> > believe), the usage docs don't specify --install or --uninstall as an
>>> > available command, but those commands are referenced right after the
>>> usage
>>> > section. I'd be in favor of using --fetch for the RETRIEVAL of
>>>plugins,
>>> > --remove for the removal of plugins from the local plugins cache, and
>>> > --install and --uninstall for the relevant actions.
>>> >
>>> > Max, re (2): correct.
>>> >
>>> > To Braden's points:
>>> >
>>> >  - I'm fine with url + name attributes for <dependency> elements.
>>>Will
>>> > update the spec/README shortly.
>>> >  - Re <clobbers> I will add a note about that to the spec as well.
>>> >  - Re parsing package Ids, fair enough.
>>> >  - About "namespacing" iOS source files, this sounds like a good
>>>idea.
>>> > This is something that plugman can handle as well, yes? That is,
>>> > management of the plist and pointing to the right location.
>>> >  - Re config munging and permissions. I vote in favor of removing all
>>> > permissions and re-adding all of them with every change in plugins
>>>(add
>>> or
>>> > remove), with a de-duping pass. Brute force approach but it'll work
>>>and
>>> is
>>> > simple. However spec wise we need a separate element for this ya?
>>> > <permission> or something? Then based on what <platform> tag
houses a
>>> > <permissions> tag we can deduce where and how to set up the
>>>appropriate
>>> > native permissions.
>>> >  - Re the different <*-file> elements. I believe behavior in how
>>>header
>>> > and source files are handled on iOS are identical, so consolidating
>>>those
>>> > is an easy simplification. I will update the spec with that. I'll
>>>leave
>>> > resource-file in there for now.
>>> >
>>> > One more question that came up: does a plugman --install call
>>>implicitly
>>> > call plugman --prepare ?
>>> >
>>> > On 4/17/13 9:31 AM, "Max Woghiren" <maxw@chromium.org> wrote:
>>> >
>>> > >(1) On line 25 of the cordova-plugman readme, is the command missing
>>> (ie.
>>> > >--add or --install or whatever)?
>>> > >
>>> > >(2) Though two versions of a plugin are not allowed, I just want to
>>>make
>>> > >sure: there will be some kind of detection that it's okay if the
>>> > >*same*version of a plugin has already been installed by a previous
>>> > >dependency,
>>> > >right?  (For example, plugins A and B both depend on C v1.0, so
>>>plugman
>>> > >will determine that this is okay, whereas if A depends on C v1.0 and
>>>B
>>> > >depends on C v1.1, there'll be an error).
>>> > >
>>> > >
>>> > >On Wed, Apr 17, 2013 at 3:08 AM, Filip Maj <fil@adobe.com> wrote:
>>> > >
>>> > >> 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="http://plugins.cordova.io/com.facebook.plugin/plugin.xml"
/>
>>> > >>         <dependency
>>> > >> url="http://plugins.phonegap.com/com.adobe.omniture/plugin.xml"
>>> > >> version="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]
>>> > >>
>>> > >>
>>> 
>>>https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=shortlog
>>> > ;
>>> > >>h=
>>> > >> refs/heads/future
>>> > >> [2] http://wiki.apache.org/cordova/PluginTooling
>>> > >>
>>> > >>
>>> >
>>> >
>>>
>


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged
material (including material protected by the solicitor-client or other applicable privileges),
or constitute non-public information. Any use of this information by anyone other than the
intended recipient is prohibited. If you have received this transmission in error, please
immediately reply to the sender and delete this information from your system. Use, dissemination,
distribution, or reproduction of this transmission by unintended recipients is not authorized
and may be unlawful.

Mime
View raw message