incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: pluginstall cleanup and improvements
Date Wed, 19 Sep 2012 21:09:57 GMT
I am in favor of failing noisily. It is too much at this point for these
tools to be there to fix user-introduced errors.

On 9/19/12 1:42 PM, "Mike Reinstein" <reinstein.mike@gmail.com> wrote:

>I think we should either make a plugin installation fail if a file is
>already present, OR alternatively we could run the plugin uninstall logic
>prior to doing the install. This would clear things out. I can see pros
>and
>cons to both approaches. The nice thing about uninstall is if you were to
>accidentally delete a key file that the plugin uses, the pluginstall step
>would fix that. Let's say for example you borked plugin.xml for example
>but
>still have references in your android manifest file, or the xcodeproj
>file.
>This would allow you to run pluginstall and it would fix all the plugin
>references.
>
>-Mike
>
>On Wed, Sep 19, 2012 at 4:33 PM, Braden Shepherdson
><braden@chromium.org>wrote:
>
>> Java's classpath loading expects the path to match the package name, so
>> you're right that it will break the build tools. We should require
>>plugins
>> to have unique namespaces, I agree. Maybe make installing a plugin fail
>>if
>> a file already exists?
>>
>>
>> On Wed, Sep 19, 2012 at 2:59 PM, Mike Reinstein
>><reinstein.mike@gmail.com
>> >wrote:
>>
>> > Yeah, I think there is some weirdness around using the plugin name to
>> >  provide the namespace container for 2 reasons:
>> >
>> >    1. Im an Android N00b but I think
>>src/Child_Browser/com/phonegap/...
>> >    break the build tools
>> >    2. the name field should really be UTF8 aware, and the idea of
>>having
>> >    directories with crazy ass characters in them is not appealing. :/
>> >
>> > maybe instead we use the package name? e.g.,
>> >
>> > www/com.phonegap.childbrowser/stuff
>> > platforms/ios/Plugins/com.phonegap.childbrowser/CDVChildBrowser.h
>> >
>> > etc? Thoughts?
>> >
>> >
>> >
>> > On Wed, Sep 19, 2012 at 2:48 PM, Anis KADRI <anis.kadri@gmail.com>
>> wrote:
>> >
>> > > Yes I agree with all of it too. Except maybe for the android
>> > namespacing. I
>> > > believe it should be read from the package statement in the java
>>files
>> or
>> > > specified somewhere in the plugin.xml.
>>src/Child_Browser/com/phonegap
>> > does
>> > > not sound right to me.
>> > > I definitely agree with keeping the plugin.xml around for
>> uninstallation
>> > > purposes.
>> > > -a
>> > >
>> > > On Wed, Sep 19, 2012 at 11:12 AM, Filip Maj <fil@adobe.com> wrote:
>> > >
>> > > > +1 to all of your points Mike
>> > > >
>> > > > On 9/19/12 9:55 AM, "Mike Reinstein" <reinstein.mike@gmail.com>
>> wrote:
>> > > >
>> > > > >Hey folks,
>> > > > >
>> > > > >As you may know, pluginstall is the low level awesome utility
>> written
>> > by
>> > > > >Andrew Lunny, and it's a very key element in the cordova command
>> line
>> > > > >tools
>> > > > >that several people have been working on. Andrew and I spoke
>> yesterday
>> > > > >over
>> > > > >email, and he's planning to be afk from this tool for several
>>weeks
>> as
>> > > he
>> > > > >gets caught up with work, and finishes the major phonegap build
>> > release
>> > > > >they are doing. I'm starting this thread to have a discussion
>>about
>> > some
>> > > > >changes; I want to make sure we can come to some agreement before
>> > > > >proceeding with actual merging and cleanup.
>> > > > >
>> > > > >For brevity's sake I'm going to assume you already have a working
>> > > > >knowledge
>> > > > >of how pluginstall works but of course feel free to ask
>>questions as
>> > > > >needed. These are the major points to discuss:
>> > > > >
>> > > > >
>> > > > >   - IMO pluginstall should force namespacing to prevent multiple
>> > > plugins
>> > > > >   from having colliding assets. For example, Child Browser
>>plugin
>> > would
>> > > > >put
>> > > > >   it's native files in ios projects under Plugins/Child_Browser
>>and
>> > for
>> > > > >   android projects under src/Child_Browser/com/phonegap/..
>> > > > >   - I've looked at a few plugins, and i think we can change from
>> > > explicit
>> > > > >   to copying declarations in the manifest file to implicit;
>>rather
>> > than
>> > > > >   having to declare source-files, header-files, and asset-files
>>in
>> > > > >   plugin.xml, all resources should be copied in, and use the
>>file
>> > > > >extension
>> > > > >   to dictate how it's handled (for example .h files will always
>>be
>> > > added
>> > > > >as
>> > > > >   headers to an ios project's xcodeproj file, etc)
>> > > > >   - rename <config-file> to <xml-graft> and <plugins-plist>
to
>> > > > >   <plist-add>. Since these tags represent operations being
>> performed
>> > on
>> > > > >data
>> > > > >   files, let's identify and rename them as such.
>> > > > >   - change the cli signature to be use more descriptive flags.
>>For
>> > > > >example
>> > > > >   maybe something like pluginstall --project <project path>
>> > --platform
>> > > > >   <ios|android> -- --plugin <plugin archive path>
This will be
>> > > important
>> > > > >as
>> > > > >   the options available for this tool grow
>> > > > >   - multiple calls to addplugin should not pile up duplicate
>> > references
>> > > > >to
>> > > > >   files. We can probably solve this quickly by internally
>>calling
>> > > > >uninstall
>> > > > >   plugin, then install
>> > > > >   - for uninstall purposes, let's keep a copy of plugin.xml in
>>each
>> > > > >   platforms namespaced directory so we have a manifest for
>>removing
>> > it
>> > > > >later.
>> > > > >   for example from bullet 1, the ios platform would have the
>>file
>> > > > >   Plugins/Child_Browser/plugin.xml
>> > > > >
>> > > > >
>> > > > > -Mike
>> > > >
>> > > >
>> > >
>> >
>>


Mime
View raw message