Re: The plugin repos and reality

[Anis KADRI]

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 wrote:

> Hrm. I don't see specifying it as so terrible. It would also unify the
>  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  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"  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  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"  wrote:
> > >>
> > >> >CB-2727 && 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  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  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"  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

Re: The plugin repos and reality

[Braden Shepherdson]

Hrm. I don't see specifying it as so terrible. It would also unify the
 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  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"  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  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"  wrote:
> >>
> >> >CB-2727 && 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  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  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"  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

Re: The plugin repos and reality

[Filip Maj]

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"  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  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"  wrote:
>>
>> >CB-2727 && 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  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  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"  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  wrote:
>> >> > >
>> >> > >> Those should be rolled back in by the COHO tool (using the
>>plugman
>> >> tool)
>> >> > >> f

Re: The plugin repos and reality

[Shazron]

 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  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"  wrote:
>
> >CB-2727 && 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  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  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"  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  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
> >>
> >> > >> 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  wrote:
> >> > >> >
> >> > >> > > That 

Re: The plugin repos and reality

[Filip Maj]

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"  wrote:

>CB-2727 && 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  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  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"  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  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
>>
>> > >> 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  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.
>> > >> > >
>> > >> > > Anyth

Re: The plugin repos and reality

[Anis KADRI]

CB-2727 && 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  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  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"  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  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 
> > >> 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  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.
> > >> > >
> > >> > >
> > >> > >

Re: The plugin repos and reality

[Shazron]

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  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"  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  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 
> >> 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  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 
> >>wrote:
> >> > >
> >> > > > On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren 
> >> > 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
> >> > > >

Re: The plugin repos and reality

[Filip Maj]

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"  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  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 
>> 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  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 
>>wrote:
>> > >
>> > > > On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren 
>> > 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.  

Re: The plugin repos and reality

[Andrew Grieve]

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  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 
> 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  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  wrote:
> > >
> > > > On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren 
> > 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.
> > > >
> > >
> >
>

Re: The plugin repos and reality

[Brian LeRoux]

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  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  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  wrote:
> >
> > > On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren 
> 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.
> > >
> >
>

Re: The plugin repos and reality

[Andrew Grieve]

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  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  wrote:
>
> > On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren  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.
> >
>

Re: The plugin repos and reality

[Brian LeRoux]

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  wrote:

> On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren  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.
>

Re: The plugin repos and reality

[Joe Bowser]

On Fri, Apr 5, 2013 at 12:34 PM, Max Woghiren  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.

Re: The plugin repos and reality

[Michal Mocny]

Warning: ** I'm not suggesting it, I'm not proposing it ** but, I'll chime
in to say that we could still potentially ship 3.0 entirely using the new
plugin architecture but without splitting core plugins into individual
repos.  We could move them out of cordova-js, but still keep them together
in one repo (remember: we decided to support multiple plugins to live in
subdirectories of one repo).

>From a cordova-cli perspective it would be functionally equivalent, so why
prematurely take the option off the table even if there is only a slim
chance we decide to take that route.  Splitting core plugins into separate
repos seems to be a versioning decision, really, and for as long as we
version them together why not leave them together.

-Michal


On Fri, Apr 5, 2013 at 3:34 PM, Max Woghiren  wrote:

