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. > >> >> > >> > > > > >> >> > >> > > > >> >> > >> > > >> >> > >> > >> >> > > >> >> > > >> >> > >> > >> > >
