maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karl Heinz Marbaise (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MNG-6412) Exceeding project discovery time when using CI friendly versions
Date Sun, 03 Jun 2018 14:02:00 GMT

    [ https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16499430#comment-16499430
] 

Karl Heinz Marbaise commented on MNG-6412:
------------------------------------------

Do those projects have many dependencies or dependencyManagement blocks or dependencies between
modules?

> Exceeding project discovery time when using CI friendly versions
> ----------------------------------------------------------------
>
>                 Key: MNG-6412
>                 URL: https://issues.apache.org/jira/browse/MNG-6412
>             Project: Maven
>          Issue Type: Bug
>    Affects Versions: 3.5.3
>            Reporter: Christoph Amshoff
>            Priority: Critical
>         Attachments: ci-version-validate.log, fix-version-validate.log, test-ci-project-scanning.zip
>
>
> We are switching a larger project to CI friendly versions ([https://maven.apache.org/maven-ci-friendly.html]),
using properties _${revision}_ (fix) and _${changelist}_ (maps to the CI build number) to
create the actual version. However, doing so, the project discovery time (right after Maven
says “Scanning for projects...”) increases dramatically from few seconds to more than
3 minutes, and we had to double the maximum heap in order to avoid “GC overhead limit exceeded”
exception.
> The project root POM looks like this:
> {noformat}
>   <groupId>test</groupId>
>   <artifactId>parent</artifactId>
>   <version>${revision}-${changelist}</version>
>   <packaging>pom</packaging>
>   ...
>   <properties>
>     <revision>1.0.0</revision>
>     <changelist>UNDEFINED</changelist>
>   </properties> {noformat}
> and is built by passing “-Dchangelist=123” to the Maven process for CI build 123,
for instance.
> In debug output, we can see that for each POM of the reactor there are messages like
these, repeatedly for every single parent POM up the complete hierarchy:
> {noformat}
> [DEBUG] Extension realms for project test:grandchild1-1:jar:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging jar from ClassRealm[plexus.core,
parent: null]
> [DEBUG] Extension realms for project test:child1:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from ClassRealm[plexus.core,
parent: null]
> [DEBUG] Extension realms for project test:parent:pom:1.0.0-123: (none)
> [DEBUG] Looking up lifecycle mappings for packaging pom from ClassRealm[plexus.core,
parent: null]
> {noformat}
> When using fix version string (release or SNAPSHOT), these messages are only present
for the reactor POMs, but not their parents, grand-parents, etc. up to the root POM.
> Looking up the lifecycle mapping for the same parent POMs over and over again seems wrong
to me, and is probably the cause of high memory consumption. Altogether, there are more than
2,800 messages "Looking up lifecycle mappings..." in the logs for about 350 subprojects built
in the reactor!
> See attached test projects and logs for fix version vs. CI friendly versions. The test
project structure is like this:
> {noformat}
> parent
>   child1
>     grandchild1-1
>     grandchild1-2
>   child2
>     grandchild2-1
>     grandchild2-2{noformat}
> If you compare both log files, you'll see the difference in project resolving.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message