cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: The plugin repos and reality
Date Sun, 07 Apr 2013 19:57:53 GMT
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 <shazron@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 <fil@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" <agrieve@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 <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