I wish we could use npm's solution for that (let every package in node_modules have its own copy of its dependencies). That works for node but not for us, because these classes need to go into a single global namespace that's getting called by the bridge.
I do like the idea of using the plugin.xml files instead, keeping them in a .cordova/plugins directory perhaps? We can solve part of the plugin version problem by using the old manifest to delete the old plugin before downloading the new version. I think we can get away with crossing our fingers on the different version problem for quite a while, it's unlikely that plugins will have very many, or very sensitive, dependencies. Braden On Thu, Mar 14, 2013 at 1:47 PM, Anis KADRI <[email protected]> wrote: > I don't think it matters either way. Copying plugin.xml to the target > project folder might be easier to start. The hard stuff is dealing with > plugin versions, dependencies and Cordova versions. > > Example: Plugin A depends on version 0.1.0 of Plugin B and Plugin C depends > on version 0.2.0 of plugin B. > > 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? > > > >> > > > >> > > > > > > > > >
