You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by "Treggiari, Leo" <le...@intel.com> on 2014/10/30 15:48:46 UTC
cordova xxx add - is there a problem?
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 CLI 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
Re: cordova xxx add - is there a problem?
Posted by Edna Y Morales <ey...@us.ibm.com>.
I have started doing some work on this. Currently "platform add" does a
check to see if the OS supports the platform. If it does not, then it just
automatically throws an error without attempting to add it. I have changed
this to just print out a warning message and continue with the process. The
"prepare" command does not seem to be giving me any issues when I add a
platform for which the environment is not set up so I think it's safe to
leave that.
The next issue is to be sure that the platform's "check_reqs" is not
getting called within the platform's create script. For Android, I believe
that was removed recently. Windows does not call it and I am currently
working on converting the iOS bash scripts to nodejs in which I have
removed the call to check_reqs. The check_reqs shouldn't be necessary until
you build and run.
The other thing to consider is what happens when you try to build using the
CLI for a platform that you don't have the environment set up for.
Currently, what I have implemented is that it will just end the process
with an error on the first platform it hits that cannot be built. It will
not try to build the remaining platforms. For example, if you are on a
windows machine and you do "build ios android", it's going to error out
when it try to build iOS and just end the process there. This is to avoid
running the after_build hooks and to let the user know that they can't
build for iOS. The idea there is that the user would skip building iOS and
just do "build android".
That is what I have so far and am open to any feedback or suggestions. My
first priority is to get the iOS scripts converted to nodejs so that the
iOS platform can be added even if you are on a nonsupported OS.
Thanks,
Edna Morales
From: Marcel Kinard <cm...@gmail.com>
To: dev@cordova.apache.org
Date: 11/03/2014 05:07 PM
Subject: Re: cordova xxx add - is there a problem?
Edna is doing some work in this area.
https://issues.apache.org/jira/browse/CB-7803
On Nov 3, 2014, at 4:33 PM, Treggiari, Leo <le...@intel.com> wrote:
>> I think you would like for each developer to be able to be able to work
on any project regardless of locally available sdks, correct?
>
> Yes. Thanks.
Re: cordova xxx add - is there a problem?
Posted by Marcel Kinard <cm...@gmail.com>.
Edna is doing some work in this area. https://issues.apache.org/jira/browse/CB-7803
On Nov 3, 2014, at 4:33 PM, Treggiari, Leo <le...@intel.com> wrote:
>> I think you would like for each developer to be able to be able to work on any project regardless of locally available sdks, correct?
>
> Yes. Thanks.
RE: cordova xxx add - is there a problem?
Posted by "Treggiari, Leo" <le...@intel.com>.
> I think you would like for each developer to be able to be able to work on any project regardless of locally available sdks, correct?
Yes. Thanks.
From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal Mocny
Sent: Monday, November 03, 2014 1:30 PM
To: Treggiari, Leo
Cc: Michal Mocny; dev
Subject: Re: cordova xxx add - is there a problem?
Okay, gotcha. I think you would like for each developer to be able to be able to work on any project regardless of locally available sdks, correct? E.g. if you on windows and some project supports ios, you should still be able to work on the wp/android parts, or use an iOS cloud build. That makes sense.
Andrew mentioned earlier that we have actually started landing patches in this direction. Specifically, the "add" scripts should fail gracefully if the sdk is not available, in a way that is easy to recover from once the sdks are added (including cloning the repo on another machine). I don't think moving things to prepare-time is required for this, though it could be an option if needed.
-Michal
On Mon, Nov 3, 2014 at 3:38 PM, Treggiari, Leo <le...@intel.com>> wrote:
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 metadata.
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.
Thanks,
Leo
From: mmocny@google.com<ma...@google.com> [mailto:mmocny@google.com<ma...@google.com>] 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?
-Michal
On Mon, Nov 3, 2014 at 1:45 PM, Treggiari, Leo <le...@intel.com>> wrote:
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, etc.
Leo
-----Original Message-----
From: mmocny@google.com<ma...@google.com> [mailto:mmocny@google.com<ma...@google.com>] 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
insufficient).
-Michal
On Fri, Oct 31, 2014 at 1:48 PM, Frederico Galvão <
frederico.galvao@pontoget.com.br<ma...@pontoget.com.br>> 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 <ag...@chromium.org>>:
>
> > 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 <
> leo.treggiari@intel.com<ma...@intel.com>>
> > 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
> CLI
> > > 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>
>
> * www.pontoget.com.br<http://www.pontoget.com.br> <http://www.pontoget.com/>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<ma...@cordova.apache.org>
For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
Re: cordova xxx add - is there a problem?
Posted by Michal Mocny <mm...@chromium.org>.
Okay, gotcha. I think you would like for each developer to be able to be
able to work on any project regardless of locally available sdks, correct?
E.g. if you on windows and some project supports ios, you should still be
able to work on the wp/android parts, or use an iOS cloud build. That
makes sense.
Andrew mentioned earlier that we have actually started landing patches in
this direction. Specifically, the "add" scripts should fail gracefully if
the sdk is not available, in a way that is easy to recover from once the
sdks are added (including cloning the repo on another machine). I don't
think moving things to prepare-time is required for this, though it could
be an option if needed.
-Michal
On Mon, Nov 3, 2014 at 3:38 PM, Treggiari, Leo <le...@intel.com>
wrote:
> 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 metadata.
>
>
>
> 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.
>
>
>
> Thanks,
>
> Leo
>
>
>
> *From:* mmocny@google.com [mailto:mmocny@google.com] *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?
>
>
>
> -Michal
>
>
>
> On Mon, Nov 3, 2014 at 1:45 PM, Treggiari, Leo <le...@intel.com>
> wrote:
>
> 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, etc.
>
> Leo
>
>
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@google.com] 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
> insufficient).
>
> -Michal
>
> On Fri, Oct 31, 2014 at 1:48 PM, Frederico Galvão <
> frederico.galvao@pontoget.com.br> 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 <ag...@chromium.org>:
> >
> > > 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 <
> > leo.treggiari@intel.com>
> > > 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
> > CLI
> > > > 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
> >
> > * www.pontoget.com.br <http://www.pontoget.com/>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
>
>
RE: cordova xxx add - is there a problem?
Posted by "Treggiari, Leo" <le...@intel.com>.
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 metadata.
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.
Thanks,
Leo
From: mmocny@google.com [mailto:mmocny@google.com] 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?
-Michal
On Mon, Nov 3, 2014 at 1:45 PM, Treggiari, Leo <le...@intel.com>> wrote:
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, etc.
Leo
-----Original Message-----
From: mmocny@google.com<ma...@google.com> [mailto:mmocny@google.com<ma...@google.com>] 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
insufficient).
-Michal
On Fri, Oct 31, 2014 at 1:48 PM, Frederico Galvão <
frederico.galvao@pontoget.com.br<ma...@pontoget.com.br>> 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 <ag...@chromium.org>>:
>
> > 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 <
> leo.treggiari@intel.com<ma...@intel.com>>
> > 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
> CLI
> > > 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>
>
> * www.pontoget.com.br<http://www.pontoget.com.br> <http://www.pontoget.com/>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org<ma...@cordova.apache.org>
For additional commands, e-mail: dev-help@cordova.apache.org<ma...@cordova.apache.org>
Re: cordova xxx add - is there a problem?
Posted by Michal Mocny <mm...@chromium.org>.
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?
-Michal
On Mon, Nov 3, 2014 at 1:45 PM, Treggiari, Leo <le...@intel.com>
wrote:
> 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, etc.
>
> Leo
>
> -----Original Message-----
> From: mmocny@google.com [mailto:mmocny@google.com] 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
> insufficient).
>
> -Michal
>
> On Fri, Oct 31, 2014 at 1:48 PM, Frederico Galvão <
> frederico.galvao@pontoget.com.br> 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 <ag...@chromium.org>:
> >
> > > 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 <
> > leo.treggiari@intel.com>
> > > 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
> > CLI
> > > > 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
> >
> > * www.pontoget.com.br <http://www.pontoget.com/>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> For additional commands, e-mail: dev-help@cordova.apache.org
>
RE: cordova xxx add - is there a problem?
Posted by "Treggiari, Leo" <le...@intel.com>.
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, etc.
Leo
-----Original Message-----
From: mmocny@google.com [mailto:mmocny@google.com] 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
insufficient).
-Michal
On Fri, Oct 31, 2014 at 1:48 PM, Frederico Galvão <
frederico.galvao@pontoget.com.br> 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 <ag...@chromium.org>:
>
> > 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 <
> leo.treggiari@intel.com>
> > 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
> CLI
> > > 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
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org
Re: cordova xxx add - is there a problem?
Posted by Michal Mocny <mm...@chromium.org>.
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
insufficient).
-Michal
On Fri, Oct 31, 2014 at 1:48 PM, Frederico Galvão <
frederico.galvao@pontoget.com.br> 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 <ag...@chromium.org>:
>
> > 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 <
> leo.treggiari@intel.com>
> > 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
> CLI
> > > 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
>
> * www.pontoget.com.br <http://www.pontoget.com/>
>
Re: cordova xxx add - is there a problem?
Posted by Frederico Galvão <fr...@pontoget.com.br>.
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 <ag...@chromium.org>:
> 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 <le...@intel.com>
> 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 CLI
> > 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
* www.pontoget.com.br <http://www.pontoget.com/>
Re: cordova xxx add - is there a problem?
Posted by Andrew Grieve <ag...@chromium.org>.
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 <le...@intel.com>
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 CLI
> 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
>