Same position as Braden. We can always add this later. There are more urgent issues right now like fixing the uninstall action and plugin dependencies.
On Mon, Apr 15, 2013 at 10:46 AM, Braden Shepherdson <bra...@chromium.org>wrote: > Hrm. I don't see specifying it as so terrible. It would also unify the > <source-file> directive and its target-dir parameter between iOS and > Android: specifying paths relative to some src directory inside the bundle. > > My intern mentioned today that if you have #include "somesubdir/foo.h" or > any other paths, it will fail when we go dumping everything into Plugins/. > So I at least support maintaining relative positions. I guess I'm > indifferent about whether specifying it vs. just copying it into Plugins/ > my.plugin.id/somesubdir/foo.h > > Braden > > > On Mon, Apr 15, 2013 at 1:31 PM, Filip Maj <f...@adobe.com> wrote: > > > So it looks like for iOS plugman support there is one outstanding issue > > Shaz has: > > > > https://issues.apache.org/jira/browse/CB-2717 > > > > > > Re: default installation of iOS code into plugins folder. > > > > Braden & Anis can you comment? This looks like it would need a tweak in > > the spec so I would like to get other people's eyes on this. > > > > On 4/8/13 7:44 AM, "Shazron" <shaz...@gmail.com> wrote: > > > > > Thanks Anis and Fil! If you need help, I suppose you could assign some > > >starter issues so I can get a feel for the codebase > > > > > > > > >On Sun, Apr 7, 2013 at 5:33 PM, Filip Maj <f...@adobe.com> wrote: > > > > > >> I will take a look Shaz. I'll update that in a separate thread where > we > > >> can put more discussion into task details and separation of work. > > >> > > >> On 4/7/13 12:57 PM, "Anis KADRI" <anis.ka...@gmail.com> wrote: > > >> > > >> >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. > > >> >> > >> > > > > > >> >> > >> > > > > >> >> > >> > > > >> >> > >> > > >> >> > > > >> >> > > > >> >> > > >> > > >> > > > > >
