eclipse / lemminx-maven

lemminx-maven
Eclipse Public License 2.0
38 stars 31 forks source link

Maven repository is polluted with not existing dependencies #213

Closed martinlippert closed 1 year ago

martinlippert commented 3 years ago

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:

https://github.com/spring-projects/sts4/issues/618

digulla commented 2 years ago

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 commented 2 years ago

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 https://github.com/eclipse/lemminx-maven/issues/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 commented 2 years ago

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 commented 2 years ago

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

Tencryn commented 2 years ago

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 commented 1 year ago

Just for your information,to avoid breaking the existing mechanism and since now we have implemented dependency validation on the fly https://github.com/eclipse/lemminx-maven/pull/479 I have worked to fix this issue with https://github.com/eclipse/lemminx-maven/pull/497

The main idea is to have: