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 20:42:00 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message