cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Treggiari, Leo" <>
Subject RE: cordova xxx add - is there a problem?
Date Mon, 03 Nov 2014 20:38:01 GMT
Hi Michal,

Thanks for the information and considering this.  The workflow that I want is somewhat different
than what you have inferred from my previous mail.

I do want “add” to set the metadata AND fetch the plugin sources / platform implementation.
 I think it is fair that if someone only wants to set the metadata, that they use a command
line option, or some other method, for that.

What I don’t want “add” to do is anything that requires the platform SDKs.  I want that
to happen with “prepare” and commands that occur post-prepare.  If “prepare” works
incrementally based upon the project metadata and knowledge of what it has done before, or
if “prepare” always redoes everything, then it should work if “add” does not call
“prepare”, right?  If “prepare” assumes that “add” has done any more than set
the metadata and fetch the sources, then a change would be necessary.

Here’s an example scenario – two developers working on the same project:

·        One uses CLI and develops on Mac for iOS and/or Android

·        One uses an IDE and develops on Windows for Windows Phone and/or Android

One user creates the project.  Either can add plugins and platforms.  The remainder of the
workflow is specific to the tools each user is using, but they don’t get into each other’s
way when they share the ‘project’ in git – i.e. the project sources and the project

Really we just need to iron out and land what Gorkem started.  Does that sound fair?

Yes, but wouldn’t it be better to change “add” to not call “prepare”.  You suggested
a "--skip-prepare" or "--save-only" type flag for
the add commands.  This would work as long as developers remembered to us it when necessary.


From: [] On Behalf Of Michal Mocny
Sent: Monday, November 03, 2014 12:10 PM
To: dev
Cc: Treggiari, Leo
Subject: Re: cordova xxx add - is there a problem?

Prepare runs hooks, updates the platform config.xml's (using platform defaults + plugin.xml's
+ app config.xml), and updates the www/ assets, including re-adding plugin js-modules.

In practice this takes about as long as copying all the files around.  However, pre/post prepare
hooks are the most common place for application developers to inject more complex conditional
actions.  Chrome Apps for Mobile, for example, will automatically install platforms / plugins
if they aren't already installed as part of pre-prepare.

Anyway, its starting to sound like we wont actually need to change the cli interface to address
your needs: IDE's can just edit the config.xml directly to insert dependant platforms/plugins
(with gorkems work) without actually adding those asserts locally if that isn't important
(i.e. for remote cloud build).  If you are working at the command line, I don't see much value
in supporting "add" without actually fetching the assets.

Really we just need to iron out and land what Gorkem started.  Does that sound fair?


On Mon, Nov 3, 2014 at 1:45 PM, Treggiari, Leo <<>>
I hate to see lots of new commands and/or options added.  They are OK if code is calling the
commands (e.g. an IDE), but not so good for users.

Certainly having a well-defined and documented place for the metadata re: plugins and platforms
is an important step forward.

How smart is "prepare"?  Does it work incrementally based upon the changes since the last
time it was invoked, or is does it do all preparation every time?  I ask from a performance
perspective with respect to moving work from "add" to "prepare", because it seems like "prepare"
is called much more often than "add".

Regarding fetching the sources and local vs. remote builds, It's not just where the build
takes place that determines whether a client wants the sources.  The sources can be used for
other things besides building, including code-assist in an editor, emulation, companion apps,


-----Original Message-----
From:<> [<>]
On Behalf Of Michal Mocny
Sent: Monday, November 03, 2014 10:25 AM
To: dev
Cc: Treggiari, Leo
Subject: Re: cordova xxx add - is there a problem?

I'm not sure that we should change the "cordova plugin/platform add" cli
command to not actually make the changes to platforms/ or plugins/, but
since both commands run "cordova prepare", we could move the logic to the
prepare step and then add a "--skip-prepare" or "--save-only" type flag for
the add commands?

