cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 17:37:40 GMT
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
>> > >>
>> > >>
>> >
>> >
>>


Mime
View raw message