[jira] [Commented] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500401#comment-16500401
]
Christoph Amshoff commented on MNG-6412:
Yes, it's a complex project with 350+ POM files and lots of dependencies, also
between modules (no cycles, though). We're using both managed and unmanaged
dependencies. Still, this was never a problem regarding project discovery time,
until switching to versions using those properties.
> 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}
> test
> parent
> ${revision}-${changelist}
> pom
> ...
>
> 1.0.0
> UNDEFINED
> {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)
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Description:
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}
test
parent
${revision}-${changelist}
pom
...
1.0.0
UNDEFINED
{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.
was:
We are switching a larger project (> 350 subprojects) 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}
test
parent
${revision}-${changelist}
pom
...
1.0.0
UNDEFINED
{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.
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.
> 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,
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Description:
We are switching a larger project (> 350 subprojects) 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}
test
parent
${revision}-${changelist}
pom
...
1.0.0
UNDEFINED
{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.
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.
was:
We are switching a larger project (> 350 subprojects) 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}
test
parent
${revision}-${changelist}
pom
...
1.0.0
UNDEFINED
{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.
See attached test projects and logs for fix version vs. CI friendly versions.
> 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 (> 350 subprojects) 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
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Attachment: fix-version-validate.log
ci-version-validate.log
> 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 (> 350 subprojects) 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}
> test
> parent
> ${revision}-${changelist}
> pom
> ...
>
> 1.0.0
> UNDEFINED
> {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.
> See attached test projects and logs for fix version vs. CI friendly versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Attachment: (was: ci-version-validate.log)
> 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 (> 350 subprojects) 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}
> test
> parent
> ${revision}-${changelist}
> pom
> ...
>
> 1.0.0
> UNDEFINED
> {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.
> See attached test projects and logs for fix version vs. CI friendly versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Attachment: (was: fix-version-validate.log)
> 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 (> 350 subprojects) 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}
> test
> parent
> ${revision}-${changelist}
> pom
> ...
>
> 1.0.0
> UNDEFINED
> {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.
> See attached test projects and logs for fix version vs. CI friendly versions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Description:
We are switching a larger project (> 350 subprojects) 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}
test
parent
${revision}-${changelist}
pom
...
1.0.0
UNDEFINED
{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.
See attached test projects and logs for fix version vs. CI friendly versions.
was:
We are switching a larger project (> 350 subprojects) 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}
test
parent
${revision}-${changelist}
pom
...
1.0.0
UNDEFINED
{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.
> 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 (> 350 subprojects) 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}
> test
> parent
>
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Attachment: ci-version-validate.log
> 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 (> 350 subprojects) 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}
> test
> parent
> ${revision}-${changelist}
> pom
> ...
>
> 1.0.0
> UNDEFINED
> {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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Attachment: test-ci-project-scanning.zip
> 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: fix-version-validate.log, test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) 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}
> test
> parent
> ${revision}-${changelist}
> pom
> ...
>
> 1.0.0
> UNDEFINED
> {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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MNG-6412) Exceeding project discovery time when using CI friendly versions
Christoph Amshoff created MNG-6412:
--
Summary: 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
Attachments: fix-version-validate.log, test-ci-project-scanning.zip
We are switching a larger project (> 350 subprojects) 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}
test
parent
${revision}-${changelist}
pom
...
1.0.0
UNDEFINED
{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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6412) Exceeding project discovery time when using CI friendly versions
[
https://issues.apache.org/jira/browse/MNG-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Amshoff updated MNG-6412:
---
Attachment: fix-version-validate.log
> 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: fix-version-validate.log, test-ci-project-scanning.zip
>
>
> We are switching a larger project (> 350 subprojects) 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}
> test
> parent
> ${revision}-${changelist}
> pom
> ...
>
> 1.0.0
> UNDEFINED
> {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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MDEPLOY-221) deploy generates wrong timestamps in maven-metadata.xml
[
https://issues.apache.org/jira/browse/MDEPLOY-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164409#comment-16164409
]
Christoph Amshoff commented on MDEPLOY-221:
---
@Rob, unfortunately, Maven 3.5.1 is not released yet. See
https://issues.apache.org/jira/projects/MNG/versions/12338964 for progress.
As also commented on MNG-6240, this is a blocker IMHO and should be
fixed/released as soon as possible, but sadly nobody seems to take care...
> deploy generates wrong timestamps in maven-metadata.xml
> ---
>
> Key: MDEPLOY-221
> URL: https://issues.apache.org/jira/browse/MDEPLOY-221
> Project: Maven Deploy Plugin
> Issue Type: Bug
> Components: deploy:deploy
>Affects Versions: 2.8.2
>Reporter: Roland Illig
>Assignee: Guillaume Boué
>
> When deploying an artifact to a Nexus server, the file {{maven-metadata.xml}}
> can end up with inconsistent timestamps.
> {noformat}
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 24 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 171 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.jar
> (18 kB at 591 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76.pom
> (2.2 kB at 71 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 43 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 33 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 40 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/artifactId-31.0.0-20170510.070327-76-sources.jar
> (12 kB at 386 kB/s)
> [INFO] Downloading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> [INFO] Downloaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/maven-metadata.xml
> (1.2 kB at 92 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 59 kB/s)
> [INFO] Uploading:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Uploaded:
> http://nexus-url/content/repositories/snapshots/groupId/artifactId/31.0.0-SNAPSHOT/maven-metadata.xml
> (1.9 kB at 65 kB/s)
> [INFO] Uploading:
>
[jira] [Commented] (MNG-6240) Duplicate components in plugin extension realm when plugin depends on maven-aether-resolver
[
https://issues.apache.org/jira/browse/MNG-6240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158685#comment-16158685
]
Christoph Amshoff commented on MNG-6240:
I'm sorry if this is annoying, but this issue is clearly a blocker since it
randomly breaks builds, and going back to Maven 3.3.9 is not always an option.
So what exactly is the reason we can't get some kind of release where this is
fixed, nearly 3 months after the issue has been marked as closed? 3.5.1-alpha
or such would be fine in case some other planned issues still need a review.
Moreover, I agree with Jay mann's comment on MDEPLOY-221 that the version 3.5.0
should be marked as buggy on the Maven homepage, or perhaps even revoked.
Please, don't let Maven users run into this without giving a heads-up, and
without a chance to get around it!
> Duplicate components in plugin extension realm when plugin depends on
> maven-aether-resolver
> ---
>
> Key: MNG-6240
> URL: https://issues.apache.org/jira/browse/MNG-6240
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
>Affects Versions: 3.5.0
>Reporter: Guillaume Boué
>Assignee: Guillaume Boué
> Fix For: 3.5.1
>
>
> When a plugin extension has a dependency on {{maven-aether-resolver}}, the
> components of this artifact are added into the plugin realm even though Maven
> Core already provides them. This is a regression introduced by the rename of
> this module to {{maven-resolver-provider}} in 3.5.0.
> This rename has kept all the classes of {{maven-aether-resolver}} for
> compatibility, therefore the old artifact name also needs to be exported by
> Maven Core in {{extension.xml}}.
> A visible side-effect of this is MDEPLOY-221, where the two
> {{MetadataGeneratorFactory}} components of {{maven-aether-provider}} (which
> are {{SnapshotMetadataGeneratorFactory}} and
> {{VersionsMetadataGeneratorFactory}}) are present twice as Guice bindings,
> and wrong metadata information is deployed as a consequence. This is due to
> the Flex Mojos plugin extension which depends on {{maven-aether-resolver}}
> used in the build.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (MNG-6253) Replace CI friendly variables in pom.xml when installing/deploying
Christoph Amshoff created MNG-6253:
--
Summary: Replace CI friendly variables in pom.xml when
installing/deploying
Key: MNG-6253
URL: https://issues.apache.org/jira/browse/MNG-6253
Project: Maven
Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Christoph Amshoff
When using variables in pom.xml to get CI friendly version
(https://maven.apache.org/maven-ci-friendly.html), these will not be replaced
in installed or deployed pom files, which makes them unusable for other builds.
Karl Heinz Marbaise suggested to use the flatten-maven-plugin to do the
property replacement
(http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
and this was also suggested as a workaround in other tickets (MDEPLOY-223 got
closed with "Not A Problem" solution).
That indeed works, but flatten-maven-plugin has to be manually configured in
the base POM, and additionally it changes the pom files in many other areas
which you would not want.
I honestly think that property replacement for the three allowed properties
({{$\{revision\}}}, {{$\{sha1\}}}, {{$\{changelist\}}}) should be done by Maven
internally without having the user configure other plugins. The feature is just
not correctly working without, so closing such issues with "Not A Problem" is
too little.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (MNG-6253) Replace CI friendly variables in pom.xml when installing/deploying
[
https://issues.apache.org/jira/browse/MNG-6253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16080384#comment-16080384
]
Christoph Amshoff commented on MNG-6253:
I just discovered there is a related issue for flatten-maven-plugin
(https://github.com/mojohaus/flatten-maven-plugin/issues/51), which is answered
by
{quote}
I think if maven started follow this way (support dynamic properties in
version) they have to complete their solution within deploy properly pom.xml
(with version replacement) to repository.
{quote}
> Replace CI friendly variables in pom.xml when installing/deploying
> --
>
> Key: MNG-6253
> URL: https://issues.apache.org/jira/browse/MNG-6253
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Christoph Amshoff
>
> When using variables in pom.xml to get CI friendly version
> (https://maven.apache.org/maven-ci-friendly.html), these will not be replaced
> in installed or deployed pom files, which makes them unusable for other
> builds.
> Karl Heinz Marbaise suggested to use the flatten-maven-plugin to do the
> property replacement
> (http://blog.soebes.de/blog/2017/04/02/maven-pom-files-without-a-version-in-it/),
> and this was also suggested as a workaround in other tickets (MDEPLOY-223
> got closed with "Not A Problem" solution).
> That indeed works, but flatten-maven-plugin has to be manually configured in
> the base POM, and additionally it changes the pom files in many other areas
> which you would not want.
> I honestly think that property replacement for the three allowed properties
> ({{$\{revision\}}}, {{$\{sha1\}}}, {{$\{changelist\}}}) should be done by
> Maven internally without having the user configure other plugins. The feature
> is just not correctly working without, so closing such issues with "Not A
> Problem" is too little.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] Commented: (MCHECKSTYLE-105) Update to Checkstyle 5.0
[ http://jira.codehaus.org/browse/MCHECKSTYLE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179164#action_179164 ] Christoph Amshoff commented on MCHECKSTYLE-105: --- This is a rather critical issue people are waiting to be fixed...! So, instead of suggesting to execute the checkout-patch-build-deploy phases locally by everybody, how about providing something like an official 2.4-SNAPSHOT version? Or maybe 2.4-alpha since we were told to not use SNAPSHOT versions of plugins? What are the plans? Java 5 is out now for quite a while, and it's annoying how the Checkstyle/Maven toolchain continues to ignore this fact, so **please** let's have progress here. Update to Checkstyle 5.0 Key: MCHECKSTYLE-105 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Felix Röthenbacher Assignee: nicolas de loof Fix For: 2.4 Attachments: patch.diff, update-to-5.0beta2.patch Checkstyle 5.0-beta01 adds support for generics, etc. See http://checkstyle.sourceforge.net/5.x/releasenotes.html for a list of new features. Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is available from a public Maven repository. Patch updates plugin to changed API / implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-71) Documentation: wrong usage of unCheckedPluginsList option in sample
Documentation: wrong usage of unCheckedPluginsList option in sample --- Key: MENFORCER-71 URL: http://jira.codehaus.org/browse/MENFORCER-71 Project: Maven 2.x Enforcer Plugin Issue Type: Bug Affects Versions: 1.0-beta-1, 1.0-alpha-4 Environment: Win XP, Maven 2.1.0-M1 Reporter: Christoph Amshoff In the plugin's documentation of requirePluginVersions enforcer rule, the given sample code is wrong (see http://maven.apache.org/enforcer/enforcer-rules/requirePluginVersions.html). The option unCheckedPluginsList must not be put below the rules node, but rather as a sibling of that below the configuration node. Given example causes an error with 1.0-alpha-4 and 1.0-beta-1. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHECKSTYLE-105) Update to Checkstyle 5.0-beta01
[ http://jira.codehaus.org/browse/MCHECKSTYLE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=175284#action_175284 ] Christoph Amshoff commented on MCHECKSTYLE-105: --- Folks, what is the status here? If there already is a working patch available, what else is required to build a new release of this plugin? This is really critical, so can we please have a new version -- even some beta version would do it...! Update to Checkstyle 5.0-beta01 --- Key: MCHECKSTYLE-105 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Felix Röthenbacher Fix For: 2.3 Attachments: patch.diff, update-to-5.0beta2.patch Checkstyle 5.0-beta01 adds support for generics, etc. See http://checkstyle.sourceforge.net/5.x/releasenotes.html for a list of new features. Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is available from a public Maven repository. Patch updates plugin to changed API / implementation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2632) Setting property in profiles is not evaluated for POM validation
Setting property in profiles is not evaluated for POM validation
Key: MNG-2632
URL: http://jira.codehaus.org/browse/MNG-2632
Project: Maven 2
Issue Type: Bug
Components: POM
Affects Versions: 2.0.4
Environment: WinXP
Reporter: Christoph Amshoff
There seems to be a problem concerning POM validation and setting properties in
profiles.xml: when I set a property in my profiles.xml it is not evaluated for
POM validation in a multi module build.
The details: My project C depends on module B, which itself is a child of
module A. Module A defines a system scope dependency like this:
{code}
dependency
groupIddb2/groupId
artifactIddb2/artifactId
version8.2/version
scopesystem/scope
systemPath${path.db2jar}/systemPath
/dependency
{code}
The path to db2.jar depends on the developer's machine and is specified in the
profiles.xml, toghether with other settings. Both A and B are building and
deploying fine.
Now, when I try to build C, it complains about missing definition for
'path.db2jar':
{code}
[WARNING] POM for '...B:pom:4.4.0-SNAPSHOT:compile' is invalid. It will be
ignored for artifact resolution. Reason:
Failed to validate POM
[DEBUG] Reason: Failed to validate POM
[DEBUG]
Validation Errors:
[DEBUG] For dependency Dependency {groupId=db2, artifactId=db2, version=8.2,
type=jar}: system-scoped dependency
must specify an absolute path systemPath.
{code}
I'm using a profiles.xml section like this one:
{code}
profile
idenv-nb/id
activation
property
nameenv/name
valuenb/value
/property
/activation
properties
path.db2jarc:/programme/IBM/SQLLIB/java/db2java.zip/path.db2jar
...
/properties
/profile
{code}
which is triggered by -Denv=nb, and this activation is working fine since
'help:effective-pom' is correctly showing me something like
{code}
properties
path.db2jarc:/programme/IBM/SQLLIB/java/db2java.zip/path.db2jar
...
/properties
{code}
So the profiles.xml seems to be evaluated correctly, but the property is not
used for validating the POM of dependent modules.
And yes, when I run Maven without the profiles.xml, but with specifying the
property on command line (like '-Dpath.db2jar=...'), all is working fine! But
that's not exactly what we want, since profiles are meant to encapsulate those
kind of settings...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-232) Improve error message when CVS URL is not correct
[ http://jira.codehaus.org/browse/SCM-232?page=comments#action_75660 ]
Christoph Amshoff commented on SCM-232:
---
Sure. The (wrong) URL we used was:
scm:cvs:pserver:${cvs.user}:@server:/home/cvs/sss:foundation
where the CVS URL is wrong. The cvs.user is set to a correct user while the
error message is telling the opposite. Correct (and working) is this one, using
the correct CVS path to our foundation project:
scm:cvs:pserver:${cvs.user}:@server:/home/cvs/sss:SSS/foundation
Improve error message when CVS URL is not correct
-
Key: SCM-232
URL: http://jira.codehaus.org/browse/SCM-232
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-cvs
Affects Versions: 1.0-beta-3
Environment: Win XP
Reporter: Christoph Amshoff
When the CVS URL is not correct because the module name is misspelled, the
error output always is Embedded error: Exception while executing SCM
command. Username isn't defined.
This is misleading, since the username is definitely correct. This took me
more than 2 hours to figure out and should be fixed by issuing a more
applicable error message.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-232) Improve error message when CVS URL is not correct
[ http://jira.codehaus.org/browse/SCM-232?page=comments#action_75662 ]
Christoph Amshoff commented on SCM-232:
---
Just saw Jira has problems with the server substitution server in my
previous comment. I'll show the two URLs again, now using (server) instead of
real server name:
wrong: scm:cvs:pserver:${cvs.user}:@(server):/home/cvs/sss:foundation
correct: scm:cvs:pserver:${cvs.user}:@(server):/home/cvs/sss:SSS/foundation
Improve error message when CVS URL is not correct
-
Key: SCM-232
URL: http://jira.codehaus.org/browse/SCM-232
Project: Maven SCM
Issue Type: Bug
Components: maven-scm-provider-cvs
Affects Versions: 1.0-beta-3
Environment: Win XP
Reporter: Christoph Amshoff
When the CVS URL is not correct because the module name is misspelled, the
error output always is Embedded error: Exception while executing SCM
command. Username isn't defined.
This is misleading, since the username is definitely correct. This took me
more than 2 hours to figure out and should be fixed by issuing a more
applicable error message.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
