> 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: [email protected] [mailto:[email protected]] 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 
<[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> 
[mailto:[email protected]<mailto:[email protected]>] 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 
<[email protected]<mailto:[email protected]>> 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: [email protected]<mailto:[email protected]> 
[mailto:[email protected]<mailto:[email protected]>] 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 <
[email protected]<mailto:[email protected]>> 
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 
> <[email protected]<mailto:[email protected]>>:
>
> > 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 <
> [email protected]<mailto:[email protected]>>
> > 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: 
[email protected]<mailto:[email protected]>
For additional commands, e-mail: 
[email protected]<mailto:[email protected]>


Reply via email to