hboutemy commented on pull request #526: URL: https://github.com/apache/maven/pull/526#issuecomment-903290931
> If I recall correclty there were one or two existing classes that needed to be extended to be able to support the cache. Could we move those to a separate PR? That will make reduce the amount of code to validate the rest of the and gives us enough time to experiment with it. > One of the things we need to discuss is whether the rest of the code should be moved to an extension. > With a separate PR we can verify all options. from first PR review, most code is put in `maven-core` in a new `org.apache.maven.caching` Java package (and generated jaxb sub-package): I suppose this whole code could me moved to a separate `maven-caching` Maven module... this caching is injected in `maven-core` through quite a few core classes modifications: - org.apache.maven.graph.DefaultGraphBuilder - org.apache.maven.lifecycle.internal.DependencyContext - org.apache.maven.lifecycle.internal.MojoExecutor - org.apache.maven.lifecycle.internal.NoResolutionContext - org.apache.maven.plugin.DefaultBuildPluginManager - org.apache.maven.plugin.MojoCheker - org.apache.maven.plugin.MojoExecution - org.apache.maven.project.DefaultProjectBuilder - org.apache.maven.project.MavenProject I fear swiching these updates to core extension will be hard... on how to learn the code, I don't see the PR being split in multiple PRs, but perhaps the unique commit being split in multiple one source of noisy modifications (and many new dependencies addition) is using jaxb to read XML config files instead of using our usual Modello -- 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
