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:29:00 GMT
In my mind that is certainly an objective, Brian.

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