cordova-dev mailing list archives

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