Re: docs on cordova.apache.org
Sent from a mobile device, please excuse mistakes and brevity On 20 Feb 2013 00:52, "Filip Maj" wrote: > > Awesome work Mike! +1000 > > On 2/19/13 4:38 PM, "Michael Brooks" wrote: > > >Update: Short-term goal [1] is now complete. > > > >The documentation is hosted on Apache infrastructure under the Apache > >Cordova website. Additionally, http://docs.cordova.io/ redirects to the > >Apache Cordova documentation. > > > >[1]: https://issues.apache.org/jira/browse/CB-1880 > > > >On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks > >wrote: > > > >> Steve Gill and myself sat down on Friday and reviewed the state of the > >> documentation and where we need it to go. > >> > >> The short-term goal is to host the documentation on > >> http://cordova.apache.org/docs and redirect with http://docs.cordova.io > >> > >> The long-term goal is everything else - theming, organization, document > >> structure, etc. I don't want this discussion to happen on this thread. > >> > >> The short-term goal is small and focused. No automation for updating or > >> anything like that. It's meant to achieve our objective on the Apache > >>board > >> report and set a new objective. After hosting the documentation, we will > >> need to cull the versions down to only those that are part of Apache > >> Cordova (removing the old PhoneGap versions). We can look into an > >> auto-update mechanism, although the generator will be replaced in the > >> long-term goal. > >> > >> A downside to hosting the documentation on the website's SVN is that it > >> will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). We > >>can > >> reduce this by removing the irrelevant versions. > >> > >> As Fil mentioned, this week has been busy. Before starting work, I'll > >> create and update the relevant JIRA issues, then open a discussion on > >>where > >> we want the docs to go. > >> > >> Michael > >> > >> On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj wrote: > >> > >>> Not sure.. Michael's had a busy week and he's had ideas on this one > >>>for a > >>> while. Mike? > >>> > >>> On 2/7/13 10:31 AM, "Marcel Kinard" wrote: > >>> > >>> >Poking this thread with the release of 2.4. > >>> > > >>> >Where are we at? > >>> > > >>> >Is there anything I can do to help? > >>> > > >>> >-- Marcel Kinard > >>> > > >>> >On Jan 17, 2013, at 12:19 PM, Michael Brooks > >>> > >>> >wrote: > >>> > > >>> >>> > >>> >>> I've got Jenkins running locally, pulling from cordova-docs, > >>>polling > >>> >>>daily, > >>> >>> and generating the docs. But the SVN Publisher doesn't seem to > >>>work: > >>> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested > >>> it > >>> >>>on > >>> >>> another SVN repo, not Apache's) -- reports success but nothing is > >>> >>>uploaded. > >>> >>> This could be a solution in the interim if I could get the > >>>publisher > >>> to > >>> >> > >>> >> > >>> >> Well, it's an interesting experiment. I don't have the time to look > >>> >>into it > >>> >> now, but > >>> >> as I said I'm working to free up February for the documentation > >>>update. > >>> >> I'll pick > >>> >> your brain about the Jenkins stuff then. Thanks for looking into it. > >>> >> > >>> >> which by the way, the whole tree right now is over > >>> >>> 300MB. en/edge right now is only 7MB > >>> >> > >>> >> > >>> >> That's not a big concern. The rewrite of the documentation will only > >>> >> version the > >>> >> latest. This will make internationalization contributions more > >>> >>confusing, > >>> >> since > >>> >> most update older version of Apache Cordova, but we can solve that > >>> >>with... > >>> >> documentation. > >>> >> > >>> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron wrote: > >>> >> > >>> >>> I've got Jenkins running locally, pulling from cordova-docs, > >>>polling > >>> >>>daily, > >>> >>> and generating the docs. But the SVN Publisher doesn't seem to > >>>work: > >>> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested > >>> it > >>> >>>on > >>> >>> another SVN repo, not Apache's) -- reports success but nothing is > >>> >>>uploaded. > >>> >>> This could be a solution in the interim if I could get the > >>>publisher > >>> to > >>> >>> actually publish -- which by the way, the whole tree right now is > >>>over > >>> >>> 300MB. en/edge right now is only 7MB. > >>> >>> > >>> >>> > >>> >>> On Mon, Jan 14, 2013 at 9:32 AM, Shazron wrote: > >>> >>> > >>> I agree with Ross that it should be on Apache's servers and not > >>> somewhere > >>> else (like Amazon S3). At most some dev could locally install > >>>Jenkins > >>> and > >>> run a CI server with a script that can auto update the SVN repo > >>> (using > >>> their creds), or something - until we can get a permanent solution > >>> > >>> > >>> On Mon, Jan 14, 2013 at 9:22 AM, Michael Brooks < > >>> >>> mich...@michaelbrooks.ca>wrote: > >>> > >>> > @Andrew I was thinking S3 so that a service can auto-update on > >>>each > >>> > commit. > >>> >>
Re: docs on cordova.apache.org
Attention: Expect a one hour outage on docs.cordova.io. I'll be updating the DNS for docs.cordova.io to use A-records instead of HTTP Redirects because it's faster. You can still access the docs using the full path: http://cordova.apache.org/docs/en/2.4.0 You can also access the PhoneGap Documentation (nearly identical) at http://docs.phonegap.com/ Michael On Tue, Feb 19, 2013 at 4:57 PM, Michael Brooks wrote: > Yay! Board Report another objective complete! > > > Or better said: Yay! Another board report objective complete! > > On Tue, Feb 19, 2013 at 4:56 PM, Michael Brooks > wrote: > >> Yay! Board Report another objective complete! >> >> >> On Tue, Feb 19, 2013 at 4:54 PM, Brian LeRoux wrote: >> >>> Sweet. I'll update the board report. =) >>> >>> On Tue, Feb 19, 2013 at 4:38 PM, Michael Brooks < >>> mich...@michaelbrooks.ca>wrote: >>> >>> > Update: Short-term goal [1] is now complete. >>> > >>> > The documentation is hosted on Apache infrastructure under the Apache >>> > Cordova website. Additionally, http://docs.cordova.io/ redirects to >>> the >>> > Apache Cordova documentation. >>> > >>> > [1]: https://issues.apache.org/jira/browse/CB-1880 >>> > >>> > On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks < >>> mich...@michaelbrooks.ca >>> > >wrote: >>> > >>> > > Steve Gill and myself sat down on Friday and reviewed the state of >>> the >>> > > documentation and where we need it to go. >>> > > >>> > > The short-term goal is to host the documentation on >>> > > http://cordova.apache.org/docs and redirect with >>> http://docs.cordova.io >>> > > >>> > > The long-term goal is everything else - theming, organization, >>> document >>> > > structure, etc. I don't want this discussion to happen on this >>> thread. >>> > > >>> > > The short-term goal is small and focused. No automation for updating >>> or >>> > > anything like that. It's meant to achieve our objective on the Apache >>> > board >>> > > report and set a new objective. After hosting the documentation, we >>> will >>> > > need to cull the versions down to only those that are part of Apache >>> > > Cordova (removing the old PhoneGap versions). We can look into an >>> > > auto-update mechanism, although the generator will be replaced in the >>> > > long-term goal. >>> > > >>> > > A downside to hosting the documentation on the website's SVN is that >>> it >>> > > will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). >>> We >>> > can >>> > > reduce this by removing the irrelevant versions. >>> > > >>> > > As Fil mentioned, this week has been busy. Before starting work, I'll >>> > > create and update the relevant JIRA issues, then open a discussion on >>> > where >>> > > we want the docs to go. >>> > > >>> > > Michael >>> > > >>> > > On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj wrote: >>> > > >>> > >> Not sure.. Michael's had a busy week and he's had ideas on this one >>> for >>> > a >>> > >> while. Mike? >>> > >> >>> > >> On 2/7/13 10:31 AM, "Marcel Kinard" wrote: >>> > >> >>> > >> >Poking this thread with the release of 2.4. >>> > >> > >>> > >> >Where are we at? >>> > >> > >>> > >> >Is there anything I can do to help? >>> > >> > >>> > >> >-- Marcel Kinard >>> > >> > >>> > >> >On Jan 17, 2013, at 12:19 PM, Michael Brooks < >>> mich...@michaelbrooks.ca >>> > > >>> > >> >wrote: >>> > >> > >>> > >> >>> >>> > >> >>> I've got Jenkins running locally, pulling from cordova-docs, >>> polling >>> > >> >>>daily, >>> > >> >>> and generating the docs. But the SVN Publisher doesn't seem to >>> work: >>> > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I >>> tested >>> > >> it >>> > >> >>>on >>> > >> >>> another SVN repo, not Apache's) -- reports success but nothing >>> is >>> > >> >>>uploaded. >>> > >> >>> This could be a solution in the interim if I could get the >>> publisher >>> > >> to >>> > >> >> >>> > >> >> >>> > >> >> Well, it's an interesting experiment. I don't have the time to >>> look >>> > >> >>into it >>> > >> >> now, but >>> > >> >> as I said I'm working to free up February for the documentation >>> > update. >>> > >> >> I'll pick >>> > >> >> your brain about the Jenkins stuff then. Thanks for looking into >>> it. >>> > >> >> >>> > >> >> which by the way, the whole tree right now is over >>> > >> >>> 300MB. en/edge right now is only 7MB >>> > >> >> >>> > >> >> >>> > >> >> That's not a big concern. The rewrite of the documentation will >>> only >>> > >> >> version the >>> > >> >> latest. This will make internationalization contributions more >>> > >> >>confusing, >>> > >> >> since >>> > >> >> most update older version of Apache Cordova, but we can solve >>> that >>> > >> >>with... >>> > >> >> documentation. >>> > >> >> >>> > >> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron >>> wrote: >>> > >> >> >>> > >> >>> I've got Jenkins running locally, pulling from cordova-docs, >>> polling >>> > >> >>>daily, >>> > >> >>> and generating the docs. But the SVN Publisher doesn't seem to >>> work: >>> > >> >>> https://wiki.jenkins-c
Re: Proposition to split cordova-blackberry into two separate plugins
Sharzon, sorry I have no clue when BB10 will be making its way to playbook. Bryan, whatever the next version is called BB11 or not, that would still be within the same repo. Conceptually BB10 is a brand new platform based on a very different SDK and unless I'm mistaken BlackBerry is the only platform to have 3 different SDKS within one repo (BBOS java, AIR, and BB10 C++). I know windows phone is separated. Plus we feel this way it will be cleanest for our developers and more conformant with the cordova dev experience. Tim we're in the midst of creating a much more CLI friendly (Not ANT) repo right now that would be based on our last webworks packager and framework but would be built directly on the NDK. As per the plugins, I'll take a look tomorrow but it's impressive when anyone makes a plugin for bb1010. Current docs are definitely lacking. Sent from my BlackBerry 10 smartphone. From: Tim Kim Sent: Tuesday, February 19, 2013 7:11 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Proposition to split cordova-blackberry into two separate plugins I don't mind either way, but I think we should have at least an idea what the cordova-blackberry10 repo should look like before we create it. To separate them right now would mean creating two very similar cordova-blackberry repos (everything the same except some build scripts). And then later on, reconfiguring the cordova-blackberry10 repo to be whatever. So I'm basically for less work now :) Also, on the topic of plugins for BlackBerry 10, I've done some work recently on this that you can check out: Here's my simple plugin that shows the structure for a BB10 plugin with native code: https://github.com/timkim/cordova.echo A tool to build the C++ code from command line: https://github.com/timkim/Renton And plugman now has bb10 support so it should be able to install the cordova.echo plugin: https://github.com/imhotep/plugman On 19 February 2013 14:55, Brian LeRoux wrote: > I'm a little uncertain about the reasoning here. What happens when BB11 > ships? New repo? > > Generally we try to keep things in a vendor directory with > the pertinent SDK's within. What is wrong w/ the current structure for > contribution? > > > > On Tue, Feb 19, 2013 at 2:45 PM, Shazron wrote: > > > +1 > > Also, any news when BB10 comes to Playbook, ballpark? --> "once BB10 is > > ported to playbook" > > > > > > > > On Tue, Feb 19, 2013 at 1:24 PM, Filip Maj wrote: > > > > > Sounds fine to me. > > > > > > As for process, assuming there are no objections (would wait a couple > > > days), file a JIRA issue on the INFRA project > > > (issues.apache.org/jira/browser/INFRA) > > > > > > On 2/19/13 1:15 PM, "Jeffrey Heifetz" wrote: > > > > > > >With all this talk of re-organizing cordova plugins we here at > > BlackBerry > > > >(RIM no more) have been discussing better alleging ourselves with the > > > >approach by splitting our existing cordova-blackberry platform into > two > > > >separate platforms. (I saw a similar call here as well > > > > > > > > > > http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnh > > > >pidbnxg5ps7zr+state:results) > > > > > > > >We propose adding a new platform, "blackberry10" with the longterm > > > >understanding that once BB10 is ported to playbook the original repo > > > >would only be for BBOS. Ideally the end result of this is that we > would > > > >have an up to date cordova-blackberry10 platform following all of the > > > >best practices (plugins moved into their own repos, etc) and we can > > > >better contribute resources to Cordova in general. > > > > > > > >Hopefully no one has any objections to this as structurally they are > > > >really separate platforms. Additionally it'll make the flow within > CLI a > > > >lot cleaner. > > > > > > > >If everyone agrees, what is the process for getting a new apache repo > > for > > > >it? > > > > > > > >- > > > >This transmission (including any attachments) may contain confidential > > > >information, privileged material (including material protected by the > > > >solicitor-client or other applicable privileges), or constitute > > > >non-public information. Any use of this information by anyone other > than > > > >the intended recipient is prohibited. If you have received this > > > >transmission in error, please immediately reply to the sender and > delete > > > >this information from your system. Use, dissemination, distribution, > or > > > >reproduction of this transmission by unintended recipients is not > > > >authorized and may be unlawful. > > > > > > > > > -- Timothy Kim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public i
Re: docs on cordova.apache.org
> > Yay! Board Report another objective complete! Or better said: Yay! Another board report objective complete! On Tue, Feb 19, 2013 at 4:56 PM, Michael Brooks wrote: > Yay! Board Report another objective complete! > > > On Tue, Feb 19, 2013 at 4:54 PM, Brian LeRoux wrote: > >> Sweet. I'll update the board report. =) >> >> On Tue, Feb 19, 2013 at 4:38 PM, Michael Brooks > >wrote: >> >> > Update: Short-term goal [1] is now complete. >> > >> > The documentation is hosted on Apache infrastructure under the Apache >> > Cordova website. Additionally, http://docs.cordova.io/ redirects to the >> > Apache Cordova documentation. >> > >> > [1]: https://issues.apache.org/jira/browse/CB-1880 >> > >> > On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks < >> mich...@michaelbrooks.ca >> > >wrote: >> > >> > > Steve Gill and myself sat down on Friday and reviewed the state of the >> > > documentation and where we need it to go. >> > > >> > > The short-term goal is to host the documentation on >> > > http://cordova.apache.org/docs and redirect with >> http://docs.cordova.io >> > > >> > > The long-term goal is everything else - theming, organization, >> document >> > > structure, etc. I don't want this discussion to happen on this thread. >> > > >> > > The short-term goal is small and focused. No automation for updating >> or >> > > anything like that. It's meant to achieve our objective on the Apache >> > board >> > > report and set a new objective. After hosting the documentation, we >> will >> > > need to cull the versions down to only those that are part of Apache >> > > Cordova (removing the old PhoneGap versions). We can look into an >> > > auto-update mechanism, although the generator will be replaced in the >> > > long-term goal. >> > > >> > > A downside to hosting the documentation on the website's SVN is that >> it >> > > will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). >> We >> > can >> > > reduce this by removing the irrelevant versions. >> > > >> > > As Fil mentioned, this week has been busy. Before starting work, I'll >> > > create and update the relevant JIRA issues, then open a discussion on >> > where >> > > we want the docs to go. >> > > >> > > Michael >> > > >> > > On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj wrote: >> > > >> > >> Not sure.. Michael's had a busy week and he's had ideas on this one >> for >> > a >> > >> while. Mike? >> > >> >> > >> On 2/7/13 10:31 AM, "Marcel Kinard" wrote: >> > >> >> > >> >Poking this thread with the release of 2.4. >> > >> > >> > >> >Where are we at? >> > >> > >> > >> >Is there anything I can do to help? >> > >> > >> > >> >-- Marcel Kinard >> > >> > >> > >> >On Jan 17, 2013, at 12:19 PM, Michael Brooks < >> mich...@michaelbrooks.ca >> > > >> > >> >wrote: >> > >> > >> > >> >>> >> > >> >>> I've got Jenkins running locally, pulling from cordova-docs, >> polling >> > >> >>>daily, >> > >> >>> and generating the docs. But the SVN Publisher doesn't seem to >> work: >> > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I >> tested >> > >> it >> > >> >>>on >> > >> >>> another SVN repo, not Apache's) -- reports success but nothing is >> > >> >>>uploaded. >> > >> >>> This could be a solution in the interim if I could get the >> publisher >> > >> to >> > >> >> >> > >> >> >> > >> >> Well, it's an interesting experiment. I don't have the time to >> look >> > >> >>into it >> > >> >> now, but >> > >> >> as I said I'm working to free up February for the documentation >> > update. >> > >> >> I'll pick >> > >> >> your brain about the Jenkins stuff then. Thanks for looking into >> it. >> > >> >> >> > >> >> which by the way, the whole tree right now is over >> > >> >>> 300MB. en/edge right now is only 7MB >> > >> >> >> > >> >> >> > >> >> That's not a big concern. The rewrite of the documentation will >> only >> > >> >> version the >> > >> >> latest. This will make internationalization contributions more >> > >> >>confusing, >> > >> >> since >> > >> >> most update older version of Apache Cordova, but we can solve that >> > >> >>with... >> > >> >> documentation. >> > >> >> >> > >> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron >> wrote: >> > >> >> >> > >> >>> I've got Jenkins running locally, pulling from cordova-docs, >> polling >> > >> >>>daily, >> > >> >>> and generating the docs. But the SVN Publisher doesn't seem to >> work: >> > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I >> tested >> > >> it >> > >> >>>on >> > >> >>> another SVN repo, not Apache's) -- reports success but nothing is >> > >> >>>uploaded. >> > >> >>> This could be a solution in the interim if I could get the >> publisher >> > >> to >> > >> >>> actually publish -- which by the way, the whole tree right now is >> > over >> > >> >>> 300MB. en/edge right now is only 7MB. >> > >> >>> >> > >> >>> >> > >> >>> On Mon, Jan 14, 2013 at 9:32 AM, Shazron >> wrote: >> > >> >>> >> > >> I agree with Ross that it should be on Apache's servers and not >> > >> somewhere >
Re: docs on cordova.apache.org
Yay! Board Report another objective complete! On Tue, Feb 19, 2013 at 4:54 PM, Brian LeRoux wrote: > Sweet. I'll update the board report. =) > > On Tue, Feb 19, 2013 at 4:38 PM, Michael Brooks >wrote: > > > Update: Short-term goal [1] is now complete. > > > > The documentation is hosted on Apache infrastructure under the Apache > > Cordova website. Additionally, http://docs.cordova.io/ redirects to the > > Apache Cordova documentation. > > > > [1]: https://issues.apache.org/jira/browse/CB-1880 > > > > On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks > >wrote: > > > > > Steve Gill and myself sat down on Friday and reviewed the state of the > > > documentation and where we need it to go. > > > > > > The short-term goal is to host the documentation on > > > http://cordova.apache.org/docs and redirect with > http://docs.cordova.io > > > > > > The long-term goal is everything else - theming, organization, document > > > structure, etc. I don't want this discussion to happen on this thread. > > > > > > The short-term goal is small and focused. No automation for updating or > > > anything like that. It's meant to achieve our objective on the Apache > > board > > > report and set a new objective. After hosting the documentation, we > will > > > need to cull the versions down to only those that are part of Apache > > > Cordova (removing the old PhoneGap versions). We can look into an > > > auto-update mechanism, although the generator will be replaced in the > > > long-term goal. > > > > > > A downside to hosting the documentation on the website's SVN is that it > > > will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). We > > can > > > reduce this by removing the irrelevant versions. > > > > > > As Fil mentioned, this week has been busy. Before starting work, I'll > > > create and update the relevant JIRA issues, then open a discussion on > > where > > > we want the docs to go. > > > > > > Michael > > > > > > On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj wrote: > > > > > >> Not sure.. Michael's had a busy week and he's had ideas on this one > for > > a > > >> while. Mike? > > >> > > >> On 2/7/13 10:31 AM, "Marcel Kinard" wrote: > > >> > > >> >Poking this thread with the release of 2.4. > > >> > > > >> >Where are we at? > > >> > > > >> >Is there anything I can do to help? > > >> > > > >> >-- Marcel Kinard > > >> > > > >> >On Jan 17, 2013, at 12:19 PM, Michael Brooks < > mich...@michaelbrooks.ca > > > > > >> >wrote: > > >> > > > >> >>> > > >> >>> I've got Jenkins running locally, pulling from cordova-docs, > polling > > >> >>>daily, > > >> >>> and generating the docs. But the SVN Publisher doesn't seem to > work: > > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I > tested > > >> it > > >> >>>on > > >> >>> another SVN repo, not Apache's) -- reports success but nothing is > > >> >>>uploaded. > > >> >>> This could be a solution in the interim if I could get the > publisher > > >> to > > >> >> > > >> >> > > >> >> Well, it's an interesting experiment. I don't have the time to look > > >> >>into it > > >> >> now, but > > >> >> as I said I'm working to free up February for the documentation > > update. > > >> >> I'll pick > > >> >> your brain about the Jenkins stuff then. Thanks for looking into > it. > > >> >> > > >> >> which by the way, the whole tree right now is over > > >> >>> 300MB. en/edge right now is only 7MB > > >> >> > > >> >> > > >> >> That's not a big concern. The rewrite of the documentation will > only > > >> >> version the > > >> >> latest. This will make internationalization contributions more > > >> >>confusing, > > >> >> since > > >> >> most update older version of Apache Cordova, but we can solve that > > >> >>with... > > >> >> documentation. > > >> >> > > >> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron > wrote: > > >> >> > > >> >>> I've got Jenkins running locally, pulling from cordova-docs, > polling > > >> >>>daily, > > >> >>> and generating the docs. But the SVN Publisher doesn't seem to > work: > > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I > tested > > >> it > > >> >>>on > > >> >>> another SVN repo, not Apache's) -- reports success but nothing is > > >> >>>uploaded. > > >> >>> This could be a solution in the interim if I could get the > publisher > > >> to > > >> >>> actually publish -- which by the way, the whole tree right now is > > over > > >> >>> 300MB. en/edge right now is only 7MB. > > >> >>> > > >> >>> > > >> >>> On Mon, Jan 14, 2013 at 9:32 AM, Shazron > wrote: > > >> >>> > > >> I agree with Ross that it should be on Apache's servers and not > > >> somewhere > > >> else (like Amazon S3). At most some dev could locally install > > Jenkins > > >> and > > >> run a CI server with a script that can auto update the SVN repo > > >> (using > > >> their creds), or something - until we can get a permanent > solution > > >> > > >> > > >> On Mon, Jan 14, 2013 at 9:22 AM, Michael Brooks < > > >
Re: docs on cordova.apache.org
Sweet. I'll update the board report. =) On Tue, Feb 19, 2013 at 4:38 PM, Michael Brooks wrote: > Update: Short-term goal [1] is now complete. > > The documentation is hosted on Apache infrastructure under the Apache > Cordova website. Additionally, http://docs.cordova.io/ redirects to the > Apache Cordova documentation. > > [1]: https://issues.apache.org/jira/browse/CB-1880 > > On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks >wrote: > > > Steve Gill and myself sat down on Friday and reviewed the state of the > > documentation and where we need it to go. > > > > The short-term goal is to host the documentation on > > http://cordova.apache.org/docs and redirect with http://docs.cordova.io > > > > The long-term goal is everything else - theming, organization, document > > structure, etc. I don't want this discussion to happen on this thread. > > > > The short-term goal is small and focused. No automation for updating or > > anything like that. It's meant to achieve our objective on the Apache > board > > report and set a new objective. After hosting the documentation, we will > > need to cull the versions down to only those that are part of Apache > > Cordova (removing the old PhoneGap versions). We can look into an > > auto-update mechanism, although the generator will be replaced in the > > long-term goal. > > > > A downside to hosting the documentation on the website's SVN is that it > > will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). We > can > > reduce this by removing the irrelevant versions. > > > > As Fil mentioned, this week has been busy. Before starting work, I'll > > create and update the relevant JIRA issues, then open a discussion on > where > > we want the docs to go. > > > > Michael > > > > On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj wrote: > > > >> Not sure.. Michael's had a busy week and he's had ideas on this one for > a > >> while. Mike? > >> > >> On 2/7/13 10:31 AM, "Marcel Kinard" wrote: > >> > >> >Poking this thread with the release of 2.4. > >> > > >> >Where are we at? > >> > > >> >Is there anything I can do to help? > >> > > >> >-- Marcel Kinard > >> > > >> >On Jan 17, 2013, at 12:19 PM, Michael Brooks > > >> >wrote: > >> > > >> >>> > >> >>> I've got Jenkins running locally, pulling from cordova-docs, polling > >> >>>daily, > >> >>> and generating the docs. But the SVN Publisher doesn't seem to work: > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested > >> it > >> >>>on > >> >>> another SVN repo, not Apache's) -- reports success but nothing is > >> >>>uploaded. > >> >>> This could be a solution in the interim if I could get the publisher > >> to > >> >> > >> >> > >> >> Well, it's an interesting experiment. I don't have the time to look > >> >>into it > >> >> now, but > >> >> as I said I'm working to free up February for the documentation > update. > >> >> I'll pick > >> >> your brain about the Jenkins stuff then. Thanks for looking into it. > >> >> > >> >> which by the way, the whole tree right now is over > >> >>> 300MB. en/edge right now is only 7MB > >> >> > >> >> > >> >> That's not a big concern. The rewrite of the documentation will only > >> >> version the > >> >> latest. This will make internationalization contributions more > >> >>confusing, > >> >> since > >> >> most update older version of Apache Cordova, but we can solve that > >> >>with... > >> >> documentation. > >> >> > >> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron wrote: > >> >> > >> >>> I've got Jenkins running locally, pulling from cordova-docs, polling > >> >>>daily, > >> >>> and generating the docs. But the SVN Publisher doesn't seem to work: > >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested > >> it > >> >>>on > >> >>> another SVN repo, not Apache's) -- reports success but nothing is > >> >>>uploaded. > >> >>> This could be a solution in the interim if I could get the publisher > >> to > >> >>> actually publish -- which by the way, the whole tree right now is > over > >> >>> 300MB. en/edge right now is only 7MB. > >> >>> > >> >>> > >> >>> On Mon, Jan 14, 2013 at 9:32 AM, Shazron wrote: > >> >>> > >> I agree with Ross that it should be on Apache's servers and not > >> somewhere > >> else (like Amazon S3). At most some dev could locally install > Jenkins > >> and > >> run a CI server with a script that can auto update the SVN repo > >> (using > >> their creds), or something - until we can get a permanent solution > >> > >> > >> On Mon, Jan 14, 2013 at 9:22 AM, Michael Brooks < > >> >>> mich...@michaelbrooks.ca>wrote: > >> > >> > @Andrew I was thinking S3 so that a service can auto-update on > each > >> > commit. > >> > From Yohei's experience with the cordova.apache.org SVN setup, it > >> >looks > >> > like automating that is a headache. > >> > > >> > Michael > >> > > >> > On Mon, Jan 14, 2013 at 9:16 AM, Andrew Grieve < > >> agri...@chromium.org> > >> >>>
Re: docs on cordova.apache.org
Awesome work Mike! On 2/19/13 4:38 PM, "Michael Brooks" wrote: >Update: Short-term goal [1] is now complete. > >The documentation is hosted on Apache infrastructure under the Apache >Cordova website. Additionally, http://docs.cordova.io/ redirects to the >Apache Cordova documentation. > >[1]: https://issues.apache.org/jira/browse/CB-1880 > >On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks >wrote: > >> Steve Gill and myself sat down on Friday and reviewed the state of the >> documentation and where we need it to go. >> >> The short-term goal is to host the documentation on >> http://cordova.apache.org/docs and redirect with http://docs.cordova.io >> >> The long-term goal is everything else - theming, organization, document >> structure, etc. I don't want this discussion to happen on this thread. >> >> The short-term goal is small and focused. No automation for updating or >> anything like that. It's meant to achieve our objective on the Apache >>board >> report and set a new objective. After hosting the documentation, we will >> need to cull the versions down to only those that are part of Apache >> Cordova (removing the old PhoneGap versions). We can look into an >> auto-update mechanism, although the generator will be replaced in the >> long-term goal. >> >> A downside to hosting the documentation on the website's SVN is that it >> will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). We >>can >> reduce this by removing the irrelevant versions. >> >> As Fil mentioned, this week has been busy. Before starting work, I'll >> create and update the relevant JIRA issues, then open a discussion on >>where >> we want the docs to go. >> >> Michael >> >> On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj wrote: >> >>> Not sure.. Michael's had a busy week and he's had ideas on this one >>>for a >>> while. Mike? >>> >>> On 2/7/13 10:31 AM, "Marcel Kinard" wrote: >>> >>> >Poking this thread with the release of 2.4. >>> > >>> >Where are we at? >>> > >>> >Is there anything I can do to help? >>> > >>> >-- Marcel Kinard >>> > >>> >On Jan 17, 2013, at 12:19 PM, Michael Brooks >>> >>> >wrote: >>> > >>> >>> >>> >>> I've got Jenkins running locally, pulling from cordova-docs, >>>polling >>> >>>daily, >>> >>> and generating the docs. But the SVN Publisher doesn't seem to >>>work: >>> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested >>> it >>> >>>on >>> >>> another SVN repo, not Apache's) -- reports success but nothing is >>> >>>uploaded. >>> >>> This could be a solution in the interim if I could get the >>>publisher >>> to >>> >> >>> >> >>> >> Well, it's an interesting experiment. I don't have the time to look >>> >>into it >>> >> now, but >>> >> as I said I'm working to free up February for the documentation >>>update. >>> >> I'll pick >>> >> your brain about the Jenkins stuff then. Thanks for looking into it. >>> >> >>> >> which by the way, the whole tree right now is over >>> >>> 300MB. en/edge right now is only 7MB >>> >> >>> >> >>> >> That's not a big concern. The rewrite of the documentation will only >>> >> version the >>> >> latest. This will make internationalization contributions more >>> >>confusing, >>> >> since >>> >> most update older version of Apache Cordova, but we can solve that >>> >>with... >>> >> documentation. >>> >> >>> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron wrote: >>> >> >>> >>> I've got Jenkins running locally, pulling from cordova-docs, >>>polling >>> >>>daily, >>> >>> and generating the docs. But the SVN Publisher doesn't seem to >>>work: >>> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested >>> it >>> >>>on >>> >>> another SVN repo, not Apache's) -- reports success but nothing is >>> >>>uploaded. >>> >>> This could be a solution in the interim if I could get the >>>publisher >>> to >>> >>> actually publish -- which by the way, the whole tree right now is >>>over >>> >>> 300MB. en/edge right now is only 7MB. >>> >>> >>> >>> >>> >>> On Mon, Jan 14, 2013 at 9:32 AM, Shazron wrote: >>> >>> >>> I agree with Ross that it should be on Apache's servers and not >>> somewhere >>> else (like Amazon S3). At most some dev could locally install >>>Jenkins >>> and >>> run a CI server with a script that can auto update the SVN repo >>> (using >>> their creds), or something - until we can get a permanent solution >>> >>> >>> On Mon, Jan 14, 2013 at 9:22 AM, Michael Brooks < >>> >>> mich...@michaelbrooks.ca>wrote: >>> >>> > @Andrew I was thinking S3 so that a service can auto-update on >>>each >>> > commit. >>> > From Yohei's experience with the cordova.apache.org SVN setup, it >>> >looks >>> > like automating that is a headache. >>> > >>> > Michael >>> > >>> > On Mon, Jan 14, 2013 at 9:16 AM, Andrew Grieve < >>> agri...@chromium.org> >>> > wrote: >>> > >>> >> cordova.io is a bunch of redirects. Do you mean to have >>> >> docs.cordova.ioredirect to >>>
Re: docs on cordova.apache.org
Update: Short-term goal [1] is now complete. The documentation is hosted on Apache infrastructure under the Apache Cordova website. Additionally, http://docs.cordova.io/ redirects to the Apache Cordova documentation. [1]: https://issues.apache.org/jira/browse/CB-1880 On Thu, Feb 7, 2013 at 4:00 PM, Michael Brooks wrote: > Steve Gill and myself sat down on Friday and reviewed the state of the > documentation and where we need it to go. > > The short-term goal is to host the documentation on > http://cordova.apache.org/docs and redirect with http://docs.cordova.io > > The long-term goal is everything else - theming, organization, document > structure, etc. I don't want this discussion to happen on this thread. > > The short-term goal is small and focused. No automation for updating or > anything like that. It's meant to achieve our objective on the Apache board > report and set a new objective. After hosting the documentation, we will > need to cull the versions down to only those that are part of Apache > Cordova (removing the old PhoneGap versions). We can look into an > auto-update mechanism, although the generator will be replaced in the > long-term goal. > > A downside to hosting the documentation on the website's SVN is that it > will shoot up to roughly 600MB (300MB in public/ and 300MB in www/). We can > reduce this by removing the irrelevant versions. > > As Fil mentioned, this week has been busy. Before starting work, I'll > create and update the relevant JIRA issues, then open a discussion on where > we want the docs to go. > > Michael > > On Thu, Feb 7, 2013 at 12:47 PM, Filip Maj wrote: > >> Not sure.. Michael's had a busy week and he's had ideas on this one for a >> while. Mike? >> >> On 2/7/13 10:31 AM, "Marcel Kinard" wrote: >> >> >Poking this thread with the release of 2.4. >> > >> >Where are we at? >> > >> >Is there anything I can do to help? >> > >> >-- Marcel Kinard >> > >> >On Jan 17, 2013, at 12:19 PM, Michael Brooks >> >wrote: >> > >> >>> >> >>> I've got Jenkins running locally, pulling from cordova-docs, polling >> >>>daily, >> >>> and generating the docs. But the SVN Publisher doesn't seem to work: >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested >> it >> >>>on >> >>> another SVN repo, not Apache's) -- reports success but nothing is >> >>>uploaded. >> >>> This could be a solution in the interim if I could get the publisher >> to >> >> >> >> >> >> Well, it's an interesting experiment. I don't have the time to look >> >>into it >> >> now, but >> >> as I said I'm working to free up February for the documentation update. >> >> I'll pick >> >> your brain about the Jenkins stuff then. Thanks for looking into it. >> >> >> >> which by the way, the whole tree right now is over >> >>> 300MB. en/edge right now is only 7MB >> >> >> >> >> >> That's not a big concern. The rewrite of the documentation will only >> >> version the >> >> latest. This will make internationalization contributions more >> >>confusing, >> >> since >> >> most update older version of Apache Cordova, but we can solve that >> >>with... >> >> documentation. >> >> >> >> On Wed, Jan 16, 2013 at 10:04 AM, Shazron wrote: >> >> >> >>> I've got Jenkins running locally, pulling from cordova-docs, polling >> >>>daily, >> >>> and generating the docs. But the SVN Publisher doesn't seem to work: >> >>> https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher (I tested >> it >> >>>on >> >>> another SVN repo, not Apache's) -- reports success but nothing is >> >>>uploaded. >> >>> This could be a solution in the interim if I could get the publisher >> to >> >>> actually publish -- which by the way, the whole tree right now is over >> >>> 300MB. en/edge right now is only 7MB. >> >>> >> >>> >> >>> On Mon, Jan 14, 2013 at 9:32 AM, Shazron wrote: >> >>> >> I agree with Ross that it should be on Apache's servers and not >> somewhere >> else (like Amazon S3). At most some dev could locally install Jenkins >> and >> run a CI server with a script that can auto update the SVN repo >> (using >> their creds), or something - until we can get a permanent solution >> >> >> On Mon, Jan 14, 2013 at 9:22 AM, Michael Brooks < >> >>> mich...@michaelbrooks.ca>wrote: >> >> > @Andrew I was thinking S3 so that a service can auto-update on each >> > commit. >> > From Yohei's experience with the cordova.apache.org SVN setup, it >> >looks >> > like automating that is a headache. >> > >> > Michael >> > >> > On Mon, Jan 14, 2013 at 9:16 AM, Andrew Grieve < >> agri...@chromium.org> >> > wrote: >> > >> >> cordova.io is a bunch of redirects. Do you mean to have >> >> docs.cordova.ioredirect to >> >> cordova.apache.org/docs (or something similar) >> >> >> >> >> >> On Mon, Jan 14, 2013 at 12:13 PM, Michael Brooks >> >> wrote: >> >> >> >>> Hi Marcel, >> >>> >> >>> I've got this one my roadmap of tasks. >>
Re: Proposition to split cordova-blackberry into two separate plugins
I don't mind either way, but I think we should have at least an idea what the cordova-blackberry10 repo should look like before we create it. To separate them right now would mean creating two very similar cordova-blackberry repos (everything the same except some build scripts). And then later on, reconfiguring the cordova-blackberry10 repo to be whatever. So I'm basically for less work now :) Also, on the topic of plugins for BlackBerry 10, I've done some work recently on this that you can check out: Here's my simple plugin that shows the structure for a BB10 plugin with native code: https://github.com/timkim/cordova.echo A tool to build the C++ code from command line: https://github.com/timkim/Renton And plugman now has bb10 support so it should be able to install the cordova.echo plugin: https://github.com/imhotep/plugman On 19 February 2013 14:55, Brian LeRoux wrote: > I'm a little uncertain about the reasoning here. What happens when BB11 > ships? New repo? > > Generally we try to keep things in a vendor directory with > the pertinent SDK's within. What is wrong w/ the current structure for > contribution? > > > > On Tue, Feb 19, 2013 at 2:45 PM, Shazron wrote: > > > +1 > > Also, any news when BB10 comes to Playbook, ballpark? --> "once BB10 is > > ported to playbook" > > > > > > > > On Tue, Feb 19, 2013 at 1:24 PM, Filip Maj wrote: > > > > > Sounds fine to me. > > > > > > As for process, assuming there are no objections (would wait a couple > > > days), file a JIRA issue on the INFRA project > > > (issues.apache.org/jira/browser/INFRA) > > > > > > On 2/19/13 1:15 PM, "Jeffrey Heifetz" wrote: > > > > > > >With all this talk of re-organizing cordova plugins we here at > > BlackBerry > > > >(RIM no more) have been discussing better alleging ourselves with the > > > >approach by splitting our existing cordova-blackberry platform into > two > > > >separate platforms. (I saw a similar call here as well > > > > > > > > > > http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnh > > > >pidbnxg5ps7zr+state:results) > > > > > > > >We propose adding a new platform, "blackberry10" with the longterm > > > >understanding that once BB10 is ported to playbook the original repo > > > >would only be for BBOS. Ideally the end result of this is that we > would > > > >have an up to date cordova-blackberry10 platform following all of the > > > >best practices (plugins moved into their own repos, etc) and we can > > > >better contribute resources to Cordova in general. > > > > > > > >Hopefully no one has any objections to this as structurally they are > > > >really separate platforms. Additionally it'll make the flow within > CLI a > > > >lot cleaner. > > > > > > > >If everyone agrees, what is the process for getting a new apache repo > > for > > > >it? > > > > > > > >- > > > >This transmission (including any attachments) may contain confidential > > > >information, privileged material (including material protected by the > > > >solicitor-client or other applicable privileges), or constitute > > > >non-public information. Any use of this information by anyone other > than > > > >the intended recipient is prohibited. If you have received this > > > >transmission in error, please immediately reply to the sender and > delete > > > >this information from your system. Use, dissemination, distribution, > or > > > >reproduction of this transmission by unintended recipients is not > > > >authorized and may be unlawful. > > > > > > > > > -- Timothy Kim
Re: [Android] Where does stuff get written?
seems to me, temp should be whatever is returned by getCacheDir and persistent should be Internal Storage [1] AFAIK all other platforms consider the file storage location to be private to the application. [1] http://developer.android.com/guide/topics/data/data-storage.html#filesInternal On Tue, Feb 19, 2013 at 3:36 PM, Joe Bowser wrote: > Fil and I were working on this issue today: > > https://issues.apache.org/jira/browse/CB-2494 > > This code writes the LICENCE file to /mnt/shell/emulated/0 on Android, > which is some unknown location that isn't accessible using the crappy > Android File Transfer app. I have no idea what the relationship > between this folder and the other Android folders are other than the > fact that we can write to it. > > So, this brings us back to the whole issue that labels like PERSISTANT > and TEMPORARY make no sense on Android, and that we have to revisit > this again. > > So, here are my questions: > 1. Where does stuff get written? > 2. Where should stuff get written? > 3. Where do we want stuff to get written? > 4. Can we offer feedback saying how broken this stupid spec is? > 5. How do we fix this without pissing off our users, who may think > this is working properly? > -- @purplecabbage risingj.com
[Android] Where does stuff get written?
Fil and I were working on this issue today: https://issues.apache.org/jira/browse/CB-2494 This code writes the LICENCE file to /mnt/shell/emulated/0 on Android, which is some unknown location that isn't accessible using the crappy Android File Transfer app. I have no idea what the relationship between this folder and the other Android folders are other than the fact that we can write to it. So, this brings us back to the whole issue that labels like PERSISTANT and TEMPORARY make no sense on Android, and that we have to revisit this again. So, here are my questions: 1. Where does stuff get written? 2. Where should stuff get written? 3. Where do we want stuff to get written? 4. Can we offer feedback saying how broken this stupid spec is? 5. How do we fix this without pissing off our users, who may think this is working properly?
RE: Tag 2.5.0rc1?
webOS has been tagged 2.5.0rc1. > From: shaz...@gmail.com > Date: Tue, 19 Feb 2013 14:46:08 -0800 > Subject: Re: Tag 2.5.0rc1? > To: dev@cordova.apache.org > > Will do the same EOD today for Eye-Oh-Ess, wrapping things up. > > > On Tue, Feb 19, 2013 at 11:55 AM, Joe Bowser wrote: > > > Gone through the same process with Fil. If we fail, we fail together > > > > On Tue, Feb 19, 2013 at 11:50 AM, Filip Maj wrote: > > > I've creatd the JIRA issues for 2.5.0rc1 tagging. > > > > > > Also created a new "next" branch under the javascript and tagged 2.5.0rc1 > > > from that branch.. Hope I did it right :s > > > > > > On 2/19/13 11:32 AM, "Brian LeRoux" wrote: > > > > > >>Sounds about right. Lets aim to get this thing tagged/bagged today. > > >> > > >>On Tue, Feb 19, 2013 at 11:23 AM, Filip Maj wrote: > > >> > > >>> I fear change! But let's do it. > > >>> > > >>> On 2/19/13 11:19 AM, "Joe Bowser" wrote: > > >>> > > >>> >So, how does this work? Do we create the next branch now and throw > > >>> >things in that? > > >>> > > >>> > > > > >
Re: Proposition to split cordova-blackberry into two separate plugins
I'm a little uncertain about the reasoning here. What happens when BB11 ships? New repo? Generally we try to keep things in a vendor directory with the pertinent SDK's within. What is wrong w/ the current structure for contribution? On Tue, Feb 19, 2013 at 2:45 PM, Shazron wrote: > +1 > Also, any news when BB10 comes to Playbook, ballpark? --> "once BB10 is > ported to playbook" > > > > On Tue, Feb 19, 2013 at 1:24 PM, Filip Maj wrote: > > > Sounds fine to me. > > > > As for process, assuming there are no objections (would wait a couple > > days), file a JIRA issue on the INFRA project > > (issues.apache.org/jira/browser/INFRA) > > > > On 2/19/13 1:15 PM, "Jeffrey Heifetz" wrote: > > > > >With all this talk of re-organizing cordova plugins we here at > BlackBerry > > >(RIM no more) have been discussing better alleging ourselves with the > > >approach by splitting our existing cordova-blackberry platform into two > > >separate platforms. (I saw a similar call here as well > > > > > > http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnh > > >pidbnxg5ps7zr+state:results) > > > > > >We propose adding a new platform, "blackberry10" with the longterm > > >understanding that once BB10 is ported to playbook the original repo > > >would only be for BBOS. Ideally the end result of this is that we would > > >have an up to date cordova-blackberry10 platform following all of the > > >best practices (plugins moved into their own repos, etc) and we can > > >better contribute resources to Cordova in general. > > > > > >Hopefully no one has any objections to this as structurally they are > > >really separate platforms. Additionally it'll make the flow within CLI a > > >lot cleaner. > > > > > >If everyone agrees, what is the process for getting a new apache repo > for > > >it? > > > > > >- > > >This transmission (including any attachments) may contain confidential > > >information, privileged material (including material protected by the > > >solicitor-client or other applicable privileges), or constitute > > >non-public information. Any use of this information by anyone other than > > >the intended recipient is prohibited. If you have received this > > >transmission in error, please immediately reply to the sender and delete > > >this information from your system. Use, dissemination, distribution, or > > >reproduction of this transmission by unintended recipients is not > > >authorized and may be unlawful. > > > > >
Re: Tag 2.5.0rc1?
Will do the same EOD today for Eye-Oh-Ess, wrapping things up. On Tue, Feb 19, 2013 at 11:55 AM, Joe Bowser wrote: > Gone through the same process with Fil. If we fail, we fail together > > On Tue, Feb 19, 2013 at 11:50 AM, Filip Maj wrote: > > I've creatd the JIRA issues for 2.5.0rc1 tagging. > > > > Also created a new "next" branch under the javascript and tagged 2.5.0rc1 > > from that branch.. Hope I did it right :s > > > > On 2/19/13 11:32 AM, "Brian LeRoux" wrote: > > > >>Sounds about right. Lets aim to get this thing tagged/bagged today. > >> > >>On Tue, Feb 19, 2013 at 11:23 AM, Filip Maj wrote: > >> > >>> I fear change! But let's do it. > >>> > >>> On 2/19/13 11:19 AM, "Joe Bowser" wrote: > >>> > >>> >So, how does this work? Do we create the next branch now and throw > >>> >things in that? > >>> > >>> > > >
Re: Proposition to split cordova-blackberry into two separate plugins
+1 Also, any news when BB10 comes to Playbook, ballpark? --> "once BB10 is ported to playbook" On Tue, Feb 19, 2013 at 1:24 PM, Filip Maj wrote: > Sounds fine to me. > > As for process, assuming there are no objections (would wait a couple > days), file a JIRA issue on the INFRA project > (issues.apache.org/jira/browser/INFRA) > > On 2/19/13 1:15 PM, "Jeffrey Heifetz" wrote: > > >With all this talk of re-organizing cordova plugins we here at BlackBerry > >(RIM no more) have been discussing better alleging ourselves with the > >approach by splitting our existing cordova-blackberry platform into two > >separate platforms. (I saw a similar call here as well > > > http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnh > >pidbnxg5ps7zr+state:results) > > > >We propose adding a new platform, "blackberry10" with the longterm > >understanding that once BB10 is ported to playbook the original repo > >would only be for BBOS. Ideally the end result of this is that we would > >have an up to date cordova-blackberry10 platform following all of the > >best practices (plugins moved into their own repos, etc) and we can > >better contribute resources to Cordova in general. > > > >Hopefully no one has any objections to this as structurally they are > >really separate platforms. Additionally it'll make the flow within CLI a > >lot cleaner. > > > >If everyone agrees, what is the process for getting a new apache repo for > >it? > > > >- > >This transmission (including any attachments) may contain confidential > >information, privileged material (including material protected by the > >solicitor-client or other applicable privileges), or constitute > >non-public information. Any use of this information by anyone other than > >the intended recipient is prohibited. If you have received this > >transmission in error, please immediately reply to the sender and delete > >this information from your system. Use, dissemination, distribution, or > >reproduction of this transmission by unintended recipients is not > >authorized and may be unlawful. > >
Re: more benchmarking in mobile-spec
K I've got a little bit ready. Just benches: 1. The # of exec invocations possible in a time interval 2. The # of exec callback invocations possible in a time interval Now my conundrum is: where do I push this to? Next branch? Master? :( On 2/19/13 12:16 PM, "Andrew Grieve" wrote: >Awesome stuff Fil! The first one is one that I tried before when doing the >bridge benchmark and found it to not get accurate results. Had a look at >the README.md of the second one, and it sounds pretty good. Looking >forward >to seeing what you come up with :) > > >On Tue, Feb 19, 2013 at 2:41 PM, Filip Maj wrote: > >> Raising this thread from the dead :) >> >> I'm thinking of either http://benchmarkjs.com/ or >> https://github.com/akdubya/uubench >> >> Both apparently support async which is our only requirement AFAIK. >> >> Will mess aboot with adding both to mobile-spec and seeing how it pans >>out. >> >> On 10/26/12 11:09 AM, "Brian LeRoux" wrote: >> >> >eh folks, any thoughts on using >> >https://github.com/robohornet/robohornet for benching? >> >>
Re: Proposition to split cordova-blackberry into two separate plugins
Sounds fine to me. As for process, assuming there are no objections (would wait a couple days), file a JIRA issue on the INFRA project (issues.apache.org/jira/browser/INFRA) On 2/19/13 1:15 PM, "Jeffrey Heifetz" wrote: >With all this talk of re-organizing cordova plugins we here at BlackBerry >(RIM no more) have been discussing better alleging ourselves with the >approach by splitting our existing cordova-blackberry platform into two >separate platforms. (I saw a similar call here as well >http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnh >pidbnxg5ps7zr+state:results) > >We propose adding a new platform, "blackberry10" with the longterm >understanding that once BB10 is ported to playbook the original repo >would only be for BBOS. Ideally the end result of this is that we would >have an up to date cordova-blackberry10 platform following all of the >best practices (plugins moved into their own repos, etc) and we can >better contribute resources to Cordova in general. > >Hopefully no one has any objections to this as structurally they are >really separate platforms. Additionally it'll make the flow within CLI a >lot cleaner. > >If everyone agrees, what is the process for getting a new apache repo for >it? > >- >This transmission (including any attachments) may contain confidential >information, privileged material (including material protected by the >solicitor-client or other applicable privileges), or constitute >non-public information. Any use of this information by anyone other than >the intended recipient is prohibited. If you have received this >transmission in error, please immediately reply to the sender and delete >this information from your system. Use, dissemination, distribution, or >reproduction of this transmission by unintended recipients is not >authorized and may be unlawful.
Proposition to split cordova-blackberry into two separate plugins
With all this talk of re-organizing cordova plugins we here at BlackBerry (RIM no more) have been discussing better alleging ourselves with the approach by splitting our existing cordova-blackberry platform into two separate platforms. (I saw a similar call here as well http://callback.markmail.org/thread/xnhpidbnxg5ps7zr#query:+page:1+mid:xnhpidbnxg5ps7zr+state:results) We propose adding a new platform, "blackberry10" with the longterm understanding that once BB10 is ported to playbook the original repo would only be for BBOS. Ideally the end result of this is that we would have an up to date cordova-blackberry10 platform following all of the best practices (plugins moved into their own repos, etc) and we can better contribute resources to Cordova in general. Hopefully no one has any objections to this as structurally they are really separate platforms. Additionally it'll make the flow within CLI a lot cleaner. If everyone agrees, what is the process for getting a new apache repo for it? - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: more benchmarking in mobile-spec
Awesome stuff Fil! The first one is one that I tried before when doing the bridge benchmark and found it to not get accurate results. Had a look at the README.md of the second one, and it sounds pretty good. Looking forward to seeing what you come up with :) On Tue, Feb 19, 2013 at 2:41 PM, Filip Maj wrote: > Raising this thread from the dead :) > > I'm thinking of either http://benchmarkjs.com/ or > https://github.com/akdubya/uubench > > Both apparently support async which is our only requirement AFAIK. > > Will mess aboot with adding both to mobile-spec and seeing how it pans out. > > On 10/26/12 11:09 AM, "Brian LeRoux" wrote: > > >eh folks, any thoughts on using > >https://github.com/robohornet/robohornet for benching? > >
Re: Tag 2.5.0rc1?
Gone through the same process with Fil. If we fail, we fail together On Tue, Feb 19, 2013 at 11:50 AM, Filip Maj wrote: > I've creatd the JIRA issues for 2.5.0rc1 tagging. > > Also created a new "next" branch under the javascript and tagged 2.5.0rc1 > from that branch.. Hope I did it right :s > > On 2/19/13 11:32 AM, "Brian LeRoux" wrote: > >>Sounds about right. Lets aim to get this thing tagged/bagged today. >> >>On Tue, Feb 19, 2013 at 11:23 AM, Filip Maj wrote: >> >>> I fear change! But let's do it. >>> >>> On 2/19/13 11:19 AM, "Joe Bowser" wrote: >>> >>> >So, how does this work? Do we create the next branch now and throw >>> >things in that? >>> >>> >
Re: Tag 2.5.0rc1?
I've creatd the JIRA issues for 2.5.0rc1 tagging. Also created a new "next" branch under the javascript and tagged 2.5.0rc1 from that branch.. Hope I did it right :s On 2/19/13 11:32 AM, "Brian LeRoux" wrote: >Sounds about right. Lets aim to get this thing tagged/bagged today. > >On Tue, Feb 19, 2013 at 11:23 AM, Filip Maj wrote: > >> I fear change! But let's do it. >> >> On 2/19/13 11:19 AM, "Joe Bowser" wrote: >> >> >So, how does this work? Do we create the next branch now and throw >> >things in that? >> >>
Re: more benchmarking in mobile-spec
Raising this thread from the dead :) I'm thinking of either http://benchmarkjs.com/ or https://github.com/akdubya/uubench Both apparently support async which is our only requirement AFAIK. Will mess aboot with adding both to mobile-spec and seeing how it pans out. On 10/26/12 11:09 AM, "Brian LeRoux" wrote: >eh folks, any thoughts on using >https://github.com/robohornet/robohornet for benching?
Re: CB-200: What's the story with this?
There's no way to have native File objects interoperate with Cordova ones, so I think it's still a valid feature request. Shelved, but not forgotten. On Tue, Feb 19, 2013 at 1:48 PM, Joe Bowser wrote: > I would also like to shelve it, despite the fact that there are tests for > it. > > On Mon, Feb 18, 2013 at 4:00 PM, Filip Maj wrote: > > I added the tests to mobile-spec and tweaked the js to account for this > > already :s > > > > On 2/18/13 3:56 PM, "Shazron" wrote: > > > >>My vote is to shelve it. > >> > >> > >>On Mon, Feb 18, 2013 at 3:50 PM, Joe Bowser wrote: > >> > >>> Hey > >>> > >>> This is slated for 2.5.x, but I don't think this will ever happen. > >>> What do we plan to do with multi-file upload with FileTransfer? > >>> > >>> Joe > >>> > > >
Re: Tag 2.5.0rc1?
Sounds about right. Lets aim to get this thing tagged/bagged today. On Tue, Feb 19, 2013 at 11:23 AM, Filip Maj wrote: > I fear change! But let's do it. > > On 2/19/13 11:19 AM, "Joe Bowser" wrote: > > >So, how does this work? Do we create the next branch now and throw > >things in that? > >
Re: Brainstorming Proposal: Implementing apps as plugins
Okay, I've let the doodle run for ~5 days.
Looks like the best date is Friday, March 22nd, at 9AM Pacific time, noon
EST, 6PM Euro time.
I'm setting aside an hour for it, but it could last less.
I will look into setting up an Adobe Connect room so we can run
screenshare and do a recording as well that we can post back to the dev
list.
Mark it in your calendars, don't forget!
On 2/14/13 10:46 AM, "Michal Mocny" wrote:
>Sounds great, thanks for coordinating.
>
>
>On Thu, Feb 14, 2013 at 1:07 PM, Filip Maj wrote:
>
>> I'll set up a doodle for early to mid-march and post it back to this
>> thread.
>>
>> On 2/14/13 10:03 AM, "Jesse" wrote:
>>
>> >Good.
>> >
>> >On Thu, Feb 14, 2013 at 9:42 AM, Filip Maj wrote:
>> >
>> >> So Anis and I were thinking of, at the minimum, doing a 10-15 min
>> >>overview
>> >> of the tools we each work on (cordova-cli and plugman) and then
>>fielding
>> >> questions.
>> >>
>> >> We can also bring up main points for and against considering an app
>> >>being
>> >> a plugin and see where that gets us.
>> >>
>> >> I am thinking of setting up a doodle and posting it to the list, to
>>see
>> >> what day works best. Time-wise, since we are all spread out between
>>west
>> >> and east coast in north america, + europe, these types of calls are
>> >> usually done early in the AM for PST (shudder), which ends up being
>> >> end-of-day for Europeans and around lunch-time for east coast folk.
>> >>
>> >> Sound good?
>> >>
>> >> On 2/12/13 11:11 PM, "Anis KADRI" wrote:
>> >>
>> >> >BTW, because I happen to like contradictions. Plugins are not
>> >>completely
>> >> >free-form. They still require some sort of directory structure for
>> >>every
>> >> >supported platform (right now: iOS, Android and BlackBerry 10).
>> >> >Precisely, src/{ios,android,BlackBerry10} needs to be there or
>> >>libraries
>> >> >(on android, bb10) and everything (on ios) will fail to install. Of
>> >>course
>> >> >this can be (and should be) changed but I am just stating the
>>current
>> >> >state.
>> >> >
>> >> >
>> >> >On Tue, Feb 12, 2013 at 11:01 PM, Anis KADRI
>> >> wrote:
>> >> >
>> >> >> I'd like to see where the overlap is before jumping in and merging
>> >>the
>> >> >>two
>> >> >> code bases.
>> >> >>
>> >> >> I think that by essence plugins and apps are different. Even
>>though
>> >>they
>> >> >> are close in that they both have manifest/assets/native files.
>> >> >>
>> >> >> I also like the existence of discrete tools that do one job rather
>> >>than
>> >> >> one big tool that does everything. Andrew Lunny separated
>> >> >> the functionalities of pluginstall into multiple tools when he
>> >>initially
>> >> >> started it (node-xcode, node-plist, etc...). It's also so much
>>easier
>> >> >>for
>> >> >> someone new to the project to just jump in and contribute. Besides
>> >>some
>> >> >> people are already using plugman separately and don't need the
>>extra
>> >> >>sugar
>> >> >> provided by cordova-cli.
>> >> >>
>> >> >> I see cordova-cli as super-master-script that uses multiple tools
>>to
>> >> >> create/build/debug/emulate/install plugins that just focused on
>>the
>> >> >>project
>> >> >> side of things... but maybe I got it wrong.
>> >> >>
>> >> >> This is just a brain dump and I can be convinced otherwise. Maybe
>>we
>> >>can
>> >> >> schedule some sort of Google+ hangout to discuss this. Fil you've
>> >>got a
>> >> >> Google+ account now, yah :-) ?
>> >> >>
>> >> >> -a
>> >> >>
>> >> >>
>> >>
>> >>
>> >
>> >
>> >--
>> >@purplecabbage
>> >risingj.com
>>
>>
Re: CLI tools: verbose mode
Adding flags SGTM. On Tue, Feb 19, 2013 at 2:26 PM, Brian LeRoux wrote: > I suppose we can thank Java for this. Ideally a script is silent unless > there is an error and then it should be noisy. Going to STDOUT fine for > now.. > > On Tue, Feb 19, 2013 at 11:15 AM, Filip Maj wrote: > > > https://issues.apache.org/jira/browse/CB-2452 > > > > > > The barrier to allowing a verbose mode for the cli scripts is that the > > underlying platform cli scripts are silent. > > > > Thoughts on adding a verbose option to the platform scripts? Essentially > > redirecting output from commands to stdout > > > > >
Re: CLI tools: verbose mode
I suppose we can thank Java for this. Ideally a script is silent unless there is an error and then it should be noisy. Going to STDOUT fine for now.. On Tue, Feb 19, 2013 at 11:15 AM, Filip Maj wrote: > https://issues.apache.org/jira/browse/CB-2452 > > > The barrier to allowing a verbose mode for the cli scripts is that the > underlying platform cli scripts are silent. > > Thoughts on adding a verbose option to the platform scripts? Essentially > redirecting output from commands to stdout > >
Re: Tag 2.5.0rc1?
I fear change! But let's do it. On 2/19/13 11:19 AM, "Joe Bowser" wrote: >So, how does this work? Do we create the next branch now and throw >things in that?
Tag 2.5.0rc1?
So, how does this work? Do we create the next branch now and throw things in that?
Re: Proposal for JS in Plugins
I think I like it! (But look forward to seeing it in a pull request.) On Thu, Feb 14, 2013 at 10:31 AM, Braden Shepherdson wrote: > So I've written up my plan for attacking this problem into a Google Doc > I've shared for public comments: > > > https://docs.google.com/document/d/1fhwnIZ5TqwklGx71pLmfSghysls1S4_5ktEsjA9ac5Y/edit?usp=sharing > > tl;dr version is that on cordova prepare (the new fast first part of > cordova build, copies www) we read all installed plugins for new XML tags > that define the JS modules and where they should be exposed on window, and > inject code into cordova.js to load the modules, and do the > clobbering/merging/executing as necessary. This is a relatively modest new > feature for the CLI that doesn't require any refactoring, and should be > fast enough to run on every prepare/build without significant slowdown. > > I'm working on a prototype of this approach in a fork of the CLI. If you > spot any problems with the approach, please comment on the doc or in this > thread. > > Braden > > > On Fri, Feb 8, 2013 at 4:45 AM, Brian LeRoux wrote: > > > You know what. I'm super wrong. I was thinking in the context of a > > native project and not a *cordova* project. > > > > The flaw in the thinking was that we were shipping only one file we > > build leaving devs to include as they see fit. But whats really > > happening is that we are generating a new file for every plugin > > add/remove which will be different for each platform. If they move > > that file around and include from a directory of their choosing we're > > fucked. > > > > The difference here is the audience. A developer content to NOT use > > our tools, and compose their own app for a single platform, say > > Android, is going to have to figure out inclusion themselves. For us, > > its a build time concern. Not magic. > > > > Consider: we are required to re-build every time a user adds/removes a > > plugin. And if they move that generated file, again, we're fucked. > > This is increasingly looking like a script injectwhich we could > > make configurable with config.xml so that it isn't too magical > > feeling. > > > > We should talk about how the www install part works though. I wonder > > if it would appropriate to propose a special folder in www for this > > purpose. Like node_modules but without fugly underscores. > > > > > > On Wed, Feb 6, 2013 at 4:01 PM, Andrew Grieve > > wrote: > > > For a project who's main language is JS, I'm a bit surprised that > > injecting > > > a script tag through DOM manipulation would put us into the "magic" > > > category... > > > > > > Brian - Your sentiments about the development stack don't make sense to > > me. > > > The development stack is *the* job of CLI. We are prescribing a way to > > set > > > up your project so that it's easy to have an x-platform www directory, > > and > > > writing tools to make it easy to add/remove plugins. Is not "the > > > development stack" *the* goal of CLI? > > > > > > This isn't a problem that we can "not solve". It's a problem that > exists, > > > and doing nothing *is a solution*. Here's the "do nothing" solution: > > > - Let plugins put their .js file anywhere within the www/ directory > (and > > > hope that it doesn't clobber anything) > > > - Have them write documentation to instruct users that they must insert > > > their script tags into each of their .html files > > > - Hope that users notice the instructions, and that they are correct, > and > > > that they don't mess them up > > > - Hope that users can remember which JS files belong to what if they > ever > > > want to remove plugins > > > > > > Note that for our core plugins, we have 78 .js files just within > > > lib/common/plugin. > > > > > > A variation on "do nothing": > > > - Tell each plugin developer to come up with their own packaging system > > > - Tell them to check in a pre-packaged version with every commit (or > just > > > on releases) > > > - Tell them to write instructions for the manual steps involved in > > adding / > > > removing their plugins. > > > > > > I don't accept that this isn't a problem. If there are actually better > > > alternatives, I'd like to hear what they are, and what the development > > > workflow looks like for both the plugin users as well as the plugin > > > developers. > > > > > > > > > Anis - What sort of needs / requirements are you thinking of that won't > > > work with the injecting script tags approach? Let's try and work > through > > > them. The same argument could be used to shoot down the entire CLI > > effort... > > > > > > > > > Andrew > > > > > > > > > On Wed, Feb 6, 2013 at 6:27 PM, Joe Bowser wrote: > > > > > >> I also disagree with automagically injecting the script tags. If > > >> we're adding the script tags, we have the ability of adding the script > > >> tags wrong, and breaking people's apps with magic. We have enough > > >> trouble directing our users to use Cordova/PhoneGap without us trying > > >> to make things
CLI tools: verbose mode
https://issues.apache.org/jira/browse/CB-2452 The barrier to allowing a verbose mode for the cli scripts is that the underlying platform cli scripts are silent. Thoughts on adding a verbose option to the platform scripts? Essentially redirecting output from commands to stdout
Re: feb report
Minor point of completeness FWIW, there were 2 DOAP files updated, one for the project and another for the PMC. -- Marcel Kinard On Feb 19, 2013, at 1:36 PM, Brian LeRoux wrote: > pls review and let me know if I missed anything big > > https://github.com/cordova/apache-board-reports/blob/master/2013-02.md
Re: CB-200: What's the story with this?
I would also like to shelve it, despite the fact that there are tests for it. On Mon, Feb 18, 2013 at 4:00 PM, Filip Maj wrote: > I added the tests to mobile-spec and tweaked the js to account for this > already :s > > On 2/18/13 3:56 PM, "Shazron" wrote: > >>My vote is to shelve it. >> >> >>On Mon, Feb 18, 2013 at 3:50 PM, Joe Bowser wrote: >> >>> Hey >>> >>> This is slated for 2.5.x, but I don't think this will ever happen. >>> What do we plan to do with multi-file upload with FileTransfer? >>> >>> Joe >>> >
Re: feb report
No new committers? That reflects slow progress, I vote we just give Max commit access ;) -Michal On Tue, Feb 19, 2013 at 1:36 PM, Brian LeRoux wrote: > pls review and let me know if I missed anything big > > https://github.com/cordova/apache-board-reports/blob/master/2013-02.md >
feb report
pls review and let me know if I missed anything big https://github.com/cordova/apache-board-reports/blob/master/2013-02.md
Re: cordova.js changes
Sounds like pause, resume events? (Which we should look to deprecate for
page visibility api but thats another story!)
On Tue, Feb 19, 2013 at 7:45 AM, Leutwyler, Markus
wrote:
> What's the process for adding stuff to cordova.js or how can i make such
> changes platform specific?
>
> Let's say I want to add a new (in my case probably webOS specific)
> document event for show/hide/relaunch to Cordova:
>
> Cordova.js, line 240
> channel.onShow = cordova.addDocumentEventHandler('show');
>
>
>
>
> Markus
>
Re: cordova.js changes
Probably your best bet would be to add it to the initialize function for
your platform (example:
https://github.com/gtanner/cordova-js/blob/master/lib/blackberry/plugin/qnx/platform.js#L26-42
)
If you need it to be sooner you have the option of the bootstrap file which
gets tacked to the end of the cordova.js file (Example:
https://github.com/gtanner/cordova-js/blob/master/lib/scripts/bootstrap-blackberry.js
)
On Tue, Feb 19, 2013 at 10:45 AM, Leutwyler, Markus wrote:
> What's the process for adding stuff to cordova.js or how can i make such
> changes platform specific?
>
> Let's say I want to add a new (in my case probably webOS specific)
> document event for show/hide/relaunch to Cordova:
>
> Cordova.js, line 240
> channel.onShow = cordova.addDocumentEventHandler('show');
>
>
>
>
> Markus
>
cordova.js changes
What's the process for adding stuff to cordova.js or how can i make such
changes platform specific?
Let's say I want to add a new (in my case probably webOS specific) document
event for show/hide/relaunch to Cordova:
Cordova.js, line 240
channel.onShow = cordova.addDocumentEventHandler('show');
Markus
