To summarize: - yes plugman needs more work before we can utilize standalone plugins.
We have several committers working on this. There are issues filed in JIRA (mainly assigned to Braden, Tim and me). With this being the blocker to moving to a bare bridge implementation of Cordova, anyone is free to jump in and help there :). All of the plugman must-have features are tagged with "future" so do a search fro that in the JIRA if you want to help out. - people concerned about doing too much right now To reiterate Brian's point, let's take it slow. Go one plugin at a time. We have 3-4 months before the slated 3.0 release. - code living in two spots at once This one is tricky, but IMO code living in two spots isn't a massive deal at this point. The benefits to having plugin code, until we hit 3.0, live in two spots at once is: * for 2.7, 2.8, 2.9, users of cordova will still get the standard APIs which they expect * we have testable plugin code that can help the development of plugman and cli The downside is clear: code in two spots. As long as the structure of the plugin code in the plugin repo is solid (I.e. Has a plugin.xml, and base functionality is provided for the native bits), I would be satisfied. That would be good enough for plugins being used as test fixtures. Finally, once we are ready to remove all of the plugins from the core repos (say, a few months down the road, around the time of 3.0.0rc1), we can do it in one fell swoop, and move over any bug fixes / features landed in the core repos for the plugins into the plugin repos. My $0.02. On 4/7/13 5:47 AM, "Andrew Grieve" <agri...@chromium.org> wrote: >I like the idea, but I think we should make sure that it will work before >pulling out the plugins. E.g. plugin JS undergo a different transformation >with the new system than with Jake. I think they'll function fine if we >pluginstall it into our project *templates*, but for people performing >upgrades, it'll be more complicated. Another tricky bit is ARC. We >previously discussed holding off changing the default template to ARC >until >3.0. Until we do though, core plugins will not compile if added to them. >Instead, they need to be added to the CordovaLib project, but their assets >still need to be added to their top-level project. > >I think we can still get to the state where we bundle in plugins during >packaging, but I want to avoid having code alive in two spots at once if >possible. E.g. if we move out the java code for Accelerometer, then we >should delete it from cordova-android. Before we do this though, plugman >needs a bit more work on it and and also on the coho tool. E.g. plugman >right now only works with plugin JS if you're using the "future" branch. > > >On Fri, Apr 5, 2013 at 4:40 PM, Brian LeRoux <b...@brian.io> wrote: > >> Those should be rolled back in by the COHO tool (using the plugman tool) >> for the phonegap dist. >> >> >> On Fri, Apr 5, 2013 at 1:24 PM, Andrew Grieve <agri...@chromium.org> >> wrote: >> >> > I agree that moving plugins into repos isn't tied to API audits, but >> > doesn't moving plugins gradually prevent our ability to do releases? >>E.g. >> > 2.7 is missing two plugins since they were moved into different repos. >> > >> > >> > On Fri, Apr 5, 2013 at 4:20 PM, Brian LeRoux <b...@brian.io> wrote: >> > >> > > That synopsis on the wiki was super helpful Joe. I think we should >>stop >> > > thinking we have to do EVERYTHING ALL AT ONCE. We do not need to >>audit >> > any >> > > apis. We do not need to update anything before moving into plugins. >> > > >> > > We need to slowly move a plugin at a time, keep their current APIs, >>and >> > > methodically move to the next API. >> > > >> > > Anything that does not fit: don't move it out. We'll deal w/ it >>later. >> It >> > > looks like everything 'with specs' can be moved with relative ease. >> Start >> > > there. Worry about the rest when you get there. I suspect that is >> plenty >> > to >> > > try to achieve in the meantime. >> > > >> > > >> > > >> > > On Fri, Apr 5, 2013 at 12:51 PM, Joe Bowser <bows...@gmail.com> >>wrote: >> > > >> > > > On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren <m...@chromium.org> >> > wrote: >> > > > > >> > > > > In Android, I've split out common File code into a FileHelper >> class. >> > > > It's >> > > > > not a plugin, and will be exposed to developers. This is the >>only >> > > > > shared-code example I know of, but if we find others (via the >> > > visibility >> > > > > removal test), we can similarly pull out the common code. >> > > > > >> > > > >> > > > There's a lot of code that's meant to be public on CordovaWebView, >> > > > since CordovaWebView is supposed to be a stand-alone component >>that's >> > > > embeddable in other Android projects. We really need to decide >>what >> > > > to expose. I also want to see DroidGap paired down and gone, >>since I >> > > > don't want people messing with anything in that class at all. >> > > > >> > > > Other than that, I can't think of any Android code that should be >> > > > public. That being said, I think we're getting off-topic. I >>think we >> > > > need to start on the dreaded API audit that we've been putting >>off. >> > > > It's clear that every plugin will need to be updated to the new >>spec >> > > > before we do this exercise. >> > > > >> > > >> > >>
