cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: A word about plugins
Date Thu, 14 Mar 2013 18:14:31 GMT
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 <anis.kadri@gmail.com> 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 <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