>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? > >> > >> > >> > >> > >> > > >> > > >> > >
