Or, we could just drop it... and just write a blog post on how to use a local
cordova vs the global one in projects you want to have a specific version
(i.e.: some script code example wrapper for a cordova command in
./node_modules/.bin/cordova).
0.o
- tommy
On 10/09/2013, at 1:42 PM, Micha
If we have the global cordova-cli doing the create step, we are basically
describing the earlier stated "magical" approach, and pointing out that we
could leverage npm for some of the smarts (rightly so, perhaps).
If we do this, I think it means we would have a node_modules/ alongside
platforms/ a
Also to be clear, I was advocating a cordova/cordova-cli approach similar to
grunt/grunt-cli, not actually enforcing some kind of grunt workflow on people.
However, I agree with Michal that we need to think carefully about this.
This is quite a lot of cli to create an initial app:
mkdir hellowo
What if the first step is to add to cordova-cli a startup check to see if
you have a locally installed cordova which is not the current executable?
I do agree with your Carlos that what you propose is good, but I'm
concerned about some details. For example, how do I bootstrap the process?
With g
Just to be clear I'm not proposing that we use grunt-cli/grunt to manage
the cordova versions.
What I'm proposing is to have less magic than what we have today in
cordova, and be more practical (at least from my point of view)
I think I'm bringing this forward because I'm having difficulty integ
I have been following this thread with a combination of interest and
trepidation.
Interest:
Anything that works towards ./platforms being a build artefact I am all for. In
our app, ./platforms is already a build artefact. We used hooks to achieve this
(updating config files, copying icon / spl
Reviving this thread for 3.1
One thing that is not part of [1] is publishing all plugins and
updating versions to our registry.
Could coho automate this process as well ?
Basically we need to run "plugman publish cordova-plugin-*" after
updating each plugin version.
[1] http://wiki.apache.org/c
Hey,
got pulled off on some other stuff:
Lets make sure you are not running an old copy of ripple:
> cordova create Baz
> cordova platform add android
> cordova prepare
> cd incubator-ripple
> jake
> ./bin/ripple emulate --path ../Baz/platforms/android/assets/www/
Ensure that you have cordova 3
Hey John, unless we find more than Jesse to help I doubt we could graduate
Windows as a full fledged platform. I'll let Jesse extrapolate what that
would mean.
On Fri, Sep 6, 2013 at 5:46 AM, Wargo, John wrote:
> Can someone fill me in on what the plans are for Windows? In 2.9, there
> was sup
Hey Gord - just checking in. If you've been too busy to return to this -
sorry - but if you missed my messages - let me know.
On 9/3/13 12:30 PM, "Gord Tanner" wrote:
>You will need to run:
>
>ripple emulate --path /path/to/cordova/project/platform/android/assets/www
>
>Let me know if that works
I should certainly be able to. I'm digging into a major refactoring of
Plugman right now, though, so I'll probably want to finish that. If it's
taking too long, though, then I'll switch gears and get this in before we
cut 3.1.
Braden
On Mon, Sep 9, 2013 at 11:48 AM, Michal Mocny wrote:
> Brade
+1 for the more straight forward easy win of the grunt/grunt-cli model.
I see the benefits of Michal's suggestion, but I agree that our efforts are
best spent elsewhere.
Let users take control of versions as with other npm modules/frameworks/libs.
Just set the cordova version in package.json. W
Last year I would've advocated we put our energy into something more
magical like grunt/grunt-cli as Michal describes. Nowadays I'm thinking we
focus on writing libs and let other ppl figure out glue w/ their Grunt. (Or
write the magical way but based on lower level smarter libs.)
On Mon, Sep 9,
What does the community think of installing cordova only locally and not
globally?
# Installing Cordova locally will provide:
- A way to use different versions of cordova on the same system/os.
- A way to specify cordova as a dependency in package.json for an App
project
- A way to sandbox cordov
I think either is fine. Note that as of last week, it is fine to use
url#branch:subdir in dependency url values.
On Mon, Sep 9, 2013 at 1:06 PM, Anis KADRI wrote:
> I don't mind that but I think we should start relying on our registry
> from now on. It's so much simpler to specify a name and a
I don't mind that but I think we should start relying on our registry
from now on. It's so much simpler to specify a name and a version than
a long url, branch and subpath. I will write tests for this specific
case this week.
On Mon, Sep 9, 2013 at 9:05 AM, Jeffrey Heifetz wrote:
> So it seems I
Aside from moving some files around and changing the order of operations a
bit, the biggest change will be adding support for and
to app.xml. By the way, thats still called config.xml, do we
want to rename it to app.xml for 3.1?
On Mon, Sep 9, 2013 at 12:47 PM, Braden Shepherdson wrote:
> I s
I should add that one benefit of what I outlined above is that you only
need to worry about installing cordova-cli once, and it could then
manage/download the various versions of itself.
The downside is that we would have to write those smarts, instead of just
leveraging npm and forcing the user t
Generally, I like it. We've discussed a somewhat variant in the past, and
I'm not sure which is better:
Instead of installing locally every time a la grunt, we discussed having a
single install base for the different cordova versions (i.e. inside
~/.cordova), and then cordova-cli is a short scrip
Braden, are you going to be able to take this on this week? I think it
would make the upgrade from 3.0 much easier.
-Michal
On Mon, Sep 9, 2013 at 9:48 AM, Michal Mocny wrote:
> If you would use a different helloworld app template (which is now
> possible to specify in both CLI and old workfl
So it seems I killed all discussion here, but before I did that I feel we
reached a consensus that relative dependencies are something we'd like to
support. The final decision to make is how we would like to do so.
Current Implementation . When url = "."
then the dependency is treated as living in
Sounds good
On Sep 9, 2013 7:50 AM, "Andrew Grieve" wrote:
> I think it's time to get the ball rolling on this. It'll be the first
> release post-3.0, so will likely have a few bumps to work through.
>
> How about:
>
> Friday 13th - Create release branches & tag RC of all repos
> Monday 16th - Dr
I think it's time to get the ball rolling on this. It'll be the first
release post-3.0, so will likely have a few bumps to work through.
How about:
Friday 13th - Create release branches & tag RC of all repos
Monday 16th - Draft Release Blog Post (digest of changelogs)
Thurs 19th - Tag 3.1.0 for a
Andrew, thanks for kicking it off. Also should note inclusion of iOS 7 support.
-James Jong
On Sep 9, 2013, at 10:42 AM, Andrew Grieve wrote:
> I think it's time to get the ball rolling on this. It'll be the first
> release post-3.0, so will likely have a few bumps to work through.
>
> How abo
If you would use a different helloworld app template (which is now possible
to specify in both CLI and old workflow), then the pre-generatred platform
config.xml template would likely be the wrong one, and thus this bundling
for self documentation would be a disservice.
I don't see very much value
On Mon, Sep 9, 2013 at 8:45 AM, Braden Shepherdson wrote:
> The defaults.xml is only part of the CLI workflow, yes. It has no relevance
> if you're not using CLI. BUT there is a complete config.xml in the
> bin/create template, and it can of course have the same values as you would
> get from an u
The defaults.xml is only part of the CLI workflow, yes. It has no relevance
if you're not using CLI. BUT there is a complete config.xml in the
bin/create template, and it can of course have the same values as you would
get from an unchanged CLI project (defaults.xml + app.xml). The
configuration va
On Sat, Sep 7, 2013 at 1:01 PM, Michal Mocny wrote:
> why are we just hearing about this?!
>
>
This! Definitely mixing :D with D: because this has been around for a while
and we've been struggling along without it.
Braden
>
> On Fri, Sep 6, 2013 at 9:03 PM, Andrew Grieve
> wrote:
>
> > heh,
Don,
Thanks, I'll try this as well.
On 9/8/2013 8:26 PM, Don Coleman wrote:
Plugman needs to clone the project, I'm not sure if you can clone a
directory.
I create a git project for each of my plugins e.g.
https://github.com/don/BluetoothSerial.git
On Sun, Sep 8, 2013 at 8:16 PM, Andrew Grie
Andrew,
Thank you, I'll try that.
On 9/8/2013 8:16 PM, Andrew Grieve wrote:
You didn't use the correct URL. Try:
https://github.com/johnwargo/cordova-programming-code.git#master:plugins/carrier
On Sun, Sep 8, 2013 at 1:33 PM, John Wargo wrote:
Is there anything special about distributing
30 matches
Mail list logo
