cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: A word about plugins
Date Thu, 14 Mar 2013 17:47:08 GMT
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