[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Smart Import concerns
|
On 30 May 2016, at 12:45, Mickael Istria wrote:
On 05/30/2016 12:22 PM, Max Rydahl Andersen wrote:
On 15 May 2016, at 22:33, Stefan Oehme wrote:
Why does BuildShip need to rename all of them? Wouldn't it work
with the generated names?
Because the user gives his Gradle projects names and of course
expects those to be reflected in Eclipse.
btw. is this not exactly the same for m2e ?
the project name in m2e is not necessarily the folder name.
I had a chat with Stefan and we'll consider new methods in the API to
better support such case.
What we talked about a while back was that once a detector stated it
can identify a project the *detector* should do the import, not
smart import itself to exactly allow things like m2e and more
complex future buildship to "take over" the import.
Did that not make it in ?
No.
What you're suggestion would be more like an ability to filter which
import wizards are visible according to the input folder.
No it is not. That is a separate end-user use case.
I'm explicitly talking about the ability of a detector or later on the
configurator to state it knows what todo and explicitly tell the
importer to not try and add more "blind" attempts on configuration.
The idea behind the importer is really to provide a unified interface
(both in term of API and UI) to allow a straightforward and consistent
import across the variety of project types. With feedback from Stefan
and compared to m2e, the importer interface will provide the ability
to give more control to the contributing strategies.
Actually, there are already ways for BuildShip and other to "take
over" parts of import (they can run some specific import operation,
even creation of project with virtual folders) as part of the
Projectconfigurator interface, but all those currently feel like
hacks. We need to make it more accessible and explicit in the API.
Yes, that was exactly what the use case is about. Letting the
detector/configurators for m2e and gradle explicitly tell smart import
to stop applying more detectors/configurators since buildship knows
more/better.
So will buildship be able to work in Neon with what we have ?
/max
http://about.me/maxandersen
