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