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:47:13 GMT
On Wed, Apr 17, 2013 at 5:44 PM, Michal Mocny <mmocny@chromium.org> wrote:

> 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.
>

Stated another way, if we move more of --install into --prepare, we wont
need as much in --uninstall, right?  Is that possible?



>
> 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