Skip to content
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

Maven repository is polluted with not existing dependencies #213

Closed
martinlippert opened this issue Apr 6, 2021 · 6 comments · Fixed by #497
Closed

Maven repository is polluted with not existing dependencies #213

martinlippert opened this issue Apr 6, 2021 · 6 comments · Fixed by #497
Labels
bug Something isn't working

Comments

@martinlippert
Copy link

We got this report on the Spring Tools distribution for Eclipse, but I think this is caused my the XML language server and its support for pom files:

spring-projects/sts4#618

@digulla
Copy link

digulla commented Jun 10, 2022

I think it would be better to delay the "try to resolve the dependency" until the POM is saved (or at least fetch a list of existing versions once and create one folder as you type each character).

I'm also seeing that all of Eclipse locks up when I'm editing the version of parent POM in a large (two 20+ modules project where one is the parent of the other), probably because the IDE tries to load the non-existing dependency in the UI thread. Maybe related to my comment in #246. Or is that a new/different issue?

@mickaelistria
Copy link
Contributor

I think it would be better to delay the "try to resolve the dependency" until the POM is saved (or at least fetch a list of existing versions once and create one folder as you type each character).

That would lead to a reduced feature. One benefit of always building and resolving is that users sees the effect of their change as-they-type, and it can easily become very productive; much more than when updating only on save.

I'm also seeing that all of Eclipse locks up when I'm editing the version of parent POM in a large (two 20+ modules project where one is the parent of the other), probably because the IDE tries to load the non-existing dependency in the UI thread. Maybe related to my comment in #246. Or is that a new/different issue?

This is most likely a different issue; or more accurately several ones (1 lock + 1 unexpectedly long operation).
The lock happening in Eclipse IDE, it should be reported there first; although some background work may not be complete yet, the UI shouldn't lock nor freeze.

@digulla
Copy link

digulla commented Jun 13, 2022

I don't like this approach. Here are my thoughts, let me know if this is correct.

My gut feeling is that there is a bug lurking: Why would m2e create folders on disk while I type? That should only happen when m2e resolves dependencies as I type which means using network resources. I don't feel comfortable with the IDE sending HTTP requests as I type; our company network, the mirror servers and especially Maven Central are not build for such loads and it also feels like a waste.

Therefore, the plugin should fetch a list of available versions once from the local mirror or Maven Central and cache this.
It should then use code completion against this list and not create a stream of broken artifacts on disk as I type. Especially not when every broken artifact is the result of a failed HTTP request.

This becomes more complicated when stable (Maven Central) and unstable (local builds) coordinates are mixed. It should be enough to fetch a list of coordinates from Maven Central once per day (if you really happen to need a release that was done 1 minutes ago, you just have to type the version manually without code completion). But for local stuff, it should just read what's on disk and not create anything new.

So maybe this is the source of my uneasiness: Typing in the editor should not create useless, broken artifacts on disk. I feel like you won't find anyone on the planet who would expect such a behavior.

@mickaelistria
Copy link
Contributor

Contributions to minimize network consumption and that which wouldn't reduce the usability would be very welcome.

@Tencryn
Copy link

Tencryn commented Jul 6, 2022

I do find the broken artifacts quite a pain, hundreds of unneeded folders is not desirable by what I'd imagine to be, most people. I don't have expert levels of knowledge by any means, but I do have a couple of suggestions.

A preference option could be added so that users can choose when Eclipse attempts to resolve artifacts, such as per keystroke, when saving, or strictly via "update project". This only reduces a feature if the user chooses such, defaulting to the current behaviour.

Another suggestion, which could go alongside the previous, is a button that will iterate through the local repository and remove obviously broken artifacts. Where that button could be, I'm uncertain, perhaps somewhere in preferences.

angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 7, 2023
angelozerr added a commit to angelozerr/lemminx-maven that referenced this issue Aug 8, 2023
@angelozerr
Copy link
Contributor

angelozerr commented Aug 8, 2023

Just for your information,to avoid breaking the existing mechanism and since now we have implemented dependency validation on the fly #479 I have worked to fix this issue with #497

The main idea is to have:

  • a temporary repository local where all downloads are done (this repo will be polluated)
  • the user local repository which will be keep clean (no download, no folder creation while the pom.xml is edting)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants