Dependency wildcards

[Jesse]

What is the point of the wildcard in the dependency tag of plugin.xml ?
I have an issue with any dependent plugin for Windows8, [1] but it probably
applies to any plugin dependency resolved via plugman on windows.

Plugman attempts to create a path [2] with the wildcard which results in
something like this on windows:
 C:\Users\Jesse\AppData\Local\Temp\plugman-tmp1375233798388\*\plugin.xml

Everything works fine if the wildcard is removed, seems like if subdir is
intended to be everything/all, then simply "/" would be just as good as
"/*" but I wanted to see if there were other implications or this was just
more windows negligence.

A dependent plugin [3]

TIA

[1] https://issues.apache.org/jira/browse/CB-4470
[2]
https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=blob;f=src/util/plugins.js;h=71a6a022f213e66e8269b35295d3645fbb494f7c;hb=HEAD#l66

[3]
https://git-wip-us.apache.org/repos/asf?p=cordova-plugin-file-transfer.git;a=blob;f=plugin.xml;h=8f7b35ad54a4abbe390b34a95a7dc92931a5d567;hb=HEAD#l11




@purplecabbage
risingj.com

[TESTING NEEDED] Re: "cordova plugin add" and variables

[Filip Maj]

Hi folks,

Jeff from BlackBerry has kicked the work off to pass flags down to
lower-level scripts. This should enable people to provide variables and
other install-time configurations when working with plugins through our
cli tool, as well as passing other useful flags to platform-level scripts
such as `build --release` or whatnot.

I have added a refactor of the CLI shim and also bumped cli's required
plugman version to 0.10.0 (which has support for iOS framework reference
counting).

The cli branch is on apache under passThrough [1].

If possible, I would love it if folks from BlackBerry and Google and
anyone else consuming the cli's latest could take this branch for a spin
and make sure your workflows pan out as desired. It has a few different
features/changes all bundled into one so I sort of see this branch as a
bit higher risk than usual.

Cheers and thanks in advance,
Fil 

[1] 
https://git-wip-us.apache.org/repos/asf?p=cordova-cli.git;a=shortlog;h=refs
/heads/passThrough


On 7/24/13 6:20 PM, "Brian LeRoux"  wrote:

>Hugely useful thx Fil
>On Jul 24, 2013 7:21 PM, "Shazron"  wrote:
>
>> Awesome, thx!
>>
>>
>> On Wed, Jul 24, 2013 at 3:59 PM, Filip Maj  wrote:
>>
>> > FYI I've resolved that issue and "merged" into
>> > https://issues.apache.org/jira/browse/CB-4273 as a bigger "pass all
>> flags
>> > to lower-level scripts/modules" issue.
>> >
>> > On 7/22/13 12:49 PM, "Shazron"  wrote:
>> >
>> > >Thanks Fil,
>> > >Filed https://issues.apache.org/jira/browse/CB-4352
>> > >
>> > >
>> > >On Mon, Jul 22, 2013 at 12:42 PM, Filip Maj  wrote:
>> > >
>> > >> Yeah file an issue. Maybe this needs to be encapsulated as a larger
>> > >> feature, I'm thinking, any flags you use with the cli get pushed
>>down
>> to
>> > >> the underlying tools. This way people could do `cordova build
>> > >>--release`,
>> > >> for example.
>> > >>
>> > >> On 7/22/13 12:33 PM, "Shazron"  wrote:
>> > >>
>> > >> >I didn't see it in the help. For example when trying to install
>>the
>> > >> >Facebook Connect plugin it complains about APP_ID variable not
>>being
>> > >>set
>> > >> >(plugman supports variables  however).
>> > >> >
>> > >> >Does anyone know the syntax to set a variable, or does this
>>feature
>> > >>need
>> > >> >to
>> > >> >be filed as an issue?
>> > >>
>> > >>
>> >
>> >
>>

Re: Status of the 2.9.x branch?

[Jesse]

No, plugman remove/install is not supported on windows phone until 3.0.0

@purplecabbage
risingj.com


On Tue, Jul 30, 2013 at 4:29 PM, Joe Bowser  wrote:

> The core plugins weren't installed with plugman, so they would have to
> be deleted manually.  Kind of a raw deal here.
>
> On Tue, Jul 30, 2013 at 4:25 PM, Filip Maj  wrote:
> > I don't think that affects plugman
> >
> > On 7/30/13 4:23 PM, "Brian LeRoux"  wrote:
> >
> >>Does plugman remove / install work here? If so, I think that would be
> >>preferred way.
> >>
> >>On Tue, Jul 30, 2013 at 4:13 PM, Joe Bowser  wrote:
> >>> Hey
> >>>
> >>> Apparently Cordova 2.9.x doesn't build with Android 4.3.  This is
> >>> because of an issue with setPluginsEnabled being deprecated in
> >>> InAppBrowser.  Since we agreed to support this release, should we
> >>> release a Cordova 2.9.1 soon to incorporate the fix, or just tell
> >>> people to replace InAppBrowser with the plugin version?
> >>>
> >>> Thoughts?
> >>>
> >>> Joe
> >
>

Re: Status of the 2.9.x branch?

[Joe Bowser]

The core plugins weren't installed with plugman, so they would have to
be deleted manually.  Kind of a raw deal here.

On Tue, Jul 30, 2013 at 4:25 PM, Filip Maj  wrote:
> I don't think that affects plugman
>
> On 7/30/13 4:23 PM, "Brian LeRoux"  wrote:
>
>>Does plugman remove / install work here? If so, I think that would be
>>preferred way.
>>
>>On Tue, Jul 30, 2013 at 4:13 PM, Joe Bowser  wrote:
>>> Hey
>>>
>>> Apparently Cordova 2.9.x doesn't build with Android 4.3.  This is
>>> because of an issue with setPluginsEnabled being deprecated in
>>> InAppBrowser.  Since we agreed to support this release, should we
>>> release a Cordova 2.9.1 soon to incorporate the fix, or just tell
>>> people to replace InAppBrowser with the plugin version?
>>>
>>> Thoughts?
>>>
>>> Joe
>

Re: Status of the 2.9.x branch?

[Filip Maj]

I don't think that affects plugman

On 7/30/13 4:23 PM, "Brian LeRoux"  wrote:

>Does plugman remove / install work here? If so, I think that would be
>preferred way.
>
>On Tue, Jul 30, 2013 at 4:13 PM, Joe Bowser  wrote:
>> Hey
>>
>> Apparently Cordova 2.9.x doesn't build with Android 4.3.  This is
>> because of an issue with setPluginsEnabled being deprecated in
>> InAppBrowser.  Since we agreed to support this release, should we
>> release a Cordova 2.9.1 soon to incorporate the fix, or just tell
>> people to replace InAppBrowser with the plugin version?
>>
>> Thoughts?
>>
>> Joe

Re: Status of the 2.9.x branch?

[Brian LeRoux]

Does plugman remove / install work here? If so, I think that would be
preferred way.

On Tue, Jul 30, 2013 at 4:13 PM, Joe Bowser  wrote:
> Hey
>
> Apparently Cordova 2.9.x doesn't build with Android 4.3.  This is
> because of an issue with setPluginsEnabled being deprecated in
> InAppBrowser.  Since we agreed to support this release, should we
> release a Cordova 2.9.1 soon to incorporate the fix, or just tell
> people to replace InAppBrowser with the plugin version?
>
> Thoughts?
>
> Joe

Re: Status of the 2.9.x branch?

[Jesse]

I have addressed some Windows Phone issues also in the 2.9.x branch, so I
am all for a 2.9.1 at some point in the near future.

@purplecabbage
risingj.com


On Tue, Jul 30, 2013 at 4:13 PM, Joe Bowser  wrote:

> Hey
>
> Apparently Cordova 2.9.x doesn't build with Android 4.3.  This is
> because of an issue with setPluginsEnabled being deprecated in
> InAppBrowser.  Since we agreed to support this release, should we
> release a Cordova 2.9.1 soon to incorporate the fix, or just tell
> people to replace InAppBrowser with the plugin version?
>
> Thoughts?
>
> Joe
>

Status of the 2.9.x branch?

[Joe Bowser]

Hey

Apparently Cordova 2.9.x doesn't build with Android 4.3.  This is
because of an issue with setPluginsEnabled being deprecated in
InAppBrowser.  Since we agreed to support this release, should we
release a Cordova 2.9.1 soon to incorporate the fix, or just tell
people to replace InAppBrowser with the plugin version?

Thoughts?

Joe

Re: Android - Removing the .api namespace

[Joe Bowser]

On Tue, Jul 30, 2013 at 3:51 PM, Don Coleman  wrote:
> Is there a suggested way for plugins to support 2.9 and 3.0 with one code
> base?
>

Well, this is a good argument that I wish I had three weeks ago!

I think we should support the shim for this purpose, since we're still
supporting Cordova 2.9, and it'd be good to at least do something for
plugin maintainers.

Re: Android - Removing the .api namespace

[Don Coleman]

Is there a suggested way for plugins to support 2.9 and 3.0 with one code
base?

Currently I'm adding org.apache.corodva.api.Dummy.java to my project and
using wildcard imports for org.apache.cordova.* and org.apache.cordova.api.*

Normally I wouldn't care about 2.9 but I'm trying to support PhoneGap build
and 3.0.


On Tue, Jul 30, 2013 at 5:03 PM, Andrew Grieve  wrote:

> Joe - I've not tried to be anonymous, and am planning on writing some blog
> posts as well (now that we have a blog to post them on).
>
> Fil - I'll spend some time tomorrow on #phonegap. That's a good suggestion.
>
> Tommy - I agree with you about our deprecation policy. I think we should
> discuss again how we can make developers more aware of changes (e.g.
> require a blog post now that we have a blog, include it in upgrade guides.
> Have plugin upgrade guides in addition to project upgrade guides). Even the
> "window" where we try and have shims is often ineffective. I think we might
> be better to remove things without shims so long as we can improve our
> communication about changes.
>
> There's a pretty good blog post on writing android plugins here:
>
> http://devgirl.org/2013/07/17/tutorial-how-to-write-a-phonegap-plugin-for-android/
>
> There are lots of things that we knew were broken with 3.0, which is why I
> wanted to label it as a "beta" release. If it weren't for PGD, I'm really
> don't think we would have released it in the state it was in.
>
>
>
> On Tue, Jul 30, 2013 at 3:36 PM, Filip Maj  wrote:
>
> > I dare you to idle in #phonegap on irc.freenode.net and answer every
> > plugin-related question.
> >
> > On 7/30/13 12:33 PM, "Filip Maj"  wrote:
> >
> > >As for who is getting angry/confused, I am helping folk on #cordova IRC
> > >upgrade their plugins because it won't work / not accounted for in the
> > >upgrade guides.
> > >
> > >On 7/30/13 12:12 PM, "Tommy-Carlos Williams" 
> wrote:
> > >
> > >>I don't wanna sound like I am being a pain, but reallyŠ the whole
> > >>deprecation policy thing is a bit pointless if it's not followed, and
> not
> > >>noisy.
> > >>
> > >>Most people who use plugins, use other people's plugins, they don't
> build
> > >>them themselves.
> > >>
> > >>The use of plugins so far in the life of Cordova has been one of
> massive
> > >>pain when in fact it should have been one of Cordova's shining lights.
> > >>
> > >>As one of the people that *does* face developer/end user wrath when
> this
> > >>stuff gets broken every few months, it would be really nice if the
> > >>Cordova devs doing the breaking could also be those to help the fixing.
> > >>
> > >>Blog posts. We need more. I can try to help on this and it's right up
> my
> > >>alley, but I am also in the middle of trying to ship an app, so time is
> > >>tight.
> > >>
> > >>I'll try to write a post on taking a 2.x plugin (say an example from
> > >>phonegap/phonegap-plugins) and turning it into a working 3.x plugin
> when
> > >>I get back to Australia. However, if a week has gone by and I haven't
> > >>been able to, can anyone put their hand up to do it in my stead?
> > >>Realistically it needs to cover Android and iOS at a minimum (the
> plugin
> > >>ecosystem for the other platforms is much smaller).
> > >>
> > >>Any takers?
> > >>
> > >>- tommy
> > >>
> > >>On 30/07/2013, at 11:57 AM, Joe Bowser  wrote:
> > >>
> > >>> So, yeah, remember how I fought this, and then suddenly we came to
> > >>> consensus because it's better to break everything all at once?
> > >>>
> > >>> https://issues.apache.org/jira/browse/CB-4454
> > >>>
> > >>> Can we actually follow our deprecation policy from now on? There's
> > >>> people there who are being unreasonable and asking for us to extend
> > >>> deprecation times to be a year in length because we do things like
> > >>> this.
> > >>>
> > >>>
> > >>> On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
> > >>>  wrote:
> >  Yup, break everything at once.
> > 
> > 
> >  Simon Mac Donald
> >  http://hi.im/simonmacdonald
> > 
> > 
> >  On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard 
> > wrote:
> > 
> > > Normally being very averse to changing pubic API's, I'm with Andrew
> > >and
> > > Ian on this. If we are going to be making breaking changes,
> > >especially if
> > > they are small, do them all at once.
> > >
> > > On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
> > >
> > >> So far, we've asked plugin developers to migrate from the
> old-style
> > >> plugins to CordovaPlugin so that their plugins will work with
> 3.0.0.
> > >> Many plugin developers have already done that.
> > >
> > > We have migrated our plugins, but have third-party plugins done the
> > >same?
> > > Or do they wait for us to release the breaking change and then they
> > >are
> > > "forced" to update their plugin? I'm guessing the latter, but that
> is
> > >just
> > > a guess.
> > >
> > > I think what would help here is a Plu

Re: Plugin / Platform mismatch problems

[Shazron]

Do we need to add a doc issue for updating this in 3.1:
1.
http://cordova.apache.org/docs/en/3.0.0/plugin_ref_plugman.md.html#Using%20Plugman%20to%20Manage%20Plugins
2.
http://cordova.apache.org/docs/en/3.0.0/guide_cli_index.md.html#The%20Command-line%20Interface

(the docs will still work of course using the existing method)


On Tue, Jul 30, 2013 at 3:33 PM, Anis KADRI  wrote:

> In the meantimeI renamed all plugins to package names in the
> cordova registry. I've also updated plugman
>
> So anyone should be able to `cordova plugin add
> org.apache.cordova.core.device` or `plugman install --platform
> platform --plugin org.apache.cordova.core.device --project
> /path/to/project` and it should just work.
>
> prefixing is not there yet. Do we really want it ?
>
> -a
>
> On Tue, Jul 30, 2013 at 9:58 AM, Brian LeRoux  wrote:
> > Oh, yes, it could also be made to install from the npm registry. It
> > does neither of those things yet.
> >
> > On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve 
> wrote:
> >> A federated system just means that anyone can host a directory of
> plugins,
> >> yes? Anis was saying that plugman could be easily made to point at any
> >> couchdb instance. Is that not federated?
> >>
> >>
> >> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux  wrote:
> >>
> >>> No, at least I don't think so. The install/uninstall are more clobbers
> >>> and plugin.xml is not a thing npm has any desire to become aware of.
> >>>
> >>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve 
> >>> wrote:
> >>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux  wrote:
> >>> >
> >>> >> > Would this require that we use the node_modules dependency
> structure?
> >>> >>
> >>> >> No. We would teach npm install about our structure.
> >>> >>
> >>> >>
> >>> >> > Would we be able to enforce our 
> as
> >>> well
> >>> >> > as our  >>> min-os-version="5.0">
> >>> >> > constraints?
> >>> >>
> >>> >> Yes.
> >>> >>
> >>> >>
> >>> >> > Some things will be uglier to express as json I think. E.g.:
> trying to
> >>> >> > embed xml snippets (like for ), that contain many "
> >>> >> characters
> >>> >> > and newline characters.
> >>> >>
> >>> >> Yes.
> >>> >>
> >>> >>
> >>> >> > Making things harder to search for has been pointed out as a
> >>> >> disadvantage.
> >>> >> > What would be the advantages?
> >>> >>
> >>> >> We implement a theoretically federated system. Cordova would
> continue
> >>> >> to use its own registry. (And thusly downstream distributions could
> >>> >> use their own.)
> >>> >>
> >>> >
> >>> > I thought this was already true with Anis' current setup?
> >>>
>

