cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: cordova-cli and plugman overview march 22nd 9am Pacific
Date Fri, 22 Mar 2013 18:43:35 GMT
Here are the meeting notes:

Meeting Notes


   1.

   Fil describing the tools
   -

      command line tools, readme from github
      -

      application assets are platform agnostic
      -

      platform, plugin, prepare, compile, build, emulate, serve
      -

      www/config.xml description
      -

      prepare command:
      -

         check_platforms command
         -

            aside: perhaps it should be a script called out to each platform
            -

         update_from_config command
         -

            platform specific magic, config formats
            -

         update_www
         -

            copy your app over platform www
            -

            destroys the platform’s www each time
            -

         update_project
         -

            project specific magic
            -

            quick note: update_project simply calls update_from_config,
            update_www, and update_overrides (and lets each parser add
more magic if it
            needs to here).
            -

      platform command:
      -

         ls, remove obvious
         -

         add, calls check_requirements, then massages based on target
         platform
         -

         libs folder contains cached versions of the platforms at the last
         release
         -

            Braden dislikes this: feature request: flag like `cordova
            platform add android --target=../../cordova-android` so
that I can install
            an arbitrary version of the platform code, potentially
with local patches.
            -

      compile command:
      -

         shell_out_to_debug
         -

      emulate command:
      -

         shell_out_to_emulate
         -

      plugin command:
      -

         lots of error checking right now
         -

         shells out to plugman to do its thing
         -

         most of the error checking will move into plugman
         -

         will look more like emulate/compile
         -

      serve command:
      -

         serves up the platform www content
         -

         Possible future update to use Ripple instead
         -

      project/module level hooks
      -

      merges folder
      -

         project parsers
         2.

   Michael Brooks discusses phonegap-cli
   -

      https://github.com/mwbrooks/phonegap-cli
      -

      uses cordova-cli under the hook, plus a phonegap-build command
      -

      phonegap-* commands have cloud backups, if it fails to work locally
      -

      Aside: app-harness work.  Michael has plans, but little/no dev work,
      Shravan may start this soon, will sync up.
      3.

   Anis discusses plugman
   -

      Examples of plugin add, remove, updates to config.xml
      -

      plugin.xml specifies changes needed to project files, config.xml
      -

      lookup by name
      4.

   Tests as plugins
   -

      The team approves in general.
      -

      Generic test suite, install as many test plugins as you like, it runs
      them all.
      -

      Some common framework for registering tests and reporting results,
      ideally independent of test harness.
      -

      Part of the motivation for multiple plugins in one repo, since now
      tests and sample apps can live in the same repo. Reduces logistical pain
      for us and others.
      5.

   Apps as plugins
   -

      Michal presented the various ideas we had, arguments in both
      directions.
      -

      No conclusions today, just something to think about.
      -

      Considerations:
      -

         plugins are getting awesome treatment:
         -

            universe
            -

            dependencies
            -

            versioning
            -

            add/remove/upgrade
            -

            access to native
            -

            multiple plugins in one repo
            -

         apps are getting some treatment:
         -

            the app manifest has access to platform properties
            -

            merges folder
            -

      So the observation is, if we merge the two concepts, we could
      potentially share the benefits, with some changes to the tools required
      (and certain confusion).
      6.

   www to be moved into a named app folder
   -

      currently www/ has to have config.xml inside it, docs inside it,
      README etc
      -

      merges folder is already a sibling of www/ but its logically part of
      the app.
      -

      So, move everything out of www that isn't the actual assets of the
      app.
      -

      Option 1: move everything to root, but then cordova files (platforms,
      plugins) clutter you app repo.
      -

      Option 2: move our current merges/ and www/ folder into a named
      folder (ie. "app")
      -

         Open question: should we support multiple named app folders?




On Fri, Mar 22, 2013 at 11:55 AM, Andrew Grieve <agrieve@chromium.org>wrote:

> Let's use this gdoc as an agenda / place to take notes:
>
>
> https://docs.google.com/document/d/1BR7WVK1MT7zE8Oj18F1cAAQ4XZCvym-5lma5JPgx1fA/edit?usp=sharing
>
>
> On Thu, Mar 21, 2013 at 6:25 PM, Filip Maj <fil@adobe.com> wrote:
>
> > I'll be likely doing it from home. Some of the other committers too. It's
> > open to the public, essentially, so setting a limit of 10 I think is
> > unreasonable.
> >
> > On 3/21/13 3:18 PM, "Braden Shepherdson" <braden@chromium.org> wrote:
> >
> > >I think it's 10. Will we have that many different rooms/laptops? All the
> > >Googlers will be in one room, hopefully most of the Apache SF folks can
> do
> > >the same.
> > >
> > >
> > >On Thu, Mar 21, 2013 at 6:09 PM, Filip Maj <fil@adobe.com> wrote:
> > >
> > >> I am looking into setting up a connect room as hangouts only support
> 20
> > >> people I believe (unless I'm wrong)
> > >>
> > >> Will be posting meeting details shortly
> > >>
> > >>
> >
> >
>

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