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 Mon, 15 Apr 2013 18:51:15 GMT
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 <braden@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 <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