Bugzilla – Full Text Bug Listing
| Summary: | dependency resolution takes forever when missing dependencies | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Igor Fedorenko <igor> |
| Component: | m2e | Assignee: | Igor Fedorenko <igor> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | bentmann, scott_sosna |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Igor Fedorenko
confirmed the problem exists in current master HEAD too. (In reply to comment #0) > Even with patch for AETHER-123 applied, m2e still re-resolves the same missing > dependencies multiple times as part of single user-initiated update dependency > or project configuration request with "force dependency update" option set to > true. Since https://issues.sonatype.org/browse/AETHER-102, this kind of repeated rechecking despite updatePolicy=always can be surpressed as long as the same repository system session or at least the same session data is used throughout the process. Has there been any progress on this? Using maven version ranges, this takes forever, likely because how maven can't decide what version ranges mean, but also because m2e constantly fetches the same metadata files repeatedly. It would be preferred that the plugin uses the .m2 repository at all times and not load things into their own mini-version. It's another way how m2e doesn't always emulate maven correctly. (In reply to comment #3) > Has there been any progress on this? Using maven version ranges, this takes No, nothing has been done for this issue. IIRC, the problem had to do with m2e creating separate repository session for each project being resolved, so we need to change the code to reuse the same session throughout entire dependency resolution request. Not sure if this is related or not to the performance problem with version ranges. I suggest you open a new bugreport and provide small standalone example project we can use to reproduce the problem. > forever, likely because how maven can't decide what version ranges mean, but > also because m2e constantly fetches the same metadata files repeatedly. It > would be preferred that the plugin uses the .m2 repository at all times and > not load things into their own mini-version. It's another way how m2e > doesn't always emulate maven correctly. Not sure what you mean by "load things into their own mini-version". m2e does use .m2/repository Should be fixed in master now https://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=293a1c09ed3ec5401093b7b3b783ea161838b6f0 https://github.com/sonatype/m2e-core-tests/commit/e7b1b2d1186b5ecbdd5b48ca1193d4fc4ad1d85f (In reply to comment #5) > Should be fixed in master now > > https://git.eclipse.org/c/m2e/m2e-core.git/commit/ > ?id=293a1c09ed3ec5401093b7b3b783ea161838b6f0 > > https://github.com/sonatype/m2e-core-tests/commit/ > e7b1b2d1186b5ecbdd5b48ca1193d4fc4ad1d85f (In reply to comment #4) > (In reply to comment #3) > > Has there been any progress on this? Using maven version ranges, this takes > > No, nothing has been done for this issue. IIRC, the problem had to do with > m2e creating separate repository session for each project being resolved, so > we need to change the code to reuse the same session throughout entire > dependency resolution request. > > Not sure if this is related or not to the performance problem with version > ranges. I suggest you open a new bugreport and provide small standalone > example project we can use to reproduce the problem. > > > forever, likely because how maven can't decide what version ranges mean, but > > also because m2e constantly fetches the same metadata files repeatedly. It > > would be preferred that the plugin uses the .m2 repository at all times and > > not load things into their own mini-version. It's another way how m2e > > doesn't always emulate maven correctly. > > Not sure what you mean by "load things into their own mini-version". m2e > does use .m2/repository The m2e plugin keeps some metadata in the Eclipse workspace, so each new workspace has to reload the metadata, which can take a while with version ranges. >
> The m2e plugin keeps some metadata in the Eclipse workspace, so each new
> workspace has to reload the metadata, which can take a while with version
> ranges.
Can you be more specific? Can you provide a standalone example that demonstrates the performance problem?
|