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:56:22 GMT
But then we'd need to be able to discover the different universes.. Unless
we all agree on a "default", don't think this is optional..

On 4/17/13 10:53 AM, "Jeffrey Heifetz" <jheifetz@blackberry.com> wrote:

>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=shortlo
>>>>g
>>>> > ;
>>>> > >>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