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 <bows...@gmail.com> wrote: > On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren <m...@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.
