cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 17:16:29 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message