> I agree with a lot of what you said.
>
> On Fri, Apr 5, 2013 at 3:13 PM, Joe Bowser  wrote:
>
> > On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren  wrote:
> > > We should slow this process down a little bit.  Our next step should be
> > to
> > > structure the plugins in the existing repos so that the process of
> > > relocating them to their individual repos is straightforward.  Trying
> to
> > do
> > > it as we go will be messy and lead to the types of problems that
> prompted
> > > Joe to make this thread to begin with.  Let's not "plugin-ize" anything
> > > until we've done the meat of the work in the existing repos.
> >
> > Part of the problem is that the plugin repositories were decided
> > without looking at any of the existing code whatsoever.  We basically
> > just grabbed a bunch of drafts and created a bunch of repositories
> > without thinking of what should actually go there.  In the past, I
> > know that we've talked about killing the App plugin, but the fact is
> > that we can't do that because it fills a real need on certain
> > platforms, such as Android where we need to override the back button.
> > I understand the whole cross-platform thing, but we need to have these
> > utility methods in reality if we want Cordova to not suck.
> >
>
> You're totally right.  I think that hastily creating the plugin repos was a
> mistake.
>
> I think we should do the majority of the work within the existing repos.
>  This will culminate with us having properly determined what our plugins
> should be.  Then we can accurately make the correct plugin repos.
>
> At this point, we can just do as Fil mentioned and request some repo
> additions/removals/renamings.
>
> In the case of the App plugin, it appears that not creating a repo was a
> deliberate decision.  The conversation Andrew linked to has "app"
> explicitly listed as a plugin not getting its own repo.  I don't think the
> desire at this point is to kill it, but to keep it bundled as a plugin in
> core Cordova.
>
>
> > > One major task that will help this process is to ensure that no plugins
> > are
> > > coupled.  We can remove visibility from all methods in native code (eg.
> > > privatize methods on Android, remove signatures from headers on iOS).
>  In
> > > this way, we can locate and deal with dependencies that will make the
> > > eventual plugin migration difficult.
> >
> > Do we want to do this?  Right now there are shared classes for file
> > manipulation that we use that might be useful for other plugin
> > developers to also use.  There are certain methods that I would like
> > to see die, but making everything private may not be practical, useful
> > or even possible for certain plugins.
>
>
> You're right again.
>
> 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.
>
>
> > > So let's hold off on actually doing any inter-repository code movement;
> > it
> > > should be the final step, and should be done once it essentially
> already
> > *
> > > has* been done in the existing repos.  I don't know that I see the
> point
> > of
> > > rushing to have it done before 3.0.
> >
> > The fact is that 3.0 is supposed to be plugins.  If we don't have this
> > feature, there's no reason to do a 3.0 release, and we might as well
> > just call it a 2.10 release.  I know for a fact that a lot of people
> > are going to be very unhappy if we don't keep going with this.  The
> > question is how do we do this without it being completely ridiculous.
> > I wish we started on this last release, because we're running out of
> > time now.
> >
>
> Agreed a third time.  3.0 will be plugins, and so 3.0 can be the
> introduction of the individual plugin repos.  Why aim for this in 2.7 (or
> 2.x, for that matter)?
>
> To do this without it being completely ridiculous, we pace ourselves and do
> this work in a structured way.  No one is expecting this until 3.0, so
> let's spend the interim releases solving these problems.
>

Re: The plugin repos and reality

[Max Woghiren]

I agree with a lot of what you said.

On Fri, Apr 5, 2013 at 3:13 PM, Joe Bowser  wrote:

> On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren  wrote:
> > We should slow this process down a little bit.  Our next step should be
> to
> > structure the plugins in the existing repos so that the process of
> > relocating them to their individual repos is straightforward.  Trying to
> do
> > it as we go will be messy and lead to the types of problems that prompted
> > Joe to make this thread to begin with.  Let's not "plugin-ize" anything
> > until we've done the meat of the work in the existing repos.
>
> Part of the problem is that the plugin repositories were decided
> without looking at any of the existing code whatsoever.  We basically
> just grabbed a bunch of drafts and created a bunch of repositories
> without thinking of what should actually go there.  In the past, I
> know that we've talked about killing the App plugin, but the fact is
> that we can't do that because it fills a real need on certain
> platforms, such as Android where we need to override the back button.
> I understand the whole cross-platform thing, but we need to have these
> utility methods in reality if we want Cordova to not suck.
>

You're totally right.  I think that hastily creating the plugin repos was a
mistake.

I think we should do the majority of the work within the existing repos.
 This will culminate with us having properly determined what our plugins
should be.  Then we can accurately make the correct plugin repos.

At this point, we can just do as Fil mentioned and request some repo
additions/removals/renamings.

In the case of the App plugin, it appears that not creating a repo was a
deliberate decision.  The conversation Andrew linked to has "app"
explicitly listed as a plugin not getting its own repo.  I don't think the
desire at this point is to kill it, but to keep it bundled as a plugin in
core Cordova.


