you are right. The variable stuff is not working as I expected. Sorry for
the confusion.
I made another error because I thought that resource-file was already
available but it is not.
I thought that
plugin ...
platform name=android
resource-file src=glass.xml dest=xml/glass.xml /
In your glass.xml example would you then advice a developer to edit
plugins/res/xml/glass.xml? I don't fully understand how plugman is going to
work with this setup. Would glass.xml be copied to
platforms/android/res/xml/glass every time you did a build? I am assuming
it will only be appended when
What cordova.json has that config.xml doesn't, is that you can set the
location of platforms with it through:
{
id:org.apache.mobilespec,
name:mobilespec,
lib: {
android: {
uri: /Users/agrieve/git/cordova/cordova-android,
version: dev,
id: cordova-android-dev
},
Going to try and do this today :)
On Fri, Dec 20, 2013 at 1:33 PM, Ian Clelland iclell...@chromium.orgwrote:
That sounds reasonable. There isn't a huge rush on it.
On Fri, Dec 20, 2013 at 10:54 AM, Andrew Grieve agri...@chromium.org
wrote:
Well, I didn't do this yesterday and don't want
Did this make it to jira? I also think its a good idea to pull config.xml
out of the www root. Anyway to track this one?
On Mon, Dec 30, 2013 at 1:51 PM, Dick Van den Brink
d_vandenbr...@outlook.com wrote:
I think it is a a good idea! So a +1
Sent from my Windows Phone
I'll make a JIRA issue on Tuesday and paste the link to it here.
On Thu, Jan 2, 2014 at 10:32 AM, Ross Gerbasi rgerb...@gmail.com wrote:
Did this make it to jira? I also think its a good idea to pull config.xml
out of the www root. Anyway to track this one?
On Mon, Dec 30, 2013 at 1:51 PM,
Are the platform locations set by Cordova CLI already? I know phonegap does
it and I actually wish to add it to Cordova CLI as well [1] but I thought
it was not implemented on CLI.
[1] https://issues.apache.org/jira/browse/CB-5218
In any case, engine info can go into cordova.xml.
--
Gorkem
On
currently, it's never written, but it is read when you do a platform add
On Thu, Jan 2, 2014 at 12:12 PM, Gorkem Ercan gorkem.er...@gmail.comwrote:
Are the platform locations set by Cordova CLI already? I know phonegap does
it and I actually wish to add it to Cordova CLI as well [1] but I
On Thu, Jan 2, 2014 at 10:22 AM, Andrew Grieve agri...@chromium.org wrote:
What cordova.json has that config.xml doesn't, is that you can set the
location of platforms with it through:
That said, I like your idea of having one top-level config file instead of
two. I don't see why we
Hi,
I created an issue in JIRA:
https://issues.apache.org/jira/browse/CB-5720
Description
Add support for resource-file src=glass.xml target=xml/glass.xml / to
a plugin's plugin.xml
The above example would copy the file glass.xml from the plugin's directory
to the
Would like someone to proof read and give me the +1 before I post:
---
layout: post
author:
name: Andrew Grieve
url: https://twitter.com/GrieveAndrew
title: Plugins Release: Jan 2, 2014
categories: news
tags: release
---
The following plugins were updated today:
*
Would like to amend this since Marcel I have discovered it's a lie.
Please review (added the update line)
Android KitKat brings a [massive update](
https://developers.google.com/chrome/mobile/docs/webview/overview)
to the system WebView. This is terrific news for Cordova developers, as
Andrew Grieve wrote:
With this release, documentation for plugins have moved from
[http://cordova.apache.org/docs](http://cordova.apache.org/docs) to the
`doc/` directory
within plugins themselves. Eventually, docs will be available online
through
[plugins.cordova.io](http://plugins.cordova.io).
Hmm, good point about absolute paths.
I think if you're using an override there though, that you could set it to
a relative path for shared projects. Same thing with plugin search paths.
I think it'll be confusing to have a cordova.xml as well as a
cordova.json file right in the root.
WDYT?
Andrew Grieve wrote:
`org.apache.cordova.dialogs`
* Move images from css to img
Probably:
* Move images from css/ to img/
-
This transmission (including any attachments) may contain confidential
information, privileged
Andrew Grieve wrote:
`org.apache.cordova.geolocation`
* Removing incorrectly added closing comments for wp7 platform in
plugin.xml
Probably:
* Removing incorrectly added closing comments for wp7 platform in
`plugin.xml`
-
This
Andrew Grieve wrote:
* [CB-5569](https://issues.apache.org/jira/browse/CB-5569) Windows8.
MediaFile constructor does not exist
Probably:
* [CB-5569](https://issues.apache.org/jira/browse/CB-5569) windows8:
MediaFile constructor does not exist
(to match earlierŠ)
Looking at the plugin spec:
http://cordova.apache.org/docs/en/3.3.0/plugin_ref_spec.md.html#Plugin%20Specification
I think this sounds great! Certainly the section in there could use some
elaboration, but I think I'd expect the tag to work as you've implemented
it.
If no one objects, I'll pull
Why is this needed? You can use source file to copy resources. This
just adds XML for the sake of adding more XML.
On Thu, Jan 2, 2014 at 10:36 AM, Andrew Grieve agri...@chromium.org wrote:
Looking at the plugin spec:
Thanks Josh. Here's an updated version:
---
layout: post
author:
name: Andrew Grieve
url: https://twitter.com/GrieveAndrew
title: Plugins Release: Jan 2, 2014
categories: news
tags: release
---
The following plugins were updated today:
* org.apache.cordova.battery-status@0.2.6
*
I thought about source-file as well, but given that resource-file is
already implemented on other platforms, I think it would make sense to have
it for Android.
Another thought is that it's more semantically correct.
E.g. We might at some point make target-dir optional for android (it's
optional
ios does something more than just copy files.
ubuntu copies the src to a subdirectory named qml.
source-file could be used on Android for my purposes. The major difference
is that my implementation of resouce-file uses a target file instead of
target-dir which would allow to rename the src.
I
I think what I will describe here is more that what CLI provides today.
An engine/lib has a version, id and a uri. On most cases, you only care about
the
id and uri and assume that the tools that you work with already knows how to
resolve the id and version to a location. In the case of CLI
Andrew Grieve wrote:
With this release, documentation for plugins have moved from
[http://cordova.apache.org/docs](http://cordova.apache.org/docs) to the
`doc/` directory
* Move images from css/ to img/
Probably `` these to match earlier style
`org.apache.cordova.media`
* Adding
Considering http://wiki.apache.org/cordova/ConfigurationFiles I'm not sure
we want more config either.
Perhaps we need to think more comprehensively rather than proposing more
abstractions.
On Thu, Jan 2, 2014 at 11:15 AM, Gorkem Ercan gorkem.er...@gmail.comwrote:
I think what I will
Reducing the number of configuration files is actually the goal here.
The abstraction is not a new one. It already exists and it is part of the
$PROJECT/.cordova/config.json.
I am suggesting to move it to $HOME/.cordova/config.json so that we no longer
need the
$PROJECT/.cordova/config.json
I really like being able to set the source location on a per-project basis,
but maybe we should just change it to a command-line flag instead of a
config.json setting?
e.g.
cordova platform add android --source=my/dev/version/cordova-android
On Thu, Jan 2, 2014 at 3:31 PM, Gorkem Ercan
I understood and read it too Gorkem.
I was (poorly) suggesting we look at the issue of configuration in a
complete view. Due to backwards compatibility we will be adding a new file
and the code to support the old file will be around a while.
We can probably roll a whole lot more into a single
... but not marked as such.
-Axel
Thanks, I've marked it as fixed and given you JIRA permissions to do so in
the future.
On Thu, Jan 2, 2014 at 4:38 PM, Axel Nennker ignisvul...@gmail.com wrote:
... but not marked as such.
-Axel
We've had a bunch of users confused by Xcode and Eclipse showing only the
output www/ and not the www/ that they are supposed to edit.
There's bugs tracking addressing this for:
iOS: https://issues.apache.org/jira/browse/CB-5397
Android: https://issues.apache.org/jira/browse/CB-5715
I've now
idk, if ppl want to use the cli I would reccomend using a text editor and
our build chain
if they want to use IDE's then they should not use the cli and just use the
project scripts
(at least, this was the intent of the design as I originally saw it)
not sure I see much benefit to making the
I'm with you, Brian... CLI for CLI, project scripts for IDEs. Anything else
will just lead to madness..
On 03/01/2014 12:21 pm, Brian LeRoux b...@brian.io wrote:
idk, if ppl want to use the cli I would reccomend using a text editor and
our build chain
if they want to use IDE's then they
33 matches
Mail list logo
