You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Mike Reinstein <re...@gmail.com> on 2012/09/19 18:55:45 UTC
pluginstall cleanup and improvements
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
Re: pluginstall cleanup and improvements
Posted by Filip Maj <fi...@adobe.com>.
Sorry, I must have missed that part. I assumed when you said:
src/Child_Browser/com/phonegap
You meant:
src/com/phonegap/childbrowser
essentially: whatever the "package" statements at the top of all plugin
.java files say.
That would be my preference, less verbose, more seamless IMO
On 9/19/12 11:48 AM, "Anis KADRI" <an...@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 <fi...@adobe.com> wrote:
>
>> +1 to all of your points Mike
>>
>> On 9/19/12 9:55 AM, "Mike Reinstein" <re...@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
>>
>>
Re: pluginstall cleanup and improvements
Posted by Mike Reinstein <re...@gmail.com>.
Another change that I'm proposing after running this by Andrew is changing
the flow control. Right now there are some mechanisms to count the number
of expected callbacks and wait for completion before proceeding. We reached
consensus that moving torwards more asnychronous i/o operations happening
in parallel is the right way to go.
-Mike
On Wed, Sep 19, 2012 at 2:59 PM, Mike Reinstein <re...@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 <an...@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 <fi...@adobe.com> wrote:
>>
>> > +1 to all of your points Mike
>> >
>> > On 9/19/12 9:55 AM, "Mike Reinstein" <re...@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
>> >
>> >
>>
>
>
Re: pluginstall cleanup and improvements
Posted by Filip Maj <fi...@adobe.com>.
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" <re...@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
><br...@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 <an...@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 <fi...@adobe.com> wrote:
>> > >
>> > > > +1 to all of your points Mike
>> > > >
>> > > > On 9/19/12 9:55 AM, "Mike Reinstein" <re...@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
>> > > >
>> > > >
>> > >
>> >
>>
Re: pluginstall cleanup and improvements
Posted by Mike Reinstein <re...@gmail.com>.
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 <br...@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 <an...@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 <fi...@adobe.com> wrote:
> > >
> > > > +1 to all of your points Mike
> > > >
> > > > On 9/19/12 9:55 AM, "Mike Reinstein" <re...@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
> > > >
> > > >
> > >
> >
>
Re: pluginstall cleanup and improvements
Posted by Braden Shepherdson <br...@chromium.org>.
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 <re...@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 <an...@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 <fi...@adobe.com> wrote:
> >
> > > +1 to all of your points Mike
> > >
> > > On 9/19/12 9:55 AM, "Mike Reinstein" <re...@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
> > >
> > >
> >
>
Re: pluginstall cleanup and improvements
Posted by Mike Reinstein <re...@gmail.com>.
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 <an...@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 <fi...@adobe.com> wrote:
>
> > +1 to all of your points Mike
> >
> > On 9/19/12 9:55 AM, "Mike Reinstein" <re...@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
> >
> >
>
Re: pluginstall cleanup and improvements
Posted by Anis KADRI <an...@gmail.com>.
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 <fi...@adobe.com> wrote:
> +1 to all of your points Mike
>
> On 9/19/12 9:55 AM, "Mike Reinstein" <re...@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
>
>
Re: pluginstall cleanup and improvements
Posted by Filip Maj <fi...@adobe.com>.
+1 to all of your points Mike
On 9/19/12 9:55 AM, "Mike Reinstein" <re...@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