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

[Stefan Oehme <st.oehme@xxxxxxxxx>]

2016-05-15 21:16 GMT+02:00 Mickael Istria <mistria@xxxxxxxxxx>:

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

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.

I guess I was a little fuzzy about what's the current behavior and what we plan for the future. Currently we do behave just like m2e does. But this is causing all kinds of limitations (like dependency conflicts, wrong runtime classpaths etc.) that can only be solved by separating projects. We are getting complaints about these from our users almost daily, so this more complex (but also more correct) model is high on our to-do list.

I think Smart Import can be adjusted to accomodate this. Thanks to your explanations I'm slowly building a mental model how we could integrate the two with relatively little change.

 

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?

Because the user gives his Gradle projects names and of course expects those to be reflected in Eclipse.

 

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?

We use what the user tells us and de-duplicate by prepending the parent names if there is a clash.

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. 

How do you do it at once? As far as I saw the API has a per-project callback and says "these methods should be stateless". If there is some hook for "Configure all of these in a batch", then that would work for Buildship.

 

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.

We agree on that. I was assuming you are configuring one by one, which would make browsing impossible due to UI thread pressure. But based on your comment above, there seems to be some way to batch all the configuration, which is great :)

 

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.

Okay, if Smart Import is not targeted at such projects, then we need "Import using Import Project Wizard" in EGit to make those advanced users happy. I'll get back to you on this on the other feature request.

 

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 ?

Before we get into details, let me summarize how we could (with minimal changes) make this work:

- Buildship gives you folders + the project names they should have

- You import each of those folders with the desired name

- Some folders might not exist yet, so you create them for us if the user selects them

- There is some way for Buildship to "collect" all the projects it needs to configure and to know when all of them are "ready to be configured" in one big batch.

Does that sounds reasonable?

 

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.

I know it's too late for big changes in Neon, but I need to give our users some timeline. Thanks to your comments it seems we can create some basic integration in Neon and then improve especially the performance in Neon.1

Cheers,

Stefan