Yea, this isn't pretty. Agree w/ Anis to cross the bridge when we get there.
Also agree w/ Fil's idea that dependencies are ok but a plugin only gets loaded once and if a dep requires a different version then we should fail noisily. In a perfect world, that will be enough info for the developer to either file a bug w/ a plugin author to update or fork it to fix to their needs. On Thu, Mar 14, 2013 at 8:23 PM, Filip Maj <f...@adobe.com> wrote: > I agree. This is not a problem worth solving (if you have ever worked with > Ruby gems, you know what I'm talking about) > > And the plugin-depending-on-a-plugin is already happening. Some plugins > require Facebook Connect already.. IMO drawing a line in the sand here is > a good first step. > > On 3/14/13 12:18 PM, "Braden Shepherdson" <bra...@chromium.org> wrote: > >>Even if we can do something clever with the code for those two versions of >>a plugin, the exec call names are still in one namespace. >> >>Adding versions to them would, in my opinion, make the cure worse than the >>disease. Then a plugin author would have to update his code every time any >>of his dependencies updated. Then all of his downstream users have to >>update themselves, and so on up the tree. >> >>Braden >> >> >>On Thu, Mar 14, 2013 at 3:01 PM, Lorin Beer >><lorin.beer....@gmail.com>wrote: >> >>> >Cordova versions: we have <engine> tags. A single cordova project is >>> >stuck to a single cordova version. Attempting to install a plugin into >>>a >>> >project running a different version of cordova should fail. Simple as >>> that. >>> >>> I'm more comfortable with a warning. While warnings are often >>>(re:always) >>> ignored by developers, a cordova-plugin wouldn't necessarily be a >>> guaranteed runtime fail. Forcing one seems unnecessarily prohibitive. >>> >>> > Plugin versions: since each cordova project is its own enclosed >>> >namespace, we can't allow for this either. You install Plugin A, it >>>needs >>> >plugin B, so plugin B gets installed along the way. You try to install >>> > Plugin C, plugman realizes that two different versions of Plugin B are >>> > then required (and colliding), and so we should fail at this point. >>> >>> agreed on this point, however is this a class of problem (interwoven >>>plugin >>> dependency) which we currently see? How many users is this sort of issue >>> likely to affect? Having a forced fail at this point strikes me as >>> justified. >>> >>> >>> This may be naive to how plugins are currently handled, but is there no >>> tractable way of providing a 'namespace' for plugins, allowing multiple >>> versions of the same plugin to run simultaneously? A 'plugin version' >>> qualifier, rather than, as Braden put it, "these classes need to go >>>into a >>> single global namespace that's getting called by the bridge." >>> >>> >>> On Thu, Mar 14, 2013 at 11:20 AM, Filip Maj <f...@adobe.com> wrote: >>> >>> > Sounds good to me Anis. More comments inline below. >>> > >>> > On 3/14/13 10:47 AM, "Anis KADRI" <anis.ka...@gmail.com> wrote: >>> > >>> > >The hard stuff is dealing with >>> > >plugin versions, dependencies and Cordova versions. >>> > >>> > If we think of these problems in light of a single cordova project, I >>> > think it gets easier because: >>> > >>> > - Cordova versions: we have <engine> tags. A single cordova project is >>> > stuck to a single cordova version. Attempting to install a plugin >>>into a >>> > project running a different version of cordova should fail. Simple as >>> that. >>> > >>> > >Example: Plugin A depends on version 0.1.0 of Plugin B and Plugin C >>> > >depends >>> > >on version 0.2.0 of plugin B. >>> > >>> > - Plugin versions: since each cordova project is its own enclosed >>> > namespace, we can't allow for this either. You install Plugin A, it >>>needs >>> > plugin B, so plugin B gets installed along the way. You try to install >>> > Plugin C, plugman realizes that two different versions of Plugin B are >>> > then required (and colliding), and so we should fail at this point. >>> > >>> > > >>> > >That is also assuming that whatever plugin we install that requires a >>> > >specific Cordova version, its dependencies will also work with that >>>same >>> > >Cordova version (<engine> tag). >>> > > >>> > >I don't know if we will have this scenario ever but this is one of >>>the >>> > >nightmares of package management. >>> > > >>> > >We can solve that problem once we hit it. For now we only need to >>>know >>> > >what >>> > >plugins are installed and how to uninstall them. >>> > > >>> > >so a simple structure like this could work to start: >>> > > >>> > >PROJECT/.plugins/BarcodeScanner/plugin.xml >>> > >PROJECT/.plugins/Facebook-Connect/plugin.xml >>> > >... >>> > > >>> > ></braindump> >>> > > >>> > >-a >>> > > >>> > >On Thu, Mar 14, 2013 at 10:33 AM, Andrew Grieve >>> > ><agri...@chromium.org>wrote: >>> > > >>> > >> Copying the plugin.xml into the platform's project somewhere sounds >>> > >>like a >>> > >> good idea to me. >>> > >> >>> > >> I don't think we'd need to look in the config.xml to see what's >>> > >>installed >>> > >> then. We can just look at what plugin.xml files exist. >>> > >> >>> > >> >>> > >> On Thu, Mar 14, 2013 at 12:15 PM, Filip Maj <f...@adobe.com> wrote: >>> > >> >>> > >> > I'm wary of creating an additional manifest.. >>> > >> > >>> > >> > What if we came up with a convention for storing each plugin's >>> > >>plugin.xml >>> > >> > within the native project structure that the plugin got installed >>> > >>into? >>> > >> It >>> > >> > IS extra space needed, but a few kb per plugin doesn't seem so >>>bad >>> > >>(this >>> > >> > is just my naïve first-pass type of brainstorming for this stuff) >>> > >> > >>> > >> > I see a few benefits: >>> > >> > >>> > >> > - Can then use <plugin> or <feature> tags inside the config.xml >>>to >>> > >> > determine which plugins are installed >>> > >> > - Can trace back to the plugin's plugin.xml file based on the >>>name >>> > >>and/or >>> > >> > value in these tags (based on whatever convention we come up with >>> > >>storing >>> > >> > the .xml file, as I suggested above). This way on each plugin >>> install >>> > >>or >>> > >> > removal, we can detect collisions. >>> > >> > - can use plugman on its own on a per-project basis >>> > >> > - since we can go from config.xml -> all the plugin.xmls, this >>>gives >>> > >>us a >>> > >> > start at dependency management >>> > >> > >>> > >> > Let's keep this train going! I feel we're getting somewhere here >>> > >> > >>> > >> > On 3/14/13 7:35 AM, "Braden Shepherdson" <bra...@chromium.org> >>> wrote: >>> > >> > >>> > >> > >I'm working on a high-level what-not-how sort of document for >>>the >>> > >>whole >>> > >> > >plugin tools story, and this is something I keep coming back to. >>> It's >>> > >> > >looking like we'll need to know what plugins are installed and >>> where >>> > >> files >>> > >> > >have been placed where. This is important for uninstalling and >>>also >>> > >>for >>> > >> > >updating the iOS project files. >>> > >> > > >>> > >> > >If we do need a manifest of that kind, it should absolutely be a >>> > >>shared >>> > >> > >format between plugman and cordova-cli. Or perhaps more >>>precisely, >>> > >>for >>> > >> > >anything dealing at the level of files, cordova-cli should be >>> calling >>> > >> > >plugman, which would deal with the files and update the >>>manifest. >>> I'm >>> > >> not >>> > >> > >thrilled about having such metadata, but it's hard to use the >>> > >>filesystem >>> > >> > >as >>> > >> > >the source of truth here. >>> > >> > > >>> > >> > >Thoughts? >>> > >> > > >>> > >> > >Braden >>> > >> > > >>> > >> > > >>> > >> > >On Thu, Mar 14, 2013 at 3:21 AM, Filip Maj <f...@adobe.com> >>>wrote: >>> > >> > > >>> > >> > >> On 3/12/13 5:26 PM, "Andrew Grieve" <agri...@chromium.org> >>> wrote: >>> > >> > >> >>> > >> > >> >One possible solution: Have JS-only plugins add a <plugin> >>>tag >>> > >>with a >>> > >> > >>name >>> > >> > >> >but no value. >>> > >> > >> >>> > >> > >> Thinking more generally here, as Anis said, the problem here >>>is >>> > >> > >> dependencies. I think determining how aware plugman needs to >>>be >>> of >>> > >>the >>> > >> > >> project is important. Pretty sure plugman needs to: >>> > >> > >> >>> > >> > >> A) know which plugins are installed >>> > >> > >> B) able to get a reference to each plugin's config file, to be >>> > >>able to >>> > >> > >> warn of things like collisions >>> > >> > >> >>> > >> > >> Does this sound right? >>> > >> > >> >>> > >> > >> >>> > >> > >>> > >> > >>> > >> >>> > >>> > >>> >
