Re: [platform-ui-dev] Smart Import concerns

[Mickael Istria <mistria@xxxxxxxxxx>]

On 05/15/2016 08:16 PM, Stefan Oehme wrote:

The .eclipse folder and all its contents would be auto-generated by Buildship. They do not exist at the time the Smart Importer runs. I guess this also answers the question below.

[...]

Software components are not physically nested folders. A single physical Gradle project can be logically divided into different components that have different compile/runtime classpaths. So the approach proposed above would only work if we actively create the folders during this loop, which would be weird, because the user hasn't even selected which he wants yet :)

I have to admit that I wasn't aware of this complexity in BuildShip. I was expecting it to behave more like m2e -adding natures, builders and classpath containers to project-, and not recreating an abstract structure of projects just for Eclipse. To be honest, given how tricky BuildShip seems to be internally, I'm wondering whether the Smart Import can match, or even should match.
As long as BuildShip is so different, it seems like users of Gradle in Eclipse will not be able to use Smart Import (at least until Oxygen).

This one is indeed an issue, but the importer will manage to import the example structures. Although project in sub2/api will be likely to be called api_(0) and sub2/impl likely to be called impl_(0). http://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/bundles/org.eclipse.ui.ide/src/org/eclipse/ui/internal/wizards/datatransfer/SmartImportJob.java#n554

Fair enough, but still Buildship has to rename all of them

Why does BuildShip need to rename all of them? Wouldn't it work with the generated names?
But for sure the names may not be perfect. Maybe another convention should be preferred in the importer directly, one that works better in general. What do you use in BuildShip?

This might work when we're talking about 1 or 2 projects. But real world projects out there have 100s, sometimes 1000s of sub-modules. You can't expect the user to click through those and change configurations.

Right.
The possibility to update multiple projects at once is something that is missing in the IDE at the moment.

Honestly, I wouldn't call this a decent user experience. The projects are unusable until all configuration is there. Doing it in the background just improves the perceived performance a little bit, but as a user I still have to wait.

Try importing a build with 500 sub-projects. It takes ages if you configure them one by one, because JDT will run lots of auto builds, the different views in Eclipse will update themselves constantly etc.

Auto-build is disabled during import, and updating Maven configuration does the whole configuration at once. So even with 500 projects, it's going OK.

Buildship does this in 10s thanks to its transactional approach. So the absolute minimum you need is doing this stuff synchronously, in a workspace transaction and allowing contributors to add additional transactional semantics. That way, e.g. we can also suppress JDT notifications until the import is completely done. Otherwise this will be way too slow for large projects.
Try importing a build with 500 sub-projects. It takes ages if you configure them one by one, because JDT will run lots of auto builds, the different views in Eclipse will update themselves constantly etc. It creates a lot of pressure on the UI thread, making the IDE almost freeze. You can't really use anything until the background job has settled down. Buildship does this in 10s thanks to its transactional approach. So the absolute minimum you need is doing this stuff synchronously, in a workspace transaction and allowing contributors to add additional transactional semantics. That way, e.g. we can also suppress JDT notifications until the import is completely done. Otherwise this will be way too slow for large projects.

The fact that users can browse the code and project structure very fast while projects are being asynchronously configured is actually a very important thing. Users can see that the project are still being configured in the Progress Bar but can already do many things.
For the projects I tried (mainly Maven projects, such as WildFly), the import returns early; and while Maven is processing the newly imported projects, I can browse code, make a search, code on the projects that are already configured... So yeah, my import is not complete, but I can do other things. If the Maven configuration (including downloading dependencies locally), I would have to stare at a wizard for an hour with wildfly from master on a clean Maven repo.

* how would a user on a new project know whether it's best to import with Maven or Gradle?

I guess you are coming from a different viewpoint here - importing small open source projects written by someone else. In those small projects, there is usually only one build system, so there would be no choice to make. I'm more concerned about large enterprise builds and there the developers know very well which build system is the "current" one and which is the "one we're migrating to".

The Smart Import is indeed more designed to have a good enough way to import any project quickly and always with the same workflow/UI. If some project are in a tricky state, it's possible that it may not be the best way to import it. People who know very well their project can and should prefer to select a dedicated import wizard if they're not satisfied with the proposals of Smart Import.
In the case of a project which has still pom and build.gradle, and which cannot copy with both in an IDE, then the user should get to the import wizard and select either m2e or BuildShip dedicated import.
 

Buildship is not far from being able to say "just use smart import". The remaining steps seems to be to Implement the project detection mentioned higher in this mail, and (depending on actual performances) to Implement configuration asynchronously like Maven did.

I hope my explanations have clarified a bit more how we are not that close yet. Let me propose another idea that moves more responsibility to the contributors, while still keeping one unified wizard:

1. User selects a root dir

2. Contributors are asked if they can provide a list of project names

3. User chooses a contriburor

4. The names provided by that contributor are shown for selection

5. The contributor is told to import those that the user selected

Now it is very important to note that those names are just identifiers for the contributor, not necessarily physical folders. So the Smart Importer does nothing itself, the contributor takes full control of how to actually imports the chosen projects. This reduces the amount of duplicated code and maximizes the possible performance.

All that is definitely interesting. The ability for contributors to recommend a name would be a nice addition. Can you please open a feature request and make me a CC ?
But to be honest, Smart Import works for several established Eclipse projects, and we're in the RC cycle for Platform. So the API is very unlikely to change at all before Oxygen.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets