You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Mark Koudritsky <ka...@google.com> on 2015/04/10 21:50:22 UTC
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
RE: Experimenting with API for cordova tooling
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
The PRs had been closed, because we've decided to revisit API to make it more solid, before it can be moved to master. The proposal has been moved to cordova-discuss repo, to be easier to review/comment.
Link to proposal: https://github.com/cordova/cordova-discuss/pull/9
---------------
Best regards, Vladimir
-----Original Message-----
From: Vladimir Kotikov (Akvelon) [mailto:v-vlkoti@microsoft.com]
Sent: Thursday, 4 June, 2015 22:30
To: dev@cordova.apache.org
Subject: RE: Experimenting with API for cordova tooling
Hello again :)
I wanted to bring your attention to this thread again.
I've opened a new PR updated according to Mark's feedback and will be very grateful if someone can review this again before merging.
There is also the implementation for Android platform which uses this new API provides own implementation for all PlatformAPI methods.
Links to PRs:
https://github.com/apache/cordova-lib/pull/235
https://github.com/apache/cordova-android/pull/179
---------------
Best regards, Vladimir
-----Original Message-----
From: Vladimir Kotikov (Akvelon) [mailto:v-vlkoti@microsoft.com]
Sent: Monday, May 25, 2015 7:31 PM
To: dev@cordova.apache.org
Subject: RE: Experimenting with API for cordova tooling
Hey, guys.
I would like to raise this thread again. I've done implementing a draft for Platform API interface, integrated directly into cordova-lib, that allows to use platform functionality as a node modules.
The PRs for this is:
Cordova-lib: https://github.com/apache/cordova-lib/pull/226
Cordova-windows (sample platform's implementation): https://github.com/apache/cordova-windows/pull/84
Here is brief details of implementation:
There is PlatformApi (former PlatformProject) class -- acts as entry point for platform-related functionality. It exposes:
a) methods that represent platform's actions, like 'build', 'run', etc. Base implementations of these methods acts as a wrappers around platform executable scripts, but each platform can provide its own implementation by defining Api.js module with same prototype methods, which will override methods of base implementation. Current draft contains wrappers for `build` and `requirements` commands.
b) PlatformHandler instance, accessible via both `getPlatformHandler()` method and `parser` property (left for backward compatibility). The PlatformHandler class is intended to be a container for platform-specific implementations for `prepare` logic. The approach here is the same as with PlatformApi class - the platform can override default implementation (currently it's being taken from cordova\metadata\<platform>_parser.js file) with custom one through providing own PlatformApi.PlatformHandler class.
c) PluginHandler instance - for plugin manipulation related functionality. Approach is the same as for PlatformHandler.
Since this implementation provides a fallback alternatives for all new functionality, it will allow to us to seamlessly move all platform-related functionality to platforms.
IMO this could be done in three steps:
1. Copy platform actions (build, run, etc. ) to platforms. (See windows PR for sample - https://github.com/MSOpenTech/cordova-windows/blob/unified_platform_api/template/cordova/Api.js ) 2. Copy `prepare`- and plugin-related logic to platforms, leave existing code for compatibility with old platforms.
3. Completely remove platform-related functionality from lib. This will break compatibility with old platforms, so we'll need to wait for some time before doing this.
Would love to hear any feedback and thoughts on this.
---------------
Best regards, Vladimir
-----Original Message-----
From: Mark Koudritsky [mailto:kamrik@google.com]
Sent: Saturday, 25 April, 2015 6:14
To: dev@cordova.apache.org
Subject: Re: Experimenting with API for cordova tooling
I like the idea of cordova-discuss, lets give it a try )
To read the md file formatted:
https://github.com/kamrik/cordova-discuss/blob/master/proposals/PlatformProject.md
To comment, look at the pull request
https://github.com/cordova/cordova-discuss/pull/4
On Fri, Apr 24, 2015 at 10:16 PM, Parashuram N (MS OPEN TECH) < panarasi@microsoft.com> wrote:
> Should we move this docs to cordova-discuss instead
> -https://github.com/cordova/cordova-discuss ?
>
> On 4/24/15, 4:02 PM, "Mark Koudritsky" <ka...@google.com> wrote:
>
> >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/1jxQvygBtTeCYhxMtHLD9jgKTKZofMJdux1
> UIzs
> >dd5b0
> >
> >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 <mm...@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
> >> <Ro...@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:kamrik@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
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: Experimenting with API for cordova tooling
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
Hello again :)
I wanted to bring your attention to this thread again.
I've opened a new PR updated according to Mark's feedback and will be very grateful if someone can review this again before merging.
There is also the implementation for Android platform which uses this new API provides own implementation for all PlatformAPI methods.
Links to PRs:
https://github.com/apache/cordova-lib/pull/235
https://github.com/apache/cordova-android/pull/179
---------------
Best regards, Vladimir
-----Original Message-----
From: Vladimir Kotikov (Akvelon) [mailto:v-vlkoti@microsoft.com]
Sent: Monday, May 25, 2015 7:31 PM
To: dev@cordova.apache.org
Subject: RE: Experimenting with API for cordova tooling
Hey, guys.
I would like to raise this thread again. I've done implementing a draft for Platform API interface, integrated directly into cordova-lib, that allows to use platform functionality as a node modules.
The PRs for this is:
Cordova-lib: https://github.com/apache/cordova-lib/pull/226
Cordova-windows (sample platform's implementation): https://github.com/apache/cordova-windows/pull/84
Here is brief details of implementation:
There is PlatformApi (former PlatformProject) class -- acts as entry point for platform-related functionality. It exposes:
a) methods that represent platform's actions, like 'build', 'run', etc. Base implementations of these methods acts as a wrappers around platform executable scripts, but each platform can provide its own implementation by defining Api.js module with same prototype methods, which will override methods of base implementation. Current draft contains wrappers for `build` and `requirements` commands.
b) PlatformHandler instance, accessible via both `getPlatformHandler()` method and `parser` property (left for backward compatibility). The PlatformHandler class is intended to be a container for platform-specific implementations for `prepare` logic. The approach here is the same as with PlatformApi class - the platform can override default implementation (currently it's being taken from cordova\metadata\<platform>_parser.js file) with custom one through providing own PlatformApi.PlatformHandler class.
c) PluginHandler instance - for plugin manipulation related functionality. Approach is the same as for PlatformHandler.
Since this implementation provides a fallback alternatives for all new functionality, it will allow to us to seamlessly move all platform-related functionality to platforms.
IMO this could be done in three steps:
1. Copy platform actions (build, run, etc. ) to platforms. (See windows PR for sample - https://github.com/MSOpenTech/cordova-windows/blob/unified_platform_api/template/cordova/Api.js ) 2. Copy `prepare`- and plugin-related logic to platforms, leave existing code for compatibility with old platforms.
3. Completely remove platform-related functionality from lib. This will break compatibility with old platforms, so we'll need to wait for some time before doing this.
Would love to hear any feedback and thoughts on this.
---------------
Best regards, Vladimir
-----Original Message-----
From: Mark Koudritsky [mailto:kamrik@google.com]
Sent: Saturday, 25 April, 2015 6:14
To: dev@cordova.apache.org
Subject: Re: Experimenting with API for cordova tooling
I like the idea of cordova-discuss, lets give it a try )
To read the md file formatted:
https://github.com/kamrik/cordova-discuss/blob/master/proposals/PlatformProject.md
To comment, look at the pull request
https://github.com/cordova/cordova-discuss/pull/4
On Fri, Apr 24, 2015 at 10:16 PM, Parashuram N (MS OPEN TECH) < panarasi@microsoft.com> wrote:
> Should we move this docs to cordova-discuss instead
> -https://github.com/cordova/cordova-discuss ?
>
> On 4/24/15, 4:02 PM, "Mark Koudritsky" <ka...@google.com> wrote:
>
> >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/1jxQvygBtTeCYhxMtHLD9jgKTKZofMJdux1
> UIzs
> >dd5b0
> >
> >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 <mm...@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
> >> <Ro...@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:kamrik@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
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
RE: Experimenting with API for cordova tooling
Posted by "Vladimir Kotikov (Akvelon)" <v-...@microsoft.com>.
Hey, guys.
I would like to raise this thread again. I've done implementing a draft for Platform API interface, integrated directly into cordova-lib, that allows to use platform functionality as a node modules.
The PRs for this is:
Cordova-lib: https://github.com/apache/cordova-lib/pull/226
Cordova-windows (sample platform's implementation): https://github.com/apache/cordova-windows/pull/84
Here is brief details of implementation:
There is PlatformApi (former PlatformProject) class -- acts as entry point for platform-related functionality. It exposes:
a) methods that represent platform's actions, like 'build', 'run', etc. Base implementations of these methods acts as a wrappers around platform executable scripts, but each platform can provide its own implementation by defining Api.js module with same prototype methods, which will override methods of base implementation. Current draft contains wrappers for `build` and `requirements` commands.
b) PlatformHandler instance, accessible via both `getPlatformHandler()` method and `parser` property (left for backward compatibility). The PlatformHandler class is intended to be a container for platform-specific implementations for `prepare` logic. The approach here is the same as with PlatformApi class - the platform can override default implementation (currently it's being taken from cordova\metadata\<platform>_parser.js file) with custom one through providing own PlatformApi.PlatformHandler class.
c) PluginHandler instance - for plugin manipulation related functionality. Approach is the same as for PlatformHandler.
Since this implementation provides a fallback alternatives for all new functionality, it will allow to us to seamlessly move all platform-related functionality to platforms.
IMO this could be done in three steps:
1. Copy platform actions (build, run, etc. ) to platforms. (See windows PR for sample - https://github.com/MSOpenTech/cordova-windows/blob/unified_platform_api/template/cordova/Api.js )
2. Copy `prepare`- and plugin-related logic to platforms, leave existing code for compatibility with old platforms.
3. Completely remove platform-related functionality from lib. This will break compatibility with old platforms, so we'll need to wait for some time before doing this.
Would love to hear any feedback and thoughts on this.
---------------
Best regards, Vladimir
-----Original Message-----
From: Mark Koudritsky [mailto:kamrik@google.com]
Sent: Saturday, 25 April, 2015 6:14
To: dev@cordova.apache.org
Subject: Re: Experimenting with API for cordova tooling
I like the idea of cordova-discuss, lets give it a try )
To read the md file formatted:
https://github.com/kamrik/cordova-discuss/blob/master/proposals/PlatformProject.md
To comment, look at the pull request
https://github.com/cordova/cordova-discuss/pull/4
On Fri, Apr 24, 2015 at 10:16 PM, Parashuram N (MS OPEN TECH) < panarasi@microsoft.com> wrote:
> Should we move this docs to cordova-discuss instead
> -https://github.com/cordova/cordova-discuss ?
>
> On 4/24/15, 4:02 PM, "Mark Koudritsky" <ka...@google.com> wrote:
>
> >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/1jxQvygBtTeCYhxMtHLD9jgKTKZofMJdux1
> UIzs
> >dd5b0
> >
> >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 <mm...@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
> >> <Ro...@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:kamrik@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
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Experimenting with API for cordova tooling
Posted by Mark Koudritsky <ka...@google.com>.
I like the idea of cordova-discuss, lets give it a try )
To read the md file formatted:
https://github.com/kamrik/cordova-discuss/blob/master/proposals/PlatformProject.md
To comment, look at the pull request
https://github.com/cordova/cordova-discuss/pull/4
On Fri, Apr 24, 2015 at 10:16 PM, Parashuram N (MS OPEN TECH) <
panarasi@microsoft.com> wrote:
> Should we move this docs to cordova-discuss instead
> -https://github.com/cordova/cordova-discuss ?
>
> On 4/24/15, 4:02 PM, "Mark Koudritsky" <ka...@google.com> wrote:
>
> >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/1jxQvygBtTeCYhxMtHLD9jgKTKZofMJdux1UIzs
> >dd5b0
> >
> >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 <mm...@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 <Ro...@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:kamrik@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
> >> >
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
Re: Experimenting with API for cordova tooling
Posted by "Parashuram N (MS OPEN TECH)" <pa...@microsoft.com>.
Should we move this docs to cordova-discuss instead
-https://github.com/cordova/cordova-discuss ?
On 4/24/15, 4:02 PM, "Mark Koudritsky" <ka...@google.com> wrote:
>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/1jxQvygBtTeCYhxMtHLD9jgKTKZofMJdux1UIzs
>dd5b0
>
>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 <mm...@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 <Ro...@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:kamrik@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
>> >
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: Experimenting with API for cordova tooling
Posted by Mark Koudritsky <ka...@google.com>.
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 <mm...@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 <Ro...@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:kamrik@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
> >
>
Re: Experimenting with API for cordova tooling
Posted by Michal Mocny <mm...@chromium.org>.
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 <Ro...@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:kamrik@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
>
RE: Experimenting with API for cordova tooling
Posted by Rob Paveza <Ro...@microsoft.com>.
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:kamrik@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