cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: The plugin repos and reality
Date Sun, 07 Apr 2013 12:47:06 GMT
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 <agrieve@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 <bowserj@gmail.com> wrote:
> > >
> > > > On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren <maxw@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.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message