> > One major task that will help this process is to ensure that no plugins
> are
> > coupled.  We can remove visibility from all methods in native code (eg.
> > privatize methods on Android, remove signatures from headers on iOS).  In
> > this way, we can locate and deal with dependencies that will make the
> > eventual plugin migration difficult.
>
> Do we want to do this?  Right now there are shared classes for file
> manipulation that we use that might be useful for other plugin
> developers to also use.  There are certain methods that I would like
> to see die, but making everything private may not be practical, useful
> or even possible for certain plugins.


You're right again.

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.


> > So let's hold off on actually doing any inter-repository code movement;
> it
> > should be the final step, and should be done once it essentially already
> *
> > has* been done in the existing repos.  I don't know that I see the point
> of
> > rushing to have it done before 3.0.
>
> The fact is that 3.0 is supposed to be plugins.  If we don't have this
> feature, there's no reason to do a 3.0 release, and we might as well
> just call it a 2.10 release.  I know for a fact that a lot of people
> are going to be very unhappy if we don't keep going with this.  The
> question is how do we do this without it being completely ridiculous.
> I wish we started on this last release, because we're running out of
> time now.
>

Agreed a third time.  3.0 will be plugins, and so 3.0 can be the
introduction of the individual plugin repos.  Why aim for this in 2.7 (or
2.x, for that matter)?

To do this without it being completely ridiculous, we pace ourselves and do
this work in a structured way.  No one is expecting this until 3.0, so
let's spend the interim releases solving these problems.

Re: The plugin repos and reality

[Joe Bowser]

I've updated the CorePlugins update page and added my initial
observations regarding moving the plugins over.  I do agree that it
does feel like we're putting the cart before the horse, but assuming
that we want a 3.0 release, I don't see another option.

https://wiki.apache.org/cordova/Core%20Plugin%20Name%20Proposal

On Fri, Apr 5, 2013 at 12:13 PM, Joe Bowser  wrote:
> On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren  wrote:
>> We should slow this process down a little bit.  Our next step should be to
>> structure the plugins in the existing repos so that the process of
>> relocating them to their individual repos is straightforward.  Trying to do
>> it as we go will be messy and lead to the types of problems that prompted
>> Joe to make this thread to begin with.  Let's not "plugin-ize" anything
>> until we've done the meat of the work in the existing repos.
>>
>
> Part of the problem is that the plugin repositories were decided
> without looking at any of the existing code whatsoever.  We basically
> just grabbed a bunch of drafts and created a bunch of repositories
> without thinking of what should actually go there.  In the past, I
> know that we've talked about killing the App plugin, but the fact is
> that we can't do that because it fills a real need on certain
> platforms, such as Android where we need to override the back button.
> I understand the whole cross-platform thing, but we need to have these
> utility methods in reality if we want Cordova to not suck.
>
>> One major task that will help this process is to ensure that no plugins are
>> coupled.  We can remove visibility from all methods in native code (eg.
>> privatize methods on Android, remove signatures from headers on iOS).  In
>> this way, we can locate and deal with dependencies that will make the
>> eventual plugin migration difficult.
>
> Do we want to do this?  Right now there are shared classes for file
> manipulation that we use that might be useful for other plugin
> developers to also use.  There are certain methods that I would like
> to see die, but making everything private may not be practical, useful
> or even possible for certain plugins.
>
>
>> So let's hold off on actually doing any inter-repository code movement; it
>> should be the final step, and should be done once it essentially already *
>> has* been done in the existing repos.  I don't know that I see the point of
>> rushing to have it done before 3.0.
>>
>
> The fact is that 3.0 is supposed to be plugins.  If we don't have this
> feature, there's no reason to do a 3.0 release, and we might as well
> just call it a 2.10 release.  I know for a fact that a lot of people
> are going to be very unhappy if we don't keep going with this.  The
> question is how do we do this without it being completely ridiculous.
> I wish we started on this last release, because we're running out of
> time now.

Re: The plugin repos and reality

[Joe Bowser]

