cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bowser <bows...@gmail.com>
Subject Re: The plugin repos and reality
Date Fri, 05 Apr 2013 19:32:56 GMT
I've updated the CorePlugins update page and added my initial
observations regarding moving the plugins over.  I do agree that it
does feel like we're putting the cart before the horse, but assuming
that we want a 3.0 release, I don't see another option.

https://wiki.apache.org/cordova/Core%20Plugin%20Name%20Proposal

On Fri, Apr 5, 2013 at 12:13 PM, Joe Bowser <bowserj@gmail.com> wrote:
> On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren <maxw@chromium.org> wrote:
>> We should slow this process down a little bit.  Our next step should be to
>> structure the plugins in the existing repos so that the process of
>> relocating them to their individual repos is straightforward.  Trying to do
>> it as we go will be messy and lead to the types of problems that prompted
>> Joe to make this thread to begin with.  Let's not "plugin-ize" anything
>> until we've done the meat of the work in the existing repos.
>>
>
> Part of the problem is that the plugin repositories were decided
> without looking at any of the existing code whatsoever.  We basically
> just grabbed a bunch of drafts and created a bunch of repositories
> without thinking of what should actually go there.  In the past, I
> know that we've talked about killing the App plugin, but the fact is
> that we can't do that because it fills a real need on certain
> platforms, such as Android where we need to override the back button.
> I understand the whole cross-platform thing, but we need to have these
> utility methods in reality if we want Cordova to not suck.
>
>> One major task that will help this process is to ensure that no plugins are
>> coupled.  We can remove visibility from all methods in native code (eg.
>> privatize methods on Android, remove signatures from headers on iOS).  In
>> this way, we can locate and deal with dependencies that will make the
>> eventual plugin migration difficult.
>
> Do we want to do this?  Right now there are shared classes for file
> manipulation that we use that might be useful for other plugin
> developers to also use.  There are certain methods that I would like
> to see die, but making everything private may not be practical, useful
> or even possible for certain plugins.
>
>
>> So let's hold off on actually doing any inter-repository code movement; it
>> should be the final step, and should be done once it essentially already *
>> has* been done in the existing repos.  I don't know that I see the point of
>> rushing to have it done before 3.0.
>>
>
> The fact is that 3.0 is supposed to be plugins.  If we don't have this
> feature, there's no reason to do a 3.0 release, and we might as well
> just call it a 2.10 release.  I know for a fact that a lot of people
> are going to be very unhappy if we don't keep going with this.  The
> question is how do we do this without it being completely ridiculous.
> I wish we started on this last release, because we're running out of
> time now.

Mime
View raw message