-
Notifications
You must be signed in to change notification settings - Fork 116
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve the user-experience with connectors #1012
Comments
Item 2 and 3 seem consensual and could be implemented without much disruption. |
For the first item I just wondering why should I not want to install it if:
Another way would be that we add as much connectors (even external ones) we see useful by the default m2e installation (e.g. with a m2e-connectors feature) if we can get IP clearance, for example Visual studio says:
so disk space seems not that much of a concern for users and we would only add a few mega-bytes (as most connectors are really small!) |
There is another concern in the quality of connectors: some of them just are not good and do not make the IDE better; some others are good and do what one expects but come with a ton of other UI elements that are not desired because the grain is too coarse... We do not know what user want; I personally wouldn't like to get some connectors automatically installed just to hack some pom.xml quickly. So there should be at least a warning on the 1st attempt to auto-download that would allow user to not automatically install connectors. |
I think that are all valid points I just wondering how should a user decide on this beforehand? |
Good question. Based on my experience with connectors, my strategy is to not install them and start working without them and only install them if I sense my workflow is inefficient because of missing integration of this or that connector. |
But even then you can trap into one of
So probably it would really be the best to require some kind of "quality gate":
Currently its quite we recommend to install the connector (green checkmark) so user would expect its fine to install them and as there are no other measures could not really "decide". Except for some expert like you that know what connectors are, how they work, and when to use them or not. |
I don't believe expecting someone to spend time trying connectors to definie universally what's good or not can work as 1. I don't believe it's a motivating task, so I don't think anyone will ever take care of it -after all same is true for most "marketplaces" and 2. I don't believe that "good enough" is an absolute state but more something that depend on each user according to their needs, liking, priorities...
I think it's OK to recommend the installation; but recommending (ie showing a subset of a catalog) is less intrusive than auto-installing. |
The good thing is that the planing council has approved m2e to be added to the funded development efforts: https://wiki.eclipse.org/Planning_Council/2022-11-02 so hopefully there will be some "motivation" (a german comedian sometimes starts his show with the sentence "Actually I would not like to be here but I was forced - with money!) and thus I think its not entirely hopeless. At least I more like to gather some points what would be the best, then we can decide if/how to archive and come out with at laest something good :-) |
One thing for example I think would be useful is, that m2e records statistics about the runtime and probably even errors that occur while execution. If we detect that some mojo is really slow, or a connector often throws errors (instead of reporting them to the BuildContext), we can ask the user:
|
I think the connector quality discussion is a result of delegating work without educating. The concept of connectors sounds nice from a technical (osgi, extensibility) perspective. However, from my experience it fails because when people write a Maven mojo to integrate their tool into Maven, they are already dealing with the complexity of Maven. It's too much of an ask to also require them to learn Eclipse specific code and processes ((M2E, Tycho, p2, etc.) just for making it work in Eclipse. They would rather say no and use IJ or some other IDE. I am a big +1 on inner-sourcing all connectors into a M2E connectors git/project with full write access for M2E committers. IMO this way, the whole 2.0 disaster, which broke all connectors for no good reason (osgi/p2 versioning issue), could have been avoided. |
It is not a requirement that the mojo-author is the connector author. And it is not a requirement to "make it work with eclipse".
Connectors where "broke" because no one maintains them and m2e can't maintain them for others that are to lazy, have lost interest or whatever.... So for most people contribution to m2e/connector this was simply not a problem. |
One important goal here would be to better support the plexus-build-api, that way most connectors can become obsolete anyways. For this we would require: |
I often deliberately do not install suggested connectors as they conflict with other connectors or cause some regressions. The quality of the connectors listed in https://github.com/eclipse-m2e/m2e-discovery-catalog is not assured by anyone and therefore installing them must be handled with extreme care. |
We should then remove those from the cataloger... A user has nearly no way to "guess" how good a connector is so offering them something to install where we are not sure if it helps or even causes issues is defiantly bad. Probably we can have some kind of incubator connectors or something then. |
I don't think that there is capacity to do this kind of QA for third party connectors. Also in some cases they just conflict with another connector (so it is totally fine for some users not using the other connector). This is due to the fact that M2E does not really deal well with e.g. multiple Maven Project Configurators for the same packaging/mojo provided by extensions. |
The we should not offer any such connectors by default... having arbitrary content suggested to the user is really not giving good user experience.
Can you please open specific issues for this and link them here? m2e should have now enough knowledge to decide the version of a packaging type as well. |
Eclipse Marketspace (and in general open source) works quite differently than e.g. Apple App Store. Everything should be listed here anyone submitted (and therefore deemed useful). m2e committers or anyone else should not evaluate the listing, because as I said, it may be useful for some but break stuff for others. |
The difference is that the marketplace is only show on user request, you have detailed information and user ratings and so on. The connectors are shown as a prerequisite to work with m2e and users won't be able to distinguish between "offered by m2e" or "offered by random 3rd party project" here. |
I created to get some feedback how we should design m2e so it fits best into Eclipse. |
Also related here as if a connector installs additional builds but these do not behave good one gets disturbing error popups: |
Currently if not a single connector can be proposed the dialog is still opened and disturbs the user even though there is nothing much one can do (and most probably want to do). This first checks if there is at least one proposal before open the dialog when importing a project. This relates to eclipse-m2e#1012
One reason for the bad user-experience in the mentioned example is that junit5 is actually a gradle project but buildship currently do not provide integration with smartimport so I trying to revive: |
Currently if not a single connector can be proposed the dialog is still opened and disturbs the user even though there is nothing much one can do (and most probably want to do). This first checks if there is at least one proposal before open the dialog when importing a project. This relates to #1012
Another disturbing dialog: |
I assume this done with the recent changes, for further improvements the linked issues should be used. |
At EclipseCon 2022 it was complained that the Connector Install Dialog lacks good user-experience.
I could think about the following improvements:
The text was updated successfully, but these errors were encountered: