cstamas edited a comment on pull request #158: URL: https://github.com/apache/maven-resolver/pull/158#issuecomment-1076065668
> @cstamas Should I create a JIRA for the reuse of [node children cache](https://github.com/bfs-skip/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DataPool.java#L72), like you found out, it don't need to be static (should be ConcurrentHashMap to support -T), just need to reuse that in constructor: DataPool pool = new DataPool( session );? > > Another thing we could do later is to reverse versions (already reversed in the skipper PR) and add a break once at least one version has been resolved to speed up version range resolution which is for MRESOLVER-133. [code here](https://github.com/apache/maven-resolver/blob/master/maven-resolver-impl/src/main/java/org/eclipse/aether/internal/impl/collect/DefaultDependencyCollector.java#L401) I tested that locally, and it miserably failed (resolver build passed, but building anything with mvn using altered resolver failed, usually with some dep not on classpath). To me it seems re-using nodes cache is a no-go, still unsure why.... My initial guess: due post-processing (like scope etc). So maybe we need to cache "raw" graph instead (but that would require a LOT of heap). Also, will look into at least carry-on caching of resolved versions, as we do that as well over and over again.... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
