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" <[email protected]> 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 ><[email protected]>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 <[email protected]> wrote: >> >> > Sounds good to me Anis. More comments inline below. >> > >> > On 3/14/13 10:47 AM, "Anis KADRI" <[email protected]> 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 >> > ><[email protected]>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 <[email protected]> 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" <[email protected]> >> 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 <[email protected]> >>wrote: >> > >> > > >> > >> > >> On 3/12/13 5:26 PM, "Andrew Grieve" <[email protected]> >> 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? >> > >> > >> >> > >> > >> >> > >> > >> > >> > >> > >> >> > >> > >>
