incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: pluginstall cleanup and improvements
Date Wed, 19 Sep 2012 18:59:07 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message