This is a cool project. I'm curious, how much work do you think it'd be to refactor the cordova CLI to interact with the projects via the PlatformProject interface? We've been talking about how we could pull some of the cordova-lib platform-specific dependencies out and put them into the platforms (one example that comes to mind is having platform-specific parameters on plugin), so that platform-specific code lives in the platform implementation rather than cordova-lib. Having each platform derive from PlatformProject seems like an excellent first step, since (at least between -lib and -windows) once -lib hands off the project to the platform code, it's just go time.
What do you think the next steps are in terms of your API shape and plans? Where do you see needing help most, where can I pitch in to get your project going more? -----Original Message----- From: Mark Koudritsky [mailto:kam...@google.com] Sent: Friday, April 10, 2015 12:50 PM To: dev@cordova.apache.org Subject: Experimenting with API for cordova tooling From today's hangout discussion, here are the links to our experiments with using cordova tooling via API rather than CLI. It is loosely based on my older experiments here https://github.com/kamrik/CordovaGulpTemplate But his time there is a separate wrapper that exposes a more object oriented API and reaches deeper into cordova-lib. It introduces a central object called PlatformProject that represents a single platform. The wrapper is here: https://github.com/kamrik/CordovaPlatformProject Please consider it experimental and feel free to fork and play with it. A demo app that uses this wrapper https://github.com/kamrik/cordova-api-example The ServiceWorker-to-Cordova script that uses the same wrapper https://github.com/MobileChromeApps/sw2cdv I'll also be giving a presentation about this at ApacheCon next week, draft slides are here http://kamrik.org/PlatformProjectSlides