On Fri, Apr 5, 2013 at 12:00 PM, Max Woghiren  wrote:
> We should slow this process down a little bit.  Our next step should be to
> structure the plugins in the existing repos so that the process of
> relocating them to their individual repos is straightforward.  Trying to do
> it as we go will be messy and lead to the types of problems that prompted
> Joe to make this thread to begin with.  Let's not "plugin-ize" anything
> until we've done the meat of the work in the existing repos.
>

Part of the problem is that the plugin repositories were decided
without looking at any of the existing code whatsoever.  We basically
just grabbed a bunch of drafts and created a bunch of repositories
without thinking of what should actually go there.  In the past, I
know that we've talked about killing the App plugin, but the fact is
that we can't do that because it fills a real need on certain
platforms, such as Android where we need to override the back button.
I understand the whole cross-platform thing, but we need to have these
utility methods in reality if we want Cordova to not suck.

> One major task that will help this process is to ensure that no plugins are
> coupled.  We can remove visibility from all methods in native code (eg.
> privatize methods on Android, remove signatures from headers on iOS).  In
> this way, we can locate and deal with dependencies that will make the
> eventual plugin migration difficult.

Do we want to do this?  Right now there are shared classes for file
manipulation that we use that might be useful for other plugin
developers to also use.  There are certain methods that I would like
to see die, but making everything private may not be practical, useful
or even possible for certain plugins.


> So let's hold off on actually doing any inter-repository code movement; it
> should be the final step, and should be done once it essentially already *
> has* been done in the existing repos.  I don't know that I see the point of
> rushing to have it done before 3.0.
>

The fact is that 3.0 is supposed to be plugins.  If we don't have this
feature, there's no reason to do a 3.0 release, and we might as well
just call it a 2.10 release.  I know for a fact that a lot of people
are going to be very unhappy if we don't keep going with this.  The
question is how do we do this without it being completely ridiculous.
I wish we started on this last release, because we're running out of
time now.

Re: The plugin repos and reality

[Max Woghiren]

I should add that in the meantime, we can still test plugman and cli with
some non-core plugins—for instance, chrome-cordova
pluginshave
already been pluginized.


On Fri, Apr 5, 2013 at 3:00 PM, Max Woghiren  wrote:

> We should slow this process down a little bit.  Our next step should be to
> structure the plugins in the existing repos so that the process of
> relocating them to their individual repos is straightforward.  Trying to do
> it as we go will be messy and lead to the types of problems that prompted
> Joe to make this thread to begin with.  Let's not "plugin-ize" anything
> until we've done the meat of the work in the existing repos.
>
> One major task that will help this process is to ensure that no plugins
> are coupled.  We can remove visibility from all methods in native code (eg.
> privatize methods on Android, remove signatures from headers on iOS).  In
> this way, we can locate and deal with dependencies that will make the
> eventual plugin migration difficult.
>
> In Javascript, most of the work is already done.  We just need to create
> plugin.xml for each of the plugins (once we've truly determined what they
> should be).
>
> So let's hold off on actually doing any inter-repository code movement; it
> should be the final step, and should be done once it essentially already *
> has* been done in the existing repos.  I don't know that I see the point
> of rushing to have it done before 3.0.
>
>
> On Fri, Apr 5, 2013 at 10:32 AM, Lucas Holmquist wrote:
>
>> Is there currently a list of plugins that can be moved,  i can start to
>> move some,  but don't want to repeat what someone has done already
>> On Apr 3, 2013, at 3:53 PM, Brian LeRoux  wrote:
>>
>> > Agree w/ Anis. Just move what can be moved and file up tickets for
>> > that which cannot be done in the immediate term / that is in the
>> > 'official' list of plugins.
>> >
>> > On Wed, Apr 3, 2013 at 11:27 AM, Anis KADRI 
>> wrote:
>> >> I think a good first pass is to plugin-ize what is plugin-izable and
>> leave
>> >> everything else (platform specific code) as part of the 'core'
>> >> implementation. Things will never exactly be exactly the same across
>> >> platforms in my opinion.
>> >>
>> >>
>> >> On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser  wrote:
>> >>
>> >>> Hey
>> >>>
>> >>> I've started moving the various Android plugins into their
>> >>> corresponding repositories, and it seems that these were made up, and
>> >>> that they don't really correspond to what exists in the code today.  I
>> >>> don't think that it's realistic for us to get this done for 2.7
>> >>> because there are certain plugins that don't have a home (i.e. App,
>> >>> Compass, AudioPlayer, Echo) and others that don't make any sense to
>> >>> have (i.e. Console, Vibration) or are unclear (Media).
>> >>>
>> >>> Also, at least for Android, we're going to have to nail down a Java
>> >>> API.  Many of the plugins use some common code for file manipulation
>> >>> such as the Capture, Camera and of course the File APIs. It would be
>> >>> good to actually expose them to plugin developers so that we're all on
>> >>> the same page as to where files should and should not go.
>> >>>
>> >>> It would have been good to create the repositories based on what we
>> >>> already have implemented more or less, and to go from there.  That
>> >>> being said, I don't know if there is a one-to-one mapping between
>> >>> Android and iOS components, let alone any of the other platforms.
>> >>>
>> >>> Anyone else have thoughts on this?
>> >>>
>> >>> Joe
>> >>>
>>
>>
>

