Community
Participate
Working Groups
Artifact not-found-cache appears to be broken after I attempted to update embedded maven runtime to use maven 3.0.4-SNAPSHOT with aether 1.12 (did not check stock embedded maven runtime yet). I was able to track problems with persistent NFC to aether and filed https://issues.sonatype.org/browse/AETHER-123. 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. Need to investigate further if the problem is in m2e, maven, aether or somewhere inbetween the three. We should probably add regression tests for this scenario to m2e test suite as Maven tests proved to be unreliable to cover this scenario.
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?
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
