cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 21:44:18 GMT
Is it possible to re-do the platform modifications on every `cordova
prepare` by running through each plugin.xml?  That way, on uninstall you
needn't do anything, just remove the plugin and run prepare again.  This
would also make it possible to make changes to a plugin's native code
without reinstalling it.

RE: plugin universe lookup by name:  If there were conflicts we could
prompt, or even just error out and have the user file an issue/remove
3rdparty universe.  I don't think this should be common, given that I
really doubt a user would have large N *global* universes to look into..
 for something like phonegap build, each app would be explicit about its
dependancies, likely.

RE: deps using same relative URL: I was thinking this would be a first
effort with fallback to normal lookup in universes, so we can still handle
the case you mentioned.  Either way, we need *some* way to reference plugin
dependancies to local files, otherwise, how do we add them?  If plugins
pulled deps from universe exclusively, you'de have to add in
reverse dependency graph order and hope there are no circular references.

-Michal


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

> K I will hold off on <permission> until we come to a consensus. You're
> right in that we could put it in as a child to <config-file>.. Duplication
> can be easily prevented (check if permission exists already before adding
> it).
>
> Removing config-file stuff during a plugin uninstall is trickier.. If two
> plugins depend on the same permission (or library, or whatever config-file
> modification), but you only uninstall one of them, we have to make sure
> that it is still there. The naïve first-pass solution to --uninstall
> testPlugin:
>
> 1. Uninstall all the things
> 2. Re-install all the things not named testPlugin
>
> Net result being: testPlugin is uninstalled.
>
> On 4/17/13 2:12 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>
> >On Wed, Apr 17, 2013 at 9:59 AM, 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.
> >>
> >
> >+1
> >
> >
> >>  - 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.
> >>
> >
> >+1. looks like the issue is assigned to me.
> >
> >
> >>  - 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.
> >>
> >
> >I don't think we need a separate element for this. Right now permissions
> >are XML fragments that are added to configuration files and
> >adding/removing
> >works just fine EXCEPT when the XML fragments have variables in them
> >(example PACKAGE_ID, API_KEY etc...). Brett is working on fixing it.
> >
> >
> >>  - 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.
> >>
> >
> >As I said on IRC. Header, Source and Resource files are all placed in
> >different sections of the iOS pbxproject so they need to be separated.
> >
> >
> >>
> >> One more question that came up: does a plugman --install call implicitly
> >> call plugman --prepare ?
> >>
> >
> >It looks like it does now but needs to be tested :-)
> >
> >
> >>
> >> 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
> >> >>
> >> >>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message