incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: pluginstall cleanup and improvements
Date Wed, 19 Sep 2012 20:33:44 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message