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 18:01:15 GMT
I think there will be a common repo, where the Cordova core plugins and
some others live. See the spec for the remotes.js file; I think it should
search for plugins with the given name in each of those universes.
Specifying a url in the <dependency> would then only be necessary for other
universes.

Braden


On Wed, Apr 17, 2013 at 1:56 PM, Filip Maj <fil@adobe.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message