cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: The plugin repos and reality
Date Mon, 15 Apr 2013 17:31:52 GMT
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
View raw message