Re: The plugin repos and reality

[Max Woghiren]

We should slow this process down a little bit.  Our next step should be to
structure the plugins in the existing repos so that the process of
relocating them to their individual repos is straightforward.  Trying to do
it as we go will be messy and lead to the types of problems that prompted
Joe to make this thread to begin with.  Let's not "plugin-ize" anything
until we've done the meat of the work in the existing repos.

One major task that will help this process is to ensure that no plugins are
coupled.  We can remove visibility from all methods in native code (eg.
privatize methods on Android, remove signatures from headers on iOS).  In
this way, we can locate and deal with dependencies that will make the
eventual plugin migration difficult.

In Javascript, most of the work is already done.  We just need to create
plugin.xml for each of the plugins (once we've truly determined what they
should be).

So let's hold off on actually doing any inter-repository code movement; it
should be the final step, and should be done once it essentially already *
has* been done in the existing repos.  I don't know that I see the point of
rushing to have it done before 3.0.


On Fri, Apr 5, 2013 at 10:32 AM, Lucas Holmquist wrote:

> Is there currently a list of plugins that can be moved,  i can start to
> move some,  but don't want to repeat what someone has done already
> On Apr 3, 2013, at 3:53 PM, Brian LeRoux  wrote:
>
> > Agree w/ Anis. Just move what can be moved and file up tickets for
> > that which cannot be done in the immediate term / that is in the
> > 'official' list of plugins.
> >
> > On Wed, Apr 3, 2013 at 11:27 AM, Anis KADRI 
> wrote:
> >> I think a good first pass is to plugin-ize what is plugin-izable and
> leave
> >> everything else (platform specific code) as part of the 'core'
> >> implementation. Things will never exactly be exactly the same across
> >> platforms in my opinion.
> >>
> >>
> >> On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser  wrote:
> >>
> >>> Hey
> >>>
> >>> I've started moving the various Android plugins into their
> >>> corresponding repositories, and it seems that these were made up, and
> >>> that they don't really correspond to what exists in the code today.  I
> >>> don't think that it's realistic for us to get this done for 2.7
> >>> because there are certain plugins that don't have a home (i.e. App,
> >>> Compass, AudioPlayer, Echo) and others that don't make any sense to
> >>> have (i.e. Console, Vibration) or are unclear (Media).
> >>>
> >>> Also, at least for Android, we're going to have to nail down a Java
> >>> API.  Many of the plugins use some common code for file manipulation
> >>> such as the Capture, Camera and of course the File APIs. It would be
> >>> good to actually expose them to plugin developers so that we're all on
> >>> the same page as to where files should and should not go.
> >>>
> >>> It would have been good to create the repositories based on what we
> >>> already have implemented more or less, and to go from there.  That
> >>> being said, I don't know if there is a one-to-one mapping between
> >>> Android and iOS components, let alone any of the other platforms.
> >>>
> >>> Anyone else have thoughts on this?
> >>>
> >>> Joe
> >>>
>
>

