cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorin Beer <lorin.beer....@gmail.com>
Subject Re: A word about plugins
Date Thu, 14 Mar 2013 19:01:49 GMT
>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 <fil@adobe.com> wrote:

> Sounds good to me Anis. More comments inline below.
>
> On 3/14/13 10:47 AM, "Anis KADRI" <anis.kadri@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
> ><agrieve@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 <fil@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" <braden@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 <fil@adobe.com> wrote:
> >> > >
> >> > >> On 3/12/13 5:26 PM, "Andrew Grieve" <agrieve@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?
> >> > >>
> >> > >>
> >> >
> >> >
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message