LGTM. There might be some reason we can't use identical flows for OSX and
iOS, but there's no point in having duplicate branches to the code if
they're the same right now. They can be split later if they diverge.
Braden
On Fri, Apr 25, 2014 at 7:17 PM, Jesse purplecabb...@gmail.com wrote:
I
to
releasing
off
of master seems like it would work fine. It's been working
fine
for
CLI/plugman, and they move much faster.
On Tue, Apr 22, 2014 at 11:37 AM, Braden Shepherdson
bra...@chromium.orgwrote:
We originally needed the plugin releases to be on the
master
branch
Sorry I missed this meeting, everyone. I was down for the count last week
with an awful head cold.
The upshots from the meeting look good to me. The only part I'm not excited
about is the idea of having a whole gaggle of cordova-lib-foo npm modules.
But I can roll with that one as long as they're
We originally needed the plugin releases to be on the master branch because
there was no way to have CLI/Plugman fetch from other branches. That is no
longer the case. Further, you're correct that the registry's tarballs is
the primary source now. Even if someone does have a git dependency
I was about to suggest exactly this. I already did part of this with the
promises refactoring; we should continue it. Mixing the arg-parsing and
actual logic is no good.
Braden
On Tue, Apr 22, 2014 at 11:26 AM, Andrew Grieve agri...@chromium.orgwrote:
I think the biggest win is to do both.
Strictly speaking it may be that a plugin could actually want to not be run
until it was require()d. In practice, I suspect most plugins either want to
clobber, merge or run, all of which will require it. So I think we're okay
with this change. That seems like an odd practice by browserify, but I
To be clear, you're suggesting that we have templates in the form of
plugins? I'm not sure that's what we really want. At least, if we install
them like regular plugins then there are several values that need to be
changed, including the directory name.
Perhaps cordova template add
Cordova platforms don't map into Cordova plugins very well at all.
For npm modules, we can specify arbitrary sources, but npm has its own
ideas about where things should be installed. Do we actually want the
platforms, or at least their templates, to live in node_modules? I suppose
that's a
+1 to this concept.
I'm in to manage the tools releases, not familiar at all with the process
for the others. But I'm willing to learn enough to do it, if we're just
passing these responsibilities around.
Braden
On Thu, Mar 13, 2014 at 2:10 PM, Marcel Kinard cmarc...@gmail.com wrote:
+1, I'm
That's the plan. It's at 7pm ET, 4pm PT, which is midnight UTC.
Braden
On Tue, Mar 4, 2014 at 3:49 PM, Wargo, John john.wa...@sap.com wrote:
Right?
That seems like a failing of those GUIs. When you git rebase -i from the
command line, it opens $EDITOR with the logs of all the commits that are
being squashed, but that's intended to give you context as you rewrite them
into a single, meaningful commit message that expresses the changes.
Braden
Responses inline.
On Thu, Feb 20, 2014 at 3:43 AM, Dominique Hazael-Massieux d...@w3.orgwrote:
[resending, think my first attempt went before I finished subscribing]
Hi all,
Let me introduce myself quickly: I am part of the W3C staff, am
responsible for supervising the mobile-related work
I don't think there's been any work in this direction.
Braden
On Tue, Feb 18, 2014 at 10:47 AM, Lisa Seacat DeLuca ldel...@us.ibm.comwrote:
Back in September our group chatted about making it possible to scaffold
out a cordova plugin to ease the creation of new Cordova plugins for
I think singleTop is not recommended for typical Android apps, that want
to go opening different activities using various Intents from
notifications. For something like Cordova, avoiding that restart is ideal.
Braden
On Fri, Feb 14, 2014 at 2:08 PM, Michal Mocny mmo...@google.com wrote:
TLDR;
First, a brief point: We do *not* follow the widget spec, not anymore. We
were close, a long time ago, but we've added multiple Cordova-specific or
Phonegap-specific things and some slight tweaks to the meaning of some tags
and attributes. Since the widget spec is officially deprecated, I argue
The intention is that it allows plugins to specify that they require at
least a certain version of the native code for each platform. This would be
for things like added a new transport type to the bridge, as when we added
binary data transmission on iOS and Android a year or so ago. Any plugins
I continue to feel that the right approach to platform updates is mostly to
keep making platforms/ a build artifact, and largely plugins/ too.
I feel that the right thing for an app developer to do for updating
platforms would be to backup the entire project, empty out platforms/ and
plugins/,
For the record, the App Harness makes child apps use the cordova.js,
cordova_plugins.js, and plugins/* which are included with the App Harness,
not the ones that come with the child app. This is because it ensures
compatibility with the native code and the Javascript side, though it can
break the
/, then changed to
platform www/.. should we change it back?
I'm with Jesse that devs should not need (but can if they want) to version
control platforms/ or plugins/, and his workaround seems quite agreeable to
me.
-Michal
On Tue, Feb 4, 2014 at 11:23 AM, Braden Shepherdson
bra
I think all the inside slots are full. People are stalking the mailing list
if you have a comment.
Braden
On Wed, Jan 29, 2014 at 12:40 PM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
Video call full?
Great to see some faces,
Cheers,
Jon
-Original Message-
From: John
Unfortunately there are no such documents. I think the best references for
how the CLI works overall are my brain, and Anis' brain. Someday we should
write down an overview.
At a glance, it sounds like your bug might be caused by having a newer
cordova-android cached than 3.0.3 is expecting,
I don't know how much credit we can really claim. My intern and I just
found zip libraries for Android and iOS and wrapped them in a Cordova
plugin. They are handy when you need them, though.
Braden
On Tue, Jan 14, 2014 at 8:59 PM, Andrew Grieve agri...@chromium.org wrote:
Woohoo!
On Tue,
There was discussion some time ago about adding platform tags to the
top-level app config.xml, which could contain config-file tags to do what
you want. Having a plugin inject default values would not be supported,
though. The best you could do in that model would be printing a message at
install
.
2014/1/7 Braden Shepherdson bra...@chromium.org
I've wanted to add Cordova plugin dependencies to the app's top-level
config.xml for a long time, but it's never reached the top of my
priorities. I think with that support, we can avoid checking in
./plugins
This section would be better simply as:
return p.then(...
- Braden Shepherdson
On Jan. 7, 2014, 9:41 p.m., Mark Koudritsky wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/16701/#review31316
---
Ship it!
Ship It!
- Braden Shepherdson
On Jan. 7, 2014, 9:41
I've wanted to add Cordova plugin dependencies to the app's top-level
config.xml for a long time, but it's never reached the top of my
priorities. I think with that support, we can avoid checking in ./plugins/
and ./platforms altogether for 99% of app developers. If it doesn't solve
anyone's use
The unfortunate part is that Eclipse and Xcode are also (more or less) the
build systems for iOS and Android. You can build from CLI, and even deploy
from the CLI if the stars align and you have your ruby slippers on the
correct feet, but in practice most people are launching from IDEs. That
makes
, Braden Shepherdson bra...@chromium.org
wrote:
The unfortunate part is that Eclipse and Xcode are also (more or less)
the
build systems for iOS and Android. You can build from CLI, and even
deploy
from the CLI if the stars align and you have your ruby slippers on the
correct feet
I'd be willing to write a Git 101, if there were interest there. We're all
familiar with the basics now, but some of the more extended features
(bisecting, stashes and rebases come to mind) might be of interest.
Braden
On Thu, Dec 12, 2013 at 3:00 PM, Brian LeRoux b...@brian.io wrote:
I've
I think this has been much discussed, but I'm not aware of it actually
being implemented.
Braden
On Tue, Dec 10, 2013 at 11:14 AM, Ian Clelland iclell...@chromium.orgwrote:
Do we have a way to specify, in plugin.xml, that a plugin depends on a
given (minimum) version of another plugin?
I
Make sure these platforms get added to cordova platform ls, with
appropriate logic for where Ubuntu can be built.
Braden
On Thu, Dec 5, 2013 at 6:02 PM, Andrew Grieve agri...@chromium.org wrote:
On Thu, Dec 5, 2013 at 8:53 PM, Steven Gill stevengil...@gmail.com
wrote:
Just wanted to give
work.
There was a hge discussion at the time that we chose to default
to *
On 04/12/2013 6:03 am, Michal Mocny mmo...@chromium.org wrote:
On Tue, Dec 3, 2013 at 1:30 PM, Braden Shepherdson
bra...@chromium.org
wrote:
There are two different files here: one
, Braden Shepherdson bra...@google.com
wrote:
It's possible I'm misunderstanding something here, but the flow you
described here is exactly the one we intended when designing how
details.xml was going to work. Platforms ship both files, cli uses
defaults.xml where available, and config.xml where
There are two different files here: one is defaults.xml, which the CLI
takes as the basis for its platform config.xml. The other is the config.xml
that you get after running bin/create. In the CLI world, that second file
is immediately overwritten by one created from defaults.xml, the top-level
Our review process works by sending mail to this list, and then pinging
it after a few days go by with no action, and then pinging it again if we
still don't get to it. It's two parts diffusion of responsibility/hoping
someone else will get it, and one part the fact there's no list of
outstanding
My sufficient condition for merging this change is it doesn't break
anything that already works, which includes our XML parsing, on any
desktop OS or mobile platform, or the CLI tools, choking on those BOMs.
Can you try it out on Linux or Mac to see what happens to the CLI tools? If
not, I guess
the version
on
master?
On Thu, Nov 7, 2013 at 10:55 AM, Braden Shepherdson
bra...@chromium.org
wrote:
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
Revert them out if you like, that's the right flow for broken commits.
There's no need for a lecture on not checking in broken code - it wasn't
broken on our machines!
Braden
On Wed, Nov 27, 2013 at 1:36 PM, Steven Gill stevengil...@gmail.com wrote:
I see it is easy to fix by changing npm
/#comment56830
This is duplicating the logic in the lazy loader for checking for custom
configs and so on.
The correct flow is:
lazy_load.based_on_config(project_root, 'android').then(function(lib_path) {
// shell out to lib_path/bin/check_reqs
});
- Braden
Hang on a second:
The release you send to the plugman registry doesn't care about git. You
point it at a (sub)directory and it uploads the plugin. The version is set
by the plugin.xml of that plugin.
If we want tags for when those plugins were pushed to npm, what's wrong
with tags like
week and a test
for it will be much better and easier in the e2e tests (got it ready
locally). So I'm starting to depend on the e2e tests.
On Thu, Nov 14, 2013 at 2:02 PM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
On Thu Nov 7 11:40 AM, Braden Shepherdson wrote:
The CLI tests
: not a discussion I think is even worth us
having AGAIN. =/
On Mon, Nov 25, 2013 at 10:32 AM, Braden Shepherdson
bra...@chromium.org
wrote:
Hang on a second:
The release you send to the plugman registry doesn't care about git.
You
point it at a (sub)directory and it uploads the plugin
Looks good to me except for the change logs. They're too spammy. I think it
would be better to remove banal things like bumping the version and fixing
the tests, leaving only relevant changes. Also there's at least one pair of
making a change and reverting it, that should probably be dropped.
these are
custom, bundled frameworks, there will never be any overlap. If so, then it's
fine.
- Braden Shepherdson
On Nov. 21, 2013, 3:26 a.m., Anis Kadri wrote:
---
This is an automatically generated e-mail. To reply, visit:
https
Reviewboard was giving Mark problems last week, too. Pull requests are more
convenient with the exception that they send emails on every comment,
rather than buffering them until you submit the review. One of the Github's
oldest outstanding requests, etc. etc.
Braden
On Wed, Nov 20, 2013 at
Whoops, I also meant to say, those LGTM, especially the first one. Much
more detailed docs for CLI are very welcome.
Braden
On Wed, Nov 20, 2013 at 1:20 PM, Braden Shepherdson bra...@chromium.orgwrote:
Reviewboard was giving Mark problems last week, too. Pull requests are
more convenient
...@chromium.org wrote:
On Fri, Nov 15, 2013 at 4:25 PM, Jonathan Bond-Caron
jbo...@gdesolutions.com wrote:
On Fri Nov 15 11:29 AM, Braden Shepherdson wrote:
I propose three things:
1. Punt all discussion of overhauling configuration files to the new
year.
2. Drop my proposals above
:
andor?
On Thu, Nov 14, 2013 at 11:44 AM, Braden Shepherdson
bra...@chromium.org (mailto:bra...@chromium.org)wrote:
I think the AND logic was chosen because you can specify engine
name=cordova-android version==3.2.0 / or similar, in order to
require
sufficiently new versions
config.xml which is a path to making platforms
true build artifacts.
- Have the ability install all plugins all at once (ala npm install).
Good points. generating a source file == bad idea.
On Thu, Nov 14, 2013 at 12:31 PM, Braden Shepherdson
bra...@chromium.org wrote
service js name - service native
name/class
On 11/13/13 2:36 PM, Brian LeRoux b...@brian.io wrote:
what are we using feature for?
On Wed, Nov 13, 2013 at 2:27 PM, Braden Shepherdson
bra...@google.comwrote:
My concern with (ab)using feature tags
Generally speaking, adding new dependencies is fine, so long as they aren't
too extensive. A markdown parser and friendlier JSON parsing are probably
fine to add, since they're not going to be adding five megs and a dozen
transitive deps.
Those changes look fine to me. Do we have a use-case for
I think the AND logic was chosen because you can specify engine
name=cordova-android version==3.2.0 / or similar, in order to require
sufficiently new versions of the platforms.
I agree that only makes sense for platform engines, and makes worklight vs.
phonegap vs. cordova engines broken. I
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 mmo...@chromium.org wrote:
;)
and are just Javascript libraries. Are there current examples of
this in Cordova currently?
On Thu, Nov 14, 2013 at 8:32 AM, Braden Shepherdson
bra...@chromium.org
wrote:
I'm going to try to summarize some points so we can get on the same
page.
tl;dr: see the last two paragraphs
this problem solving I
have no idea what the actual problem is we are trying to solve. We have
lots of solutions but what precisely do our users gain from runtime
introspection here?
On Thu, Nov 14, 2013 at 10:26 AM, Braden Shepherdson
bra...@chromium.org
wrote:
Brian
Adding or makes sense to me, and we may as well throw in and at the
same time.
I think the default logic should still be AND.
Braden
On Thu, Nov 14, 2013 at 1:51 PM, Andrew Grieve agri...@chromium.org wrote:
andor?
On Thu, Nov 14, 2013 at 11:44 AM, Braden Shepherdson bra...@chromium.org
, 2013 at 10:53 AM, Braden Shepherdson
bra...@chromium.org wrote:
I apologize for getting somewhat short in my previous email.
Let me explain my comment on needing more, and more hacky, code.
Because
of how Plugman parses the config-file tags and makes the edits to the
XML
files
Brian, I think you're a bit confused about which information is in what
files. I can break that down here if people would find it valuable.
That timing works for me, Anis. I'll see you, and any other interested
parties, there and then. If you're not Anis, add +Braden Shepherdson ahead
of time
is out of sync between the published version of the platforms and the
cli.
@purplecabbage
risingj.com
On Wed, Nov 6, 2013 at 11:02 AM, Braden Shepherdson bra...@chromium.org
wrote:
There is existing special handling for blackberry10 scattered
throughout the lazy
now, just in my and Anis's heads.
Braden
On Thu, Nov 14, 2013 at 2:41 PM, Brian LeRoux b...@brian.io wrote:
http://www.youtube.com/watch?v=a1N2k0-F1pU
On Thu, Nov 14, 2013 at 9:11 AM, Braden Shepherdson bra...@chromium.org
wrote:
We have reason not to move ./plugins/*.json into .cordova
There's a bit of a BC issue here because cordova.js needs to know what file
to inject a script tag for, so it can load the file and then load its
module. That's why I hesitated to modify the format of that file,
originally. (It currently sets module.exports to an array of js-module
info.) Like
never reads or writes this file directly in the
normal flow of things.
Braden
On Thu, Nov 14, 2013 at 3:29 PM, Braden Shepherdson bra...@chromium.orgwrote:
There's a bit of a BC issue here because cordova.js needs to know what
file to inject a script tag for, so it can load the file and then load
Hey folks,
We've been kicking around the idea of getting at which plugins/versions are
installed, at runtime. In order to make that happen, I've taken the first
step of having plugman prepare insert a tag into config.xml for each
plugin. It will look like this:
plugins
plugin
My understanding is a feature tag matches a plugin (not a subset) so
why the duplication?
[1] http://www.w3.org/TR/widgets/#feature
On Wed, Nov 13, 2013 at 12:23 PM, Braden Shepherdson
bra...@chromium.org wrote:
The feature tags list only those plugins which are relevant to the
bridge
PM, Braden Shepherdson bra...@chromium.org
wrote:
The feature tags list only those plugins which are relevant to the
bridge. Also they map from exec bridge name to native code class name,
and
have no information about which plugin they're from, or that plugin's id
or
version
adobe sf just had a coffee break...
--
Gorkem
On Wed, Nov 13, 2013 at 4:27 PM, Braden Shepherdson bra...@chromium.org
wrote:
I'm open to changing the names to something else, since I realize there
used to be a plugins tag and plugin tags inside, before we used
feature.
Adding
Following up here with the note that there's a public branch called
e2e-tests with working tests for create and platform commands. These tests
are touching the real filesystem using only slightly hacked-up fixtures.
A couple of things we learned: the res/ directory in the helloworld
template is
I think people are not aware that the semantics of the serve command
changed a while ago.
The correct steps now are:
- run cordova serve, with no platform named.
- go to http://localhost:8000/android or some other platform you have
installed
- it works, you can fetch the various assets. Cordova
Actually, it's only in some provinces, like BC. Notable exceptions include
Ontario, so the Waterloo-based Google team is still around today.
Braden
On Mon, Nov 11, 2013 at 11:45 AM, purplecabbage purplecabb...@gmail.comwrote:
Today is a statutory holiday in Canada; Just in case anyone was
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15328/#review28455
---
Ship it!
Ship It!
- Braden Shepherdson
On Nov. 7, 2013, 9:59
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 gorkem.er...@gmail.com wrote:
Hello,
Does anyone recall the reason for CLI to having
Why is any development here happening outside of Cordova? Most apps are
going to depend on Cordova APIs too deeply to get all that far with the
early steps in your outline.
Braden
On Tue, Nov 5, 2013 at 4:35 PM, Jonathan Bond-Caron jbo...@gdesolutions.com
wrote:
On Mon Nov 4 11:00 AM, Josh
...I'm imagining a split file system where Cordova is perhaps FAT and the
target is anything else...
This isn't a concern. That potential problem is not unique to Cordova, and
so when Unixy systems view or copy from permission-less filesystems like
FAT, they generally set 777, or at least 7xx,
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15046/#review27917
---
Ship it!
Ship It!
- Braden Shepherdson
On Oct. 30, 2013, 4:12
The common places to fetch the plugin are over the network, from the plugin
registry or from git. Therefore the tools are expecting to download exactly
the files that are needed by the plugin, plus or minus a README or
whatever. They expect local plugins to be self-contained, in a directory by
I thought we were shelling out that command, not trying to load the file.
Then Windows would locate the version.bat file and run it, while Unixy
platforms would see the version file with +x, and run it.
Are we no longer going through the shell? (This should be using
child_process.exec, not
As long as we are still tracking mostly by the version numbers on JIRA and
so on, I'm okay with silly marketing names. Too bad these suggested schemes
don't support Fancy Pants.
I'm perfectly happy with nonsensical names; I think the AngularJS
releases[1] are hilarious. (radioactive-gargle,
plugins and it's convenient to keep examples in the same repo as the code.
On Wed, Oct 23, 2013 at 10:42 AM, Braden Shepherdson bra...@chromium.org
wrote:
The common places to fetch the plugin are over the network, from the
plugin
registry or from git. Therefore the tools are expecting
wrote:
Yes, a copy is simpler but I think that copying only the needed files
specified in plugin.xml makes a lot of sense.
Am 23.10.2013 16:42 schrieb Braden Shepherdson bra...@chromium.org:
The common places to fetch the plugin are over the network, from the
plugin
registry or from
There have been significant improvements to plugman yesterday, where I
fixed some nasty and long-standing dependency uninstallation bugs. We want
to get that out soon, so I agree with the 24th or maybe tomorrow the 23rd.
CLI is getting some much less exciting fixes today, as well. Remember that
It would be nice to have such hooks, but it only works well if everyone is
running them. If some people are not, and they break the tests, now it's
complaining at you when you try to commit. Also for people like me who
commit every other save and then squash a dozen commits into one or two,
it's
There's no restriction, we just wanted to know what tools people were
using. That means we definitely want JBoss Tools to call home and identify
itself! We want to know what fraction of the downloads are coming from
JBoss, and to have those downloads count towards the overall plugin
download
I'd be happier if it were JSON, but it's not, and the XML doesn't cause
enough pain to be worth making the switch.
Ian explained it accurately; it's mostly a historical accident that we're
using XML.
Braden
On Mon, Oct 21, 2013 at 10:09 AM, Lucas Holmquist lholm...@redhat.comwrote:
yea,
Less Magic (bin/create, Plugman) and More Magic (CLI).[1]
Mike Billau's suggestions look decent to me. How about classic instead of
legacy? Removes the it sucks and will die someday connotation, since
that's not true.
Braden
On Mon, Oct 21, 2013 at 11:25 AM, Mike Billau mike.bil...@gmail.com
Whoops, forgot my citation:
[1] http://www.catb.org/jargon/html/magic-story.html
On Mon, Oct 21, 2013 at 11:33 AM, Braden Shepherdson bra...@chromium.orgwrote:
Less Magic (bin/create, Plugman) and More Magic (CLI).[1]
Mike Billau's suggestions look decent to me. How about classic instead
Those two sound more like things the info command should be printing. Or do
you mean those should be part of plugins.Cordova.io?
On Oct 17, 2013 8:38 PM, purplecabbage purplecabb...@gmail.com wrote:
+ list platforms supported for each plugin
+ list all plugins available for a platform
Sent
Chiming in late here, but I thought Cordova-registry was a temporary repo
Anis had set up during development of the registry, but that it's now
folded into Cordova-plugman, and can be retired.
Does it hold the website?
Braden
On Oct 18, 2013 7:55 AM, David Kemp drk...@google.com wrote:
Issue
the option
stdio: 'inherit' if we're in --verbose mode, and stdio: 'ignore' when not
verbose. That avoids buffering the output altogether, which we don't really
want anyway.
- Braden Shepherdson
On Oct. 18, 2013, 4:34 a.m., Carlos Santana wrote
Merged. Please close the PR.
Braden
On Thu, Oct 17, 2013 at 2:32 AM, Maxime LUCE max...@somatic.fr wrote:
I just created an issue on JIRA associated with its pull request.
https://issues.apache.org/jira/browse/CB-5111?filter=-1
This patch optimize plugman for future platform integration
typo: porject
- Braden Shepherdson
On Oct. 16, 2013, 9:27 p.m., Mark Koudritsky wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14681
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14681/#review27125
---
Ship it!
Ship It!
- Braden Shepherdson
On Oct. 16, 2013, 9:27
We are adding CLI and Plugman master to our continuous builds. That means I
will start getting nag emails whenever they break, and I will be sending
frowny emails to the authors of those commits.
Run the tests! It's easy, just run npm test, in either repo. They only take
a couple of seconds.
They might be related to an error, they might not. Either way, they're a
bug that needs fixing because they're not supposed to be in the output.
Similarly for the handful of JSON blurbs inside the dots at the top.
Braden
On Thu, Oct 17, 2013 at 12:44 PM, Ian Clelland
cleaning up the tests yesterday
evening.
https://issues.apache.org/jira/browse/CB-5106
I am planning on spending some time today and trying to get those
failures
fixed. I also need to add some new tests.
On Thu, Oct 17, 2013 at 10:17 AM, Braden Shepherdson
bra...@chromium.orgwrote
to respond. I like Michal's first step but growing
to a
full suite of tools. Are you currently tackling this Braden? I feel
like
it
is related to the Medic stuff and maybe we should throw one of our
guys on
the problem fully.
On Sep 27, 2013 5:10 PM, Braden Shepherdson bra
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14621/#review27024
---
Ship it!
Ship It!
- Braden Shepherdson
On Oct. 12, 2013, 2:45
I've added some comments. Ping this thread when you have a CLA on file and
have made those changes, and I'll pull this change.
Braden
On Mon, Oct 7, 2013 at 10:17 AM, Dick Van den Brink
d_vandenbr...@outlook.com wrote:
Hi guys,
I noticed that only the WP7 parser fired a hook (with the
in 3.1.0 or is it targeted for 3.2.0?
On 2013-10-03 11:30, Michal Mocny wrote:
Yeah Braden we've diverged sorry, lets focus.
Big +1 for your proposal to make prepare step do what users expect.
-Michal
On Thu, Oct 3, 2013 at 10:20 AM, Braden Shepherdson bra...@chromium.org
wrote:
I agree
For now, remove and add. There are plans for a more compact upgrade command
in the future. In the meantime, there are some features planned that will
make plugin development much friendlier, so that you won't have to run
anything other than cordova prepare to get the latest plugin code.
Braden
1 - 100 of 309 matches
Mail list logo
