[
https://issues.apache.org/jira/browse/MBUILDCACHE-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652081#comment-17652081
]
ASF GitHub Bot commented on MBUILDCACHE-25:
-------------------------------------------
AlexanderAshitkin commented on code in PR #34:
URL:
https://github.com/apache/maven-build-cache-extension/pull/34#discussion_r1057395224
##########
src/main/java/org/apache/maven/buildcache/xml/CacheConfigImpl.java:
##########
@@ -81,6 +81,7 @@ public class CacheConfigImpl implements
org.apache.maven.buildcache.xml.CacheCon
public static final String CONFIG_PATH_PROPERTY_NAME =
"maven.build.cache.configPath";
public static final String CACHE_ENABLED_PROPERTY_NAME =
"maven.build.cache.enabled";
public static final String CACHE_LOCATION_PROPERTY_NAME =
"maven.build.cache.location";
+ public static final String REMOTE_URL_PROPERTY_NAME =
"maven.build.cache.remoteUrl";
Review Comment:
Yes, with this change is to set remote cache url from command line in
integration tests to test remote cache interactions using WireMock. The change
allows to use using dynamic WireMock ports to prevent port conflicts in tests
> Project processed multiple time in presence of forked executions
> ----------------------------------------------------------------
>
> Key: MBUILDCACHE-25
> URL: https://issues.apache.org/jira/browse/MBUILDCACHE-25
> Project: Maven Build Cache Extension
> Issue Type: Bug
> Reporter: Alexander Ashitkin
> Priority: Minor
> Labels: pull-request-available
>
> In forked executions present in build, project goes through full lifecycle
> multiple times - one time for project itself + 1 time for each forked
> execution (could be 5, 10 - depends on configuration):
> * checksum will be calculated multiple times
> * artifacts uploaded multiple times
> The issue is manifested by multiple cache calculation log records for the
> same project:
> {noformat}
> LOGGER.info( "Going to calculate checksum for project [groupId=" +
> project.getGroupId()
> + ", artifactId=" + project.getArtifactId() + "]" );{noformat}
> The issue initially observed with PMD and Spotbugs plugins
> h3. Impact
> No functional impact observed, just unnecessary performance penalty on cache
> h3. Cause
> For every forked execution MojoExecutor clones project per forked execution.
> Each forked project goes through full cache lifecycle:
> {code:java}
> // public List<MavenProject> executeForkedExecutions( MojoExecution
> mojoExecution, MavenSession session,
> ProjectIndex projectIndex )
> throws LifecycleExecutionException
> {
> ...
> Map<String, List<MojoExecution>> forkedExecutions =
> mojoExecution.getForkedExecutions();
> if ( !forkedExecutions.isEmpty() )
> {
> ...
> try
> {
> for ( Map.Entry<String, List<MojoExecution>> fork :
> forkedExecutions.entrySet() )
> {
> MavenProject executedProject = forkedProject.clone();
> forkedProject.setExecutionProject( executedProject );
> List<MojoExecution> mojoExecutions = fork.getValue();
> ...
> try
> {
> ...
> // here cloned project enters cache as a standalone
> project
> execute( session, mojoExecutions, projectIndex );{code}
> Additional notes: the cloning doesn't affect effective pome, so checksum is
> stable and the same in all calculations
> Proposed solution: reuse calculated inputs from cache
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
