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 Tue, 12 Mar 2013 21:57:18 GMT
I've sent a pull request to plugman earlier today that fixes one case of
this, among other things.

Here's an example of it in master:
https://github.com/imhotep/plugman/blob/master/platforms/android.js#L202
This function looks up a <config-file> tag in the android <platform>, but
that might not exist. iOS does something similar.

There was a similar fix to cordova-cli a couple of months ago, where it was
choking on failing to find any <source-file>s in the android <platform>,
back when I first wrote the refresh plugin.

I'm not trying to blame developers for introducing problems. My goal here
is to get people to remember, when they're working on these tools, that
there are plugins that lack either native code or Javascript code, and that
don't add <plugin> tags to config.xml.

Braden


On Tue, Mar 12, 2013 at 5:36 PM, Anis KADRI <anis.kadri@gmail.com> wrote:

> Dear Braden,
>
> Indeed, plugman assumes that there are javascript files, config files and
> uses a tag in the config file to check whether a plugin is installed or
> not. This is obviously not an ideal solution for javascript only plugins
> that don't have a plugin tag in the config file. You are right. We need a
> better solution to detect the status of javascript/native only plugins. I
> believe we'll solve this problem when we solve the problem of plugin
> dependencies.
>
> However, as much as I like critiques, I like them better when they're
> constructive and I am not sure who you're referring to when you're saying
> "stop writing code" or "people making this implicit assumption". If
> something doesn't work the way you think it should, I suggest you just open
> an issue and describe your problems/frustrations. If you have solution to
> the problem or a pull request that's even better.
>
> Cheers,
>
> -a
>
>
> On Tue, Mar 12, 2013 at 12:56 PM, Braden Shepherdson <braden@chromium.org
> >wrote:
>
> > Well, people keep making this implicit assumption and I have to keep
> fixing
> > it to keep my several JS-only plugins working.
> >
> > The problem with plugman is a higher-level problem. If we want to keep
> > plugman as a separate tool to support building Cordova apps manually,
> then
> > we need a solution to detecting what plugins are installed. I'm not sure
> > what that approach should be.
> >
> >
> > On Tue, Mar 12, 2013 at 3:36 PM, Filip Maj <fil@adobe.com> wrote:
> >
> > > So should we file a plugman issue or is this a bigger problem around
> what
> > > committers are doing? I'm confused, it sounds like someone did
> something
> > > wrong?
> > >
> > > On 3/12/13 2:33 PM, "Braden Shepherdson" <braden@chromium.org> wrote:
> > >
> > > >This is a problem for adding and removing plugins in plugman.
> > cordova-cli
> > > >can use the existence of directories in plugins/ to know what's
> > installed,
> > > >but plugman can't do that. It currently looks for a <plugin> tag
or
> > > ><config-file> tag, and assumes they exist, which causes errors. So
I
> > check
> > > >whether the tag is defined before trying to read attributes from it.
> > > >
> > > >That avoids the error but doesn't solve the problem of knowing what is
> > and
> > > >isn't installed. Plugman just assumes JS-only plugins are never
> > installed,
> > > >so they can be double installed, and can't be removed.
> > > >
> > > >
> > > >On Tue, Mar 12, 2013 at 3:24 PM, Brian LeRoux <b@brian.io> wrote:
> > > >
> > > >> Hey Braden, is there a specific place this happened?
> > > >>
> > > >> On Tue, Mar 12, 2013 at 8:45 AM, Braden Shepherdson
> > > >><braden@chromium.org>
> > > >> wrote:
> > > >> > There are JS-only plugins with no native side. Stop writing code
> > that
> > > >> > expects there will always be a <config-file> or <plugin>
directive
> > in
> > > >> > plugins.xml
> > > >> >
> > > >> > There are native-only plugins with no Javascript, too.
> > > >> >
> > > >> > Braden
> > > >>
> > >
> > >
> >
>

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