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.m...@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 ><bra...@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.m...@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.ka...@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 <f...@adobe.com> wrote: >> > > >> > > > +1 to all of your points Mike >> > > > >> > > > On 9/19/12 9:55 AM, "Mike Reinstein" <reinstein.m...@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 >> > > > >> > > > >> > > >> > >>
