incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lunny <>
Subject Re: CommandLine Tooling Design
Date Tue, 10 Apr 2012 22:21:34 GMT
Thanks for writing this up Pat.

I think the best way for us to approach command-line tooling is to be
laser-focused on individual problems. For example, I worked on the
pluginstall tool to solve a very specific problem - programmatically
installing plugins into Cordova projects, which can involve touching
manifest files, modifying xcodeproj files, adding assets to www
directories, and so forth. It's not complete by any means, but it's already
been very useful for us at PG Build.

What are the biggest problems that people writing Cordova apps face? Which
of these can we solve with CLI tooling?

One of the biggest problem I've seen on the mailing list and (which has a lot of Cordova questions, not just PGB)
is getting an iOS project started - the www directory going missing, and
the weirdo ARC checkbox that makes everything break, and so forth. It might
be best to bite off a small problem like that - how do we make creating
Cordova iOS projects super easy? - rather than going after everything at


On 9 April 2012 20:21, Patrick Mueller <> wrote:

> On Mon, Apr 9, 2012 at 18:24, Paul Beusterien <
> >wrote:
> >   - Any aspirations to have "cordova deploy" and "cordova run" or would
> >   that be too hard on non-Android?
> >
> Sure.  I've been thinking more about the "build" side of the issues, but
> "run"-ish commands should be available as well, as much as possible.
> >   - It would be useful to support the concept of cordova version,
> >   including querying, updating, and validation
> >
> Right.  Ideally, the "command" (cordova) can be logically separated from
> the particular version of Cordova libraries in use.  Seems like you could -
> in theory - support multiple versions of the Cordova runtime at the same
> time; say, switch back and forth between 2.0 and 2.1, within a single
> project, or something.  But, I don't think that's terribly useful, and
> seems like a great vector for errors.  :-)
> Long term, the version of the core Cordova runtime can be separated out
> from the core plugins as well.  They can evolve and ship separately.
> Beyond that is the "W3C version" issue.  When the a W3C spec changes, we
> should really create a new implementation of the new version; I think this
> should be baked into the "fully qualified" name of the plugin,
> eg webaudio-20120315 vs webaudio-20111215 ( example from
> ) , though the 'versioned' name would
> likely
> just be used when installing the plugin - most of the time, you don't want
> to see that.
> >   - As you imply, the directory structure doesn't work in conjunction
> with
> >   the Eclipse Android Development Tools where the www directory needs to
> be
> >   part of the Android assets directory hierarchy and plugins in the src
> >   directory.
> >
> Right.  Sorry.  The directory structure won't work for ANY of the
> platforms, directly, as I've specified.  That's just where we lay down the
> source, so the tools can find it.  What I'd like to see if we can get away
> with - and realize that we might not be able to - is for us to augment the
> existing platform-specific build bits so they COPY things like the www/
> tree into the platform specific directories, if required.  The www/
> directory is just the tip of the iceberg.  As I've drawn it out, there will
> be native code in
> plugins/KewlioPlugin/platform/android/native/ (or some
> such) that will also need to be compiled.  Again, thinking - copy it before
> a build.  You have it easy with Eclipse/Android, compared to the "fun" that
> will be had with Xcode.  :-)
> --
> Patrick Mueller

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message