Rename service/service_factory of file_system_provider and launcher_search_provider

Rename service/service_factory of file_system_provider

Duplicate basenames cannot be used in the same static library (for Mac).
Previously this was enforced, but it was accidentally dropped, and is
now being reinstated.

file_system_provider and launcher_search_provider's files collide. I
renamed both so as to not be so generic in basename.

This is an entirely mechanical move, no intended functionality change.

(The presubmit also made me run git cl format).

BUG=490824, gyp:384, 472772

[scottmg, 2015-05-26 23:28:34]

scottmg@chromium.org changed reviewers:
+ mtomasz@chromium.org, stevenjb@chromium.org

[scottmg, 2015-05-26 23:28:43]

The CQ bit was checked by scottmg@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-05-26 23:30:35]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1148293006/20001

[mtomasz, 2015-05-27 00:15:34]

On 2015/05/26 23:30:35, I haz the power - commit-bot wrote:
> Dry run: CQ is trying da patch. Follow status at
>  https://chromium-cq-status.appspot.com/patch-status/1148293006/20001

Hold on. Is this really necessary? file_system_provider/* code is NOT compiled
on Mac.
Do we really need to have such long file names?

This breaks now consistency. We used to have file names matching class names
inside.

[commit-bot: I haz the power, 2015-05-27 00:27:14]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-05-27 00:27:16]

Dry run: This issue passed the CQ dry run.

[scottmg, 2015-05-27 00:52:46]

On 2015/05/27 00:15:34, mtomasz wrote:
> On 2015/05/26 23:30:35, I haz the power - commit-bot wrote:
> > Dry run: CQ is trying da patch. Follow status at
> >  https://chromium-cq-status.appspot.com/patch-status/1148293006/20001
> 
> Hold on. Is this really necessary? file_system_provider/* code is NOT compiled
> on Mac.

(It was just a tryjob, not committing).

> Do we really need to have such long file names?

They can be shorter, but they can't be duplicated inside the same lib. I don't
know anything about these bits, but if they're independent they could
potentially be split into multiple libs, maybe that would make sense?

> 
> This breaks now consistency. We used to have file names matching class names
> inside.

[mtomasz, 2015-05-27 00:59:54]

On 2015/05/27 00:52:46, scottmg wrote:
> On 2015/05/27 00:15:34, mtomasz wrote:
> > On 2015/05/26 23:30:35, I haz the power - commit-bot wrote:
> > > Dry run: CQ is trying da patch. Follow status at
> > >  https://chromium-cq-status.appspot.com/patch-status/1148293006/20001
> > 
> > Hold on. Is this really necessary? file_system_provider/* code is NOT
compiled
> > on Mac.
> 
> (It was just a tryjob, not committing).
> 
> > Do we really need to have such long file names?
> 
> They can be shorter, but they can't be duplicated inside the same lib. I don't
> know anything about these bits, but if they're independent they could
> potentially be split into multiple libs, maybe that would make sense?
> 
> > 
> > This breaks now consistency. We used to have file names matching class names
> > inside.

We have --no-duplicate-basename-check in gyp
(https://code.google.com/p/gyp/source/detail?r=1947).
Can we use it for non-Mac and allow duplicated file names? Both
launcher_search_provider and file_system_provider are compiled on Chrome OS
*only*.

[scottmg, 2015-05-27 03:23:05]

On 2015/05/27 00:59:54, mtomasz wrote:
> On 2015/05/27 00:52:46, scottmg wrote:
> > On 2015/05/27 00:15:34, mtomasz wrote:
> > > On 2015/05/26 23:30:35, I haz the power - commit-bot wrote:
> > > > Dry run: CQ is trying da patch. Follow status at
> > > >  https://chromium-cq-status.appspot.com/patch-status/1148293006/20001
> > > 
> > > Hold on. Is this really necessary? file_system_provider/* code is NOT
> compiled
> > > on Mac.
> > 
> > (It was just a tryjob, not committing).
> > 
> > > Do we really need to have such long file names?
> > 
> > They can be shorter, but they can't be duplicated inside the same lib. I
don't
> > know anything about these bits, but if they're independent they could
> > potentially be split into multiple libs, maybe that would make sense?
> > 
> > > 
> > > This breaks now consistency. We used to have file names matching class
names
> > > inside.
> 
> We have --no-duplicate-basename-check in gyp
> (https://code.google.com/p/gyp/source/detail?r=1947).
> Can we use it for non-Mac and allow duplicated file names? Both
> launcher_search_provider and file_system_provider are compiled on Chrome OS
> *only*.

I understand, it just seems a bit error prone to only forbid it on certain
platforms as for shared code, it'll mean someone working on Linux, etc. will
only find out at the "end" that they need to rename things. But maybe it's fine
as it's relatively uncommon.

[mtomasz, 2015-05-27 06:13:24]

On 2015/05/27 03:23:05, scottmg wrote:
> On 2015/05/27 00:59:54, mtomasz wrote:
> > On 2015/05/27 00:52:46, scottmg wrote:
> > > On 2015/05/27 00:15:34, mtomasz wrote:
> > > > On 2015/05/26 23:30:35, I haz the power - commit-bot wrote:
> > > > > Dry run: CQ is trying da patch. Follow status at
> > > > >  https://chromium-cq-status.appspot.com/patch-status/1148293006/20001
> > > > 
> > > > Hold on. Is this really necessary? file_system_provider/* code is NOT
> > compiled
> > > > on Mac.
> > > 
> > > (It was just a tryjob, not committing).
> > > 
> > > > Do we really need to have such long file names?
> > > 
> > > They can be shorter, but they can't be duplicated inside the same lib. I
> don't
> > > know anything about these bits, but if they're independent they could
> > > potentially be split into multiple libs, maybe that would make sense?
> > > 
> > > > 
> > > > This breaks now consistency. We used to have file names matching class
> names
> > > > inside.
> > 
> > We have --no-duplicate-basename-check in gyp
> > (https://code.google.com/p/gyp/source/detail?r=1947).
> > Can we use it for non-Mac and allow duplicated file names? Both
> > launcher_search_provider and file_system_provider are compiled on Chrome OS
> > *only*.
> 
> I understand, it just seems a bit error prone to only forbid it on certain
> platforms as for shared code, it'll mean someone working on Linux, etc. will
> only find out at the "end" that they need to rename things. But maybe it's
fine
> as it's relatively uncommon.

I think not really at the end. Whether we go with no-duplicate-basename-check or
with the rename like in this CL, people who create new duplicating files on Mac
will simply fail to compile. Same result. Am I understanding correctly?

[stevenjb, 2015-05-27 16:48:44]

owner lgtm

[stevenjb, 2015-05-27 17:05:13]

https://codereview.chromium.org/1148293006/diff/20001/chrome/browser/ui/app_l...
File
chrome/browser/ui/app_list/search/launcher_search/launcher_search_provider.cc
(right):

https://codereview.chromium.org/1148293006/diff/20001/chrome/browser/ui/app_l...
chrome/browser/ui/app_list/search/launcher_search/launcher_search_provider.cc:9:
#include
"chrome/browser/chromeos/launcher_search_provider/launcher_search_provider_service.h"
Actually, this file should really be launcher_search_provider_chromeos.cc (or in
a chromeos/ subdirectory) since it is only included in chromeos. That might
explain why this is causing a problem on OSX (which shouldn't be dependent on
any chromeos specific files)?

https://codereview.chromium.org/1148293006/diff/20001/chrome/browser/ui/app_l...
File chrome/browser/ui/app_list/search/launcher_search/launcher_search_result.cc
(right):

https://codereview.chromium.org/1148293006/diff/20001/chrome/browser/ui/app_l...
chrome/browser/ui/app_list/search/launcher_search/launcher_search_result.cc:8:
#include
"chrome/browser/chromeos/launcher_search_provider/launcher_search_provider_service.h"
This file should also be chromeos specific.

[scottmg, 2015-05-27 20:00:04]

Disabled the basename check for cros instead. Closing.