cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Braden Shepherdson <bra...@chromium.org>
Subject Re: The plugin repos and reality
Date Mon, 15 Apr 2013 17:46:40 GMT
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 <fil@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" <shazron@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 <fil@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.kadri@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 <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