Quickfix to add a maven dependecy automatically to the target if a missing type is found

[laeubi]

Most people have a lot of stuff already in their local maven repository, and we can use this rich meta-data for the following purpose:

1. Index all artifacts and their classes
2. If a users uses a Type found in the local repository we could suggest to add the item to the target, reload the target platform, and add an appropriate import

[HannesWell]

In general a good proposal.

1. Index all artifacts and their classes

But creating and maintaining the index sounds like a very expensive operation and we don't get notified about all changes in the local maven repo. Also the question is if that index is saved somewhere (potentially large) or recreated in memory everytime the IDE is started (potentially long running).

The good news is that search.maven.org already maintains such index and provides access to it via their REST API: https://central.sonatype.org/search/rest-api-guide/

https://search.maven.org/solrsearch/select?q=c:junit&rows=20&wt=json | Mimics searching by classname in Advanced Search. Returns a list of artifacts, down to the specific version, containing the class. -- | --

[lukaseder]

I suspect this feature has shipped already, in Eclipse 2023-03, for example? I personally don't really like it. I hardly ever need to add new dependencies, and if I do, I want to do that manually, and carefully. Yet, every time I quick fix, I get tons of these m2e options that I never select:

It would be great if I could deactivate this addition. See also: https://stackoverflow.com/q/75746202/521799

[laeubi]

@lukaseder you could provide a patch for a configuration option to disable this if you like.

[howlger]

To support different ways of working out of the box, there are also the following options:

• Propose only Add Maven dependency containing 'List'... that opens a separate dialog
• Move the proposal(s) to the bottom

[laeubi]

I suspect this feature has shipped already

Actually this is about another feature (the pde-target integration), so this is not shipped but a different feature.

To support different ways of working

I think the best would be if there is a check if it could be fixed by a simple import (what is represented as first choice here) because then most likely one don't want to add new dependencies.

Weather or not one "like it" or not, if it is more or less important (should be more on top or more on bottom) also depends a bit on the user ... so if one like a configuration option seems both easy to archive and most flexible.

Probably also the search algorithm can be enhance... currently it looks in the workspace projects if any of them can provide the type List (what is maybe a too broad term for any type search anyways), so one might check if the Type is directly in that project or only indirectly and so on ... pull request for enhancing this are welcome :-)

[howlger]

I suspect this feature has shipped already

Actually this is about another feature (the pde-target integration), so this is not shipped but a different feature.

So this issue is about a not yet implemented quick fix that should be provided on an import statement that cannot be resolved, whereas @lukaseder is talking about the quick fix that is provided on a type that cannot be resolved and that was introduced by commit https://github.com/eclipse-m2e/m2e-core/commit/a743960dc0d4c2f826ac596fbc4c3c4fbebafe1d and therefor included in Eclipse 2022-12 and 2023-03, right?

I guess it would be better to have a separate issue on what @lukaseder is talking about and to which my comment referred.

[lukaseder]

I guess it would be better to have a separate issue on what @lukaseder is talking about and to which my comment referred.

I'm sorry for the confusion. I was pointed here by a comment on Stack Overflow.

[laeubi]

@howlger correct, I'm not sure why this issue was used for commenting because it is not referenced in the commit (was merged with https://github.com/eclipse-m2e/m2e-core/pull/1048 ) so open a new issue would be most suitable.

Basically there are two "things":

1. If there is a missing TypeX and one of your workspace projects has a TypeX and it is a maven project m2eclipse offers to add that project as a dependency. I find this quite handy, because otherwise one need to do a type search in the workspace, check if the type is from a project, then navigate to the project and find out the project artifact+group id, open the pom.xml and add it to the dependency section (probably creating one from scratch if not already there). Of course as you said, different users might work differently, so I think if there is anything to improve the feature it would be great. Best would be of course instead of on/off to make it more useful.
2. If there is a missing TypeX and there is some "repository index" (e.g. maven-central) one might want to extend the target-platform (!) to add the dependency, this would be independent of if this is a maven project, because that's a feature of PDE (that m2e extends).

I'm sorry for the confusion. I was pointed here by a comment on Stack Overflow.

No problem, I think the general points might still be valid for this issue as well.

[kjaranso]

I would also like to have a way to disable this feature or improve its performance. In my case, I've run into cases where doing the quick fix locks up eclipse for a minute or two before it finally responds again with the quick fix answer. Different quick fixes result in different response times.

The worst has been when clicking on the red X next to a lombok Builder annotation: When I clicked on that most recently, it hung for 2 minutes 14 seconds before it returned a response. It included the correct lombok import along with 13 or so other m2 import options that were not what I wanted. I have 18 projects in my eclipse workspace currently. It sounds like if I removed them all, it would speed things up, but that doesn't seem like something I should have to do. I'm running eclipse on a dedicated linux machine. This same quick fix solution had previously returned almost right away before the update that includes the m2 solutions.

So if anyone is able to make it be some option to include or not include these, that would be great. Or if there was some optimization to make it faster, that would also be great, though that is likely a lot more difficult as my situation may not be easily repeatable for others.

[howlger]

I'm sorry for the confusion. I was pointed here by a comment on Stack Overflow.

@lukaseder I pointed you to the commit and ask you to report it as a new issue. Someone else has wondered why the mistakenly considered as the corresponding issue has not been closed yet. From my experience, projects want users to report issues of released features as new issues, rather than reopening issues or commenting on issues that are not yet closed or related.

@kjaranso You are commenting at the wrong issue, as explained above.

Please comment and/or vote here instead:

• Pull request #1329: Disable "Add ... dependency" quick fix due to bad user feedback
• Issue #1328: Fix and improve m2e "Add ... dependency" quick fix

As workaround to disable the m2e "Add ... dependency" quick fix, manually apply pull request #1329 and then start Eclipse with -clean.