CB-2727 && CB-2719 <https://issues.apache.org/jira/browse/CB-2719> are resolved shaz (in master not future). I will take care of CB-2717 && CB-2718 this week.
On Sun, Apr 7, 2013 at 11:59 AM, Shazron <shaz...@gmail.com> wrote: > Fil, > I have some issues filed for plugman: http://cl.ly/O7Th > I'd like to contribute but since we have many cooks here, I don't know if I > will be treading on some code that is going to change anyway. Some of them > filed are critical for iOS, but not labeled with 'future'. Can you take a > quick glance and see where the issues fit in the scheme of things? > > > > On Sun, Apr 7, 2013 at 11:14 AM, Filip Maj <f...@adobe.com> wrote: > > > 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. > > >> > > > > > >> > > > > >> > > > >> > > > > >