Re: android commit: Upgrading project to Android 4.3

[Filip Maj]

K I will log issues / deal with it as its coupled with some cli work I
have planned

Thx for the validation

On 7/30/13 3:47 PM, "Joe Bowser"  wrote:

>Yes, they need to be changed!
>
>On Tue, Jul 30, 2013 at 3:34 PM, Filip Maj  wrote:
>> Hey Joe,
>>
>> With this change, do we need to update the check_reqs script(s)? Those
>> scripts check that you have android-17 as a target installed. Should
>>that
>> be updated to now check for android-18 ?
>>
>> On 7/29/13 11:30 AM, "bows...@apache.org"  wrote:
>>
>>>Updated Branches:
>>>  refs/heads/master b4236b978 -> 5c38101a9
>>>
>>>
>>>Upgrading project to Android 4.3
>>>
>>>
>>>Project: http://git-wip-us.apache.org/repos/asf/cordova-android/repo
>>>Commit:
>>>http://git-wip-us.apache.org/repos/asf/cordova-android/commit/5c38101a
>>>Tree: 
>>>http://git-wip-us.apache.org/repos/asf/cordova-android/tree/5c38101a
>>>Diff: 
>>>http://git-wip-us.apache.org/repos/asf/cordova-android/diff/5c38101a
>>>
>>>Branch: refs/heads/master
>>>Commit: 5c38101a9eda2a18b65dfcabf0452bd727009598
>>>Parents: b4236b9
>>>Author: Joe Bowser 
>>>Authored: Mon Jul 29 11:30:41 2013 -0700
>>>Committer: Joe Bowser 
>>>Committed: Mon Jul 29 11:30:41 2013 -0700
>>>
>>>--
>>> framework/project.properties | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>--
>>>
>>>
>>>http://git-wip-us.apache.org/repos/asf/cordova-android/blob/5c38101a/fra
>>>me
>>>work/project.properties
>>>--
>>>diff --git a/framework/project.properties b/framework/project.properties
>>>index 2f39d91..931aa8a 100644
>>>--- a/framework/project.properties
>>>+++ b/framework/project.properties
>>>@@ -10,7 +10,7 @@
>>> # Indicates whether an apk should be generated for each density.
>>> split.density=false
>>> # Project target.
>>>-target=android-17
>>>+target=android-18
>>> apk-configurations=
>>> renderscript.opt.level=O0
>>> android.library=true
>>>
>>

Re: android commit: Upgrading project to Android 4.3

[Joe Bowser]

Yes, they need to be changed!

On Tue, Jul 30, 2013 at 3:34 PM, Filip Maj  wrote:
> Hey Joe,
>
> With this change, do we need to update the check_reqs script(s)? Those
> scripts check that you have android-17 as a target installed. Should that
> be updated to now check for android-18 ?
>
> On 7/29/13 11:30 AM, "bows...@apache.org"  wrote:
>
>>Updated Branches:
>>  refs/heads/master b4236b978 -> 5c38101a9
>>
>>
>>Upgrading project to Android 4.3
>>
>>
>>Project: http://git-wip-us.apache.org/repos/asf/cordova-android/repo
>>Commit:
>>http://git-wip-us.apache.org/repos/asf/cordova-android/commit/5c38101a
>>Tree: http://git-wip-us.apache.org/repos/asf/cordova-android/tree/5c38101a
>>Diff: http://git-wip-us.apache.org/repos/asf/cordova-android/diff/5c38101a
>>
>>Branch: refs/heads/master
>>Commit: 5c38101a9eda2a18b65dfcabf0452bd727009598
>>Parents: b4236b9
>>Author: Joe Bowser 
>>Authored: Mon Jul 29 11:30:41 2013 -0700
>>Committer: Joe Bowser 
>>Committed: Mon Jul 29 11:30:41 2013 -0700
>>
>>--
>> framework/project.properties | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>--
>>
>>
>>http://git-wip-us.apache.org/repos/asf/cordova-android/blob/5c38101a/frame
>>work/project.properties
>>--
>>diff --git a/framework/project.properties b/framework/project.properties
>>index 2f39d91..931aa8a 100644
>>--- a/framework/project.properties
>>+++ b/framework/project.properties
>>@@ -10,7 +10,7 @@
>> # Indicates whether an apk should be generated for each density.
>> split.density=false
>> # Project target.
>>-target=android-17
>>+target=android-18
>> apk-configurations=
>> renderscript.opt.level=O0
>> android.library=true
>>
>

Re: android commit: Upgrading project to Android 4.3

[Filip Maj]

Hey Joe,

With this change, do we need to update the check_reqs script(s)? Those
scripts check that you have android-17 as a target installed. Should that
be updated to now check for android-18 ?

On 7/29/13 11:30 AM, "bows...@apache.org"  wrote:

>Updated Branches:
>  refs/heads/master b4236b978 -> 5c38101a9
>
>
>Upgrading project to Android 4.3
>
>
>Project: http://git-wip-us.apache.org/repos/asf/cordova-android/repo
>Commit: 
>http://git-wip-us.apache.org/repos/asf/cordova-android/commit/5c38101a
>Tree: http://git-wip-us.apache.org/repos/asf/cordova-android/tree/5c38101a
>Diff: http://git-wip-us.apache.org/repos/asf/cordova-android/diff/5c38101a
>
>Branch: refs/heads/master
>Commit: 5c38101a9eda2a18b65dfcabf0452bd727009598
>Parents: b4236b9
>Author: Joe Bowser 
>Authored: Mon Jul 29 11:30:41 2013 -0700
>Committer: Joe Bowser 
>Committed: Mon Jul 29 11:30:41 2013 -0700
>
>--
> framework/project.properties | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>--
>
>
>http://git-wip-us.apache.org/repos/asf/cordova-android/blob/5c38101a/frame
>work/project.properties
>--
>diff --git a/framework/project.properties b/framework/project.properties
>index 2f39d91..931aa8a 100644
>--- a/framework/project.properties
>+++ b/framework/project.properties
>@@ -10,7 +10,7 @@
> # Indicates whether an apk should be generated for each density.
> split.density=false
> # Project target.
>-target=android-17
>+target=android-18
> apk-configurations=
> renderscript.opt.level=O0
> android.library=true
>

Re: Plugin / Platform mismatch problems

[Anis KADRI]

In the meantimeI renamed all plugins to package names in the
cordova registry. I've also updated plugman

So anyone should be able to `cordova plugin add
org.apache.cordova.core.device` or `plugman install --platform
platform --plugin org.apache.cordova.core.device --project
/path/to/project` and it should just work.

prefixing is not there yet. Do we really want it ?

-a

On Tue, Jul 30, 2013 at 9:58 AM, Brian LeRoux  wrote:
> Oh, yes, it could also be made to install from the npm registry. It
> does neither of those things yet.
>
> On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve  wrote:
>> A federated system just means that anyone can host a directory of plugins,
>> yes? Anis was saying that plugman could be easily made to point at any
>> couchdb instance. Is that not federated?
>>
>>
>> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux  wrote:
>>
>>> No, at least I don't think so. The install/uninstall are more clobbers
>>> and plugin.xml is not a thing npm has any desire to become aware of.
>>>
>>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve 
>>> wrote:
>>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux  wrote:
>>> >
>>> >> > Would this require that we use the node_modules dependency structure?
>>> >>
>>> >> No. We would teach npm install about our structure.
>>> >>
>>> >>
>>> >> > Would we be able to enforce our  as
>>> well
>>> >> > as our >> min-os-version="5.0">
>>> >> > constraints?
>>> >>
>>> >> Yes.
>>> >>
>>> >>
>>> >> > Some things will be uglier to express as json I think. E.g.: trying to
>>> >> > embed xml snippets (like for ), that contain many "
>>> >> characters
>>> >> > and newline characters.
>>> >>
>>> >> Yes.
>>> >>
>>> >>
>>> >> > Making things harder to search for has been pointed out as a
>>> >> disadvantage.
>>> >> > What would be the advantages?
>>> >>
>>> >> We implement a theoretically federated system. Cordova would continue
>>> >> to use its own registry. (And thusly downstream distributions could
>>> >> use their own.)
>>> >>
>>> >
>>> > I thought this was already true with Anis' current setup?
>>>

Re: android commit: CB-3819: Implemented Feature

[Joe Bowser]

HELLS YEAH!