Re: The plugin repos and reality

[Lucas Holmquist]

Is there currently a list of plugins that can be moved,  i can start to move 
some,  but don't want to repeat what someone has done already
On Apr 3, 2013, at 3:53 PM, Brian LeRoux  wrote:

> Agree w/ Anis. Just move what can be moved and file up tickets for
> that which cannot be done in the immediate term / that is in the
> 'official' list of plugins.
> 
> On Wed, Apr 3, 2013 at 11:27 AM, Anis KADRI  wrote:
>> I think a good first pass is to plugin-ize what is plugin-izable and leave
>> everything else (platform specific code) as part of the 'core'
>> implementation. Things will never exactly be exactly the same across
>> platforms in my opinion.
>> 
>> 
>> On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser  wrote:
>> 
>>> Hey
>>> 
>>> I've started moving the various Android plugins into their
>>> corresponding repositories, and it seems that these were made up, and
>>> that they don't really correspond to what exists in the code today.  I
>>> don't think that it's realistic for us to get this done for 2.7
>>> because there are certain plugins that don't have a home (i.e. App,
>>> Compass, AudioPlayer, Echo) and others that don't make any sense to
>>> have (i.e. Console, Vibration) or are unclear (Media).
>>> 
>>> Also, at least for Android, we're going to have to nail down a Java
>>> API.  Many of the plugins use some common code for file manipulation
>>> such as the Capture, Camera and of course the File APIs. It would be
>>> good to actually expose them to plugin developers so that we're all on
>>> the same page as to where files should and should not go.
>>> 
>>> It would have been good to create the repositories based on what we
>>> already have implemented more or less, and to go from there.  That
>>> being said, I don't know if there is a one-to-one mapping between
>>> Android and iOS components, let alone any of the other platforms.
>>> 
>>> Anyone else have thoughts on this?
>>> 
>>> Joe
>>> 

Re: The plugin repos and reality

[Andrew Grieve]

for netinfo, I think it's fine to not delay deviceready since we can just
set it to "unknown" at the start.

For device though, if we're not going to delay deviceready, then we should
remove the "device" symbol being exposed so that the only way to get to the
properties is through the async API. For this, probably step one would be
to deprecate the device symbol.


On Wed, Apr 3, 2013 at 11:31 PM, Andrew Grieve  wrote:

> I think we mostly had this names discussion already:
>
> http://callback.markmail.org/thread/cgvj6cnu7dna7umj#query:+page:1+mid:pz23mpifkcyewv2e+state:results
>
> In terms of moving files out, I think we should go slowly and just focus
> on 1 or 2 until we get it right. I'm a bit worried that bugfixes will need
> to be applied to both repos until we get to 3.0.
>
> Although, maybe another option is to package plugin files that have been
> moved into their own repos back into the core repos as a part of the
> release bundling process? That way we won't have two copies of things?
>
>
>
> On Wed, Apr 3, 2013 at 8:26 PM, Shazron  wrote:
>
>> Forgive me if this was already discussed, for the plugins:
>> 1. cordova-plugin-device
>> 2. cordova-plugin-network-information
>>
>> deviceready event being dispatched will not be dependent on these two
>> anymore right? At least on iOS it is currently.
>>
>>
>>
>> On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser  wrote:
>>
>> > Hey
>> >
>> > I've started moving the various Android plugins into their
>> > corresponding repositories, and it seems that these were made up, and
>> > that they don't really correspond to what exists in the code today.  I
>> > don't think that it's realistic for us to get this done for 2.7
>> > because there are certain plugins that don't have a home (i.e. App,
>> > Compass, AudioPlayer, Echo) and others that don't make any sense to
>> > have (i.e. Console, Vibration) or are unclear (Media).
>> >
>> > Also, at least for Android, we're going to have to nail down a Java
>> > API.  Many of the plugins use some common code for file manipulation
>> > such as the Capture, Camera and of course the File APIs. It would be
>> > good to actually expose them to plugin developers so that we're all on
>> > the same page as to where files should and should not go.
>> >
>> > It would have been good to create the repositories based on what we
>> > already have implemented more or less, and to go from there.  That
>> > being said, I don't know if there is a one-to-one mapping between
>> > Android and iOS components, let alone any of the other platforms.
>> >
>> > Anyone else have thoughts on this?
>> >
>> > Joe
>> >
>>
>
>

