I'm back from ApacheCon and vacation. Very glad to see some enthusiasm about this! My thoughts about the next steps turned out to be rather lengthy so here is a doc: https://docs.google.com/document/d/1jxQvygBtTeCYhxMtHLD9jgKTKZofMJdux1UIzsdd5b0
The most important next steps are: - Take one platform and try combine the logic from cordova/metadata and plugman/platforms for it. This will help figure out some details. - Improve plugin (un)install logic in PlatformProject so that the CLI can be eventually implemented in terms of PlatformProject. Comments and discussion will be greatly appreciated! On Wed, Apr 15, 2015 at 1:52 PM, Michal Mocny <mmo...@chromium.org> wrote: > Great enthusiasm! > > Mark is currently at ApacheCon and then taking a few vacation days, so I'm > not sure if he will answer this quickly. Figured I'd chime in for now. > > I think that exactly as you say, the PlatformProject work was started by > Mark as a way to separate the divide between platforms and lib. This > experiment I think came out of discussions on how best to move out the > platform parsers (search ML for "Move platform parsers from CLI to > platforms" started by Steven Gill). > > I also emphasize earlier points that these are experiments and are totally > open for re-design. I don't have concrete steps to propose for going > forward, but sounds like you already have some good ideas. > > Another topic that came out of discussion at Hangout was to create a > cleaner cordova-lib-core, still leaving it within the cordova-lib repo. > High-level strawman suggests this core would not do various input parsing > or make any assumptions about project directory structure, but would have a > very strict and simple interface, which various higher levels use to do > with it what they will. > > -Michal > > On Wed, Apr 15, 2015 at 12:33 PM, Rob Paveza <rob.pav...@microsoft.com> > wrote: > > > 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 > > >