Alternatively, we could do something like what phonegap-cli does and have a
"cordova remote plugin add" to differentiate local installs from mere
metadata updates.

Either way, seems this is related to Gorkems work to add platform / plugin
deps to config.xml (though, the current implementation as it exists is


On Fri, Oct 31, 2014 at 1:48 PM, Frederico Galvão <<>> wrote:

> Well, afaik 'cordova plugin add <>' only does 'cordova prepare' after the
> plugin stuff is done, and 'cordova prepare' works even without native SDKs.
> 2014-10-30 23:43 GMT-02:00 Andrew Grieve <<>>:
> > There've been some changes to CLI in the last month that fix Android
> > requiring an SDK to run create & plugin add. Likewise, a fix just went in
> > this week (last week?) that fixes the slash problem for xcode project
> files
> > on windows.
> >
> > That said, I like your idea of not modifying platforms/ outside of
> prepare
> > / build.
> >
> > On Thu, Oct 30, 2014 at 10:48 AM, Treggiari, Leo <
> > wrote:
> >
> > > Is there an issue with the semantics of "plugin add" and "platform
> add"?
> > >
> > > This is just a high level query to see if this is something worth
> > > discussing in more detail.  I don't know exactly what each Cordova CLI
> > > command does.  My knowledge is based upon reading documentation (which
> is
> > > sometimes wrong as noted in recent e-mails) and experimentation.
> > >
> > > What does "add" do?
> > >
> > >
> > > 1.      For "plugin add" fetches the plugin sources.  For "platform
> add"
> > > fetches the platform implementation if necessary.
> > >
> > > 2.      Stores some metadata somewhere indicating that the plugin or
> > > platform was added?  What and where this metadata is stored should be
> > > better documented.
> > >
> > > 3.      For "plugin add", processes plugin variables, if specified,
> which
> > > modifies the plugin sources.
> > >
> > > 4.      Creates/modifies the native platform "project" (e.g. a Visual
> > > Studio, Eclipse, or Xcode, etc. project) to make the appropriate
> changes.
> > >
> > > If  "plugin add" or "platform add" do more than this, I'd appreciate
> > being
> > > educated.
> > >
> > > My question is, should "add" stop at step #2 and leave the rest to the
> > > prepare step?
> > >
> > > Here's why:
> > >
> > > *        We see there is an issue with multiple developers on the same
> > > project on different platforms.  E.g. when one developer is on Windows
> > > working on the Windows and Android versions of the project and another
> is
> > > on Mac working on the iOS version of the project.  If the shared
> project
> > > wants to add all three platforms (which it does...) then Cordova CLI
> has
> > > problems.  Basically because not much else than the "create" command
> > works
> > > without having native SDKs installed.  Would many issues be solved if
> the
> > > "add" command did not require the presence of native SDKs, but rather
> > > "prepare" did?
> > >
> > > *        There seems to be an issue with the co-existence of Cordova
> > > and IDEs, and in particular with IDEs that want to build in the cloud
> > > without the requirement of native SDKs.  It would be ideal if multiple
> > > users on the same project could use different tools - e.g. one use the
> > > command line and one use the IDE.  The basic "definition" of a Cordova
> > CLI
> > > project, i.e. the part that needs to be shared, is the list of
> platforms
> > > and plugins and the settings in the top level config.xml.  If the basic
> > > definition of the project could be created/edited from both the CLI and
> > > various IDEs, then the rest of the development workflow (prepare,
> build,
> > > emulate, etc.) could be implemented in different ways, but the project
> > > definition could still be shared.
> > >
> > > P.S. the "remove" command has similar semantics.
> > >
> > > Thanks,
> > > Leo
> > >
> >
> --
> *Frederico Galvão*
> Diretor de Tecnologia
> PontoGet Inovação Web
> ( +55(62) 8131-5720<tel:%28%20%2B55%2862%29%208131-5720>
> *<> <>
To unsubscribe, e-mail:<>
For additional commands, e-mail:<>

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