Re: The plugin repos and reality

[Andrew Grieve]

I think we mostly had this names discussion already:
http://callback.markmail.org/thread/cgvj6cnu7dna7umj#query:+page:1+mid:pz23mpifkcyewv2e+state:results

In terms of moving files out, I think we should go slowly and just focus on
1 or 2 until we get it right. I'm a bit worried that bugfixes will need to
be applied to both repos until we get to 3.0.

Although, maybe another option is to package plugin files that have been
moved into their own repos back into the core repos as a part of the
release bundling process? That way we won't have two copies of things?



On Wed, Apr 3, 2013 at 8:26 PM, Shazron  wrote:

> Forgive me if this was already discussed, for the plugins:
> 1. cordova-plugin-device
> 2. cordova-plugin-network-information
>
> deviceready event being dispatched will not be dependent on these two
> anymore right? At least on iOS it is currently.
>
>
>
> On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser  wrote:
>
> > Hey
> >
> > I've started moving the various Android plugins into their
> > corresponding repositories, and it seems that these were made up, and
> > that they don't really correspond to what exists in the code today.  I
> > don't think that it's realistic for us to get this done for 2.7
> > because there are certain plugins that don't have a home (i.e. App,
> > Compass, AudioPlayer, Echo) and others that don't make any sense to
> > have (i.e. Console, Vibration) or are unclear (Media).
> >
> > Also, at least for Android, we're going to have to nail down a Java
> > API.  Many of the plugins use some common code for file manipulation
> > such as the Capture, Camera and of course the File APIs. It would be
> > good to actually expose them to plugin developers so that we're all on
> > the same page as to where files should and should not go.
> >
> > It would have been good to create the repositories based on what we
> > already have implemented more or less, and to go from there.  That
> > being said, I don't know if there is a one-to-one mapping between
> > Android and iOS components, let alone any of the other platforms.
> >
> > Anyone else have thoughts on this?
> >
> > Joe
> >
>

Re: The plugin repos and reality

[Shazron]

Forgive me if this was already discussed, for the plugins:
1. cordova-plugin-device
2. cordova-plugin-network-information

deviceready event being dispatched will not be dependent on these two
anymore right? At least on iOS it is currently.



On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser  wrote:

> Hey
>
> I've started moving the various Android plugins into their
> corresponding repositories, and it seems that these were made up, and
> that they don't really correspond to what exists in the code today.  I
> don't think that it's realistic for us to get this done for 2.7
> because there are certain plugins that don't have a home (i.e. App,
> Compass, AudioPlayer, Echo) and others that don't make any sense to
> have (i.e. Console, Vibration) or are unclear (Media).
>
> Also, at least for Android, we're going to have to nail down a Java
> API.  Many of the plugins use some common code for file manipulation
> such as the Capture, Camera and of course the File APIs. It would be
> good to actually expose them to plugin developers so that we're all on
> the same page as to where files should and should not go.
>
> It would have been good to create the repositories based on what we
> already have implemented more or less, and to go from there.  That
> being said, I don't know if there is a one-to-one mapping between
> Android and iOS components, let alone any of the other platforms.
>
> Anyone else have thoughts on this?
>
> Joe
>

Re: The plugin repos and reality

[Brian LeRoux]

Agree w/ Anis. Just move what can be moved and file up tickets for
that which cannot be done in the immediate term / that is in the
'official' list of plugins.

