cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Max Woghiren <m...@chromium.org>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 16:31:39 GMT
(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