+1. lets get this over with so we can put some serious goodness into 2.6
On Mon, Feb 25, 2013 at 1:44 PM, Filip Maj wrote:
> How's everyone feeling with the last rc release? The issue tracker has
> been kind of quiet, good sign? I'd like to set up the tagging issues
> tomorrow-ish so we can get t
How's everyone feeling with the last rc release? The issue tracker has
been kind of quiet, good sign? I'd like to set up the tagging issues
tomorrow-ish so we can get the thing tagged-n-bagged by end-of-week.
Actually, got this working, pushed a remote branch for feedback:
Commit:
http://git-wip-us.apache.org/repos/asf/cordova-mobile-spec/commit/9ec39e93
We can add the other platforms, of course, and on windows you can hard link
the file, I think?
-Michal
On Mon, Feb 25, 2013 at 2:59 PM, Michal Moc
Do the changes you'd like to see cherry-picked fix regressions? If not,
then I'd say just leave them broken in 2.5.
I think what'd you'd do then is cherry-pick into next, and then immediately
merge next into master. The merge in this case should have a conflict
because of the two identical changes
I haven't cherry-picked anything into next yet. I've kept working on
master and I've been ignoring next. However, there's some things in
master that I would like to see in the next release. How do we do
that without cherry-picking? Or do we just keep things broken in 2.5
and just shrug our shoul
Joe - do you mean you're committing to master and cherry-picking into next?
I think this would result in two identical-but-different changes appearing
in the two branches, whereas checking into next and merging into master
ends up with the same change appearing in both branches. The result of this
Yeah I'm trying to prototype what I proposed and I cannot find a way to
test for file existence in a sync way, and the mobile spec tests don't deal
well with having cordova.js injected after page load. This is solvable but
I'll shelve it until I get more feedback/interest expressed.
-Michal
On
For every version, I do the following for WP7 and WP8 :
- create a new project from the latest template
- remove the dll and link to the repo project directly
- copy over mobile-spec
- modify cordova.js to include cordova.windowsphone.js
- add visual studio link to cordova-js output pkg version
R
How do other devs test mobile spec locally?
Specifically, how do you set up your repo to test with your working
cordova.js version, in a way that you can make changes to mobile-spec
tests, push local changes merge changes coming from remote.
I'm always overriding/clearing/overriding the default c
Okay, I've fixed the tests and pushing now. I didn't notice the indirect
use of callbackFromNative via the spy, but updated tests to expect new
syntax.
Thanks for catching this!
-Michal
On Mon, Feb 25, 2013 at 1:49 PM, Michal Mocny wrote:
> also: failing for me too, looking into it
>
>
> On
That's assuming that we're fixing for release. I've been doing all
work in master at this point. I think we're fine doing both
cherrypicks and merging, but I think that's what makes this process
complicated.
On Mon, Feb 25, 2013 at 10:42 AM, Filip Maj wrote:
>
>>Also, on a side note, for the rel
also: failing for me too, looking into it
On Mon, Feb 25, 2013 at 1:48 PM, Michal Mocny wrote:
> nvm, seems they run with 'jake' but not 'jake btest'
>
>
> On Mon, Feb 25, 2013 at 1:47 PM, Michal Mocny wrote:
>
>> Joe, I can't seem to be able to run jake tests locally:
>>
>> Error: Cannot find
nvm, seems they run with 'jake' but not 'jake btest'
On Mon, Feb 25, 2013 at 1:47 PM, Michal Mocny wrote:
> Joe, I can't seem to be able to run jake tests locally:
>
> Error: Cannot find module 'connect'
> at Function.Module._resolveFilename (module.js:338:15)
>
>
> On Mon, Feb 25, 2013 at
Joe, I can't seem to be able to run jake tests locally:
Error: Cannot find module 'connect'
at Function.Module._resolveFilename (module.js:338:15)
On Mon, Feb 25, 2013 at 1:42 PM, Filip Maj wrote:
>
> >Also, on a side note, for the release, if there's commits in master
> >that we want in t
>Also, on a side note, for the release, if there's commits in master
>that we want in this release, do we do a cherry pick into next?
Yes. I see it the opposite way (I commit into next and merge into master).
Sweet! I should keep my mouth shut until I play with the code :)
On 2/25/13 10:06 AM, "Andrew Grieve" wrote:
>Just to clarify - Braden's prototype doesn't concat plugin js.
>
>I think we're on the same page in terms of concatenating making it hard to
>figure out user reports.
>
>What this does i
Those are all from me.
I am all for high-quality user-facing resources, and that was the intention. I
wasn't aware that there was access to UX skills, and didn't intend to do
anything outside of protocol.
Q1: Would you like me to perform the changes you've described below?
Q2: I did add a ste
Just to clarify - Braden's prototype doesn't concat plugin js.
I think we're on the same page in terms of concatenating making it hard to
figure out user reports.
What this does is concat the code to inject script tags. Each plugin's code
then lives in their own .js files.
On Mon, Feb 25, 2013
The original proposal said that pre-compiled "Can be an alternative (not
replacement) to distributing plugins as source-code." so I don't think the
original intent was for selling plugins. Thats not to say that that isn't
useful, but my understanding is that end goal of this particular thread is
a
Sweet! Thanks for putting this together Braden. I now have something to
play with on the flight to Portland this afternoon :D
Related, we had spoke a few months ago [1] about what to do with plugin
installation and inclusion of plugin JS (as either concat'ed to cordova.js
or with new script tags a
On Mon, Feb 25, 2013 at 9:11 AM, Braden Shepherdson wrote:
> I'm working on our prototype for automatic installation of Javascript from
> plugins in cordova-cli. We already have installation for native code and
> non-JS www assets. I don't see anything to be gained from precompiled
> libraries, si
Just to clarify this in my head:
* Since we have a prepare step now, you propose moving some of the logic
that used to run on plugin add out into the prepare step. That sounds good.
* You want to fix how we track which plugins are installed by going to
source instead of some config file. That so
I sent around a document[1] outlining my plan for automatically installing
plugin Javascript files last week. The prototype is complete and in a pull
request[2] now.
tl;dr for how this works is: tags in the plugin.xml specify
, and for each JS file; cordova prepare copies
the JS files into the
I agree with all that Marcel said, and I think most of the points he
outlined are well under way. So, I vote we just revisit this once those
are done and we have some time to ingest the changes, and see if we still
have a use case for this.
For the example of 2 year old plugin, it seems unlikely
I'm running into several problems with the current implementation of
cordova-cli:
* There's no single source of truth for what plugins are installed. It uses
the presence of a plugin's name in the www/config.xml currently. This
doesn't work for JS-only plugins, and there are some, especially on ot
I'm working on our prototype for automatic installation of Javascript from
plugins in cordova-cli. We already have installation for native code and
non-JS www assets. I don't see anything to be gained from precompiled
libraries, since a user of Cordova already has the device SDK in place and
is usi
26 matches
Mail list logo