On Wed, Apr 3, 2013 at 11:27 AM, Anis KADRI  wrote:
> I think a good first pass is to plugin-ize what is plugin-izable and leave
> everything else (platform specific code) as part of the 'core'
> implementation. Things will never exactly be exactly the same across
> platforms in my opinion.
>
>
> On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser  wrote:
>
>> Hey
>>
>> I've started moving the various Android plugins into their
>> corresponding repositories, and it seems that these were made up, and
>> that they don't really correspond to what exists in the code today.  I
>> don't think that it's realistic for us to get this done for 2.7
>> because there are certain plugins that don't have a home (i.e. App,
>> Compass, AudioPlayer, Echo) and others that don't make any sense to
>> have (i.e. Console, Vibration) or are unclear (Media).
>>
>> Also, at least for Android, we're going to have to nail down a Java
>> API.  Many of the plugins use some common code for file manipulation
>> such as the Capture, Camera and of course the File APIs. It would be
>> good to actually expose them to plugin developers so that we're all on
>> the same page as to where files should and should not go.
>>
>> It would have been good to create the repositories based on what we
>> already have implemented more or less, and to go from there.  That
>> being said, I don't know if there is a one-to-one mapping between
>> Android and iOS components, let alone any of the other platforms.
>>
>> Anyone else have thoughts on this?
>>
>> Joe
>>

Re: The plugin repos and reality

[Anis KADRI]

I think a good first pass is to plugin-ize what is plugin-izable and leave
everything else (platform specific code) as part of the 'core'
implementation. Things will never exactly be exactly the same across
platforms in my opinion.


On Wed, Apr 3, 2013 at 11:17 AM, Joe Bowser  wrote:

> Hey
>
> I've started moving the various Android plugins into their
> corresponding repositories, and it seems that these were made up, and
> that they don't really correspond to what exists in the code today.  I
> don't think that it's realistic for us to get this done for 2.7
> because there are certain plugins that don't have a home (i.e. App,
> Compass, AudioPlayer, Echo) and others that don't make any sense to
> have (i.e. Console, Vibration) or are unclear (Media).
>
> Also, at least for Android, we're going to have to nail down a Java
> API.  Many of the plugins use some common code for file manipulation
> such as the Capture, Camera and of course the File APIs. It would be
> good to actually expose them to plugin developers so that we're all on
> the same page as to where files should and should not go.
>
> It would have been good to create the repositories based on what we
> already have implemented more or less, and to go from there.  That
> being said, I don't know if there is a one-to-one mapping between
> Android and iOS components, let alone any of the other platforms.
>
> Anyone else have thoughts on this?
>
> Joe
>

Re: The plugin repos and reality

[Filip Maj]

We can file infra requests to modify names / add more repos for plugins as
needed, so that shouldn't be an issue. Some plugins may not be completely
cross-platform (debug console, for example, will likely only have iOS
native code).

As for landing it all in 2.7: also not a big deal. We can try to get it
done for 2.8. Or 2.9. Hopefully for 3.0 :)

It seems reasonable to extract code that is commonly used by various
plugins into some kind of a Cordova utils class (or something). Since
you're starting down this path already Joe, you probably have the clearest
idea of where to go from here. Perhaps start writing down the issues you
see in a new wiki page, and then we can all take a look and come up with
some kind of proposal for a blessed Java API for cordova-android? The
other platforms I'm sure will come across similar (but maybe not exactly
the same) issues so this is a good exercise to go through earlier rather
than later.

On 4/3/13 2:17 PM, "Joe Bowser"  wrote:

>Hey
>
>I've started moving the various Android plugins into their
>corresponding repositories, and it seems that these were made up, and
>that they don't really correspond to what exists in the code today.  I
>don't think that it's realistic for us to get this done for 2.7
>because there are certain plugins that don't have a home (i.e. App,
>Compass, AudioPlayer, Echo) and others that don't make any sense to
>have (i.e. Console, Vibration) or are unclear (Media).
>
>Also, at least for Android, we're going to have to nail down a Java
>API.  Many of the plugins use some common code for file manipulation
>such as the Capture, Camera and of course the File APIs. It would be
>good to actually expose them to plugin developers so that we're all on
>the same page as to where files should and should not go.
>
>It would have been good to create the repositories based on what we
>already have implemented more or less, and to go from there.  That
>being said, I don't know if there is a one-to-one mapping between
>Android and iOS components, let alone any of the other platforms.
>
>Anyone else have thoughts on this?
>
>Joe