Added jbondc to https://wiki.apache.org/cordova/ContributorsGroup. You
should have wiki edit access now.
On Fri, Nov 15, 2013 at 11:10 AM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:
> On Fri Nov 15 09:28 AM, Josh Soref wrote:
> > Jonathan wrote:
> > > You should add:
> >
> > I'll add
On Fri Nov 15 09:28 AM, Josh Soref wrote:
> Jonathan wrote:
> > You should add:
>
> I'll add it to the wiki if no one beats me to it.
>
> Please feel free to edit this page or any other. If you don't have the wiki
> edit bit,
> just send an email here with your account name and someone will give
On Fri, Nov 15, 2013 at 9:28 AM, Josh Soref wrote:
> Jonathan wrote:
> > You should add:
>
> I'll add it to the wiki if no one beats me to it.
>
> Please feel free to edit this page or any other. If you don't have the
> wiki edit bit, just send an email here with your account name and someone
> w
Jonathan wrote:
> You should add:
I'll add it to the wiki if no one beats me to it.
Please feel free to edit this page or any other. If you don't have the wiki
edit bit, just send an email here with your account name and someone will give
you the bit.
> Another use case to consider for more
Josh, indeed, thanks for all the improvements you've been making to the wiki.
It helps all of us.
On Nov 15, 2013, at 7:59 AM, Jonathan Bond-Caron
wrote:
> On Thu Nov 14 06:12 PM, Josh Soref wrote:
>> I've converted that into a wiki page:
>> https://wiki.apache.org/cordova/ConfigurationFiles
>
On Thu, Nov 14, 2013 at 9:33 PM, Michal Mocny wrote:
> plugin.xml is where *plugin authors* define metadata. A user shouldn't be
> looking there at all, unless for curiosity, and certainly not making edits
> unless they are taking over the role of plugin author.
>
> And plugin.xml's are only use
On Thu Nov 14 06:12 PM, Josh Soref wrote:
> I've converted that into a wiki page:
> https://wiki.apache.org/cordova/ConfigurationFiles
> -
Awesome, thanks for this. You should add:
$PROJECT/platforms//www/cordova_plugins.js
- Me
Yep, of course its the plugin author to define it!
But I guess maybe I'm confusing the mapping you are asking about, so lets
make sure: plugin.xml is the file that specifies the feature tag, which
maps a name (just an arbitrary js-string) to native class name. I assumed
thats what you meant by "
So would a plugin author not be the one to define a mapping? Seems
gratuitous for a userland feature.
On Nov 14, 2013 6:41 PM, "Michal Mocny" wrote:
> plugin.xml is where *plugin authors* define metadata. A user shouldn't be
> looking there at all, unless for curiosity, and certainly not making
plugin.xml is where *plugin authors* define metadata. A user shouldn't be
looking there at all, unless for curiosity, and certainly not making edits
unless they are taking over the role of plugin author.
And plugin.xml's are only used for plugin install & cli prepare. They are
not available to t
I've converted that into a wiki page:
https://wiki.apache.org/cordova/ConfigurationFiles
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by t
That is something alright.
So, plugin.xml is where we define metadata as it relates to plugin. Would
mapping the JS class to the native class not make more sense in there? I
see no reason why a user would do that. Seems to me a user would definitely
be interested in plugin ID and VERSION however.
Great summary, thank you.
On Thu, Nov 14, 2013 at 3:19 PM, Braden Shepherdson wrote:
> As requested elsewhere, a summary of the various configuration and metadata
> files in Cordova. I'm speaking here of a complete CLI project, but I'll
> note which bits are CLI-only, and which apply to Plugman-
As requested elsewhere, a summary of the various configuration and metadata
files in Cordova. I'm speaking here of a complete CLI project, but I'll
note which bits are CLI-only, and which apply to Plugman-only projects as
well.
First, the XML files:
$PROJECT/www/config.xml
- Top-level configurati
http://www.youtube.com/watch?v=a1N2k0-F1pU
On Thu, Nov 14, 2013 at 9:11 AM, Braden Shepherdson wrote:
> We have reason not to move ./plugins/*.json into .cordova/config.json is
> that the latter file doesn't exist unless you're using CLI, whereas Plugman
> needs and maintains the ./plugins/*.jso
We have reason not to move ./plugins/*.json into .cordova/config.json is
that the latter file doesn't exist unless you're using CLI, whereas Plugman
needs and maintains the ./plugins/*.json files.
Braden
On Thu, Nov 14, 2013 at 9:19 AM, Michal Mocny wrote:
> ;) http://xkcd.com/927/
>
> Some mo
;) http://xkcd.com/927/
Some more data:
- I've heard discussed before that ./plugins/*.json should be moved in to
.cordova/config.json, it just hasn't happened yet.
- The config.xml thats inside your app we've suggested be renamed to
app.xml for less confusion with the final platform config.xml.
Ok. Ya, obviously this is not ideal. I want to get a map of the road before
we try and throw a highway in. Or another config file.
On Wed, Nov 13, 2013 at 6:40 PM, Michal Mocny wrote:
> - platforms/'s have defaults.xml and the final config.xml
> - ~/.cordova/...
> - ~/.plugman/config
>
> Welcom
- platforms/'s have defaults.xml and the final config.xml
- ~/.cordova/...
- ~/.plugman/config
Welcome to our world.
On Wed, Nov 13, 2013 at 5:45 PM, Steven Gill wrote:
> each plugin has plugin.xml.
>
>
> On Wed, Nov 13, 2013 at 2:36 PM, Brian LeRoux wrote:
>
> > So we currently have:
> >
> >
each plugin has plugin.xml.
On Wed, Nov 13, 2013 at 2:36 PM, Brian LeRoux wrote:
> So we currently have:
>
> - config.xml
> - .cordova/config.json
> - ./plugins/[PLATFORM].json
>
> Am I missing anything?
>
20 matches
Mail list logo
