cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 21:31:00 GMT
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
View raw message