On Tue, Jul 30, 2013 at 3:27 PM, Filip Maj  wrote:
> Best commit message evar!
>
> On 7/30/13 3:21 PM, "bows...@apache.org"  wrote:
>
>>Updated Branches:
>>  refs/heads/master 7cbe8f584 -> 2bdc849c2
>>
>>
>>CB-3819: Implemented Feature
>>
>>
>>Project: http://git-wip-us.apache.org/repos/asf/cordova-android/repo
>>Commit:
>>http://git-wip-us.apache.org/repos/asf/cordova-android/commit/2bdc849c
>>Tree: http://git-wip-us.apache.org/repos/asf/cordova-android/tree/2bdc849c
>>Diff: http://git-wip-us.apache.org/repos/asf/cordova-android/diff/2bdc849c
>>
>>Branch: refs/heads/master
>>Commit: 2bdc849c2ba505d944f2b81fc02245fba9fbf204
>>Parents: 7cbe8f5
>>Author: Joe Bowser 
>>Authored: Tue Jul 30 15:03:25 2013 -0700
>>Committer: Joe Bowser 
>>Committed: Tue Jul 30 15:03:25 2013 -0700
>>
>>--
>> framework/src/org/apache/cordova/Config.java|  4 ++
>> .../src/org/apache/cordova/CordovaActivity.java | 65 ++--
>> .../src/org/apache/cordova/CordovaWebView.java  |  1 +
>> 3 files changed, 50 insertions(+), 20 deletions(-)
>>--
>>
>>
>>http://git-wip-us.apache.org/repos/asf/cordova-android/blob/2bdc849c/frame
>>work/src/org/apache/cordova/Config.java
>>--
>>diff --git a/framework/src/org/apache/cordova/Config.java
>>b/framework/src/org/apache/cordova/Config.java
>>index 51f8f3f..716b795 100644
>>--- a/framework/src/org/apache/cordova/Config.java
>>+++ b/framework/src/org/apache/cordova/Config.java
>>@@ -136,6 +136,10 @@ public class Config {
>> int value = xml.getAttributeIntValue(null,
>>"value", 2);
>> action.getIntent().putExtra(name, value);
>> }
>>+else if(name.equalsIgnoreCase("SplashScreenDelay")) {
>>+int value = xml.getAttributeIntValue(null,
>>"value", 3000);
>>+action.getIntent().putExtra(name, value);
>>+}
>> else if(name.equalsIgnoreCase("KeepRunning"))
>> {
>> boolean value = xml.getAttributeValue(null,
>>"value").equals("true");
>>
>>http://git-wip-us.apache.org/repos/asf/cordova-android/blob/2bdc849c/frame
>>work/src/org/apache/cordova/CordovaActivity.java
>>--
>>diff --git a/framework/src/org/apache/cordova/CordovaActivity.java
>>b/framework/src/org/apache/cordova/CordovaActivity.java
>>index 685424c..82d97c9 100755
>>--- a/framework/src/org/apache/cordova/CordovaActivity.java
>>+++ b/framework/src/org/apache/cordova/CordovaActivity.java
>>@@ -391,6 +391,16 @@ public class CordovaActivity extends Activity
>>implements CordovaInterface {
>> this.init();
>> }
>>
>>+this.splashscreenTime =
>>this.getIntegerProperty("SplashScreenDelay", this.splashscreenTime);
>>+if(this.splashscreenTime > 0)
>>+{
>>+this.splashscreen = this.getIntegerProperty("SplashScreen",
>>0);
>>+if(this.splashscreen != 0)
>>+{
>>+this.showSplashScreen(this.splashscreenTime);
>>+}
>>+}
>>+
>> // Set backgroundColor
>> this.backgroundColor =
>>this.getIntegerProperty("BackgroundColor", Color.BLACK);
>> this.root.setBackgroundColor(this.backgroundColor);
>>@@ -401,9 +411,43 @@ public class CordovaActivity extends Activity
>>implements CordovaInterface {
>> // Then load the spinner
>> this.loadSpinner();
>>
>>-this.appView.loadUrl(url);
>>+//Load the correct splashscreen
>>+
>>+if(this.splashscreen != 0)
>>+{
>>+this.appView.loadUrl(url, this.splashscreenTime);
>>+}
>>+else
>>+{
>>+this.appView.loadUrl(url);
>>+}
>> }
>>
>>+/**
>>+ * Load the url into the webview after waiting for period of time.
>>+ * This is used to display the splashscreen for certain amount of
>>time.
>>+ *
>>+ * @param url
>>+ * @param time  The number of ms to wait before loading
>>webview
>>+ */
>>+public void loadUrl(final String url, int time) {
>>+
>>+this.splashscreenTime = time;
>>+this.loadUrl(url);
>>+
>>+/*
>>+// Init web view if not already done
>>+if (this.appView == null) {
>>+this.init();
>>+}
>>+
>>+this.splashscreenTime = time;
>>+this.splashscreen = this.getIntegerProperty("SplashScreen", 0);
>>+this.showSplashScreen(this.splashscreenTime);
>>+this.appView.loadUrl(url, time);
>>+*/
>>+}
>>+
>> /*
>>  * Load the spinner
>>  */
>>@@ -437,25 +481,6 @@ public class CordovaActivity extends Activity
>>implements CordovaInterface {
>>

[Windows / BB testing help request] Re: Refactored cordova-js bootstrap

[Brian LeRoux]

Much cleaner. Think its totally appropriate to ask for testing help in
the subj header Andrew.

Mapes / Jesse / Lorin or someone from BB can you check it on a phone?


On Tue, Jul 30, 2013 at 12:22 PM, Andrew Grieve  wrote:
> 1. Rather than have every platform with a bootstrap-FOO.js as well as a
> platform.js, I moved the bootstrap code into platform.js for the platforms.
> This will also allow bootstrap logic to be unit tested.
> 2. I moved bootstrap.js's logic into cordova/common/init.js. Now, all
> bootstrap.js does is require('cordova/init'); I figure this is a bit nicer
> because again, it can be unit tested, and now lives with the rest of the
> code within the lib/ directory.
>
> I ran unit tests & mobile spec for iOS & Android, but not for windows &
> blackberry. If I messed it up and the fix isn't obvious, I made sure each
> platform can be reverted via a single commit:
>
> BB: http://git-wip-us.apache.org/repos/asf/cordova-js/commit/08da18a7
> win8: http://git-wip-us.apache.org/repos/asf/cordova-js/commit/732c9e91
> winphone: http://git-wip-us.apache.org/repos/asf/cordova-js/commit/6da628d5

Re: android commit: CB-3819: Implemented Feature

[Filip Maj]

Best commit message evar!

On 7/30/13 3:21 PM, "bows...@apache.org"  wrote:

>Updated Branches:
>  refs/heads/master 7cbe8f584 -> 2bdc849c2
>
>
>CB-3819: Implemented Feature
>
>
>Project: http://git-wip-us.apache.org/repos/asf/cordova-android/repo
>Commit: 
>http://git-wip-us.apache.org/repos/asf/cordova-android/commit/2bdc849c
>Tree: http://git-wip-us.apache.org/repos/asf/cordova-android/tree/2bdc849c
>Diff: http://git-wip-us.apache.org/repos/asf/cordova-android/diff/2bdc849c
>
>Branch: refs/heads/master
>Commit: 2bdc849c2ba505d944f2b81fc02245fba9fbf204
>Parents: 7cbe8f5
>Author: Joe Bowser 
>Authored: Tue Jul 30 15:03:25 2013 -0700
>Committer: Joe Bowser 
>Committed: Tue Jul 30 15:03:25 2013 -0700
>
>--
> framework/src/org/apache/cordova/Config.java|  4 ++
> .../src/org/apache/cordova/CordovaActivity.java | 65 ++--
> .../src/org/apache/cordova/CordovaWebView.java  |  1 +
> 3 files changed, 50 insertions(+), 20 deletions(-)
>--
>
>
>http://git-wip-us.apache.org/repos/asf/cordova-android/blob/2bdc849c/frame
>work/src/org/apache/cordova/Config.java
>--
>diff --git a/framework/src/org/apache/cordova/Config.java
>b/framework/src/org/apache/cordova/Config.java
>index 51f8f3f..716b795 100644
>--- a/framework/src/org/apache/cordova/Config.java
>+++ b/framework/src/org/apache/cordova/Config.java
>@@ -136,6 +136,10 @@ public class Config {
> int value = xml.getAttributeIntValue(null,
>"value", 2);
> action.getIntent().putExtra(name, value);
> }
>+else if(name.equalsIgnoreCase("SplashScreenDelay")) {
>+int value = xml.getAttributeIntValue(null,
>"value", 3000);
>+action.getIntent().putExtra(name, value);
>+}
> else if(name.equalsIgnoreCase("KeepRunning"))
> {
> boolean value = xml.getAttributeValue(null,
>"value").equals("true");
>
>http://git-wip-us.apache.org/repos/asf/cordova-android/blob/2bdc849c/frame
>work/src/org/apache/cordova/CordovaActivity.java
>--
>diff --git a/framework/src/org/apache/cordova/CordovaActivity.java
>b/framework/src/org/apache/cordova/CordovaActivity.java
>index 685424c..82d97c9 100755
>--- a/framework/src/org/apache/cordova/CordovaActivity.java
>+++ b/framework/src/org/apache/cordova/CordovaActivity.java
>@@ -391,6 +391,16 @@ public class CordovaActivity extends Activity
>implements CordovaInterface {
> this.init();
> }
> 
>+this.splashscreenTime =
>this.getIntegerProperty("SplashScreenDelay", this.splashscreenTime);
>+if(this.splashscreenTime > 0)
>+{
>+this.splashscreen = this.getIntegerProperty("SplashScreen",
>0);
>+if(this.splashscreen != 0)
>+{
>+this.showSplashScreen(this.splashscreenTime);
>+}
>+}
>+
> // Set backgroundColor
> this.backgroundColor =
>this.getIntegerProperty("BackgroundColor", Color.BLACK);
> this.root.setBackgroundColor(this.backgroundColor);
>@@ -401,9 +411,43 @@ public class CordovaActivity extends Activity
>implements CordovaInterface {
> // Then load the spinner
> this.loadSpinner();
> 
>-this.appView.loadUrl(url);
>+//Load the correct splashscreen
>+
>+if(this.splashscreen != 0)
>+{
>+this.appView.loadUrl(url, this.splashscreenTime);
>+}
>+else
>+{
>+this.appView.loadUrl(url);
>+}
> }
> 
>+/**
>+ * Load the url into the webview after waiting for period of time.
>+ * This is used to display the splashscreen for certain amount of
>time.
>+ *
>+ * @param url
>+ * @param time  The number of ms to wait before loading
>webview
>+ */
>+public void loadUrl(final String url, int time) {
>+
>+this.splashscreenTime = time;
>+this.loadUrl(url);
>+
>+/*
>+// Init web view if not already done
>+if (this.appView == null) {
>+this.init();
>+}
>+
>+this.splashscreenTime = time;
>+this.splashscreen = this.getIntegerProperty("SplashScreen", 0);
>+this.showSplashScreen(this.splashscreenTime);
>+this.appView.loadUrl(url, time);
>+*/
>+}
>+
> /*
>  * Load the spinner
>  */
>@@ -437,25 +481,6 @@ public class CordovaActivity extends Activity
>implements CordovaInterface {
> }
> }
> 
>-/**
>- * Load the url into the webview after waiting for period of time.
>- * This is used to display the splashscreen for certain amount of
>

Re: [Vote] Transifex Translation : please vote

[Anis KADRI]

I vote yes. I am a bit worried about translations though. I feel like
people who translate and are not involved in the project tend to
produce poor translations. But translation is better than no
translation. So +1.

-a

On Tue, Jul 30, 2013 at 2:02 PM, Lisa Seacat DeLuca  wrote:
> I sent a note out about a month ago about using Transifex for translation
> of the Cordova docs.  Everyone was preparing for the 3.0 release and
> phonegap day so I didn't receive much of a response.  So I'm reopening the
> discussion.
>
> I have created a project within Transifex for cordova here:
> https://www.transifex.com/projects/p/cordova
>
> The way it works is:
> 1.  files are upload  to the Transifex system.  Transifex does not
> have markdown files as one of the options for file type to import but they
> do have html and plain text.  I have chosen plain text for testing and it
> appears to work great.  I setup a preferences for the resource to be
> pulled from github on a daily basis with the latest version of the file.
> 2.  Users may come in and provide translation or all or part of a
> file.
> 3.  A "maintainer" or language expert is assigned to each language and
> approves the translations
> 4.  progress information and status can be shown per file/project.
>  Once complete, the translated file can be uploaded back into github under
> the specific language.  This part is a manual process
> Other open source projects use Transifex, for example, OpenStack.
>
> I propose we do the following:
> Use Transifex for each major release starting with 3.0.  If it is
> relatively easy to translate for minor releases we can vote to do so with
> each.
> Assign a language "maintainer" for each supported language to monitor
> translations. I suggest we start with Spanish and French since those are
> the languages our group of committers can best contribute to at this time.
>  (If we have a consensus to use Transfix, please volunteer if you'd like
> to be the maintainer for a specific language).
> Once a section of the documentation is approved by the language moderator,
> we push the updates to GitHub.
> I created a new JIRA issue related to globalization so we can track
> comments outside of the mailing list as well.
> https://issues.apache.org/jira/browse/CB-4461
>
> Another thing to think about, Transifex offers automatic translation for
> faster translation using google translation services or microsoft's which
> require an api key and a paid subscription.  I don't know if either of
> those companies offer a free key for open source needs. I know we have a
> few representatives from those companies that might be able to give us
> more information.
>
> Why we should be worried about translation?
> Globalization! If we can attract more developers to Cordova and make it
> easier for those developers to get up and running with cordova by
> providing documentation in their native languages,  cordova will continue
> to grow in popularity globally.
>
>
> Please vote if you are okay with moving forward with Transifex as a
> solution to our translation needs.
>
>
> Lisa
> ldel...@us.ibm.com
> @IBMLisa
>
>
>
> From:   Lisa Seacat DeLuca/San Francisco/IBM
> To: dev@cordova.apache.org,
> Date:   07/17/2013 10:23 AM
> Subject:Transifex
>
>
> I have been doing some research into translation services available and
> ran into a group that has been working on a solution for Open Stack using
> Transifex.  Lets face it, the cordova translation story is just not where
> it could be.  It looks like the Transifex service is free for open source
> projects.  Does anyone have a strong opinion one way or another on whether
> or not we could utilize Transifex for cordova?
>
> Transifex website: http://www.transifex.com
> Supported File Formats:
> http://support.transifex.com/customer/portal/articles/971979-supported-file-formats
>
> cordova project I created on transifex:
> https://www.transifex.com/projects/p/cordova
>
> I uploaded the overview file (
> https://www.transifex.com/projects/p/cordova/resource/guide_overview_indexmdhtml/
> )  to give the service a try and see what we can expect.  It would be
> interesting to build this into our release cycle, especially during major
> releases when the getting started guides, plugin guides, etc. change
> drastically.
>
>
> Lisa
> ldel...@us.ibm.com
>

Re: Deprecating in plugin.xml

[Filip Maj]

Well, in any case I've filed CB-4455 and CB-4456 to track
deprecation/removal.

On 7/30/13 2:05 PM, "RUDD, Brett"  wrote:

>(spoilers) 
>
>when we complete 3.0 integration we'll be getting rid of all the
>plugin-plist supported cordova versions.
>
>-brett
>
>On 30 Jul 2013, at 12:38, Shazron  wrote:
>
>> Oh yea, totally forgot about the Build team 8^)
>> 
>> 
>> On Tue, Jul 30, 2013 at 12:35 PM, Filip Maj  wrote:
>> 
>>> Phonegap build is an example of a team using plugman and still relying
>>>on
>>> plugins-plist.
>>> 
>>> I will set up an issue to deprecate its use for 3.1 and remove it for
>>>3.4.
>>> 
>>> On 7/30/13 2:00 AM, "Shazron"  wrote:
>>> 
 Isn't our support for plugman "official" with 3.0.0? when plugman was
 exposed to the world I'm not sure we expressed any forms of stability
 assurance I don't think -- everything was moving at a rapid pace. IMO
I'd
 just remove support for Plugins.plist
 
 
 On Mon, Jul 29, 2013 at 7:39 PM, Filip Maj  wrote:
 
> Sorry yes, Plugins.plist
> 
> Maybe folks are using plugman with old cordova-ios projects? Iuno
> 
> On 7/29/13 7:19 PM, "Andrew Grieve"  wrote:
> 
>> You mean plugins.plist?
>> 
>> No need to deprecate it if it doesn't work right now anyways.
>> 
>> 
>> On Mon, Jul 29, 2013 at 10:12 PM, Filip Maj  wrote:
>> 
>>> Yeah, back before we had config.xml, we had a plugins.xml for
>>> cordova-ios
>>> projects, and that¹s where service labels were mapped to classes
>>> 
>>> On 7/29/13 7:09 PM, "Andrew Grieve"  wrote:
>>> 
 I'm not 100% sure of what  does, but if it's for
> setting
 plugin-specific config settings, the code on iOS has already
> changed to
 remove support for that (only settings in the main config.xml are
 supported
 now).
 
 
 On Mon, Jul 29, 2013 at 9:22 PM, Filip Maj  wrote:
 
> We currently document support for  in our spec
>[1].
>>> This
> is
> to support old cordova-ios (2.2 I believe).
> 
> 
> It would save with some lame special-case code [2] [3] [4].
> 
> Warn folks using plugman w/ plugins using 
>elements
>>> that
> support is being removed soon? 3 releases for deprecation ya, so
>>> around
> 3.3 we remove support for it?
> 
> [1]
> 
> 
>>> 
>>> 
> 
> 
>>> 
>>>https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md#plu
>>>g
> in
> s-plist
> [2]
> 
> 
>>> 
>>> 
> 
> 
>>> 
>>>https://github.com/apache/cordova-plugman/blob/master/src/util/config-ch
>>>a
> ng
> es.js#L93-L104
> [3]
> 
> 
>>> 
>>> 
> 
> 
>>> 
>>>https://github.com/apache/cordova-plugman/blob/master/src/util/config-ch
>>>a
> ng
> es.js#L147-L166
> [4]
> 
> 
>>> 
>>> 
> 
> 
>>> 
>>>https://github.com/apache/cordova-plugman/blob/master/src/util/config-ch
>>>a
> ng
> es.js#L236-L252
> 
> 
>>> 
>>> 
> 
> 
>>> 
>>> 
>

Re: Deprecating in plugin.xml

[RUDD, Brett]

(spoilers) 

when we complete 3.0 integration we'll be getting rid of all the plugin-plist 
supported cordova versions.

-brett

On 30 Jul 2013, at 12:38, Shazron  wrote:

> Oh yea, totally forgot about the Build team 8^)
> 
> 
> On Tue, Jul 30, 2013 at 12:35 PM, Filip Maj  wrote:
> 
>> Phonegap build is an example of a team using plugman and still relying on
>> plugins-plist.
>> 
>> I will set up an issue to deprecate its use for 3.1 and remove it for 3.4.
>> 
>> On 7/30/13 2:00 AM, "Shazron"  wrote:
>> 
>>> Isn't our support for plugman "official" with 3.0.0? when plugman was
>>> exposed to the world I'm not sure we expressed any forms of stability
>>> assurance I don't think -- everything was moving at a rapid pace. IMO I'd
>>> just remove support for Plugins.plist
>>> 
>>> 
>>> On Mon, Jul 29, 2013 at 7:39 PM, Filip Maj  wrote:
>>> 
 Sorry yes, Plugins.plist
 
 Maybe folks are using plugman with old cordova-ios projects? Iuno
 
 On 7/29/13 7:19 PM, "Andrew Grieve"  wrote:
 
> You mean plugins.plist?
> 
> No need to deprecate it if it doesn't work right now anyways.
> 
> 
> On Mon, Jul 29, 2013 at 10:12 PM, Filip Maj  wrote:
> 
>> Yeah, back before we had config.xml, we had a plugins.xml for
>> cordova-ios
>> projects, and that¹s where service labels were mapped to classes
>> 
>> On 7/29/13 7:09 PM, "Andrew Grieve"  wrote:
>> 
>>> I'm not 100% sure of what  does, but if it's for
 setting
>>> plugin-specific config settings, the code on iOS has already
 changed to
>>> remove support for that (only settings in the main config.xml are
>>> supported
>>> now).
>>> 
>>> 
>>> On Mon, Jul 29, 2013 at 9:22 PM, Filip Maj  wrote:
>>> 
 We currently document support for  in our spec [1].
>> This
 is
 to support old cordova-ios (2.2 I believe).
 
 
 It would save with some lame special-case code [2] [3] [4].
 
 Warn folks using plugman w/ plugins using  elements
>> that
 support is being removed soon? 3 releases for deprecation ya, so
>> around
 3.3 we remove support for it?
 
 [1]
 
 
>> 
>> 
 
 
>> https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md#plug
 in
 s-plist
 [2]
 
 
>> 
>> 
 
 
>> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
 ng
 es.js#L93-L104
 [3]
 
 
>> 
>> 
 
 
>> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
 ng
 es.js#L147-L166
 [4]
 
 
>> 
>> 
 
 
>> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
 ng
 es.js#L236-L252
 
 
>> 
>> 
 
 
>> 
>> 

Re: Android - Removing the .api namespace

[Andrew Grieve]

Joe - I've not tried to be anonymous, and am planning on writing some blog
posts as well (now that we have a blog to post them on).

Fil - I'll spend some time tomorrow on #phonegap. That's a good suggestion.

Tommy - I agree with you about our deprecation policy. I think we should
discuss again how we can make developers more aware of changes (e.g.
require a blog post now that we have a blog, include it in upgrade guides.
Have plugin upgrade guides in addition to project upgrade guides). Even the
"window" where we try and have shims is often ineffective. I think we might
be better to remove things without shims so long as we can improve our
communication about changes.

There's a pretty good blog post on writing android plugins here:
http://devgirl.org/2013/07/17/tutorial-how-to-write-a-phonegap-plugin-for-android/

There are lots of things that we knew were broken with 3.0, which is why I
wanted to label it as a "beta" release. If it weren't for PGD, I'm really
don't think we would have released it in the state it was in.



On Tue, Jul 30, 2013 at 3:36 PM, Filip Maj  wrote:

> I dare you to idle in #phonegap on irc.freenode.net and answer every
> plugin-related question.
>
> On 7/30/13 12:33 PM, "Filip Maj"  wrote:
>
> >As for who is getting angry/confused, I am helping folk on #cordova IRC
> >upgrade their plugins because it won't work / not accounted for in the
> >upgrade guides.
> >
> >On 7/30/13 12:12 PM, "Tommy-Carlos Williams"  wrote:
> >
> >>I don't wanna sound like I am being a pain, but reallyŠ the whole
> >>deprecation policy thing is a bit pointless if it's not followed, and not
> >>noisy.
> >>
> >>Most people who use plugins, use other people's plugins, they don't build
> >>them themselves.
> >>
> >>The use of plugins so far in the life of Cordova has been one of massive
> >>pain when in fact it should have been one of Cordova's shining lights.
> >>
> >>As one of the people that *does* face developer/end user wrath when this
> >>stuff gets broken every few months, it would be really nice if the
> >>Cordova devs doing the breaking could also be those to help the fixing.
> >>
> >>Blog posts. We need more. I can try to help on this and it's right up my
> >>alley, but I am also in the middle of trying to ship an app, so time is
> >>tight.
> >>
> >>I'll try to write a post on taking a 2.x plugin (say an example from
> >>phonegap/phonegap-plugins) and turning it into a working 3.x plugin when
> >>I get back to Australia. However, if a week has gone by and I haven't
> >>been able to, can anyone put their hand up to do it in my stead?
> >>Realistically it needs to cover Android and iOS at a minimum (the plugin
> >>ecosystem for the other platforms is much smaller).
> >>
> >>Any takers?
> >>
> >>- tommy
> >>
> >>On 30/07/2013, at 11:57 AM, Joe Bowser  wrote:
> >>
> >>> So, yeah, remember how I fought this, and then suddenly we came to
> >>> consensus because it's better to break everything all at once?
> >>>
> >>> https://issues.apache.org/jira/browse/CB-4454
> >>>
> >>> Can we actually follow our deprecation policy from now on? There's
> >>> people there who are being unreasonable and asking for us to extend
> >>> deprecation times to be a year in length because we do things like
> >>> this.
> >>>
> >>>
> >>> On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
> >>>  wrote:
>  Yup, break everything at once.
> 
> 
>  Simon Mac Donald
>  http://hi.im/simonmacdonald
> 
> 
>  On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard 
> wrote:
> 
> > Normally being very averse to changing pubic API's, I'm with Andrew
> >and
> > Ian on this. If we are going to be making breaking changes,
> >especially if
> > they are small, do them all at once.
> >
> > On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
> >
> >> So far, we've asked plugin developers to migrate from the old-style
> >> plugins to CordovaPlugin so that their plugins will work with 3.0.0.
> >> Many plugin developers have already done that.
> >
> > We have migrated our plugins, but have third-party plugins done the
> >same?
> > Or do they wait for us to release the breaking change and then they
> >are
> > "forced" to update their plugin? I'm guessing the latter, but that is
> >just
> > a guess.
> >
> > I think what would help here is a Plugin Migration Guide in
> >cordova-docs
> > that gives a nice list of what the plugin developer needs to do. Most
> > plugin devs are probably OK with making changes, as long as we tell
> >them
> > what they need to know.
> >
> > If there is a third-party plugin that an app developer needs that is
> > abandonware, then they can stick with 2.9.x until the plugin gets
> >updated.
> >
> >
> >>
> >
>
>

[Vote] Transifex Translation : please vote

[Lisa Seacat DeLuca]

I sent a note out about a month ago about using Transifex for translation 
of the Cordova docs.  Everyone was preparing for the 3.0 release and 
phonegap day so I didn't receive much of a response.  So I'm reopening the 
discussion.  

I have created a project within Transifex for cordova here:
https://www.transifex.com/projects/p/cordova

The way it works is:
1.  files are upload  to the Transifex system.  Transifex does not 
have markdown files as one of the options for file type to import but they 
do have html and plain text.  I have chosen plain text for testing and it 
appears to work great.  I setup a preferences for the resource to be 
pulled from github on a daily basis with the latest version of the file. 
2.  Users may come in and provide translation or all or part of a 
file.
3.  A "maintainer" or language expert is assigned to each language and 
approves the translations
4.  progress information and status can be shown per file/project. 
 Once complete, the translated file can be uploaded back into github under 
the specific language.  This part is a manual process
Other open source projects use Transifex, for example, OpenStack.  

I propose we do the following:
Use Transifex for each major release starting with 3.0.  If it is 
relatively easy to translate for minor releases we can vote to do so with 
each.
Assign a language "maintainer" for each supported language to monitor 
translations. I suggest we start with Spanish and French since those are 
the languages our group of committers can best contribute to at this time. 
 (If we have a consensus to use Transfix, please volunteer if you'd like 
to be the maintainer for a specific language).
Once a section of the documentation is approved by the language moderator, 
we push the updates to GitHub.
I created a new JIRA issue related to globalization so we can track 
comments outside of the mailing list as well.
https://issues.apache.org/jira/browse/CB-4461

Another thing to think about, Transifex offers automatic translation for 
faster translation using google translation services or microsoft's which 
require an api key and a paid subscription.  I don't know if either of 
those companies offer a free key for open source needs. I know we have a 
few representatives from those companies that might be able to give us 
more information.

Why we should be worried about translation?
Globalization! If we can attract more developers to Cordova and make it 
easier for those developers to get up and running with cordova by 
providing documentation in their native languages,  cordova will continue 
to grow in popularity globally.


Please vote if you are okay with moving forward with Transifex as a 
solution to our translation needs.


Lisa
ldel...@us.ibm.com
@IBMLisa



From:   Lisa Seacat DeLuca/San Francisco/IBM
To: dev@cordova.apache.org, 
Date:   07/17/2013 10:23 AM
Subject:Transifex


I have been doing some research into translation services available and 
ran into a group that has been working on a solution for Open Stack using 
Transifex.  Lets face it, the cordova translation story is just not where 
it could be.  It looks like the Transifex service is free for open source 
projects.  Does anyone have a strong opinion one way or another on whether 
or not we could utilize Transifex for cordova?

Transifex website: http://www.transifex.com 
Supported File Formats: 
http://support.transifex.com/customer/portal/articles/971979-supported-file-formats
 

cordova project I created on transifex: 
https://www.transifex.com/projects/p/cordova

I uploaded the overview file (
https://www.transifex.com/projects/p/cordova/resource/guide_overview_indexmdhtml/
 
)  to give the service a try and see what we can expect.  It would be 
interesting to build this into our release cycle, especially during major 
releases when the getting started guides, plugin guides, etc. change 
drastically. 


Lisa
ldel...@us.ibm.com

Re: Deprecating in plugin.xml

[Shazron]

Oh yea, totally forgot about the Build team 8^)


On Tue, Jul 30, 2013 at 12:35 PM, Filip Maj  wrote:

> Phonegap build is an example of a team using plugman and still relying on
> plugins-plist.
>
> I will set up an issue to deprecate its use for 3.1 and remove it for 3.4.
>
> On 7/30/13 2:00 AM, "Shazron"  wrote:
>
> >Isn't our support for plugman "official" with 3.0.0? when plugman was
> >exposed to the world I'm not sure we expressed any forms of stability
> >assurance I don't think -- everything was moving at a rapid pace. IMO I'd
> >just remove support for Plugins.plist
> >
> >
> >On Mon, Jul 29, 2013 at 7:39 PM, Filip Maj  wrote:
> >
> >> Sorry yes, Plugins.plist
> >>
> >> Maybe folks are using plugman with old cordova-ios projects? Iuno
> >>
> >> On 7/29/13 7:19 PM, "Andrew Grieve"  wrote:
> >>
> >> >You mean plugins.plist?
> >> >
> >> >No need to deprecate it if it doesn't work right now anyways.
> >> >
> >> >
> >> >On Mon, Jul 29, 2013 at 10:12 PM, Filip Maj  wrote:
> >> >
> >> >> Yeah, back before we had config.xml, we had a plugins.xml for
> >> >>cordova-ios
> >> >> projects, and that¹s where service labels were mapped to classes
> >> >>
> >> >> On 7/29/13 7:09 PM, "Andrew Grieve"  wrote:
> >> >>
> >> >> >I'm not 100% sure of what  does, but if it's for
> >>setting
> >> >> >plugin-specific config settings, the code on iOS has already
> >>changed to
> >> >> >remove support for that (only settings in the main config.xml are
> >> >> >supported
> >> >> >now).
> >> >> >
> >> >> >
> >> >> >On Mon, Jul 29, 2013 at 9:22 PM, Filip Maj  wrote:
> >> >> >
> >> >> >> We currently document support for  in our spec [1].
> >> >>This
> >> >> >>is
> >> >> >> to support old cordova-ios (2.2 I believe).
> >> >> >>
> >> >> >>
> >> >> >> It would save with some lame special-case code [2] [3] [4].
> >> >> >>
> >> >> >> Warn folks using plugman w/ plugins using  elements
> >> >>that
> >> >> >> support is being removed soon? 3 releases for deprecation ya, so
> >> >>around
> >> >> >> 3.3 we remove support for it?
> >> >> >>
> >> >> >> [1]
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md#plug
> >> >> >>in
> >> >> >> s-plist
> >> >> >> [2]
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
> >> >> >>ng
> >> >> >> es.js#L93-L104
> >> >> >> [3]
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
> >> >> >>ng
> >> >> >> es.js#L147-L166
> >> >> >> [4]
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
> >> >> >>ng
> >> >> >> es.js#L236-L252
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>

Re: Android - Removing the .api namespace

[Filip Maj]

I dare you to idle in #phonegap on irc.freenode.net and answer every
plugin-related question.

On 7/30/13 12:33 PM, "Filip Maj"  wrote:

>As for who is getting angry/confused, I am helping folk on #cordova IRC
>upgrade their plugins because it won't work / not accounted for in the
>upgrade guides.
>
>On 7/30/13 12:12 PM, "Tommy-Carlos Williams"  wrote:
>
>>I don't wanna sound like I am being a pain, but reallyŠ the whole
>>deprecation policy thing is a bit pointless if it's not followed, and not
>>noisy.
>>
>>Most people who use plugins, use other people's plugins, they don't build
>>them themselves.
>>
>>The use of plugins so far in the life of Cordova has been one of massive
>>pain when in fact it should have been one of Cordova's shining lights.
>>
>>As one of the people that *does* face developer/end user wrath when this
>>stuff gets broken every few months, it would be really nice if the
>>Cordova devs doing the breaking could also be those to help the fixing.
>>
>>Blog posts. We need more. I can try to help on this and it's right up my
>>alley, but I am also in the middle of trying to ship an app, so time is
>>tight.
>>
>>I'll try to write a post on taking a 2.x plugin (say an example from
>>phonegap/phonegap-plugins) and turning it into a working 3.x plugin when
>>I get back to Australia. However, if a week has gone by and I haven't
>>been able to, can anyone put their hand up to do it in my stead?
>>Realistically it needs to cover Android and iOS at a minimum (the plugin
>>ecosystem for the other platforms is much smaller).
>>
>>Any takers?
>>
>>- tommy 
>>
>>On 30/07/2013, at 11:57 AM, Joe Bowser  wrote:
>>
>>> So, yeah, remember how I fought this, and then suddenly we came to
>>> consensus because it's better to break everything all at once?
>>> 
>>> https://issues.apache.org/jira/browse/CB-4454
>>> 
>>> Can we actually follow our deprecation policy from now on? There's
>>> people there who are being unreasonable and asking for us to extend
>>> deprecation times to be a year in length because we do things like
>>> this.
>>> 
>>> 
>>> On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
>>>  wrote:
 Yup, break everything at once.
 
 
 Simon Mac Donald
 http://hi.im/simonmacdonald
 
 
 On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard 
wrote:
 
> Normally being very averse to changing pubic API's, I'm with Andrew
>and
> Ian on this. If we are going to be making breaking changes,
>especially if
> they are small, do them all at once.
> 
> On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
> 
>> So far, we've asked plugin developers to migrate from the old-style
>> plugins to CordovaPlugin so that their plugins will work with 3.0.0.
>> Many plugin developers have already done that.
> 
> We have migrated our plugins, but have third-party plugins done the
>same?
> Or do they wait for us to release the breaking change and then they
>are
> "forced" to update their plugin? I'm guessing the latter, but that is
>just
> a guess.
> 
> I think what would help here is a Plugin Migration Guide in
>cordova-docs
> that gives a nice list of what the plugin developer needs to do. Most
> plugin devs are probably OK with making changes, as long as we tell
>them
> what they need to know.
> 
> If there is a third-party plugin that an app developer needs that is
> abandonware, then they can stick with 2.9.x until the plugin gets
>updated.
> 
> 
>>
>

Re: Deprecating in plugin.xml

[Filip Maj]

Phonegap build is an example of a team using plugman and still relying on
plugins-plist.

I will set up an issue to deprecate its use for 3.1 and remove it for 3.4.

On 7/30/13 2:00 AM, "Shazron"  wrote:

>Isn't our support for plugman "official" with 3.0.0? when plugman was
>exposed to the world I'm not sure we expressed any forms of stability
>assurance I don't think -- everything was moving at a rapid pace. IMO I'd
>just remove support for Plugins.plist
>
>
>On Mon, Jul 29, 2013 at 7:39 PM, Filip Maj  wrote:
>
>> Sorry yes, Plugins.plist
>>
>> Maybe folks are using plugman with old cordova-ios projects? Iuno
>>
>> On 7/29/13 7:19 PM, "Andrew Grieve"  wrote:
>>
>> >You mean plugins.plist?
>> >
>> >No need to deprecate it if it doesn't work right now anyways.
>> >
>> >
>> >On Mon, Jul 29, 2013 at 10:12 PM, Filip Maj  wrote:
>> >
>> >> Yeah, back before we had config.xml, we had a plugins.xml for
>> >>cordova-ios
>> >> projects, and that¹s where service labels were mapped to classes
>> >>
>> >> On 7/29/13 7:09 PM, "Andrew Grieve"  wrote:
>> >>
>> >> >I'm not 100% sure of what  does, but if it's for
>>setting
>> >> >plugin-specific config settings, the code on iOS has already
>>changed to
>> >> >remove support for that (only settings in the main config.xml are
>> >> >supported
>> >> >now).
>> >> >
>> >> >
>> >> >On Mon, Jul 29, 2013 at 9:22 PM, Filip Maj  wrote:
>> >> >
>> >> >> We currently document support for  in our spec [1].
>> >>This
>> >> >>is
>> >> >> to support old cordova-ios (2.2 I believe).
>> >> >>
>> >> >>
>> >> >> It would save with some lame special-case code [2] [3] [4].
>> >> >>
>> >> >> Warn folks using plugman w/ plugins using  elements
>> >>that
>> >> >> support is being removed soon? 3 releases for deprecation ya, so
>> >>around
>> >> >> 3.3 we remove support for it?
>> >> >>
>> >> >> [1]
>> >> >>
>> >> >>
>> >>
>> >>
>> 
>>https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md#plug
>> >> >>in
>> >> >> s-plist
>> >> >> [2]
>> >> >>
>> >> >>
>> >>
>> >>
>> 
>>https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
>> >> >>ng
>> >> >> es.js#L93-L104
>> >> >> [3]
>> >> >>
>> >> >>
>> >>
>> >>
>> 
>>https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
>> >> >>ng
>> >> >> es.js#L147-L166
>> >> >> [4]
>> >> >>
>> >> >>
>> >>
>> >>
>> 
>>https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
>> >> >>ng
>> >> >> es.js#L236-L252
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>

Re: Android - Removing the .api namespace

[Filip Maj]

As for who is getting angry/confused, I am helping folk on #cordova IRC
upgrade their plugins because it won't work / not accounted for in the
upgrade guides.

On 7/30/13 12:12 PM, "Tommy-Carlos Williams"  wrote:

>I don't wanna sound like I am being a pain, but reallyŠ the whole
>deprecation policy thing is a bit pointless if it's not followed, and not
>noisy.
>
>Most people who use plugins, use other people's plugins, they don't build
>them themselves.
>
>The use of plugins so far in the life of Cordova has been one of massive
>pain when in fact it should have been one of Cordova's shining lights.
>
>As one of the people that *does* face developer/end user wrath when this
>stuff gets broken every few months, it would be really nice if the
>Cordova devs doing the breaking could also be those to help the fixing.
>
>Blog posts. We need more. I can try to help on this and it's right up my
>alley, but I am also in the middle of trying to ship an app, so time is
>tight.
>
>I'll try to write a post on taking a 2.x plugin (say an example from
>phonegap/phonegap-plugins) and turning it into a working 3.x plugin when
>I get back to Australia. However, if a week has gone by and I haven't
>been able to, can anyone put their hand up to do it in my stead?
>Realistically it needs to cover Android and iOS at a minimum (the plugin
>ecosystem for the other platforms is much smaller).
>
>Any takers?
>
>- tommy 
>
>On 30/07/2013, at 11:57 AM, Joe Bowser  wrote:
>
>> So, yeah, remember how I fought this, and then suddenly we came to
>> consensus because it's better to break everything all at once?
>> 
>> https://issues.apache.org/jira/browse/CB-4454
>> 
>> Can we actually follow our deprecation policy from now on? There's
>> people there who are being unreasonable and asking for us to extend
>> deprecation times to be a year in length because we do things like
>> this.
>> 
>> 
>> On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
>>  wrote:
>>> Yup, break everything at once.
>>> 
>>> 
>>> Simon Mac Donald
>>> http://hi.im/simonmacdonald
>>> 
>>> 
>>> On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard 
>>>wrote:
>>> 
 Normally being very averse to changing pubic API's, I'm with Andrew
and
 Ian on this. If we are going to be making breaking changes,
especially if
 they are small, do them all at once.
 
 On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
 
> So far, we've asked plugin developers to migrate from the old-style
> plugins to CordovaPlugin so that their plugins will work with 3.0.0.
> Many plugin developers have already done that.
 
 We have migrated our plugins, but have third-party plugins done the
same?
 Or do they wait for us to release the breaking change and then they
are
 "forced" to update their plugin? I'm guessing the latter, but that is
just
 a guess.
 
 I think what would help here is a Plugin Migration Guide in
cordova-docs
 that gives a nice list of what the plugin developer needs to do. Most
 plugin devs are probably OK with making changes, as long as we tell
them
 what they need to know.
 
 If there is a third-party plugin that an app developer needs that is
 abandonware, then they can stick with 2.9.x until the plugin gets
updated.
 
 
>

Re: Android - Removing the .api namespace

[Joe Bowser]

Honestly, I really wish that we broke this on 2.9 so that there was
enough time for people to get pissed off at PhoneGap Day.  I feel that
those responsible got an easy ride since they work in mostly
anonymity, and it'll be public facing people like myself, Tommy and
Fil who feel the wrath of the users who are affected by this change.

In my opinion, the only way we can really get this change is if the
people involved in the breaking change directly feel the wrath of the
users.  That's why we have a deprecation policy to begin with.  It
definitely wasn't a magical benevolent Cordova committer invention by
any means.

On Tue, Jul 30, 2013 at 12:12 PM, Tommy-Carlos Williams
 wrote:
> I don't wanna sound like I am being a pain, but really… the whole deprecation 
> policy thing is a bit pointless if it's not followed, and not noisy.
>
> Most people who use plugins, use other people's plugins, they don't build 
> them themselves.
>
> The use of plugins so far in the life of Cordova has been one of massive pain 
> when in fact it should have been one of Cordova's shining lights.
>
> As one of the people that *does* face developer/end user wrath when this 
> stuff gets broken every few months, it would be really nice if the Cordova 
> devs doing the breaking could also be those to help the fixing.
>
> Blog posts. We need more. I can try to help on this and it's right up my 
> alley, but I am also in the middle of trying to ship an app, so time is tight.
>
> I'll try to write a post on taking a 2.x plugin (say an example from 
> phonegap/phonegap-plugins) and turning it into a working 3.x plugin when I 
> get back to Australia. However, if a week has gone by and I haven't been able 
> to, can anyone put their hand up to do it in my stead? Realistically it needs 
> to cover Android and iOS at a minimum (the plugin ecosystem for the other 
> platforms is much smaller).
>
> Any takers?
>
> - tommy
>
> On 30/07/2013, at 11:57 AM, Joe Bowser  wrote:
>
>> So, yeah, remember how I fought this, and then suddenly we came to
>> consensus because it's better to break everything all at once?
>>
>> https://issues.apache.org/jira/browse/CB-4454
>>
>> Can we actually follow our deprecation policy from now on? There's
>> people there who are being unreasonable and asking for us to extend
>> deprecation times to be a year in length because we do things like
>> this.
>>
>>
>> On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
>>  wrote:
>>> Yup, break everything at once.
>>>
>>>
>>> Simon Mac Donald
>>> http://hi.im/simonmacdonald
>>>
>>>
>>> On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard  wrote:
>>>
 Normally being very averse to changing pubic API's, I'm with Andrew and
 Ian on this. If we are going to be making breaking changes, especially if
 they are small, do them all at once.

 On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:

> So far, we've asked plugin developers to migrate from the old-style
> plugins to CordovaPlugin so that their plugins will work with 3.0.0.
> Many plugin developers have already done that.

 We have migrated our plugins, but have third-party plugins done the same?
 Or do they wait for us to release the breaking change and then they are
 "forced" to update their plugin? I'm guessing the latter, but that is just
 a guess.

 I think what would help here is a Plugin Migration Guide in cordova-docs
 that gives a nice list of what the plugin developer needs to do. Most
 plugin devs are probably OK with making changes, as long as we tell them
 what they need to know.

 If there is a third-party plugin that an app developer needs that is
 abandonware, then they can stick with 2.9.x until the plugin gets updated.


>

Re: Android - Removing the .api namespace

[Tommy-Carlos Williams]

Shazron,

As always, you rule.. 

Also, as an aside, how did I not know about this questions repo. Such a good 
resource.

- tommy



On 30/07/2013, at 12:18 PM, Shazron  wrote:

> I would - I'll see if I can write up a blog post later today based on my
> answer here: https://github.com/shazron/phonegap-questions/issues/13
> 
> 
> 
> 
> On Tue, Jul 30, 2013 at 12:12 PM, Tommy-Carlos Williams
> wrote:
> 
>> I don't wanna sound like I am being a pain, but really… the whole
>> deprecation policy thing is a bit pointless if it's not followed, and not
>> noisy.
>> 
>> Most people who use plugins, use other people's plugins, they don't build
>> them themselves.
>> 
>> The use of plugins so far in the life of Cordova has been one of massive
>> pain when in fact it should have been one of Cordova's shining lights.
>> 
>> As one of the people that *does* face developer/end user wrath when this
>> stuff gets broken every few months, it would be really nice if the Cordova
>> devs doing the breaking could also be those to help the fixing.
>> 
>> Blog posts. We need more. I can try to help on this and it's right up my
>> alley, but I am also in the middle of trying to ship an app, so time is
>> tight.
>> 
>> I'll try to write a post on taking a 2.x plugin (say an example from
>> phonegap/phonegap-plugins) and turning it into a working 3.x plugin when I
>> get back to Australia. However, if a week has gone by and I haven't been
>> able to, can anyone put their hand up to do it in my stead? Realistically
>> it needs to cover Android and iOS at a minimum (the plugin ecosystem for
>> the other platforms is much smaller).
>> 
>> Any takers?
>> 
>> - tommy
>> 
>> On 30/07/2013, at 11:57 AM, Joe Bowser  wrote:
>> 
>>> So, yeah, remember how I fought this, and then suddenly we came to
>>> consensus because it's better to break everything all at once?
>>> 
>>> https://issues.apache.org/jira/browse/CB-4454
>>> 
>>> Can we actually follow our deprecation policy from now on? There's
>>> people there who are being unreasonable and asking for us to extend
>>> deprecation times to be a year in length because we do things like
>>> this.
>>> 
>>> 
>>> On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
>>>  wrote:
 Yup, break everything at once.
 
 
 Simon Mac Donald
 http://hi.im/simonmacdonald
 
 
 On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard 
>> wrote:
 
> Normally being very averse to changing pubic API's, I'm with Andrew and
> Ian on this. If we are going to be making breaking changes, especially
>> if
> they are small, do them all at once.
> 
> On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
> 
>> So far, we've asked plugin developers to migrate from the old-style
>> plugins to CordovaPlugin so that their plugins will work with 3.0.0.
>> Many plugin developers have already done that.
> 
> We have migrated our plugins, but have third-party plugins done the
>> same?
> Or do they wait for us to release the breaking change and then they are
> "forced" to update their plugin? I'm guessing the latter, but that is
>> just
> a guess.
> 
> I think what would help here is a Plugin Migration Guide in
>> cordova-docs
> that gives a nice list of what the plugin developer needs to do. Most
> plugin devs are probably OK with making changes, as long as we tell
>> them
> what they need to know.
> 
> If there is a third-party plugin that an app developer needs that is
> abandonware, then they can stick with 2.9.x until the plugin gets
>> updated.
> 
> 
>> 
>> 

Refactored cordova-js bootstrap

[Andrew Grieve]

1. Rather than have every platform with a bootstrap-FOO.js as well as a
platform.js, I moved the bootstrap code into platform.js for the platforms.
This will also allow bootstrap logic to be unit tested.
2. I moved bootstrap.js's logic into cordova/common/init.js. Now, all
bootstrap.js does is require('cordova/init'); I figure this is a bit nicer
because again, it can be unit tested, and now lives with the rest of the
code within the lib/ directory.

I ran unit tests & mobile spec for iOS & Android, but not for windows &
blackberry. If I messed it up and the fix isn't obvious, I made sure each
platform can be reverted via a single commit:

BB: http://git-wip-us.apache.org/repos/asf/cordova-js/commit/08da18a7
win8: http://git-wip-us.apache.org/repos/asf/cordova-js/commit/732c9e91
winphone: http://git-wip-us.apache.org/repos/asf/cordova-js/commit/6da628d5

Re: Android - Removing the .api namespace

[Shazron]

I would - I'll see if I can write up a blog post later today based on my
answer here: https://github.com/shazron/phonegap-questions/issues/13




On Tue, Jul 30, 2013 at 12:12 PM, Tommy-Carlos Williams
wrote:

> I don't wanna sound like I am being a pain, but really… the whole
> deprecation policy thing is a bit pointless if it's not followed, and not
> noisy.
>
> Most people who use plugins, use other people's plugins, they don't build
> them themselves.
>
> The use of plugins so far in the life of Cordova has been one of massive
> pain when in fact it should have been one of Cordova's shining lights.
>
> As one of the people that *does* face developer/end user wrath when this
> stuff gets broken every few months, it would be really nice if the Cordova
> devs doing the breaking could also be those to help the fixing.
>
> Blog posts. We need more. I can try to help on this and it's right up my
> alley, but I am also in the middle of trying to ship an app, so time is
> tight.
>
> I'll try to write a post on taking a 2.x plugin (say an example from
> phonegap/phonegap-plugins) and turning it into a working 3.x plugin when I
> get back to Australia. However, if a week has gone by and I haven't been
> able to, can anyone put their hand up to do it in my stead? Realistically
> it needs to cover Android and iOS at a minimum (the plugin ecosystem for
> the other platforms is much smaller).
>
> Any takers?
>
> - tommy
>
> On 30/07/2013, at 11:57 AM, Joe Bowser  wrote:
>
> > So, yeah, remember how I fought this, and then suddenly we came to
> > consensus because it's better to break everything all at once?
> >
> > https://issues.apache.org/jira/browse/CB-4454
> >
> > Can we actually follow our deprecation policy from now on? There's
> > people there who are being unreasonable and asking for us to extend
> > deprecation times to be a year in length because we do things like
> > this.
> >
> >
> > On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
> >  wrote:
> >> Yup, break everything at once.
> >>
> >>
> >> Simon Mac Donald
> >> http://hi.im/simonmacdonald
> >>
> >>
> >> On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard 
> wrote:
> >>
> >>> Normally being very averse to changing pubic API's, I'm with Andrew and
> >>> Ian on this. If we are going to be making breaking changes, especially
> if
> >>> they are small, do them all at once.
> >>>
> >>> On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
> >>>
>  So far, we've asked plugin developers to migrate from the old-style
>  plugins to CordovaPlugin so that their plugins will work with 3.0.0.
>  Many plugin developers have already done that.
> >>>
> >>> We have migrated our plugins, but have third-party plugins done the
> same?
> >>> Or do they wait for us to release the breaking change and then they are
> >>> "forced" to update their plugin? I'm guessing the latter, but that is
> just
> >>> a guess.
> >>>
> >>> I think what would help here is a Plugin Migration Guide in
> cordova-docs
> >>> that gives a nice list of what the plugin developer needs to do. Most
> >>> plugin devs are probably OK with making changes, as long as we tell
> them
> >>> what they need to know.
> >>>
> >>> If there is a third-party plugin that an app developer needs that is
> >>> abandonware, then they can stick with 2.9.x until the plugin gets
> updated.
> >>>
> >>>
>
>

Re: Android - Removing the .api namespace

[Tommy-Carlos Williams]

I don't wanna sound like I am being a pain, but really… the whole deprecation 
policy thing is a bit pointless if it's not followed, and not noisy.

Most people who use plugins, use other people's plugins, they don't build them 
themselves.

The use of plugins so far in the life of Cordova has been one of massive pain 
when in fact it should have been one of Cordova's shining lights.

As one of the people that *does* face developer/end user wrath when this stuff 
gets broken every few months, it would be really nice if the Cordova devs doing 
the breaking could also be those to help the fixing.

Blog posts. We need more. I can try to help on this and it's right up my alley, 
but I am also in the middle of trying to ship an app, so time is tight.

I'll try to write a post on taking a 2.x plugin (say an example from 
phonegap/phonegap-plugins) and turning it into a working 3.x plugin when I get 
back to Australia. However, if a week has gone by and I haven't been able to, 
can anyone put their hand up to do it in my stead? Realistically it needs to 
cover Android and iOS at a minimum (the plugin ecosystem for the other 
platforms is much smaller).

Any takers?

- tommy 

On 30/07/2013, at 11:57 AM, Joe Bowser  wrote:

> So, yeah, remember how I fought this, and then suddenly we came to
> consensus because it's better to break everything all at once?
> 
> https://issues.apache.org/jira/browse/CB-4454
> 
> Can we actually follow our deprecation policy from now on? There's
> people there who are being unreasonable and asking for us to extend
> deprecation times to be a year in length because we do things like
> this.
> 
> 
> On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
>  wrote:
>> Yup, break everything at once.
>> 
>> 
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>> 
>> 
>> On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard  wrote:
>> 
>>> Normally being very averse to changing pubic API's, I'm with Andrew and
>>> Ian on this. If we are going to be making breaking changes, especially if
>>> they are small, do them all at once.
>>> 
>>> On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
>>> 
 So far, we've asked plugin developers to migrate from the old-style
 plugins to CordovaPlugin so that their plugins will work with 3.0.0.
 Many plugin developers have already done that.
>>> 
>>> We have migrated our plugins, but have third-party plugins done the same?
>>> Or do they wait for us to release the breaking change and then they are
>>> "forced" to update their plugin? I'm guessing the latter, but that is just
>>> a guess.
>>> 
>>> I think what would help here is a Plugin Migration Guide in cordova-docs
>>> that gives a nice list of what the plugin developer needs to do. Most
>>> plugin devs are probably OK with making changes, as long as we tell them
>>> what they need to know.
>>> 
>>> If there is a third-party plugin that an app developer needs that is
>>> abandonware, then they can stick with 2.9.x until the plugin gets updated.
>>> 
>>> 

Re: Android - Removing the .api namespace

[Andrew Grieve]

Can I ask who's angry?

What would we put in a point release other than updating the docs? I
attempted a shim, but found that it was not that easy because .api.Foo
instanceof Foo, but Foo is not instanceof .api.Foo. Users need to update
all of their plugins for 3.0 anyways, and this has to be one of the
smallest changes.

The upgrade docs are actually fine for the CLI case, since they say to
create a new project with the new template.


On Tue, Jul 30, 2013 at 3:01 PM, Filip Maj  wrote:

> Bah, this thread must have slipped my radar, apologies. I was replying to
> the other one. Sigh.
>
> On 7/30/13 11:57 AM, "Joe Bowser"  wrote:
>
> >So, yeah, remember how I fought this, and then suddenly we came to
> >consensus because it's better to break everything all at once?
> >
> >https://issues.apache.org/jira/browse/CB-4454
> >
> >Can we actually follow our deprecation policy from now on? There's
> >people there who are being unreasonable and asking for us to extend
> >deprecation times to be a year in length because we do things like
> >this.
> >
> >
> >On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
> > wrote:
> >> Yup, break everything at once.
> >>
> >>
> >> Simon Mac Donald
> >> http://hi.im/simonmacdonald
> >>
> >>
> >> On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard 
> >>wrote:
> >>
> >>> Normally being very averse to changing pubic API's, I'm with Andrew and
> >>> Ian on this. If we are going to be making breaking changes, especially
> >>>if
> >>> they are small, do them all at once.
> >>>
> >>> On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
> >>>
> >>> > So far, we've asked plugin developers to migrate from the old-style
> >>> > plugins to CordovaPlugin so that their plugins will work with 3.0.0.
> >>> > Many plugin developers have already done that.
> >>>
> >>> We have migrated our plugins, but have third-party plugins done the
> >>>same?
> >>> Or do they wait for us to release the breaking change and then they are
> >>> "forced" to update their plugin? I'm guessing the latter, but that is
> >>>just
> >>> a guess.
> >>>
> >>> I think what would help here is a Plugin Migration Guide in
> >>>cordova-docs
> >>> that gives a nice list of what the plugin developer needs to do. Most
> >>> plugin devs are probably OK with making changes, as long as we tell
> >>>them
> >>> what they need to know.
> >>>
> >>> If there is a third-party plugin that an app developer needs that is
> >>> abandonware, then they can stick with 2.9.x until the plugin gets
> >>>updated.
> >>>
> >>>
>
>

Re: Generating Docs with minimal changes

[Michael Brooks]

nokogiri --version
# Nokogiri (1.5.9)
---
warnings: []

libxml:
  compiled: 2.7.7
  loaded: 2.7.7
  binding: extension
nokogiri: 1.5.9
ruby:
  description: ruby 1.8.7 (2012-02-08 patchlevel 358)
[universal-darwin11.0]
  version: 1.8.7
  engine: mri
  platform: universal-darwin11.0

jodoc
SHA b64f9841e95eedcbdfaf3cb2e9817e6a00a032e2


On Thu, Jul 25, 2013 at 11:42 AM, Andrew Grieve wrote:

> Shoot, that's the same version that I have.
>
> $ md5 /usr/local/bin/markdown
> MD5 (/usr/local/bin/markdown) = c1609b303b7fe654435380a168d78acf
>
> Also have:
>
> nokogiri --version
> # Nokogiri (1.5.5)
> ---
> libxml:
>   compiled: 2.8.0
>   loaded: 2.8.0
>   binding: extension
> warnings: []
>
> ruby:
>   engine: mri
>   description: ruby 1.8.7 (2012-02-08 patchlevel 358)
> [universal-darwin12.0]
>   version: 1.8.7
>   platform: universal-darwin12.0
> nokogiri: 1.5.5
>
>
>
> joDoc doesn't seem to report a version :(.
>
> Does your nokogiri version match?
>
>
>
> On Thu, Jul 25, 2013 at 2:26 PM, Michael Brooks 
> wrote:
>
>> $ markdown --version
>>
>> This is Markdown, version 1.0.1.
>> Copyright 2004 John Gruber
>> http://daringfireball.net/projects/markdown/
>>
>>
>> On Tue, Jul 23, 2013 at 11:19 AM, Andrew Grieve wrote:
>>
>>> Working on CB-4360, and think I've got it mostly covered (use rsync
>>> instead of cp).
>>>
>>> Having this one issue though: When I update the files, they have
>>> whitespace differences:
>>>
>>> E.g.
>>>
>>> -
 -3.
 Setup New Project
 -
 +3.
 Setup New Project
>>>
>>>
>>> One guess is that this is caused from using different versions of
>>> Markdown.pl.
>>>
>>> Michael - looks like you generated the 3.0.0 docs. Could you reply with
>>> your version of Markdown.pl and I'll see if it generates the same output on
>>> my machine? If so, I'll check the file into the repo so that we are all
>>> using the same version.
>>>
>>
>>
>

Re: Android - Removing the .api namespace

[Filip Maj]

Bah, this thread must have slipped my radar, apologies. I was replying to
the other one. Sigh.

On 7/30/13 11:57 AM, "Joe Bowser"  wrote:

>So, yeah, remember how I fought this, and then suddenly we came to
>consensus because it's better to break everything all at once?
>
>https://issues.apache.org/jira/browse/CB-4454
>
>Can we actually follow our deprecation policy from now on? There's
>people there who are being unreasonable and asking for us to extend
>deprecation times to be a year in length because we do things like
>this.
>
>
>On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
> wrote:
>> Yup, break everything at once.
>>
>>
>> Simon Mac Donald
>> http://hi.im/simonmacdonald
>>
>>
>> On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard 
>>wrote:
>>
>>> Normally being very averse to changing pubic API's, I'm with Andrew and
>>> Ian on this. If we are going to be making breaking changes, especially
>>>if
>>> they are small, do them all at once.
>>>
>>> On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
>>>
>>> > So far, we've asked plugin developers to migrate from the old-style
>>> > plugins to CordovaPlugin so that their plugins will work with 3.0.0.
>>> > Many plugin developers have already done that.
>>>
>>> We have migrated our plugins, but have third-party plugins done the
>>>same?
>>> Or do they wait for us to release the breaking change and then they are
>>> "forced" to update their plugin? I'm guessing the latter, but that is
>>>just
>>> a guess.
>>>
>>> I think what would help here is a Plugin Migration Guide in
>>>cordova-docs
>>> that gives a nice list of what the plugin developer needs to do. Most
>>> plugin devs are probably OK with making changes, as long as we tell
>>>them
>>> what they need to know.
>>>
>>> If there is a third-party plugin that an app developer needs that is
>>> abandonware, then they can stick with 2.9.x until the plugin gets
>>>updated.
>>>
>>>

Re: Plugin packages on Android

[Joe Bowser]

I think this is the wrong thread!

On Tue, Jul 30, 2013 at 11:52 AM, Filip Maj  wrote:
> It seems like removal of the "org.apache.cordova.api" namespace happened
> in 3.0 anyways, even though there was no consensus on this thread for it,
> with the big one being CordovaPlugin (moved to org.apache.cordova), and no
> shims were put in place.
>
> No surprise, users are confused and angry.
>
> I would think at a minimum we would have put in a deprecation notice, let
> alone keep shims around to support users for a few months.
>
> I think this issue is big enough to warrant releasing a 3.0.1.
>
> The change was also not documented which I've filed as CB-4454 [1].
>
> I'm not pleased about this commit landing [2].
>
> [1] https://issues.apache.org/jira/browse/CB-4454
> [2]
> https://github.com/apache/cordova-android/commit/b5c3ac605ac2d771a56dadc3a0
> 6cd120976f9a99
>
> On 7/16/13 9:18 AM, "Brian LeRoux"  wrote:
>
>>ftr phonegap predates semver which is basically a reaction to ruby's
>>globally installed package legacy
>>
>>that said, its a neat system
>>
>>On Tue, Jul 16, 2013 at 12:22 AM, Filip Maj  wrote:
>>> We definitely do not follow semver
>>>
>>> http://wiki.apache.org/cordova/DeprecationPolicy
>>>
>>>
>>> On 7/16/13 12:15 AM, "David Pfahler"  wrote:
>>>
What or where exactly is the deprecation policy? It's probably not
semver,
because breaking changes need a major version update in semver. Hence,
breaking these plugins would require 4.0, not 3.1. But I guess this is
just
not how you have set it up.


On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve 
wrote:

> On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux  wrote:
>
> > A package namespace is not a part of the API? Are we saying we in
> > Cordova draw the semantic line at a method signature? (Its certainly
> > not a normal view on what defines an API. Anyhow! Super not
> > important.)
> >
> > One more time! Specifics. What packages are changing in precisely
>what
> > files? Right now we're discussing a completely undefined scope in
> > light of an obviously standard best practice.
> >
> >
> >
> > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve
>
> > wrote:
> > > -1 to shims. A plugin's java package name shouldn't be considered
>a
> part
> > of
> > > its API. That's why there is a mapping in the config.xml.
> > >
> > > Shouldn't have to change any require() statements, or any JS at
>all.
> > Those
> > > use plugin IDs, not java namespaces.
> > >
> > > Replace-all on the package statement at the top of the file, and
>change
> > the
> > > reference in plugin.xml. I'd put this change in the "polish"
>category.
> > > That's what we should be doing now, no?
> >
> ^^ this is the specifics. pkg stmts for plugin files + refs in
>plugin.xml.
> This is different from the phonegap->cordova change because a) no core
> files are changed and b) we've already changed the pkg name by adding
> ".core"
>
>
> > >
> > >
> > >
> > >
> > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj  wrote:
> > >
> > >> +1 wait until 3.1.
> > >>
> > >> +1 add shims for less breakage
> > >>
> > >> Also worth pointing out that we'll need to add this to the
>deprecation
> > >> list on the wiki
> > >>
> > >> On 7/15/13 11:30 AM, "Simon MacDonald"
>
> > wrote:
> > >>
> > >> >The reason things broke back then was we didn't leave in shims
>to
> point
> > >> >anyone compiling against com.phonegap.api to
>org.apache.cordova.api.
> > That
> > >> >was quickly corrected.
> > >> >
> > >> >I agree with the package name change but with 3.0 shipping this
> > week(?).
> > >> >It
> > >> >should probably wait until the next version.
> > >> >
> > >> >
> > >> >Simon Mac Donald
> > >> >http://hi.im/simonmacdonald
> > >> >
> > >> >
> > >> >On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux 
>wrote:
> > >> >
> > >> >> No. You are proposing an API change. A package is most
>certainly a
> > >> >> part of the API! When we moved from `com.phonegap` to
>`org.apache`
> > >> >> there was a huge outcry b/c it broke all existing community
> plugins.
> > >> >>
> > >> >> I'm completely open to changing stuff for 3.0 but, again, what
> > >> >> specifically are you proposing we change?
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI
> >
> > >> >>wrote:
> > >> >> > I agree. The only downside I see is that it will be hard to
> > dissociate
> > >> >> core
> > >> >> > plugins from other but I don't think it's really that
>important.
> > Also
> > >> >> > because it's not a giant change it could happen for 3.0.
> > >> >> >
> > >>

Re: Android - Removing the .api namespace

[Joe Bowser]

So, yeah, remember how I fought this, and then suddenly we came to
consensus because it's better to break everything all at once?

https://issues.apache.org/jira/browse/CB-4454

Can we actually follow our deprecation policy from now on? There's
people there who are being unreasonable and asking for us to extend
deprecation times to be a year in length because we do things like
this.


On Wed, Jul 10, 2013 at 12:58 PM, Simon MacDonald
 wrote:
> Yup, break everything at once.
>
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Wed, Jul 10, 2013 at 3:55 PM, Marcel Kinard  wrote:
>
>> Normally being very averse to changing pubic API's, I'm with Andrew and
>> Ian on this. If we are going to be making breaking changes, especially if
>> they are small, do them all at once.
>>
>> On Jul 9, 2013, at 11:06 PM, Joe Bowser  wrote:
>>
>> > So far, we've asked plugin developers to migrate from the old-style
>> > plugins to CordovaPlugin so that their plugins will work with 3.0.0.
>> > Many plugin developers have already done that.
>>
>> We have migrated our plugins, but have third-party plugins done the same?
>> Or do they wait for us to release the breaking change and then they are
>> "forced" to update their plugin? I'm guessing the latter, but that is just
>> a guess.
>>
>> I think what would help here is a Plugin Migration Guide in cordova-docs
>> that gives a nice list of what the plugin developer needs to do. Most
>> plugin devs are probably OK with making changes, as long as we tell them
>> what they need to know.
>>
>> If there is a third-party plugin that an app developer needs that is
>> abandonware, then they can stick with 2.9.x until the plugin gets updated.
>>
>>

Re: Plugin packages on Android

[Filip Maj]

It seems like removal of the "org.apache.cordova.api" namespace happened
in 3.0 anyways, even though there was no consensus on this thread for it,
with the big one being CordovaPlugin (moved to org.apache.cordova), and no
shims were put in place.

No surprise, users are confused and angry.

I would think at a minimum we would have put in a deprecation notice, let
alone keep shims around to support users for a few months.

I think this issue is big enough to warrant releasing a 3.0.1.

The change was also not documented which I've filed as CB-4454 [1].

I'm not pleased about this commit landing [2].

[1] https://issues.apache.org/jira/browse/CB-4454
[2] 
https://github.com/apache/cordova-android/commit/b5c3ac605ac2d771a56dadc3a0
6cd120976f9a99

On 7/16/13 9:18 AM, "Brian LeRoux"  wrote:

>ftr phonegap predates semver which is basically a reaction to ruby's
>globally installed package legacy
>
>that said, its a neat system
>
>On Tue, Jul 16, 2013 at 12:22 AM, Filip Maj  wrote:
>> We definitely do not follow semver
>>
>> http://wiki.apache.org/cordova/DeprecationPolicy
>>
>>
>> On 7/16/13 12:15 AM, "David Pfahler"  wrote:
>>
>>>What or where exactly is the deprecation policy? It's probably not
>>>semver,
>>>because breaking changes need a major version update in semver. Hence,
>>>breaking these plugins would require 4.0, not 3.1. But I guess this is
>>>just
>>>not how you have set it up.
>>>
>>>
>>>On Tue, Jul 16, 2013 at 1:15 AM, Andrew Grieve 
>>>wrote:
>>>
 On Mon, Jul 15, 2013 at 5:23 PM, Brian LeRoux  wrote:

 > A package namespace is not a part of the API? Are we saying we in
 > Cordova draw the semantic line at a method signature? (Its certainly
 > not a normal view on what defines an API. Anyhow! Super not
 > important.)
 >
 > One more time! Specifics. What packages are changing in precisely
what
 > files? Right now we're discussing a completely undefined scope in
 > light of an obviously standard best practice.
 >
 >
 >
 > On Mon, Jul 15, 2013 at 12:14 PM, Andrew Grieve

 > wrote:
 > > -1 to shims. A plugin's java package name shouldn't be considered
a
 part
 > of
 > > its API. That's why there is a mapping in the config.xml.
 > >
 > > Shouldn't have to change any require() statements, or any JS at
all.
 > Those
 > > use plugin IDs, not java namespaces.
 > >
 > > Replace-all on the package statement at the top of the file, and
change
 > the
 > > reference in plugin.xml. I'd put this change in the "polish"
category.
 > > That's what we should be doing now, no?
 >
 ^^ this is the specifics. pkg stmts for plugin files + refs in
plugin.xml.
 This is different from the phonegap->cordova change because a) no core
 files are changed and b) we've already changed the pkg name by adding
 ".core"


 > >
 > >
 > >
 > >
 > > On Mon, Jul 15, 2013 at 2:49 PM, Filip Maj  wrote:
 > >
 > >> +1 wait until 3.1.
 > >>
 > >> +1 add shims for less breakage
 > >>
 > >> Also worth pointing out that we'll need to add this to the
deprecation
 > >> list on the wiki
 > >>
 > >> On 7/15/13 11:30 AM, "Simon MacDonald"

 > wrote:
 > >>
 > >> >The reason things broke back then was we didn't leave in shims
to
 point
 > >> >anyone compiling against com.phonegap.api to
org.apache.cordova.api.
 > That
 > >> >was quickly corrected.
 > >> >
 > >> >I agree with the package name change but with 3.0 shipping this
 > week(?).
 > >> >It
 > >> >should probably wait until the next version.
 > >> >
 > >> >
 > >> >Simon Mac Donald
 > >> >http://hi.im/simonmacdonald
 > >> >
 > >> >
 > >> >On Mon, Jul 15, 2013 at 2:07 PM, Brian LeRoux 
wrote:
 > >> >
 > >> >> No. You are proposing an API change. A package is most
certainly a
 > >> >> part of the API! When we moved from `com.phonegap` to
`org.apache`
 > >> >> there was a huge outcry b/c it broke all existing community
 plugins.
 > >> >>
 > >> >> I'm completely open to changing stuff for 3.0 but, again, what
 > >> >> specifically are you proposing we change?
 > >> >>
 > >> >>
 > >> >>
 > >> >> On Mon, Jul 15, 2013 at 10:43 AM, Anis KADRI
>>> >
 > >> >>wrote:
 > >> >> > I agree. The only downside I see is that it will be hard to
 > dissociate
 > >> >> core
 > >> >> > plugins from other but I don't think it's really that
important.
 > Also
 > >> >> > because it's not a giant change it could happen for 3.0.
 > >> >> >
 > >> >> >
 > >> >> > On Mon, Jul 15, 2013 at 10:33 AM, Max Woghiren <
 m...@chromium.org>
 > >> >> wrote:
 > >> >> >
 > >> >> >> I'm not proposing any API changes in this email; example
(1)
 does
 > >> >> mention
 > >> >> 

Re: Google Team's Task Backlog: Plugman & CLI

[Frank Hennig]

No, not for .gitignore for the whole point "Set platform & plugin sources & 
versions in config.xml, added by cordova tool upon add"  including the feature 
to save the platform and plugin dependencies. "E.g like npm install --save" 

On Jul 30, 2013, at 6:43 PM, Filip Maj wrote:

> 
>>>- E.g. Support the setup of having plugins/ and platforms/ in your
>>> .gitignore
>> 
>> Has someone created a feature branch in git for this feature meanwhile?
>> I'm really interested in this feature. Actual we discuss in our company,
>> to wait for this feature, or build our own solution.
>> Has someone created a roadmap for this feature?
> 
> For .gitignore? Yes, two related issues:
> 
> - implement a .cordovaignore [1]
> - provide a sample .gitignore with the cli [2]
> 
> [1] https://issues.apache.org/jira/browse/CB-3383
> [2] https://issues.apache.org/jira/browse/CB-4321
> 

Re: Plugin / Platform mismatch problems

[Brian LeRoux]

Oh, yes, it could also be made to install from the npm registry. It
does neither of those things yet.

On Tue, Jul 30, 2013 at 9:43 AM, Andrew Grieve  wrote:
> A federated system just means that anyone can host a directory of plugins,
> yes? Anis was saying that plugman could be easily made to point at any
> couchdb instance. Is that not federated?
>
>
> On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux  wrote:
>
>> No, at least I don't think so. The install/uninstall are more clobbers
>> and plugin.xml is not a thing npm has any desire to become aware of.
>>
>> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve 
>> wrote:
>> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux  wrote:
>> >
>> >> > Would this require that we use the node_modules dependency structure?
>> >>
>> >> No. We would teach npm install about our structure.
>> >>
>> >>
>> >> > Would we be able to enforce our  as
>> well
>> >> > as our > min-os-version="5.0">
>> >> > constraints?
>> >>
>> >> Yes.
>> >>
>> >>
>> >> > Some things will be uglier to express as json I think. E.g.: trying to
>> >> > embed xml snippets (like for ), that contain many "
>> >> characters
>> >> > and newline characters.
>> >>
>> >> Yes.
>> >>
>> >>
>> >> > Making things harder to search for has been pointed out as a
>> >> disadvantage.
>> >> > What would be the advantages?
>> >>
>> >> We implement a theoretically federated system. Cordova would continue
>> >> to use its own registry. (And thusly downstream distributions could
>> >> use their own.)
>> >>
>> >
>> > I thought this was already true with Anis' current setup?
>>

Re: Medic - Automated Testing

[Filip Maj]

That all sounds great. Kick it off David!

On 7/30/13 5:43 AM, "David Kemp"  wrote:

>It looked like much of the device-specific deployment bits could be
>applied
>between cli prepare and cli run - as long as run does not do a prepare -
>or
>a deploy option is added (discussed in a separate thread).
>Then I think you can deploy to a device and start a timer (x n devices).
>
>There's probably stuff I'm missing, but the lack of a deploy-only option
>in
>cli was the only roadblock I saw.
>
>I was thinking of a flow like the 'working with 3.0' page with a few
>additions. That keeps the test environment really close to our recommended
>workflow.
>
>Roughly:
>* coho to get everything (platforms, plugins, js, cli, mobilespec)
>* npm install cli
>* npm install js
>* build js (log tests)
>* patch json
>* cli to add platforms, plugins
>* copy in the newest js
>* hook up the mobilespec project
>* cli prepare
>* Medic bits to patch the project for each platform
>* cli to compile for each platform
>* cli to deploy to each device
>
>all along there, the Medic/couchDB stuff needs to be recording
>success/failures.
>
>
>
>
>
>
>
>On Mon, Jul 29, 2013 at 6:04 PM, Filip Maj  wrote:
>
>> Definitely agree that the presentation bits need a ton of work. I
>> bikeshedded the whole thing. Essentially the web frontend can be
>> completely tossed. The reusable bits are the bits integrating with the
>> couch db.
>>
>> I really want to have medic run on top of cordova-cli, but there are
>> limitations there. A bunch of the multi-device deployment scripts in
>>medic
>> are built right on top of native mobile tooling, and I'm not sure if
>>that
>> is possible to implement right now on top of cordova-cli. Additionally,
>>I
>> am unsure if that is the type of use case that we want to support in
>> cordova-cli. If so: we should refactor cordova-cli to enable it. If not,
>> well, then we support it in medic.
>>
>> Once the repo is up and we push stuff from my fork over we can start
>> figure out a roadmap for it. We DEFINITELY should talk about medic at
>>our
>> committer meeting coming up .. Whenever that is.
>>
>> On 7/29/13 11:35 AM, "David Kemp"  wrote:
>>
>> >I have been reviewing the medic components and the procedures for
>>testing
>> >the various parts of the Cordova project. With the changes in 3.0,
>>there
>> >are plugins that need to be handled and as already mentioned, I would
>>like
>> >to expand to include the tooling as well. One side effect of this is
>>error
>> >reporting on about 20 'projects' instead of just 2-3.
>> >
>> >Currently medic does a bunch of things :
>> >* provides a dashboard of the test results and commits
>> >* watches for commits on the android, ios,blackberry and mobilespec
>> >projects
>> >* when commits happen
>> >  * get the newest code
>> >  * build and report any errors to couchdb
>> >  * modify a few things to add jasmine reporting to a couchdb
>> >  * deploy to a bunch of appropriate devices
>> >  * log to couchdb if the tests do not finish in time
>> >
>> >With the 3.0 structure, the git monitoring and project structure gets
>> >quite
>> >a bit more interesting. Also we have now added a bunch of tools that do
>> >some of this as part of their flow that we should be testing.
>> >
>> >So 
>> >
>> >I propose that the cordova-cli and cordova-coho tools be used as part
>>of
>> >the test process. This means using something to watch for commits, then
>> >launch coho to get a full set of plugins, platforms and mobilespec. It
>> >might be wise at this point to even compile cordova-js and log the
>>results
>> >of the tests there.
>> >Then some medic magic needs to happen to prepare the project for
>>jasmine
>> >reporting and auto-launch. Then use cli to build and deploy.
>> >Any errors in the tooling would need to be captured in the test DB as
>> >separate items from the errors in the platforms.
>> >
>> >For this to work, the medic components to manage the db and prepare a
>> >project for an automated mobilespec would need to be broken out into
>> >separate utilities. Also there would probably need to be a few
>>additions
>> >to
>> >cli to target multiple devices, etc.
>> >
>> >At the top level, we still need discovery of new commits, but over a
>>broad
>> >range of projects. There are bits in medic that do that (needs a little
>> >work) or possibly use buildbot for that layer. One advantage of that
>>would
>> >be the already built-in notification for a broken build (email/irc,
>>...).
>> >Perhaps we could even report the commit(s) that broke it...
>> >
>> >The data presentation/reporting will need some work. There will be lots
>> >more to show.
>> >
>> >Thoughts and/or discussion?
>>
>>

Re: Google Team's Task Backlog: Plugman & CLI

[Filip Maj]

>> - E.g. Support the setup of having plugins/ and platforms/ in your
>> .gitignore
>
>Has someone created a feature branch in git for this feature meanwhile?
>I'm really interested in this feature. Actual we discuss in our company,
>to wait for this feature, or build our own solution.
>Has someone created a roadmap for this feature?

For .gitignore? Yes, two related issues:

- implement a .cordovaignore [1]
- provide a sample .gitignore with the cli [2]

[1] https://issues.apache.org/jira/browse/CB-3383
[2] https://issues.apache.org/jira/browse/CB-4321

Re: Cordova Android Commit Needs Review

[Max Woghiren]

I've committed your work.  Thanks!  Please close the pull request in GitHub.


On Tue, Jul 30, 2013 at 5:17 AM, Sharif Ahmed  wrote:

> Hi,
>
> I have submitted the ICLA.
>
> It is now safe to merge my commits.
>
> Thanks :)
>
>
> On Mon, Jul 29, 2013 at 9:12 PM, Sharif Ahmed 
> wrote:
>
> > Yes yes, I totally overlooked.
> >
> > Ok I will do it by tomorrow and let you guys know.
> >
> > Thanks for reminder me :)
> >
> >
> > On Mon, Jul 29, 2013 at 8:15 PM, Andrew Grieve  >wrote:
> >
> >> Sharif, fixes look good. I think you need to sign the Apache ICLA before
> >> we
> >> can pull the code in though:
> >>
> >> http://www.apache.org/licenses/#clas
> >>
> >> As noted on: http://wiki.apache.org/cordova/ContributorWorkflow
> >>
> >>
> >>
> >> On Sun, Jul 28, 2013 at 3:22 AM, Sharif Ahmed 
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > Need a review to my recent commit:
> >> > https://github.com/apache/cordova-android/pull/76
> >> >
> >> > Jira Issue:
> >> > https://issues.apache.org/jira/browse/CB-4410
> >> >
> >> > Thanks.
> >> >
> >>
> >
> >
> >
> > --
> > Regards,
> >
> > Sharif Ahmed
> > Junior Software Engineer
> > Therap Services, LLC
> > +01715438290
> >
> >
>
>
> --
> Regards,
>
> Sharif Ahmed
> Junior Software Engineer
> Therap Services, LLC
> +01715438290
>

Fwd: ICLA

[Sharif Ahmed]

FYI

-- Forwarded message --
From: James Carman 
Date: Tue, 30 Jul 2013 14:11:08 +
Subject: Re: ICLA
To: Sharif Ahmed 
Cc: secret...@apache.org, Sharif Ahmed ,
priv...@cordova.apache.org

Dear Sharif Ahmed,

This message acknowledges receipt of your ICLA, which has been filed
in the Apache Software Foundation records.

If you have been invited as a committer, please advise the project PMC
that your ICLA has been filed.

Warm Regards,

-- James Carman
Assistant Secretary, Apache Software Foundation

RE: authoring docs

[Michael Sierra]

Thanks.  I've been adding to it randomly & without a great deal of thought as I 
go.   I'd be interested in any feedback for any issues you notice are treated 
inconsistently in the doc.

--Mike S



From: Marcel Kinard [cmarc...@gmail.com]
Sent: Monday, July 29, 2013 3:46 PM
To: dev@cordova.apache.org
Subject: authoring docs

FYI: @msierra, I added a shout-out to your style guide from the 
ContributorWorkflow and CommitterWorkflow wiki pages.

Begin forwarded message:

> From: Apache Wiki 
> Subject: [Cordova Wiki] Update of "ContributorWorkflow" by MarcelKinard
> Date: July 29, 2013 3:35:18 PM EDT
> To: Apache Wiki 
> Reply-To: dev@cordova.apache.org
>
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Cordova Wiki" for 
> change notification.
>
> The "ContributorWorkflow" page has been changed by MarcelKinard:
> https://wiki.apache.org/cordova/ContributorWorkflow?action=diff&rev1=29&rev2=30
>
> Comment:
> added reference to the style guidelines
>
>
>  It is recommended that you add a comment in Jira about what testing you did 
> with your change, so a committer can understand what testing was done before 
> they merge your change. It is also recommended that where reasonably 
> feasible, you add automated tests to validate your change and catch any 
> future regressions.
>
> + If you are writing documentation (i.e., cordova-docs), then be aware of the 
> [[https://github.com/apache/cordova-docs/blob/master/STYLESHEET.md|style 
> guidelines]].
> +
>  === Commit More File Changes ===
>  {{{
>  $ myeditor accelerometer/watchPosition.md

Re: Google Team's Task Backlog: iOS

[David Kemp]

Note that the PluginResult callback would be done synchronously in the
bridge, possibly impacting other PluginResult timings.



On Mon, Jul 29, 2013 at 10:43 AM, Andrew Grieve wrote:

> On Thu, Jul 25, 2013 at 3:06 PM, Shazron  wrote:
>
> > Comments inline.
> >
> >
> > cordova-ios:
> > >
> > > - Move header symbols into .m files where possible (reduce API surface)
> > >
> > > Makes sense now since the core code shouldn't be called into with the
> > exception of some classes like CDVPlugin.h
> >
> >
> >
> > > - Move resource copy step into an external script
> > >
> >
> > +1 - it's a PITA to edit Run scripts in .pbxproj when not in Xcode
> >
> >
> > >
> > > - Make Xcode have a custom build step that runs prepare for CLI setup
> > >
> > >
> >  as long as it works for people not using the CLI
> >
> >
> > > - Make Xcode's project navigator point to your root www/ and merges/
> > >
> > >
> > also, have to make sure if user not using the CLI
> >
> >
> >
> > > - (CB-3900) Have PluginResult that gets populated lazily - at the time
> of
> > > being sent over the bridge.
> > >
> >
> > not sure what this is exactly, the issue referred to is an Android issue?
> >
> This is more of an Android problem, but there was a report of accelerometer
> callbacks being sent faster than the bridge could deliver them. Same thing
> could happen with FileTransfer progress events. The primary example is when
> there's a JS alert on Android. I figured that this scenario would apply to
> both platforms though.
>
> The idea here is that a plugin can send a PluginResult that has a callback
> in it instead of a value. The plugin then knows not to send any further
> PluginResults until that callback has been called. When the bridge goes to
> serialize pending PluginResults to be sent to JS, it calls the callback in
> order to populate the value of the result. This will ensure the
> PluginResult has the freshest data. This approach should be used for
> accelerometer, compass, progress events.
>

Re: Google Team's Task Backlog: Plugman & CLI

[Frank Hennig]

On 07/25/2013 07:48 PM, Andrew Grieve wrote:

We've done some planning around what we'd like to get done over the next
quarter, and so I thought I'd share.

This isn't to say that we'll be going and doing these things without
further discussion or proper JIRA issues. It also doesn't mean we will be
solely focused on this list, nor that we'll actually end up completing
everything on the list. Just that we *currently* think that these things
should get done.


  cordova-cli:

- "plugin rm --force" To remove a plugin that is depended on

- Motive here is to be able to remove & re-add plugins in mobile-spec

- "project upgrade" To execute platform update scripts

- E.g. to move from 3.0 -> 3.1, Grab the new CLI and run "cordova
platform upgrade android"

- Set platform & plugin sources & versions in config.xml, added by cordova
tool upon add

- E.g. like: npm install --save

- E.g. Support the setup of having plugins/ and platforms/ in your
.gitignore


Has someone created a feature branch in git for this feature meanwhile? 
I'm really interested in this feature. Actual we discuss in our company, 
to wait for this feature, or build our own solution.

Has someone created a roadmap for this feature?




- Purge lib/ from git history so the repo clones faster

- Make CLI fast (fix shelljs.exec problem)

- Have platforms specifying what default plugins they come with (e.g.
Android's App plugin)

- Make --verbose on by default

- Move config.xml to be a sibling of www/ (but still support having one in
www/ for backwards compat)

- Separate npm modules into "cordova" and "cordova-cli" (a la grunt)


cordova-plugman:

- Support some assets x-platform (e.g. icon, splashscreen)

- Change existing  to do a shallow merge (aka, it's a collection of
clobbers)

- Add a version of  that targets a module instead of a symbol

- Add support for specifying iOS Localizable.strings files

- Support for  tag to specify which version of a plugin is
compatible with your version of cordova-core

Re: Away

[James Jong]

Thanks Shaz!  I ran thru the tests in wiki for 2.9 so I should be good there.  
I will need to brush up on what's available in coho.

-James Jong

On Jul 30, 2013, at 4:54 AM, Shazron  wrote:

> Welcome back James! Thanks :) A lot of the procedures are in the Wiki
> anyway (I hope), and some of the tasks can be done by cordova-coho as
> well...
> 
> 
> On Mon, Jul 29, 2013 at 6:47 PM, James Jong  wrote:
> 
>> Shaz,
>> I've been away a good portion in July but will be around in August.  I can
>> cover iOS testing/release duties while you're away.
>> -James Jong
>> 
>> On Jul 29, 2013, at 7:26 PM, Shazron  wrote:
>> 
>>> iOS 7 beta 4 out today, I'd say we probably can start testing with the
>> next
>>> beta onwards. Checking API diffs, tons of new APIs added/removed in this
>>> release, so I wouldn't call it "stable" yet.
>>> 
>>> 
>>> On Mon, Jul 29, 2013 at 4:22 PM, Brian LeRoux  wrote:
>>> 
 Also, think we are following the tradition of not shipping a platform
 update (3.1) until end of Sept. Though consensus otherwise could make
 this statement irrelevant. Either way, we probably want to wait for
 iOS7 to drop.
 
 
 On Mon, Jul 29, 2013 at 6:07 PM, Shazron  wrote:
> If any of the committers want read-write privileges to the ios-sim and
> ios-deploy repos, let me know...
> 
> 
> On Mon, Jul 29, 2013 at 2:10 PM, Shazron  wrote:
> 
>> Hi guys,
>> I'll be away from Aug 1st and back on Aug 26th, where my work hours
>> will
>> be UTC+08:00 (Singapore time) based.
>> 
>> Not sure when 3.1.0 is slated to be released, but it's likely I will
 miss
>> the window for helping out with the release -- if someone can pick up
 the
>> release/testing baton for iOS that will be great. I doubt I will get
>> to
>> Cordova OS X CLI issues for 3.1.0, it will have to wait for a future
>> release.
>> 
>> Trying to finish up any remaining CLI issues for iOS. The ios-sim and
>> ios-deploy tools used by cordova-ios are under the "phonegap"
 organization
>> in Github, and if patches are needed any of the Adobe committers have
>> access to them.
>> 
 
>> 
>> 

Re: Plugin / Platform mismatch problems

[Andrew Grieve]

A federated system just means that anyone can host a directory of plugins,
yes? Anis was saying that plugman could be easily made to point at any
couchdb instance. Is that not federated?


On Mon, Jul 29, 2013 at 11:38 PM, Brian LeRoux  wrote:

> No, at least I don't think so. The install/uninstall are more clobbers
> and plugin.xml is not a thing npm has any desire to become aware of.
>
> On Mon, Jul 29, 2013 at 11:24 PM, Andrew Grieve 
> wrote:
> > On Mon, Jul 29, 2013 at 11:19 PM, Brian LeRoux  wrote:
> >
> >> > Would this require that we use the node_modules dependency structure?
> >>
> >> No. We would teach npm install about our structure.
> >>
> >>
> >> > Would we be able to enforce our  as
> well
> >> > as our  min-os-version="5.0">
> >> > constraints?
> >>
> >> Yes.
> >>
> >>
> >> > Some things will be uglier to express as json I think. E.g.: trying to
> >> > embed xml snippets (like for ), that contain many "
> >> characters
> >> > and newline characters.
> >>
> >> Yes.
> >>
> >>
> >> > Making things harder to search for has been pointed out as a
> >> disadvantage.
> >> > What would be the advantages?
> >>
> >> We implement a theoretically federated system. Cordova would continue
> >> to use its own registry. (And thusly downstream distributions could
> >> use their own.)
> >>
> >
> > I thought this was already true with Anis' current setup?
>

Re: Medic - Automated Testing

[David Kemp]

It looked like much of the device-specific deployment bits could be applied
between cli prepare and cli run - as long as run does not do a prepare - or
a deploy option is added (discussed in a separate thread).
Then I think you can deploy to a device and start a timer (x n devices).

There's probably stuff I'm missing, but the lack of a deploy-only option in
cli was the only roadblock I saw.

I was thinking of a flow like the 'working with 3.0' page with a few
additions. That keeps the test environment really close to our recommended
workflow.

Roughly:
* coho to get everything (platforms, plugins, js, cli, mobilespec)
* npm install cli
* npm install js
* build js (log tests)
* patch json
* cli to add platforms, plugins
* copy in the newest js
* hook up the mobilespec project
* cli prepare
* Medic bits to patch the project for each platform
* cli to compile for each platform
* cli to deploy to each device

all along there, the Medic/couchDB stuff needs to be recording
success/failures.







On Mon, Jul 29, 2013 at 6:04 PM, Filip Maj  wrote:

> Definitely agree that the presentation bits need a ton of work. I
> bikeshedded the whole thing. Essentially the web frontend can be
> completely tossed. The reusable bits are the bits integrating with the
> couch db.
>
> I really want to have medic run on top of cordova-cli, but there are
> limitations there. A bunch of the multi-device deployment scripts in medic
> are built right on top of native mobile tooling, and I'm not sure if that
> is possible to implement right now on top of cordova-cli. Additionally, I
> am unsure if that is the type of use case that we want to support in
> cordova-cli. If so: we should refactor cordova-cli to enable it. If not,
> well, then we support it in medic.
>
> Once the repo is up and we push stuff from my fork over we can start
> figure out a roadmap for it. We DEFINITELY should talk about medic at our
> committer meeting coming up .. Whenever that is.
>
> On 7/29/13 11:35 AM, "David Kemp"  wrote:
>
> >I have been reviewing the medic components and the procedures for testing
> >the various parts of the Cordova project. With the changes in 3.0, there
> >are plugins that need to be handled and as already mentioned, I would like
> >to expand to include the tooling as well. One side effect of this is error
> >reporting on about 20 'projects' instead of just 2-3.
> >
> >Currently medic does a bunch of things :
> >* provides a dashboard of the test results and commits
> >* watches for commits on the android, ios,blackberry and mobilespec
> >projects
> >* when commits happen
> >  * get the newest code
> >  * build and report any errors to couchdb
> >  * modify a few things to add jasmine reporting to a couchdb
> >  * deploy to a bunch of appropriate devices
> >  * log to couchdb if the tests do not finish in time
> >
> >With the 3.0 structure, the git monitoring and project structure gets
> >quite
> >a bit more interesting. Also we have now added a bunch of tools that do
> >some of this as part of their flow that we should be testing.
> >
> >So 
> >
> >I propose that the cordova-cli and cordova-coho tools be used as part of
> >the test process. This means using something to watch for commits, then
> >launch coho to get a full set of plugins, platforms and mobilespec. It
> >might be wise at this point to even compile cordova-js and log the results
> >of the tests there.
> >Then some medic magic needs to happen to prepare the project for jasmine
> >reporting and auto-launch. Then use cli to build and deploy.
> >Any errors in the tooling would need to be captured in the test DB as
> >separate items from the errors in the platforms.
> >
> >For this to work, the medic components to manage the db and prepare a
> >project for an automated mobilespec would need to be broken out into
> >separate utilities. Also there would probably need to be a few additions
> >to
> >cli to target multiple devices, etc.
> >
> >At the top level, we still need discovery of new commits, but over a broad
> >range of projects. There are bits in medic that do that (needs a little
> >work) or possibly use buildbot for that layer. One advantage of that would
> >be the already built-in notification for a broken build (email/irc, ...).
> >Perhaps we could even report the commit(s) that broke it...
> >
> >The data presentation/reporting will need some work. There will be lots
> >more to show.
> >
> >Thoughts and/or discussion?
>
>

Re: Cordova Android Commit Needs Review

[Sharif Ahmed]

Hi,

I have submitted the ICLA.

It is now safe to merge my commits.

Thanks :)


On Mon, Jul 29, 2013 at 9:12 PM, Sharif Ahmed  wrote:

> Yes yes, I totally overlooked.
>
> Ok I will do it by tomorrow and let you guys know.
>
> Thanks for reminder me :)
>
>
> On Mon, Jul 29, 2013 at 8:15 PM, Andrew Grieve wrote:
>
>> Sharif, fixes look good. I think you need to sign the Apache ICLA before
>> we
>> can pull the code in though:
>>
>> http://www.apache.org/licenses/#clas
>>
>> As noted on: http://wiki.apache.org/cordova/ContributorWorkflow
>>
>>
>>
>> On Sun, Jul 28, 2013 at 3:22 AM, Sharif Ahmed 
>> wrote:
>>
>> > Hi,
>> >
>> > Need a review to my recent commit:
>> > https://github.com/apache/cordova-android/pull/76
>> >
>> > Jira Issue:
>> > https://issues.apache.org/jira/browse/CB-4410
>> >
>> > Thanks.
>> >
>>
>
>
>
> --
> Regards,
>
> Sharif Ahmed
> Junior Software Engineer
> Therap Services, LLC
> +01715438290
>
>


-- 
Regards,

Sharif Ahmed
Junior Software Engineer
Therap Services, LLC
+01715438290

Re: Deprecating in plugin.xml

[Shazron]

Isn't our support for plugman "official" with 3.0.0? when plugman was
exposed to the world I'm not sure we expressed any forms of stability
assurance I don't think -- everything was moving at a rapid pace. IMO I'd
just remove support for Plugins.plist


On Mon, Jul 29, 2013 at 7:39 PM, Filip Maj  wrote:

> Sorry yes, Plugins.plist
>
> Maybe folks are using plugman with old cordova-ios projects? Iuno
>
> On 7/29/13 7:19 PM, "Andrew Grieve"  wrote:
>
> >You mean plugins.plist?
> >
> >No need to deprecate it if it doesn't work right now anyways.
> >
> >
> >On Mon, Jul 29, 2013 at 10:12 PM, Filip Maj  wrote:
> >
> >> Yeah, back before we had config.xml, we had a plugins.xml for
> >>cordova-ios
> >> projects, and that¹s where service labels were mapped to classes
> >>
> >> On 7/29/13 7:09 PM, "Andrew Grieve"  wrote:
> >>
> >> >I'm not 100% sure of what  does, but if it's for setting
> >> >plugin-specific config settings, the code on iOS has already changed to
> >> >remove support for that (only settings in the main config.xml are
> >> >supported
> >> >now).
> >> >
> >> >
> >> >On Mon, Jul 29, 2013 at 9:22 PM, Filip Maj  wrote:
> >> >
> >> >> We currently document support for  in our spec [1].
> >>This
> >> >>is
> >> >> to support old cordova-ios (2.2 I believe).
> >> >>
> >> >>
> >> >> It would save with some lame special-case code [2] [3] [4].
> >> >>
> >> >> Warn folks using plugman w/ plugins using  elements
> >>that
> >> >> support is being removed soon? 3 releases for deprecation ya, so
> >>around
> >> >> 3.3 we remove support for it?
> >> >>
> >> >> [1]
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/cordova-plugman/blob/master/plugin_spec.md#plug
> >> >>in
> >> >> s-plist
> >> >> [2]
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
> >> >>ng
> >> >> es.js#L93-L104
> >> >> [3]
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
> >> >>ng
> >> >> es.js#L147-L166
> >> >> [4]
> >> >>
> >> >>
> >>
> >>
> https://github.com/apache/cordova-plugman/blob/master/src/util/config-cha
> >> >>ng
> >> >> es.js#L236-L252
> >> >>
> >> >>
> >>
> >>
>
>

Re: Away

[Shazron]

Welcome back James! Thanks :) A lot of the procedures are in the Wiki
anyway (I hope), and some of the tasks can be done by cordova-coho as
well...


On Mon, Jul 29, 2013 at 6:47 PM, James Jong  wrote:

> Shaz,
> I've been away a good portion in July but will be around in August.  I can
> cover iOS testing/release duties while you're away.
> -James Jong
>
> On Jul 29, 2013, at 7:26 PM, Shazron  wrote:
>
> > iOS 7 beta 4 out today, I'd say we probably can start testing with the
> next
> > beta onwards. Checking API diffs, tons of new APIs added/removed in this
> > release, so I wouldn't call it "stable" yet.
> >
> >
> > On Mon, Jul 29, 2013 at 4:22 PM, Brian LeRoux  wrote:
> >
> >> Also, think we are following the tradition of not shipping a platform
> >> update (3.1) until end of Sept. Though consensus otherwise could make
> >> this statement irrelevant. Either way, we probably want to wait for
> >> iOS7 to drop.
> >>
> >>
> >> On Mon, Jul 29, 2013 at 6:07 PM, Shazron  wrote:
> >>> If any of the committers want read-write privileges to the ios-sim and
> >>> ios-deploy repos, let me know...
> >>>
> >>>
> >>> On Mon, Jul 29, 2013 at 2:10 PM, Shazron  wrote:
> >>>
>  Hi guys,
>  I'll be away from Aug 1st and back on Aug 26th, where my work hours
> will
>  be UTC+08:00 (Singapore time) based.
> 
>  Not sure when 3.1.0 is slated to be released, but it's likely I will
> >> miss
>  the window for helping out with the release -- if someone can pick up
> >> the
>  release/testing baton for iOS that will be great. I doubt I will get
> to
>  Cordova OS X CLI issues for 3.1.0, it will have to wait for a future
>  release.
> 
>  Trying to finish up any remaining CLI issues for iOS. The ios-sim and
>  ios-deploy tools used by cordova-ios are under the "phonegap"
> >> organization
>  in Github, and if patches are needed any of the Adobe committers have
>  access to them.
> 
> >>
>
>