Joe,
As we discussed on the call yesterday, I wrote a script that transforms a
Cordova plugin's android platform to a module structure:
https://github.com/jasongin/cordova-plugin-compat/blob/master/scripts/Modularize.js
The transformation to a module includes:
* Generation of build.gradle for t
Could npm shrinkwrap be a solution? The cordova-coho docs mention shrinkwrap
was avoided previously because it was "not mature", but it has apparently
improved a lot in v3. According to a comment [1] in another related issue it
has solved this problem in v3. I'm not totally familiar with the pla
How is that a breaking change? Note it doesn't affect a platform-centric
workflow.
I had expected only a minor version bump would be appropriate.
-Original Message-
From: Vladimir Kotikov (Akvelon) [mailto:v-vlk...@microsoft.com]
Sent: Friday, May 27, 2016 2:21 AM
To: dev@cordova.apach
From: Jason Ginchereau [mailto:jason...@microsoft.com]
Sent: Thursday, May 26, 2016 3:26 PM
To: dev@cordova.apache.org
Subject: RE: [DISCUSS] iOS release
Hold on just a moment. Nikhil had a comment about the PR that I need to
investigate and possibly make a small change. It should be ready later
: [DISCUSS] iOS release
Jason - I'll run the tests again and pull this in
On Thu, May 26, 2016 at 2:54 PM, Jason Ginchereau
wrote:
> I have a PR here that we'd like to get in:
> https://github.com/apache/cordova-ios/pull/220
>
> It includes bundling of cordova-common 1.3.
I have a PR here that we'd like to get in:
https://github.com/apache/cordova-ios/pull/220
It includes bundling of cordova-common 1.3.0.
-Original Message-
From: Steven Gill [mailto:stevengil...@gmail.com]
Sent: Thursday, May 26, 2016 2:48 PM
To: dev@cordova.apache.org
Subject: [DISCUSS]
ion bump, since it's new functionality.
Jason
-Original Message-
From: Jason Ginchereau [mailto:jason...@microsoft.com]
Sent: Tuesday, April 26, 2016 9:39 AM
To: dev@cordova.apache.org
Subject: RE: [DISCUSS] Faster incremental builds
I don't understand how adding a file li
" == "cordova clean && cordova prepare"
- Carlos
@csantanapr
> On Apr 22, 2016, at 7:45 PM, Jason Ginchereau wrote:
>
> I don't think making the after_prepare hook API more complicated is a good
> design. Instead can we just document that after_pre
f a break API on CLI so
maybe CLI 7.x but not sure.
Also for folks that want the conversation approach with one command we can also
have a flag --clean "cordova prepare --clean"
- Carlos
@csantanapr
> On Apr 21, 2016, at 7:42 PM, Jason Ginchereau wrote:
>
> T
ss to to the body element to for
platform identification
- Carlos
@csantanapr
> On Apr 21, 2016, at 5:12 PM, Jason Ginchereau wrote:
>
> If "cordova clean" would also take care of deleting the files copied by
> prepare, then I'd be confident in making prepare incremen
at the same
time I enable the incremental prepare.
Jason
-Original Message-
From: Jason Ginchereau [mailto:jason...@microsoft.com]
Sent: Wednesday, April 20, 2016 10:00 AM
To: dev@cordova.apache.org
Subject: RE: [DISCUSS] Faster incremental builds
My concern with making this the defaul
e just need to test more to make sure it functions as
> > > expected everywhere, and then it should just make it's way in
> > > directly, without
> > the
> > > overhead of addition flag code, or documentation ...
> > >
> > >
> > > @pur
apache.org
Subject: Re: [DISCUSS] Faster incremental builds
Sounds like a worthy cause. Do you have any stats on how much time is saved?
Definitely put it behind the --incremental flag to start.
On Tue, Apr 19, 2016 at 2:43 PM, Jason Ginchereau
wrote:
> We've had a few customers complai
We've had a few customers complain that the dev inner loop for Cordova apps is
slow compared to native app development. So recently I've been looking at ways
to optimize it. The two largest pieces of a Cordova build are "prepare" and
"compile" phases. While there's not much we can realistically
+1
This will make it much easier to develop and unit-test plugins as a
self-contained lib project.
-Original Message-
From: julio cesar sanchez [mailto:jcesarmob...@gmail.com]
Sent: Friday, April 8, 2016 12:43 PM
To: dev@cordova.apache.org
Subject: Re: Publishing the AAR after the next r
Distributing Android platforms and plugins as AAR binaries seems to go against
open-source conventions and the existing Cordova model, where everything is
distributed as source. It also breaks the platform-centric workflow that
otherwise allows easily making changes to the platform and plugin co
Hi Joe,
Can you provide more specific reasons why you think using reflection is
problematic in this case? This seems to me like exactly the sort of situation
where reflection is an appropriate solution.
There are valid reasons why many app developers might not be ready to move to
API level 23
I think this PR should get in the release:
https://github.com/apache/cordova-plugin-file/pull/146
It might be considered a blocker, because it is a regression that could cause
loss of data when upgrading apps which relied on the default
AndroidPersistentFileLocation value.
This would be a good
ng on improving plugin quality.
Jason Ginchereau
19 matches
Mail list logo
