It seems that all the platform scripts do something subtly different.
Some of them do support custom platform paths, others don't, etc. It seems
like something we could easily consolidate.
On Wed, Nov 27, 2013 at 4:51 PM, Michal Mocny wrote:
> https://reviews.apache.org/r/15889/
>
>
> On Wed,
https://reviews.apache.org/r/15889/
On Wed, Nov 27, 2013 at 4:38 PM, Michal Mocny wrote:
> But the file warns that its auto-generated and shouldn't be edited ;)
>
> I've got a patch for this. Seems of the other platforms were already
> doing it right. Reviewboard incoming since I don't much w
But the file warns that its auto-generated and shouldn't be edited ;)
I've got a patch for this. Seems of the other platforms were already doing
it right. Reviewboard incoming since I don't much with CLI often.
On Wed, Nov 27, 2013 at 3:03 PM, Joe Bowser wrote:
> I'm bumping it to 19 now. Y
I'm bumping it to 19 now. You just change project.properties to do
this on Android. :)
On Wed, Nov 27, 2013 at 11:59 AM, Michal Mocny wrote:
> Ah, indeed. CLI has hard coded req on 17 in
> module.exports.check_requirements in android_parser.js. That needs to
> change especially quickly now sin
The correct fix here is to scrap CLI's half-assed custom check_requirements
implementation and have it call the real Android platform script instead.
Then that script should do the right thing re: API versions.
Braden
On Wed, Nov 27, 2013 at 11:59 AM, Michal Mocny wrote:
> Ah, indeed. CLI has
Ah, indeed. CLI has hard coded req on 17 in
module.exports.check_requirements in android_parser.js. That needs to
change especially quickly now since the platform SDK dependency was bumped
to 18 in our 3.2 release (so CLI and platform workflows have atm different
requirements).
On Wed, Nov 27,
The problem is that we should never be relying on the CLI for this
info, and that the platforms should be doing it. That's why I edited
the bug in the first place. This is also a problem with iOS, although
less of a problem due to >=.
On Wed, Nov 27, 2013 at 11:43 AM, Michal Mocny wrote:
> Woul
Would be nice to change scripts to check for >= target-level instead of
exactly ==. I currently just re-installed my android SDK locally with only
4.4 (API 19), and now fail to create a project with CLI since it isnt
exactly the version we look for.
Since there won't be another android release fo
I think some people are confused about this number and backward
compatibility.
There are *two* version constraints on Android. The one we're discussing
here is which API we're compiling against, which should generally be set at
the latest stable version (+1 to 3.2 targeting API 18 (Android 4.3)).
We are also in the works on getting a Nexus 5, probably on Friday we want
to get unlocked
On Thu, Nov 7, 2013 at 9:38 AM, Joe Bowser wrote:
> That's correct. I only have an old Nexus 7 with an AOSP build I made
> yesterday to test things on 4.4 while I wait for the Nexus 5 or the
> official upd
That's correct. I only have an old Nexus 7 with an AOSP build I made
yesterday to test things on 4.4 while I wait for the Nexus 5 or the
official updates, and since I have no camera drivers working.
BTW: We still have a gallery, but I think the Camera plugin may be broken
in 4.4.
On Nov 7, 2013 6
To be clear the goal for Cordova 3.2 is to set target 18 (Android 4.3) and
for Cordova 3.3 target 19 (Android 4.4) ?
We are about to release 3.2 so I want to be sure.
I vote to set target 19/4.4 (KitKat) for Cordova 3.3 (Allows time to
investigate, test, integrate, and document)
On Thu, Nov 7,
Joe is right on the money. If the target is older than 13 it will fail to
compile which was detected elsewhere [1].
Also as detected on the other thread CLI is not actually [2] [3] delegating
the requirement checks to platform scripts for
Android and iOS. After this issue is resolved it will depen
Axel: you are correct that we want as many devices as possible. This is why
we've always set to the highest level. If you set to the highest level it
is inclusive to all platforms before it (that we decide to support).
On Thu, Nov 7, 2013 at 12:00 PM, Axel Nennker wrote:
> I think the highest l
The whole point is to have one APK across all official Android versions.
This requirement is going to confuse pur users even more and make
maintaining the platform next to impossible. Web developers shouldn't have
to know about API level.
The fact is that we've been fairly successful in maintaini
I think the highest level is not what developers need.
When you create a product/app you want your app to run on as many devices
as possible and not only the latest.
Am 07.11.2013 11:36 schrieb "Brian LeRoux" :
> Apologies I think there is another thread about this but I'd like to
> understand mor
+1
On 7 Nov 2013, at 9:35 pm, Brian LeRoux wrote:
> Apologies I think there is another thread about this but I'd like to
> understand more about what we're thinking here. There's been discussion
> that we should make this configurable. I disagree. I think we need to
> target highest available l
Apologies I think there is another thread about this but I'd like to
understand more about what we're thinking here. There's been discussion
that we should make this configurable. I disagree. I think we need to
target highest available level possible, as we always have in the past, and
take backwar
Created issues to sync cheq requirements for CLI
https://issues.apache.org/jira/browse/CB-5298
https://issues.apache.org/jira/browse/CB-5297
On Tue, Nov 5, 2013 at 5:36 PM, Carlos Santana wrote:
> Sorry wrong link for iOS Check Reqs
>
> https://github.com/apache/cordova-cli/blob/master/src/met
Sorry wrong link for iOS Check Reqs
https://github.com/apache/cordova-cli/blob/master/src/metadata/ios_parser.js#L32
Should I open jira issues for these 2?
On Tue, Nov 5, 2013 at 5:31 PM, Carlos Santana wrote:
> Similar problem with iOS cheq_reqs
>
> CLI Checks for XCode 4.5 as min [1]
> Plat
5.0.1 should be the min if we want to go arm64:
https://issues.apache.org/jira/browse/CB-4863
On Tue, Nov 5, 2013 at 2:31 PM, Carlos Santana wrote:
> Similar problem with iOS cheq_reqs
>
> CLI Checks for XCode 4.5 as min [1]
> Platform Checks for XCode 4.6 as min [2]
>
> Which with XCode 5 out,
Similar problem with iOS cheq_reqs
CLI Checks for XCode 4.5 as min [1]
Platform Checks for XCode 4.6 as min [2]
Which with XCode 5 out, I think Xcode 5.0.1 should be the minimum :-)
[1]:
https://github.com/apache/cordova-cli/blob/master/src/metadata/ios_parser.js#L32
[2]:
https://github.com/apac
Based on CLI Design [1]
The CLI should not hold the code to check requirements (i.e.
src/metadata/android_parser.js)
The CLI instead should delegate to platform by calling
(platform/android/cordova/check_reqs)
Today there is duplicate of code not in sync for Android and iOS (other
platforms dele
I don't know how this value got updated in the past, it should presumably
be set to target the latest version of Android.
+1 for bumping it to 19.
Braden
On Tue, Nov 5, 2013 at 4:19 PM, Gorkem Ercan wrote:
> Hello,
> Does anyone recall the reason for CLI to having "android-17" as a hard
> tar
I don't use the CLI, but I think that this is clearly a terrible idea,
especially since it may cause a broken "Quirks Mode" version of
Chrome WebView on Android 4.4. :(
On Tue, Nov 5, 2013 at 1:19 PM, Gorkem Ercan wrote:
> Hello,
> Does anyone recall the reason for CLI to having "android-17" as
Hello,
Does anyone recall the reason for CLI to having "android-17" as a hard
target dependency.
--
Gorkem
26 matches
Mail list logo
