[jira] [Commented] (MNG-6427) IT for MNG-1957 fails on Java 9+
[
https://issues.apache.org/jira/browse/MNG-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729360#comment-16729360
]
Hudson commented on MNG-6427:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-5693 #4
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5693/4/
> IT for MNG-1957 fails on Java 9+
>
>
> Key: MNG-6427
> URL: https://issues.apache.org/jira/browse/MNG-6427
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The execution fails with:
> {noformat}
> junit.framework.ComparisonFailure: expected: but was:
> at
> org.apache.maven.it.MavenITmng1957JdkActivationWithVersionRangeTest.testitMNG1957(MavenITmng1957JdkActivationWithVersionRangeTest.java:64)
> {noformat}
> This is caused by incorrect JDK ranges in the {{pom.xml}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729362#comment-16729362 ] Hudson commented on MNG-6481: - Build unstable in Jenkins: Maven TLP » maven » MNG-5693 #4 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5693/4/ > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6509) Upgrade maven-dependency-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729363#comment-16729363 ] Hudson commented on MNG-6509: - Build unstable in Jenkins: Maven TLP » maven » MNG-5693 #4 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5693/4/ > Upgrade maven-dependency-plugin to 3.1.1 > > > Key: MNG-6509 > URL: https://issues.apache.org/jira/browse/MNG-6509 > Project: Maven > Issue Type: Dependency upgrade > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Upgrade plugin to version compatible with Java 9+ for dependency:resolve goal > in Bootstrap ITs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-1957) clause in the activation section has to provide more complex expressions.
[ https://issues.apache.org/jira/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729361#comment-16729361 ] Hudson commented on MNG-1957: - Build unstable in Jenkins: Maven TLP » maven » MNG-5693 #4 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5693/4/ > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: https://issues.apache.org/jira/browse/MNG-1957 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee >Assignee: Brett Porter >Priority: Major > Fix For: 2.1.0 > > Attachments: MNG-1957-maven-project.patch > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 1.4 ~ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-1957) clause in the activation section has to provide more complex expressions.
[ https://issues.apache.org/jira/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729348#comment-16729348 ] Hudson commented on MNG-1957: - Build unstable in Jenkins: Maven TLP » maven » MNG-5666 #9 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/9/ > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: https://issues.apache.org/jira/browse/MNG-1957 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee >Assignee: Brett Porter >Priority: Major > Fix For: 2.1.0 > > Attachments: MNG-1957-maven-project.patch > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 1.4 ~ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729349#comment-16729349 ] Hudson commented on MNG-6481: - Build unstable in Jenkins: Maven TLP » maven » MNG-5666 #9 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/9/ > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6427) IT for MNG-1957 fails on Java 9+
[
https://issues.apache.org/jira/browse/MNG-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729347#comment-16729347
]
Hudson commented on MNG-6427:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-5666 #9
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/9/
> IT for MNG-1957 fails on Java 9+
>
>
> Key: MNG-6427
> URL: https://issues.apache.org/jira/browse/MNG-6427
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The execution fails with:
> {noformat}
> junit.framework.ComparisonFailure: expected: but was:
> at
> org.apache.maven.it.MavenITmng1957JdkActivationWithVersionRangeTest.testitMNG1957(MavenITmng1957JdkActivationWithVersionRangeTest.java:64)
> {noformat}
> This is caused by incorrect JDK ranges in the {{pom.xml}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-1957) clause in the activation section has to provide more complex expressions.
[ https://issues.apache.org/jira/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729352#comment-16729352 ] Hudson commented on MNG-1957: - Build unstable in Jenkins: Maven TLP » maven » Java7Features #29 See https://builds.apache.org/job/maven-box/job/maven/job/Java7Features/29/ > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: https://issues.apache.org/jira/browse/MNG-1957 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee >Assignee: Brett Porter >Priority: Major > Fix For: 2.1.0 > > Attachments: MNG-1957-maven-project.patch > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 1.4 ~ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6427) IT for MNG-1957 fails on Java 9+
[
https://issues.apache.org/jira/browse/MNG-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729351#comment-16729351
]
Hudson commented on MNG-6427:
-
Build unstable in Jenkins: Maven TLP » maven » Java7Features #29
See https://builds.apache.org/job/maven-box/job/maven/job/Java7Features/29/
> IT for MNG-1957 fails on Java 9+
>
>
> Key: MNG-6427
> URL: https://issues.apache.org/jira/browse/MNG-6427
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The execution fails with:
> {noformat}
> junit.framework.ComparisonFailure: expected: but was:
> at
> org.apache.maven.it.MavenITmng1957JdkActivationWithVersionRangeTest.testitMNG1957(MavenITmng1957JdkActivationWithVersionRangeTest.java:64)
> {noformat}
> This is caused by incorrect JDK ranges in the {{pom.xml}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6509) Upgrade maven-dependency-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729354#comment-16729354 ] Hudson commented on MNG-6509: - Build unstable in Jenkins: Maven TLP » maven » Java7Features #29 See https://builds.apache.org/job/maven-box/job/maven/job/Java7Features/29/ > Upgrade maven-dependency-plugin to 3.1.1 > > > Key: MNG-6509 > URL: https://issues.apache.org/jira/browse/MNG-6509 > Project: Maven > Issue Type: Dependency upgrade > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Upgrade plugin to version compatible with Java 9+ for dependency:resolve goal > in Bootstrap ITs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6509) Upgrade maven-dependency-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729350#comment-16729350 ] Hudson commented on MNG-6509: - Build unstable in Jenkins: Maven TLP » maven » MNG-5666 #9 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-5666/9/ > Upgrade maven-dependency-plugin to 3.1.1 > > > Key: MNG-6509 > URL: https://issues.apache.org/jira/browse/MNG-6509 > Project: Maven > Issue Type: Dependency upgrade > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Upgrade plugin to version compatible with Java 9+ for dependency:resolve goal > in Bootstrap ITs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729353#comment-16729353 ] Hudson commented on MNG-6481: - Build unstable in Jenkins: Maven TLP » maven » Java7Features #29 See https://builds.apache.org/job/maven-box/job/maven/job/Java7Features/29/ > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6427) IT for MNG-1957 fails on Java 9+
[
https://issues.apache.org/jira/browse/MNG-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729336#comment-16729336
]
Hudson commented on MNG-6427:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6069 #20
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6069/20/
> IT for MNG-1957 fails on Java 9+
>
>
> Key: MNG-6427
> URL: https://issues.apache.org/jira/browse/MNG-6427
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The execution fails with:
> {noformat}
> junit.framework.ComparisonFailure: expected: but was:
> at
> org.apache.maven.it.MavenITmng1957JdkActivationWithVersionRangeTest.testitMNG1957(MavenITmng1957JdkActivationWithVersionRangeTest.java:64)
> {noformat}
> This is caused by incorrect JDK ranges in the {{pom.xml}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-1957) clause in the activation section has to provide more complex expressions.
[ https://issues.apache.org/jira/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729337#comment-16729337 ] Hudson commented on MNG-1957: - Build unstable in Jenkins: Maven TLP » maven » MNG-6069 #20 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6069/20/ > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: https://issues.apache.org/jira/browse/MNG-1957 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee >Assignee: Brett Porter >Priority: Major > Fix For: 2.1.0 > > Attachments: MNG-1957-maven-project.patch > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 1.4 ~ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6509) Upgrade maven-dependency-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729339#comment-16729339 ] Hudson commented on MNG-6509: - Build unstable in Jenkins: Maven TLP » maven » MNG-6069 #20 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6069/20/ > Upgrade maven-dependency-plugin to 3.1.1 > > > Key: MNG-6509 > URL: https://issues.apache.org/jira/browse/MNG-6509 > Project: Maven > Issue Type: Dependency upgrade > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Upgrade plugin to version compatible with Java 9+ for dependency:resolve goal > in Bootstrap ITs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729338#comment-16729338 ] Hudson commented on MNG-6481: - Build unstable in Jenkins: Maven TLP » maven » MNG-6069 #20 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6069/20/ > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6427) IT for MNG-1957 fails on Java 9+
[
https://issues.apache.org/jira/browse/MNG-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729331#comment-16729331
]
Hudson commented on MNG-6427:
-
Build unstable in Jenkins: Maven TLP » maven » MNG-6065 #14
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6065/14/
> IT for MNG-1957 fails on Java 9+
>
>
> Key: MNG-6427
> URL: https://issues.apache.org/jira/browse/MNG-6427
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The execution fails with:
> {noformat}
> junit.framework.ComparisonFailure: expected: but was:
> at
> org.apache.maven.it.MavenITmng1957JdkActivationWithVersionRangeTest.testitMNG1957(MavenITmng1957JdkActivationWithVersionRangeTest.java:64)
> {noformat}
> This is caused by incorrect JDK ranges in the {{pom.xml}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6509) Upgrade maven-dependency-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729334#comment-16729334 ] Hudson commented on MNG-6509: - Build unstable in Jenkins: Maven TLP » maven » MNG-6065 #14 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6065/14/ > Upgrade maven-dependency-plugin to 3.1.1 > > > Key: MNG-6509 > URL: https://issues.apache.org/jira/browse/MNG-6509 > Project: Maven > Issue Type: Dependency upgrade > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Upgrade plugin to version compatible with Java 9+ for dependency:resolve goal > in Bootstrap ITs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729333#comment-16729333 ] Hudson commented on MNG-6481: - Build unstable in Jenkins: Maven TLP » maven » MNG-6065 #14 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6065/14/ > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-1957) clause in the activation section has to provide more complex expressions.
[ https://issues.apache.org/jira/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729332#comment-16729332 ] Hudson commented on MNG-1957: - Build unstable in Jenkins: Maven TLP » maven » MNG-6065 #14 See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6065/14/ > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: https://issues.apache.org/jira/browse/MNG-1957 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee >Assignee: Brett Porter >Priority: Major > Fix For: 2.1.0 > > Attachments: MNG-1957-maven-project.patch > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 1.4 ~ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6427) IT for MNG-1957 fails on Java 9+
[
https://issues.apache.org/jira/browse/MNG-6427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729326#comment-16729326
]
Hudson commented on MNG-6427:
-
Build unstable in Jenkins: Maven TLP » maven » MAVEN-3.6/MNG-6399 #16
See
https://builds.apache.org/job/maven-box/job/maven/job/MAVEN-3.6%252FMNG-6399/16/
> IT for MNG-1957 fails on Java 9+
>
>
> Key: MNG-6427
> URL: https://issues.apache.org/jira/browse/MNG-6427
> Project: Maven
> Issue Type: Bug
> Components: Integration Tests
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> The execution fails with:
> {noformat}
> junit.framework.ComparisonFailure: expected: but was:
> at
> org.apache.maven.it.MavenITmng1957JdkActivationWithVersionRangeTest.testitMNG1957(MavenITmng1957JdkActivationWithVersionRangeTest.java:64)
> {noformat}
> This is caused by incorrect JDK ranges in the {{pom.xml}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6481) Allow to compile and test Maven with Java 11
[ https://issues.apache.org/jira/browse/MNG-6481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729328#comment-16729328 ] Hudson commented on MNG-6481: - Build unstable in Jenkins: Maven TLP » maven » MAVEN-3.6/MNG-6399 #16 See https://builds.apache.org/job/maven-box/job/maven/job/MAVEN-3.6%252FMNG-6399/16/ > Allow to compile and test Maven with Java 11 > > > Key: MNG-6481 > URL: https://issues.apache.org/jira/browse/MNG-6481 > Project: Maven > Issue Type: Improvement >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > Fix For: 3.6.1 > > > Java 11 is coming closer, let's prepare to use it for the development of > Maven. > A minimal requirement to run Maven - still Java 7. > * compile and pass Maven's tests with Java 11 > * adjust ITs to run under Java 11 > Do we need compile and to pass all tests with Java 9, 10 and 11? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-1957) clause in the activation section has to provide more complex expressions.
[ https://issues.apache.org/jira/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729327#comment-16729327 ] Hudson commented on MNG-1957: - Build unstable in Jenkins: Maven TLP » maven » MAVEN-3.6/MNG-6399 #16 See https://builds.apache.org/job/maven-box/job/maven/job/MAVEN-3.6%252FMNG-6399/16/ > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: https://issues.apache.org/jira/browse/MNG-1957 > Project: Maven > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee >Assignee: Brett Porter >Priority: Major > Fix For: 2.1.0 > > Attachments: MNG-1957-maven-project.patch > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 1.4 ~ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6509) Upgrade maven-dependency-plugin to 3.1.1
[ https://issues.apache.org/jira/browse/MNG-6509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729329#comment-16729329 ] Hudson commented on MNG-6509: - Build unstable in Jenkins: Maven TLP » maven » MAVEN-3.6/MNG-6399 #16 See https://builds.apache.org/job/maven-box/job/maven/job/MAVEN-3.6%252FMNG-6399/16/ > Upgrade maven-dependency-plugin to 3.1.1 > > > Key: MNG-6509 > URL: https://issues.apache.org/jira/browse/MNG-6509 > Project: Maven > Issue Type: Dependency upgrade > Components: Integration Tests >Reporter: Sylwester Lachiewicz >Assignee: Sylwester Lachiewicz >Priority: Minor > > Upgrade plugin to version compatible with Java 9+ for dependency:resolve goal > in Bootstrap ITs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] andretadeu commented on issue #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on issue #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/' URL: https://github.com/apache/maven-war-plugin/pull/3#issuecomment-450068096 Hi @eolivelli , I replaced java.nio.files.Paths with a solution that uses Regex. Does that code passes in the code review? Would you prefer that I create another pull request? Thanks, This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729287#comment-16729287 ] Dan Tran commented on WAGON-537: sorry about the noise, I am able to cook up a multi SCM freeslyle job to build both wagon and maven > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729276#comment-16729276 ] Dan Tran commented on WAGON-537: Could you deploy latest wagon snapshot to repository.apache.org? This is much easier for me to build apache-maven at our Jenkins with -DwagonVersion=3.3.0-SNAPSHOT. > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r243771102
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -113,7 +109,7 @@ public void addAll( Collection paths, String
prefix )
{
for ( String val : paths )
{
-add( prefix + val );
+add( Paths.get( prefix, val ).toString() );
Review comment:
Another detail:
PathSet class still store the set of paths as String due to serialization /
deserialization to XML. This could not be changed to Set, otherwise you
will get a StackOverflowError during this process.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break first-win rule for web resource with target path ending with '/'
andretadeu commented on a change in pull request #3: [MWAR-371] Overlays break
first-win rule for web resource with target path ending with '/'
URL: https://github.com/apache/maven-war-plugin/pull/3#discussion_r243770770
##
File path: src/main/java/org/apache/maven/plugins/war/util/PathSet.java
##
@@ -113,7 +109,7 @@ public void addAll( Collection paths, String
prefix )
{
for ( String val : paths )
{
-add( prefix + val );
+add( Paths.get( prefix, val ).toString() );
Review comment:
This class does not eagerly traverse the File System, it just represents the
Path, parse it properly and returns a file when you call the method 'toFile()'.
If the file or the path does not exist, it won't complain unless you try to
open, check for files inside the folder, etc. It also deals with relative and
absolute paths.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[jira] [Comment Edited] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729208#comment-16729208
]
Michael Osipov edited comment on MJAVADOC-469 at 12/26/18 10:58 PM:
[~tschoening], I have pushed a new branch with a naive implementation. Please
test.
The solution will make invalid options truly invalid:
{code}
-stylesheetfile
${project.basedir}\nope\stylesheet.css"
{code}
must actually be two {{additionalOptions}}, pretty much {{ProcessBuilder}}
would expect it.
was (Author: michael-o):
[~tschoening], I have pushed a new branch with a naive implementation. Please
test.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-788) Add functionality to collect raw dependencies in Maven 3+
[ https://issues.apache.org/jira/browse/MSHARED-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729206#comment-16729206 ] Karl Heinz Marbaise commented on MSHARED-788: - Hi [~belingueres], an answer on mailing list can take time in particular over holidays... The [maven-artifact-transfer lib|https://maven.apache.org/shared/maven-artifact-transfer/index.html] is intended for install, deploy and resolve artifacts in Maven 3. which would give you the chance the concentrate only on solving the tree problems in dependency tree without having to bother about Aether etc. and yes currently maven-artifact-transfer is being used already in several plugins which you might think based on the version 0.10.1 ...but this means on the other hand we can change/enhance it to our needs or maybe you have needs to for that lib as well... Ok Now I understand your intention that you like to make Enforcer with Maven 3+ only working correctly...which would be great...and I appreciate your help hereJust ping me if you need help or support...also don't hesitate to do that on the mailing list > Add functionality to collect raw dependencies in Maven 3+ > - > > Key: MSHARED-788 > URL: https://issues.apache.org/jira/browse/MSHARED-788 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-3.0, maven-dependency-tree-3.0.1 >Reporter: Gabriel Belingueres >Priority: Major > Time Spent: 10m > > Add funcionality allowing to collect raw project dependencies. Add a layer to > hide against Maven 3's sonatype aether and Maven 3.1+ eclipse aether. > This could be used to implement dependencyConvergence and > requireUpperBoundDeps enforcer rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729208#comment-16729208
]
Michael Osipov commented on MJAVADOC-469:
-
[~tschoening], I have pushed a new branch with a naive implementation. Please
test.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov reopened MJAVADOC-469:
-
Reopening since further discussion is needed.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-788) Add functionality to collect raw dependencies in Maven 3+
[ https://issues.apache.org/jira/browse/MSHARED-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729201#comment-16729201 ] Gabriel Belingueres commented on MSHARED-788: - Hi Karl. Yes I've been looking at maven-artifact-transfer...seemed to me a library pretty much as dependency-tree 3.x. Asked a question on the mailing list...no answers. About the Enforcer rules, I did not meant to re implement them again, but to make them work again when upgrading to maven-dependency-tree 3.0.x. As a matter of fact, I used the Enforcer project ITs to test this component. Anyway, you may want to hold the merge as I discovered that it pass all Enforcer tests with dependencyConvergence and requireUpperBounds, but it doesn't retrieve the right component versions in more elaborated cases...I will be committing over this PR when I could finally solve them. > Add functionality to collect raw dependencies in Maven 3+ > - > > Key: MSHARED-788 > URL: https://issues.apache.org/jira/browse/MSHARED-788 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-3.0, maven-dependency-tree-3.0.1 >Reporter: Gabriel Belingueres >Priority: Major > Time Spent: 10m > > Add funcionality allowing to collect raw project dependencies. Add a layer to > hide against Maven 3's sonatype aether and Maven 3.1+ eclipse aether. > This could be used to implement dependencyConvergence and > requireUpperBoundDeps enforcer rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MSHARED-788) Add functionality to collect raw dependencies in Maven 3+
[ https://issues.apache.org/jira/browse/MSHARED-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729195#comment-16729195 ] Karl Heinz Marbaise commented on MSHARED-788: - You know of the component maven-artifact-transfer which has already a layer for Sonatype Aether and Maven 3.1+ eclipse aether ? > Add functionality to collect raw dependencies in Maven 3+ > - > > Key: MSHARED-788 > URL: https://issues.apache.org/jira/browse/MSHARED-788 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-3.0, maven-dependency-tree-3.0.1 >Reporter: Gabriel Belingueres >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Add funcionality allowing to collect raw project dependencies. Add a layer to > hide against Maven 3's sonatype aether and Maven 3.1+ eclipse aether. > This could be used to implement dependencyConvergence and > requireUpperBoundDeps enforcer rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (MSHARED-788) Add functionality to collect raw dependencies in Maven 3+
[ https://issues.apache.org/jira/browse/MSHARED-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729195#comment-16729195 ] Karl Heinz Marbaise edited comment on MSHARED-788 at 12/26/18 9:50 PM: --- You know of the component maven-artifact-transfer which has already a layer for Sonatype Aether and Maven 3.1+ eclipse aether ? BTW: Maybe I misunderstand the issue here but a dependencyConvergence rule already exists in Maven Enforcer ? And also requireUpperbounds ? was (Author: khmarbaise): You know of the component maven-artifact-transfer which has already a layer for Sonatype Aether and Maven 3.1+ eclipse aether ? > Add functionality to collect raw dependencies in Maven 3+ > - > > Key: MSHARED-788 > URL: https://issues.apache.org/jira/browse/MSHARED-788 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-3.0, maven-dependency-tree-3.0.1 >Reporter: Gabriel Belingueres >Priority: Major > Time Spent: 10m > > Add funcionality allowing to collect raw project dependencies. Add a layer to > hide against Maven 3's sonatype aether and Maven 3.1+ eclipse aether. > This could be used to implement dependencyConvergence and > requireUpperBoundDeps enforcer rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-788) Add functionality to collect raw dependencies in Maven 3+
[ https://issues.apache.org/jira/browse/MSHARED-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-788: Remaining Estimate: (was: 0h) > Add functionality to collect raw dependencies in Maven 3+ > - > > Key: MSHARED-788 > URL: https://issues.apache.org/jira/browse/MSHARED-788 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Affects Versions: maven-dependency-tree-3.0, maven-dependency-tree-3.0.1 >Reporter: Gabriel Belingueres >Priority: Major > Time Spent: 10m > > Add funcionality allowing to collect raw project dependencies. Add a layer to > hide against Maven 3's sonatype aether and Maven 3.1+ eclipse aether. > This could be used to implement dependencyConvergence and > requireUpperBoundDeps enforcer rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] khmarbaise commented on issue #176: Fix to prevent warning due to CI-friendly version in the parent pom
khmarbaise commented on issue #176: Fix to prevent warning due to CI-friendly version in the parent pom URL: https://github.com/apache/maven/pull/176#issuecomment-450030012 Unfortunately no reaction. So I close this PR. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] khmarbaise closed pull request #176: Fix to prevent warning due to CI-friendly version in the parent pom
khmarbaise closed pull request #176: Fix to prevent warning due to CI-friendly version in the parent pom URL: https://github.com/apache/maven/pull/176 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729191#comment-16729191
]
Michael Osipov commented on MJAVADOC-469:
-
The funny thing is that the most recent Javadoc documentation does not even
document the argument file behavior. It is completely unclear and opaque.
This is for Java 8
.bq An argument file can include javac options and source file names in any
combination. The arguments within a file can be space-separated or
newline-separated. If a file name contains embedded spaces, then put the whole
file name in double quotation marks.
Java 11 says: Noting about this. Not even mention backslash or colon. Just made
a quick test with 11, it still requires backslash escapes, sigh...what a mess.
It does not require any escaping if you don't quite..
Oracle's lack of documentation is just frustrating.
[~tschoening], your actual proposal is to unconditionally escape backslashes?
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MENFORCER-277) Upgrade maven-dependency-tree to 3.x
[
https://issues.apache.org/jira/browse/MENFORCER-277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729161#comment-16729161
]
Gabriel Belingueres commented on MENFORCER-277:
---
Hi [~rfscholte]: I've been working in adding the remaining functionality in
m-dependency-tree.
I've tested the m-enforcer-plugin using your patch as base and it seems to work
in most relevant Maven versions (see MSHARED-788).
I could push a PR on this issue if required.
Regards,
Gabriel
> Upgrade maven-dependency-tree to 3.x
>
>
> Key: MENFORCER-277
> URL: https://issues.apache.org/jira/browse/MENFORCER-277
> Project: Maven Enforcer Plugin
> Issue Type: Improvement
>Affects Versions: 1.4.1
>Reporter: Robert Scholte
>Priority: Major
> Attachments: MENFORCER-277.patch
>
>
> As part of MENFORCER-264 maven-dependency-tree should be upgraded. This would
> imply switching from the M2 {{DependencyTreeBuilder}} to M2/M3
> {{DependencyGraphBuilder}}.
> However, {{DependencyGraphBuilder}} uses {{ProjectDependenciesResolver}},
> which provides the *resolved* graph instead of a raw tree.
> This is a requirement for both {{DependencyConvergence}} and
> {{RequireUpperBoundDeps}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729162#comment-16729162
]
Thorsten Schöning commented on MJAVADOC-469:
bq. How is Maven supposed to know that this is a path and not a mere string?
One might argue that the backslash is explicitly used as an escape character in
the spec at least at two places, one is the already mentioned paths, the other
seem to be tag names:
bq. Use of Colon in Tag Name - A colon can be used in a tag name if it is
escaped with a backslash. For this doc comment:
https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#javadocoptions
bq. If a filename contains embedded spaces, put the whole filename in double
quotes, and double each backslash ("My Files\\Stuff.java").
https://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
If the backslash is an escape character, it can not be used by itself only in
the options files and that is the only thing one needs to take care about in
this context. So shouldn't it be somewhat safe to simply define that if a
backslash is not followed by another one or a colon, it needs to be doubled?
`\\` is a valid escape sequence and `\:` is as well, all others are not.
The only problem is that it's not clearly documented this way in the spec from
my understanding, but again one could argue that an optionally wrong `\\` in
some arbitrary text not breaking things might be less of a problem than a not
escaped `\` in a path breaking things or needing ugly workarounds like mine.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MCOMPILER-366) Warning about automodules should provide the list of offending libraries
[ https://issues.apache.org/jira/browse/MCOMPILER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729154#comment-16729154 ] Oscar Farga commented on MCOMPILER-366: --- Attached patch that adds the related filename to the logs. > Warning about automodules should provide the list of offending libraries > > > Key: MCOMPILER-366 > URL: https://issues.apache.org/jira/browse/MCOMPILER-366 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Gili >Priority: Major > Labels: up-for-grabs > Attachments: MCOMPILER-366-maven-compiler-plugin.patch > > > [https://github.com/apache/maven-compiler-plugin/blob/875947802d28bcf8348eb634985c0512a790170a/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L257] > warns about the presence of automodules but does not help the user fix the > problem. > Please collect the full list of dependencies causing this problem and append > them to the end of the warning message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MCOMPILER-366) Warning about automodules should provide the list of offending libraries
[ https://issues.apache.org/jira/browse/MCOMPILER-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oscar Farga updated MCOMPILER-366: -- Attachment: MCOMPILER-366-maven-compiler-plugin.patch > Warning about automodules should provide the list of offending libraries > > > Key: MCOMPILER-366 > URL: https://issues.apache.org/jira/browse/MCOMPILER-366 > Project: Maven Compiler Plugin > Issue Type: Improvement >Reporter: Gili >Priority: Major > Labels: up-for-grabs > Attachments: MCOMPILER-366-maven-compiler-plugin.patch > > > [https://github.com/apache/maven-compiler-plugin/blob/875947802d28bcf8348eb634985c0512a790170a/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L257] > warns about the presence of automodules but does not help the user fix the > problem. > Please collect the full list of dependencies causing this problem and append > them to the end of the warning message. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] belingueres opened a new pull request #1: [MSHARED-788] Add functionality to collect raw dependencies in Maven 3+
belingueres opened a new pull request #1: [MSHARED-788] Add functionality to collect raw dependencies in Maven 3+ URL: https://github.com/apache/maven-dependency-tree/pull/1 Added the funcionality. No added ITs, instead tested the maven-enforcer-plugin with this version of m-dependency-tree. Tested and passed all tests with: Maven 3.0.4, 3.0.5, 3.1.0, 3.5.4, 3.6.0. Didn't work with Maven 3.0.0 (sonatype aether 1.7). Other Maven versions not tested. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] gmcdonald closed pull request #223: commit change
gmcdonald closed pull request #223: commit change
URL: https://github.com/apache/maven/pull/223
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/pom.xml b/pom.xml
index d504e02be4..92aa7fe43a 100644
--- a/pom.xml
+++ b/pom.xml
@@ -109,7 +109,7 @@ under the License.
https://builds.apache.org/job/maven-box/job/maven/
-https://maven.apache.org/download.html
+
http://192.168.60.6:8081/nexus/content/repositories/snapshots/
apache.website
scm:svn:https://svn.apache.org/repos/asf/maven/website/components/${maven.site.path}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] gmcdonald closed pull request #224: updated pom
gmcdonald closed pull request #224: updated pom
URL: https://github.com/apache/maven/pull/224
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/pom.xml b/pom.xml
index d504e02be4..92aa7fe43a 100644
--- a/pom.xml
+++ b/pom.xml
@@ -109,7 +109,7 @@ under the License.
https://builds.apache.org/job/maven-box/job/maven/
-https://maven.apache.org/download.html
+
http://192.168.60.6:8081/nexus/content/repositories/snapshots/
apache.website
scm:svn:https://svn.apache.org/repos/asf/maven/website/components/${maven.site.path}
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] gmcdonald closed pull request #171: Update pom.xml
gmcdonald closed pull request #171: Update pom.xml URL: https://github.com/apache/maven/pull/171 This is a PR merged from a forked repository. As GitHub hides the original diff on merge, it is displayed below for the sake of provenance: As this is a foreign pull request (from a fork), the diff is supplied below (as it won't show otherwise due to GitHub magic): diff --git a/pom.xml b/pom.xml index cf4b364de4..8842e1555a 100644 --- a/pom.xml +++ b/pom.xml @@ -93,6 +93,17 @@ under the License. maven-compat apache-maven + + + + +org.sonarsource.scanner.maven +sonar-maven-plugin +3.4.0.905 + + + + scm:git:https://gitbox.apache.org/repos/asf/maven.git This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] gmcdonald closed pull request #178: Maven 3.0.x
gmcdonald closed pull request #178: Maven 3.0.x URL: https://github.com/apache/maven/pull/178 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (MSHARED-788) Add functionality to collect raw dependencies in Maven 3+
Gabriel Belingueres created MSHARED-788: --- Summary: Add functionality to collect raw dependencies in Maven 3+ Key: MSHARED-788 URL: https://issues.apache.org/jira/browse/MSHARED-788 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-tree Affects Versions: maven-dependency-tree-3.0.1, maven-dependency-tree-3.0 Reporter: Gabriel Belingueres Add funcionality allowing to collect raw project dependencies. Add a layer to hide against Maven 3's sonatype aether and Maven 3.1+ eclipse aether. This could be used to implement dependencyConvergence and requireUpperBoundDeps enforcer rules. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MDEP-586) Unpacking different resources into different location from the same artifact doesn't work
[
https://issues.apache.org/jira/browse/MDEP-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729128#comment-16729128
]
Vidar Breivik commented on MDEP-586:
I have looked at this issue and reproduced the behaviour.
I am a bit uncertain about how this should be solved.
Should the log message be changed from INFO to WARN, and add a helpful text
along the line of "...something-something already exists/processed/?, please
set or to ...something-something"?
Or should the second execution not skip? This looks kind of hard to achieve,
because then the second execution will need to know which files were extracted
in the first step. My understanding is that now it only looks at a marker-file
in target/dependency-maven-plugin-markers, and when it exists it skips (unless
overWrite is set).
> Unpacking different resources into different location from the same artifact
> doesn't work
> -
>
> Key: MDEP-586
> URL: https://issues.apache.org/jira/browse/MDEP-586
> Project: Maven Dependency Plugin
> Issue Type: Bug
> Components: unpack-dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
> Maven home: C:\Program Files (x86)\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_111, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_111\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Tomas Tulka
>Priority: Major
> Labels: up-for-grabs
> Attachments: pom.xml
>
>
> I have one artifact, in the simplest case only with two resources inside:
> ResourceArtifact-1.0.jar
> /resource1.dat
> /resource2.dat
> I want to unpack one resource into one location and the second in a different
> location, all this with one pom.xml:
> {code:xml}
>
> org.apache.maven.plugins
> maven-dependency-plugin
> 3.0.2
>
>
> unpack-resource1
>
> unpack-dependencies
>
>
> ResourceArtifact
> resource1.dat
> resources1
>
>
>
> unpack-resource2
>
> unpack-dependencies
>
>
> ResourceArtifact
> resource2.dat
> resources2
>
>
>
>
> {code}
> When I +*don't*+ use (which makes not so much sense, because in fact there's
> nothing to overwrite):
> {code:xml}
> true
> true
> {code}
> Then I get an info (even not a warning):
> {noformat}
> [INFO] --- maven-dependency-plugin:3.0.2:unpack-dependencies
> (unpack-resource2) @ maven-unpack-same-artifact ---
> [INFO] test:ResourceArtifact:jar:1.0 already exists in destination.
> {noformat}
> And the second resource is not unpacked.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-6450) Allow importing a POM with a classifier
[ https://issues.apache.org/jira/browse/MNG-6450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729064#comment-16729064 ] Michael Osipov commented on MNG-6450: - [~rfscholte], it doesn't sound that stupid to generate a BOM POM. If we relax this, current usecases wouldn't actually break because there is no change for them. [~yborovikov], do you have a sample project for this already. I'd be interested to see how you imagine this plugin to work. As far as I know the Spring Framework BOM POM is managed manually and it works fine. > Allow importing a POM with a classifier > --- > > Key: MNG-6450 > URL: https://issues.apache.org/jira/browse/MNG-6450 > Project: Maven > Issue Type: Improvement > Components: Dependencies, POM >Affects Versions: 3.0 >Reporter: Yegor Borovikov >Priority: Major > Labels: easy-fix, pull-request-available > > Currently, a POM-packaged artifact with a classifier cannot be imported - > there is an explicit check for that in > [DefaultModelValidator|https://github.com/apache/maven/blob/master/maven-model-builder/src/main/java/org/apache/maven/model/validation/DefaultModelValidator.java#L480]. > I couldn't find anything in Maven documentation that would mention/explain > this limitation. According to [~rfscholte] this [might > be|https://www.mail-archive.com/dev@maven.apache.org/msg114101.html] > "historical". > Example use case: a BOM (bill of materials) plugin could generate a BOM POM > and attach it (with a classifier) to the project. However, currently there's > no way to import the generated BOM because of the restriction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #171: Update pom.xml
michael-o commented on issue #171: Update pom.xml URL: https://github.com/apache/maven/pull/171#issuecomment-449979302 No reaction, we shall close this. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-5705) NPE on parallel build in BuilderCommon.handleBuildError(BuilderCommon.java:147)
[
https://issues.apache.org/jira/browse/MNG-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729050#comment-16729050
]
Michael Osipov commented on MNG-5705:
-
[~pekarna], can you check branch MNG-5965 if it solves your issue?
> NPE on parallel build in
> BuilderCommon.handleBuildError(BuilderCommon.java:147)
> ---
>
> Key: MNG-5705
> URL: https://issues.apache.org/jira/browse/MNG-5705
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.2.1
>Reporter: Ondra Žižka
>Priority: Major
>
> STR:
> {code}
> git clone g...@github.com:OndraZizka/windup.git
> cd windup
> git checkout 91a454b # MavenNPE2
> mvn -T 1C clean javadoc:aggregate -PjavadocDist
> {code}
> {code}
> [INFO]
>
> [INFO] Windup Parent . SUCCESS [ 0.132 s]
> [INFO] Windup Engine - Frames SUCCESS [ 0.009 s]
> [INFO] Windup Engine - Utils . SUCCESS [ 0.035 s]
> [INFO] Windup Engine - Graph Parent .. SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Graph API . FAILURE [ 0.003 s]
> [INFO] Windup Engine - Graph Impl SKIPPED
> [INFO] Windup Engine - Graph Addon ... SKIPPED
> [INFO] Windup Engine - Graph Tests ... SKIPPED
> [INFO] Windup Engine - Config Parent . SUCCESS [ 0.008 s]
> [INFO] Windup Engine - Config API SKIPPED
> [INFO] Windup Engine - Config Impl ... SKIPPED
> [INFO] Windup Engine - Config Addon .. SKIPPED
> [INFO] Windup Engine - Decompiler SUCCESS [ 0.011 s]
> [INFO] Windup Engine - Decompiler API SUCCESS [ 0.039 s]
> [INFO] Windup Engine - Decompiler Procyon SKIPPED
> [INFO] Windup Extension - Config - XML ... SKIPPED
> [INFO] Windup Engine - Reporting Parent .. SUCCESS [ 0.016 s]
> [INFO] Windup Engine - Reporting API . SKIPPED
> [INFO] Windup Engine - Reporting Impl SKIPPED
> [INFO] Windup Engine - Reporting Addon ... SKIPPED
> [INFO] Windup Engine - Execution API Parent .. SUCCESS [ 0.003 s]
> [INFO] Windup Engine - Execution API . SKIPPED
> [INFO] Windup Engine - Execution API Impl SKIPPED
> [INFO] Windup Engine - Execution API Addon ... SKIPPED
> [INFO] Windup Rules - XML - Basic SKIPPED
> [INFO] Windup Extension - Config - Groovy SKIPPED
> [INFO] Windup Rules - Java - Basic ... SKIPPED
> [INFO] Windup Engine - Config Tests .. SKIPPED
> [INFO] Windup Rules - Java EE - Basic SKIPPED
> [INFO] Windup Engine - Execution API Tests ... SKIPPED
> [INFO] Windup Engine - Reporting Tests ... SKIPPED
> [INFO] Windup Engine - UI SKIPPED
> [INFO] Windup Engine - Test Utilities SUCCESS [ 0.004 s]
> [INFO] Windup Engine - Tests . SKIPPED
> [INFO] Windup - Bootstrap module . SUCCESS [ 0.002 s]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ decompiler-api ---
> [INFO] Windup - Distribution Build ... FAILURE [ 0.008 s]
> [INFO] Windup Rulesets BOM ... SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 1.721 s (Wall Clock)
> [INFO] Finished at: 2014-10-22T16:39:30+01:00
> [INFO] Final Memory: 21M/211M
> [INFO]
>
> [ERROR] Internal error: java.lang.NullPointerException -> [Help 1]
> org.apache.maven.InternalErrorException: Internal error:
> java.lang.NullPointerException
> at
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.handleBuildError(BuilderCommon.java:147)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:121)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> at
> org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
>
[jira] [Commented] (MRESOLVER-55) Artifact download failures
[
https://issues.apache.org/jira/browse/MRESOLVER-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729037#comment-16729037
]
Michael Osipov commented on MRESOLVER-55:
-
Can we have a wireshark dump, privately? Otherwise I have to close eas {{Cannot
Reproduce}} because we don't have access to your infrastructure.
> Artifact download failures
> --
>
> Key: MRESOLVER-55
> URL: https://issues.apache.org/jira/browse/MRESOLVER-55
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Affects Versions: Maven Artifact Resolver 1.1.1
> Environment: Windows, Ubuntu
>Reporter: Lasse Westh-Nielsen
>Priority: Major
> Fix For: waiting-for-feedback
>
>
> Hey,
> We often run Maven builds of [https://github.com/neo4j/neo4j] on machines
> with cold caches/ empty ~/.m2/repository folders.
> There are rather a lot of dependencies to download, so even though the
> failure rate of individual artifact downloads is small, at our scale it
> causes significant build failures.
> I am working on seeding caches. Separately though it would be great to be
> able to configure retries and timeouts for dependency downloads - optimise
> for build throughput rather than latency as it were.
> How do I do that? I can't find it documented anywhere, and trying to browse
> "wagon" source code got me nowhere.
> Regards,
> Lasse
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-5965) Parallel build multiplies work if multiple goals are given
[ https://issues.apache.org/jira/browse/MNG-5965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MNG-5965: Fix Version/s: 3.6.1 > Parallel build multiplies work if multiple goals are given > -- > > Key: MNG-5965 > URL: https://issues.apache.org/jira/browse/MNG-5965 > Project: Maven > Issue Type: Bug > Components: Bootstrap Build >Affects Versions: 3.3.9 > Environment: Windows 7 64bit >Reporter: Matthias Schmalz >Assignee: Michael Osipov >Priority: Major > Fix For: 3.6.1 > > Attachments: parallel.test.zip > > > When I run a parallel build which invokes multiple goals Maven multiplies the > work e.g. when I run > install sonar:sonar > Every phase is executed once as expected. However when I run > install sonar:sonar -T 4 > Every phase is executed twice. > The problem can be reproduced with a single simple Java project (of course > parallel builds are useless with a single module). Debugging showed that > every Mojo is really called twice per project. > Find attached a simple project and two build outputs, where you can see that > the parallel build is doing everything twice (you can ignore that Sonar fails > in the end, due to no server is up). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #125: [MNG-5965] Parallel build multiplies work if multiple goals are given
michael-o commented on issue #125: [MNG-5965] Parallel build multiplies work if multiple goals are given URL: https://github.com/apache/maven/pull/125#issuecomment-449964891 @dbmeneses the reason text contains some typos, for the sake of clarity and complexity of the issue, can you please fix them? It is hard enough to wrap one's mind around the actual problem. I had to read the problem several times to understand it. ;-) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (MRESOLVER-21) Maven Resolver trying to resolve optional dependencies
[
https://issues.apache.org/jira/browse/MRESOLVER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MRESOLVER-21.
---
Resolution: Incomplete
Fix Version/s: (was: waiting-for-feedback)
No reaction of a fix proposal.
> Maven Resolver trying to resolve optional dependencies
> --
>
> Key: MRESOLVER-21
> URL: https://issues.apache.org/jira/browse/MRESOLVER-21
> Project: Maven Resolver
> Issue Type: Bug
> Components: resolver
>Reporter: Cedric Beust
>Priority: Major
>
> I modified the `ResolveTransitiveDependencies.java` example in two ways:
> - Modified the id to
> `"org.springframework:spring-context-support:2.5.6.SEC03"`
> - Replaced the filter with one that excludes optional dependencies
> I'm including the full code below.
> Despite that, `system.resolveDependencies()` fails with a
> `DependencyResolutionException when trying to resolve a bunch of optional
> dependencies, sugh as `jasperreports`.
> Head of the stack trace:
> {noformat}org.eclipse.aether.resolution.DependencyResolutionException: Failed
> to collect dependencies at
> org.springframework:spring-context-support:jar:2.5.6.SEC03 ->
> jasperreports:jasperreports:jar:2.0.5 ->
> commons-logging:commons-logging:jar:99.0-does-not-exist
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:380)
> at
> org.apache.maven.resolver.examples.ResolveTransitiveDependencies.main(ResolveTransitiveDependencies.java:71)
> Caused by: org.eclipse.aether.collection.DependencyCollectionException:
> Failed to collect dependencies at
> org.springframework:spring-context-support:jar:2.5.6.SEC03 ->
> jasperreports:jasperreports:jar:2.0.5 ->
> commons-logging:commons-logging:jar:99.0-does-not-exist
> at
> org.eclipse.aether.internal.impl.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:291)
> at
> org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:341)
> ... 1 more
> Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed
> to read artifact descriptor for
> commons-logging:commons-logging:jar:99.0-does-not-exist{noformat}
> {code:java}
> public static void main( String[] args )
> throws Exception
> {
> System.out.println(
> "" );
> System.out.println(
> ResolveTransitiveDependencies.class.getSimpleName() );
> RepositorySystem system = Booter.newRepositorySystem();
> RepositorySystemSession session = Booter.newRepositorySystemSession(
> system );
> Artifact artifact = new DefaultArtifact(
> "org.springframework:spring-context-support:2.5.6.SEC03" );
> DependencyFilter classpathFlter =
> DependencyFilterUtils.classpathFilter( JavaScopes.COMPILE );
> DependencyFilter optionalFilter = new DependencyFilter() {
> @Override
> public boolean accept(DependencyNode dependencyNode,
> List list) {
> return ! dependencyNode.getDependency().getOptional();
> }
> };
> CollectRequest collectRequest = new CollectRequest();
> collectRequest.setRoot( new Dependency( artifact, JavaScopes.COMPILE
> ) );
> collectRequest.setRepositories( Booter.newRepositories( system,
> session ) );
> DependencyRequest dependencyRequest = new DependencyRequest(
> collectRequest, optionalFilter );
> try {
> List artifactResults =
> system.resolveDependencies(session,
> dependencyRequest).getArtifactResults();
> for (ArtifactResult artifactResult : artifactResults) {
> System.out.println(artifactResult.getArtifact() + " resolved
> to "
> + artifactResult.getArtifact().getFile());
> }
> } catch(Exception ex) {
> ex.printStackTrace();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on issue #10: [MRESOLVER-7] Download dependency POMs in parallel v2
michael-o commented on issue #10: [MRESOLVER-7] Download dependency POMs in parallel v2 URL: https://github.com/apache/maven-resolver/pull/10#issuecomment-449961758 @slachiewicz, do you think you can take on this? You know the change best by now. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] vbreivik commented on issue #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11)
vbreivik commented on issue #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11) URL: https://github.com/apache/maven-dependency-plugin/pull/8#issuecomment-449961687 I have tested the maven-dependency-analyzer 1.11.1 and voted on the dev list. I will try to follow up and update the PR when it 1.11.1 is released. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (SUREFIRE-1611) Deprecate skipTests in Failsafe Plugin
[
https://issues.apache.org/jira/browse/SUREFIRE-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729025#comment-16729025
]
Tibor Digana commented on SUREFIRE-1611:
[~cguillaume]
A single parameter is discussed in
https://issues.apache.org/jira/browse/SUREFIRE-1170
> Deprecate skipTests in Failsafe Plugin
> --
>
> Key: SUREFIRE-1611
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1611
> Project: Maven Surefire
> Issue Type: Task
> Components: Maven Failsafe Plugin
>Reporter: Tibor Digana
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 3.0.0-M3
>
>
> We had an ambition to add prefixes surefire and failsafe in the old system
> properties which do not have them. At the same time we should remove
> {{skipTests}} from {{maven-failsafe-plugin}} because this have been
> associated with unit tests for long and thus {{maven-surefire-plugin}}. On
> the other side the {{maven-failsafe-plugin}} has a better property to use
> {{skipITs}}. Since the {{skip***}} system properties are so famous and have
> been used everywhere, we should not add prefixes for those; otherwise we
> broke all the world. We can make it with other system properties. We want to
> remove deprecated config parameters in the last milestone of {{3.0.0}}. One
> more reason to do these unpopular changes is the fact that system properties
> without prefixes interfere with other plugins.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] michael-o commented on a change in pull request #125: [MNG-5965] Parallel build multiplies work if multiple goals are given
michael-o commented on a change in pull request #125: [MNG-5965] Parallel build
multiplies work if multiple goals are given
URL: https://github.com/apache/maven/pull/125#discussion_r243990973
##
File path:
maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/ConcurrencyDependencyGraph.java
##
@@ -61,12 +61,12 @@ public int getNumberOfBuilds()
/**
* Gets all the builds that have no reactor-dependencies
*
- * @return A list of all the initial builds
+ * @return A set of all the initial builds
*/
-public List getRootSchedulableBuilds()
+public Set getRootSchedulableBuilds()
{
-List result = new ArrayList<>();
+Set result = new HashSet<>();
Review comment:
I think this should be `LinkedHashSet` to retain Insertion order just like
`ArrayList` does. I will change the PR locally.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] michael-o commented on a change in pull request #125: [MNG-5965] Parallel build multiplies work if multiple goals are given
michael-o commented on a change in pull request #125: [MNG-5965] Parallel build
multiplies work if multiple goals are given
URL: https://github.com/apache/maven/pull/125#discussion_r243990973
##
File path:
maven-core/src/main/java/org/apache/maven/lifecycle/internal/builder/multithreaded/ConcurrencyDependencyGraph.java
##
@@ -61,12 +61,12 @@ public int getNumberOfBuilds()
/**
* Gets all the builds that have no reactor-dependencies
*
- * @return A list of all the initial builds
+ * @return A set of all the initial builds
*/
-public List getRootSchedulableBuilds()
+public Set getRootSchedulableBuilds()
{
-List result = new ArrayList<>();
+Set result = new HashSet<>();
Review comment:
I think this should be `LinkedHashSet` to retain Insertion order just like
`ArrayList` does.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] michael-o commented on issue #22: [MNG-5965] Parallel build multiplies work if multiple goals are given
michael-o commented on issue #22: [MNG-5965] Parallel build multiplies work if multiple goals are given URL: https://github.com/apache/maven-integration-testing/pull/22#issuecomment-449960978 @dbmeneses why is there no parent element on the module POMs? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] michael-o removed a comment on issue #125: [MNG-5965] Parallel build multiplies work if multiple goals are given
michael-o removed a comment on issue #125: [MNG-5965] Parallel build multiplies work if multiple goals are given URL: https://github.com/apache/maven/pull/125#issuecomment-449960818 @dbmeneses why is there no parent element on the module POMs? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] michael-o commented on issue #125: [MNG-5965] Parallel build multiplies work if multiple goals are given
michael-o commented on issue #125: [MNG-5965] Parallel build multiplies work if multiple goals are given URL: https://github.com/apache/maven/pull/125#issuecomment-449960818 @dbmeneses why is there no parent element on the module POMs? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rfscholte closed pull request #14: Exclude non-exported packages when Java Modules are present.
rfscholte closed pull request #14: Exclude non-exported packages when Java
Modules are present.
URL: https://github.com/apache/maven-javadoc-plugin/pull/14
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/pom.xml b/pom.xml
index dbead88..bba7bfa 100644
--- a/pom.xml
+++ b/pom.xml
@@ -536,7 +536,7 @@ under the License.
maven-surefire-plugin
-**/*Test*.java
+**/*Test*.java
diff --git
a/src/it/projects/MJAVADOC-556_hide-non-exported-packages/invoker.properties
b/src/it/projects/MJAVADOC-556_hide-non-exported-packages/invoker.properties
new file mode 100644
index 000..81ca246
--- /dev/null
+++ b/src/it/projects/MJAVADOC-556_hide-non-exported-packages/invoker.properties
@@ -0,0 +1,19 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+invoker.java.version=9+
+invoker.goals=javadoc:aggregate
diff --git
a/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/pom.xml
b/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/pom.xml
new file mode 100644
index 000..e5bea45
--- /dev/null
+++ b/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/pom.xml
@@ -0,0 +1,44 @@
+
+
+http://maven.apache.org/POM/4.0.0;
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;>
+
+org.apache.maven.plugins.maven-javadoc-plugin.it
+MJAVADOC-556
+1.0-SNAPSHOT
+
+4.0.0
+module
+
+
+
+
+org.apache.maven.plugins
+maven-compiler-plugin
+3.8.0
+
+9
+9
+
+
+
+
+
\ No newline at end of file
diff --git
a/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/src/main/java/module-info.java
b/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/src/main/java/module-info.java
new file mode 100644
index 000..ccb7c17
--- /dev/null
+++
b/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/src/main/java/module-info.java
@@ -0,0 +1,23 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+module module
+{
+exports package1;
+}
\ No newline at end of file
diff --git
a/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/src/main/java/package1/Main1.java
b/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/src/main/java/package1/Main1.java
new file mode 100644
index 000..f380ab9
--- /dev/null
+++
b/src/it/projects/MJAVADOC-556_hide-non-exported-packages/module/src/main/java/package1/Main1.java
@@ -0,0 +1,24 @@
+package package1;
+
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ *
[GitHub] rfscholte commented on issue #14: Exclude non-exported packages when Java Modules are present.
rfscholte commented on issue #14: Exclude non-exported packages when Java Modules are present. URL: https://github.com/apache/maven-javadoc-plugin/pull/14#issuecomment-449960407 Merged into Apache Git This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rfscholte commented on a change in pull request #14: Exclude non-exported packages when Java Modules are present.
rfscholte commented on a change in pull request #14: Exclude non-exported
packages when Java Modules are present.
URL:
https://github.com/apache/maven-javadoc-plugin/pull/14#discussion_r243990204
##
File path:
src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
##
@@ -4342,6 +4351,102 @@ private void copyAdditionalJavadocResources( File
anOutputDirectory )
return getPackageNamesOrFilesWithUnnamedPackages( sourcePaths, files,
true );
}
+/**
+ * @param allSourcePaths not null, containing absolute and relative
paths
+ * @return a list of exported package names for files in allSourcePaths
+ * @throws MavenReportException if any
+ * @see #getFiles
+ * @see #getSourcePaths()
+ */
+private List getPackageNamesRespectingJavaModules( Map> allSourcePaths )
+throws MavenReportException
+{
+List returnList = new ArrayList<>();
+
+if ( !StringUtils.isEmpty( sourcepath ) )
+{
+return returnList;
+}
+LocationManager locationManager = new LocationManager();
Review comment:
locationManager is used at least twice now, which is pretty expensive. I'll
refactor it
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] rfscholte commented on issue #15: Don't fail if module source path already exists.
rfscholte commented on issue #15: Don't fail if module source path already exists. URL: https://github.com/apache/maven-javadoc-plugin/pull/15#issuecomment-449960262 Merged in Apache Git This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] rfscholte closed pull request #15: Don't fail if module source path already exists.
rfscholte closed pull request #15: Don't fail if module source path already
exists.
URL: https://github.com/apache/maven-javadoc-plugin/pull/15
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
b/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
index d1560cf..1e79932 100644
--- a/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
+++ b/src/main/java/org/apache/maven/plugins/javadoc/AbstractJavadocMojo.java
@@ -4754,7 +4754,11 @@ private void addJavadocOptions( File
javadocOutputDirectory,
addArgIfNotEmpty( arguments, "--patch-module",
moduleName + '='
+ JavadocUtil.quotedPathArgument(
getSourcePath( projectSourcepaths.getValue() ) ) );
-Files.createDirectories( moduleSourceDir.resolve(
moduleName ) );
+Path modulePath = moduleSourceDir.resolve(
moduleName );
+if ( !Files.isDirectory( modulePath ) )
+{
+Files.createDirectory( modulePath );
+}
}
catch ( IOException e )
{
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] michael-o commented on issue #125: [MNG-5965] Parallel build multiplies work if multiple goals are given
michael-o commented on issue #125: [MNG-5965] Parallel build multiplies work if multiple goals are given URL: https://github.com/apache/maven/pull/125#issuecomment-449959815 Looking into this. @dbmeneses thank you for the rich documentation. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Issue Comment Deleted] (MNG-5965) Parallel build multiplies work if multiple goals are given
[
https://issues.apache.org/jira/browse/MNG-5965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MNG-5965:
Comment: was deleted
(was: [~janos.gyerik], cannot reproduce:
{noformat}
PS D:\Entwicklung\workspace-4.7\toll> mvn -V install:install-file
"-Dfile=pom.xml" -T10 -Dgrou
pId=one -DartifactId=one -Dversion=1 -Dpackaging=pom
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T20:33:14+02:00)
Maven home: D:\Entwicklung\Programme\apache-maven-3.5.4\bin\..
Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_181\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
[INFO]
[INFO] Using the MultiThreadedBuilder implementation with a thread count of 10
[INFO]
[INFO] -< toll:toll >--
[INFO] Building toll 0.0.1-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-install-plugin:2.4:install-file (default-cli) @ toll ---
[INFO] Installing D:\Entwicklung\workspace-4.7\toll\pom.xml to
C:\Users\mosipov\.m2\repository\one\one\1\one-1.pom
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.342 s (Wall Clock)
[INFO] Finished at: 2018-12-26T13:18:54+01:00
[INFO]
{noformat}
Looking into the IT...)
> Parallel build multiplies work if multiple goals are given
> --
>
> Key: MNG-5965
> URL: https://issues.apache.org/jira/browse/MNG-5965
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.3.9
> Environment: Windows 7 64bit
>Reporter: Matthias Schmalz
>Assignee: Michael Osipov
>Priority: Major
> Attachments: parallel.test.zip
>
>
> When I run a parallel build which invokes multiple goals Maven multiplies the
> work e.g. when I run
> install sonar:sonar
> Every phase is executed once as expected. However when I run
> install sonar:sonar -T 4
> Every phase is executed twice.
> The problem can be reproduced with a single simple Java project (of course
> parallel builds are useless with a single module). Debugging showed that
> every Mojo is really called twice per project.
> Find attached a simple project and two build outputs, where you can see that
> the parallel build is doing everything twice (you can ignore that Sonar fails
> in the end, due to no server is up).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MNG-5965) Parallel build multiplies work if multiple goals are given
[
https://issues.apache.org/jira/browse/MNG-5965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729017#comment-16729017
]
Michael Osipov commented on MNG-5965:
-
[~janos.gyerik], cannot reproduce:
{noformat}
PS D:\Entwicklung\workspace-4.7\toll> mvn -V install:install-file
"-Dfile=pom.xml" -T10 -Dgrou
pId=one -DartifactId=one -Dversion=1 -Dpackaging=pom
Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe;
2018-06-17T20:33:14+02:00)
Maven home: D:\Entwicklung\Programme\apache-maven-3.5.4\bin\..
Java version: 1.8.0_181, vendor: Oracle Corporation, runtime: C:\Program
Files\Java\jdk1.8.0_181\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
[INFO] Scanning for projects...
[INFO]
[INFO] Using the MultiThreadedBuilder implementation with a thread count of 10
[INFO]
[INFO] -< toll:toll >--
[INFO] Building toll 0.0.1-SNAPSHOT
[INFO] [ jar ]-
[INFO]
[INFO] --- maven-install-plugin:2.4:install-file (default-cli) @ toll ---
[INFO] Installing D:\Entwicklung\workspace-4.7\toll\pom.xml to
C:\Users\mosipov\.m2\repository\one\one\1\one-1.pom
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 0.342 s (Wall Clock)
[INFO] Finished at: 2018-12-26T13:18:54+01:00
[INFO]
{noformat}
Looking into the IT...
> Parallel build multiplies work if multiple goals are given
> --
>
> Key: MNG-5965
> URL: https://issues.apache.org/jira/browse/MNG-5965
> Project: Maven
> Issue Type: Bug
> Components: Bootstrap Build
>Affects Versions: 3.3.9
> Environment: Windows 7 64bit
>Reporter: Matthias Schmalz
>Assignee: Michael Osipov
>Priority: Major
> Attachments: parallel.test.zip
>
>
> When I run a parallel build which invokes multiple goals Maven multiplies the
> work e.g. when I run
> install sonar:sonar
> Every phase is executed once as expected. However when I run
> install sonar:sonar -T 4
> Every phase is executed twice.
> The problem can be reproduced with a single simple Java project (of course
> parallel builds are useless with a single module). Debugging showed that
> every Mojo is really called twice per project.
> Find attached a simple project and two build outputs, where you can see that
> the parallel build is doing everything twice (you can ignore that Sonar fails
> in the end, due to no server is up).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MJAVADOC-527) detectLinks may pass invalid URLs to javadoc(1)
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MJAVADOC-527: Summary: detectLinks may pass invalid URLs to javadoc(1) (was: detectLinks may pass invalid URLs to javadoc) > detectLinks may pass invalid URLs to javadoc(1) > --- > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Assignee: Michael Osipov >Priority: Major > Labels: detectLinks > Fix For: 3.0.2 > > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] michael-o commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc
michael-o commented on issue #4: [MJAVADOC-527] - detectLinks may pass invalid urls to javadoc URL: https://github.com/apache/maven-javadoc-plugin/pull/4#issuecomment-449958130 The change looks mostly fine to me. Please rebase again and drop unrelated changes. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (MJAVADOC-527) detectLinks may pass invalid urls to javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MJAVADOC-527: Fix Version/s: 3.0.2 > detectLinks may pass invalid urls to javadoc > > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Assignee: Michael Osipov >Priority: Major > Labels: detectLinks > Fix For: 3.0.2 > > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MJAVADOC-527) detectLinks may pass invalid URLs to javadoc
[ https://issues.apache.org/jira/browse/MJAVADOC-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated MJAVADOC-527: Summary: detectLinks may pass invalid URLs to javadoc (was: detectLinks may pass invalid urls to javadoc) > detectLinks may pass invalid URLs to javadoc > > > Key: MJAVADOC-527 > URL: https://issues.apache.org/jira/browse/MJAVADOC-527 > Project: Maven Javadoc Plugin > Issue Type: Bug > Components: javadoc >Affects Versions: 3.0.1 > Environment: Windows 10 > JDK 8 > Maven 3.5.2 >Reporter: Roberto Benedetti >Assignee: Michael Osipov >Priority: Major > Labels: detectLinks > Fix For: 3.0.2 > > > The url of artifact com.sun.mail:mailapi:1.5.5 is > [http://javamail.java.net/mailapi], so the plugin tests if > [http://javamail.java.net/mailapi/apidocs/package-list] is valid. > That url redirects to [https://javaee.github.io/javamail/] which is JavaMail > home page, so the plugin thinks the url is valid and passes it to javadoc. > javadoc warns about invalid link. > Maybe checking if the effective url is still "package-list" would be safer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (MJAVADOC-469) javadoc-plugin does not double backslashes in argument file
[
https://issues.apache.org/jira/browse/MJAVADOC-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MJAVADOC-469.
---
Resolution: Won't Fix
OK, I have played around a bit, tried the Git test repo and must say that this
is ugly, but an invalid case. Since one is passing raw arguments, there is no
way how Maven can guess its semantic. How is Maven supposed to know that this
is a path and not a mere string? The workaround from [~tschoening] is ugly, but
does the right thing. At best, all path-related args would suppor the
{{file:///}} URI scheme which would make args portable from command line and
args file.
If someone has a better idea, I am all ears.
> javadoc-plugin does not double backslashes in argument file
> ---
>
> Key: MJAVADOC-469
> URL: https://issues.apache.org/jira/browse/MJAVADOC-469
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 2.10.4
>Reporter: Ilya Basin
>Assignee: Michael Osipov
>Priority: Major
>
> On Windows `generate-rest-docs` goal of `maven-jira-plugin` calls
> `maven-javadoc-plugin` with:
> {code}additionalparam: -output
> "C:\path\to\target\classes\resourcedoc.xml"{code}
> If this argument was passed to `javadoc.exe` directly, I'm pretty sure this
> would work. However, the javadoc plugin generates an argument file[1] named
> "options" and executes:
> {code}javadoc.exe ... @options{code}
> The file contains all arguments with unescaped backslashes, although javadoc
> command documentation[2] suggests:
> {quote}If a filename contains embedded spaces, put the whole filename in
> double quotes, and double each backslash ("My Files\\Stuff.java"){quote}
> javadoc plugin version "2.4" is hardcoded in jira plugin, but I see no
> related changes in "2.10.4" in AbstractJavadocMojo.addCommandLineOptions() .
> [1]: https://maven.apache.org/plugins/maven-javadoc-plugin/
> [2]:
> http://docs.oracle.com/javase/7/docs/technotes/tools/windows/javadoc.html#argumentfiles
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (MNG-6538) upgrade Maven Artifact Resolver to 1.3.2 to restore API
[ https://issues.apache.org/jira/browse/MNG-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNG-6538: - Summary: upgrade Maven Artifact Resolver to 1.3.2 to restore API (was: upgrade Maven Artifact Resolver to 3.6.2 to restore API) > upgrade Maven Artifact Resolver to 1.3.2 to restore API > --- > > Key: MNG-6538 > URL: https://issues.apache.org/jira/browse/MNG-6538 > Project: Maven > Issue Type: Task > Components: Embedding >Affects Versions: 3.6.0 >Reporter: Hervé Boutemy >Priority: Major > Fix For: 3.6.1 > > > IntelliJ IDEA Maven integration was broken by API removal done in MRESOLVER-36 > the missing API was added back (with empty implementation) in MRESOLVER-64 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] khmarbaise commented on issue #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11)
khmarbaise commented on issue #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11) URL: https://github.com/apache/maven-dependency-plugin/pull/8#issuecomment-449954672 If we have released maven-dependency-analzyer 1.11.1 (you can vote on the DEV list) afterwards you can upgrade your PR and I appreciate to merge it This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] khmarbaise commented on issue #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11)
khmarbaise commented on issue #8: [MDEP-613] - Fixes bug Analyze failed: Unsupported class file major version 55 (Java 11) URL: https://github.com/apache/maven-dependency-plugin/pull/8#issuecomment-449954596 This was not related to the change you have made. It was an issue related having build [dependency-analyzer with JDK 9 which caused that issue](https://issues.apache.org/jira/browse/MSHARED-786). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MJAVADOC-556) javadoc:aggregate fails with "No source files for package" for packages that are not exported
[
https://issues.apache.org/jira/browse/MJAVADOC-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729006#comment-16729006
]
Hudson commented on MJAVADOC-556:
-
Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » master #109
See
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/109/
> javadoc:aggregate fails with "No source files for package" for packages that
> are not exported
> -
>
> Key: MJAVADOC-556
> URL: https://issues.apache.org/jira/browse/MJAVADOC-556
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.2
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (for Java 11 support)
>Reporter: Gili
>Priority: Major
> Labels: pull-request-available
> Attachments: testcase.zip
>
>
> # Unpack testcase (contains module1, module2 but only module 1 is exported)
> # Run {{clean install javadoc:aggregate}}
> # Build fails with: {{javadoc: error - No source files for package module2}}
> # Modify {{module-info.java}} so it also exports module2
> # Run {{clean install javadoc:aggregate}}
> # Notice that no error occurs
> Expected behavior: {{maven-javadoc-module}} should omit non-exported packages
> from {{target/site/apidocs/packages}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MSHARED-781) Upgrade plexus-archiver 4.0.1
[ https://issues.apache.org/jira/browse/MSHARED-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729004#comment-16729004 ] Karl Heinz Marbaise commented on MSHARED-781: - changed issue title accordingly. > Upgrade plexus-archiver 4.0.1 > - > > Key: MSHARED-781 > URL: https://issues.apache.org/jira/browse/MSHARED-781 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-archiver >Affects Versions: maven-archiver-3.3.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.3.1 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-781) Upgrade plexus-archiver 4.0.1
[ https://issues.apache.org/jira/browse/MSHARED-781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MSHARED-781: Summary: Upgrade plexus-archiver 4.0.1 (was: Upgrade plexus-archiver 3.7.0) > Upgrade plexus-archiver 4.0.1 > - > > Key: MSHARED-781 > URL: https://issues.apache.org/jira/browse/MSHARED-781 > Project: Maven Shared Components > Issue Type: Dependency upgrade > Components: maven-archiver >Affects Versions: maven-archiver-3.3.1 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: maven-archiver-3.3.1 > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MNG-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
[
https://issues.apache.org/jira/browse/MNG-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729000#comment-16729000
]
Hudson commented on MNG-6529:
-
Build succeeded in Jenkins: Maven TLP » maven » master #115
See https://builds.apache.org/job/maven-box/job/maven/job/master/115/
> ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest)
> doesn't honor ProjectBuildingRequest.isResolveDependencies()
> ---
>
> Key: MNG-6529
> URL: https://issues.apache.org/jira/browse/MNG-6529
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Mickael Istria
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.6.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm willing to update Eclipse m2e to take advantage of the
> {{ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)}}
> to avoid duplication of MavenProject in the IDE caused by
> {{ProjectBuilder.build(File singleFile, ProjectBuildingRequest)}}.
> It's already measured to have drastically good impact on the IDE, as
> explained in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38].
> However, using this cause regressions because the multi-projects entry-point
> method seems to totally ignore the
> {{ProjectBuildRequest.isResolveDependencies()}} flag and never returns a
> valid list of {{MavenProject.getArtifacts()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (MNG-6529) ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest) doesn't honor ProjectBuildingRequest.isResolveDependencies()
[
https://issues.apache.org/jira/browse/MNG-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hervé Boutemy closed MNG-6529.
--
Resolution: Fixed
PR merged:
https://gitbox.apache.org/repos/asf?p=maven.git=commit=732e7de8938afdc0b0c6bfa7aa78f5595aa6721b
thank you
> ProjectBuilder.build(List projects, boolean, ProjectBuildingRequest)
> doesn't honor ProjectBuildingRequest.isResolveDependencies()
> ---
>
> Key: MNG-6529
> URL: https://issues.apache.org/jira/browse/MNG-6529
> Project: Maven
> Issue Type: Bug
> Components: core
>Affects Versions: 3.5.3
>Reporter: Mickael Istria
>Assignee: Robert Scholte
>Priority: Critical
> Fix For: 3.6.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I'm willing to update Eclipse m2e to take advantage of the
> {{ProjectBuilder.build(List project, boolean, ProjectBuildingRequest)}}
> to avoid duplication of MavenProject in the IDE caused by
> {{ProjectBuilder.build(File singleFile, ProjectBuildingRequest)}}.
> It's already measured to have drastically good impact on the IDE, as
> explained in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c20] and
> [https://bugs.eclipse.org/bugs/show_bug.cgi?id=515668#c38].
> However, using this cause regressions because the multi-projects entry-point
> method seems to totally ignore the
> {{ProjectBuildRequest.isResolveDependencies()}} flag and never returns a
> valid list of {{MavenProject.getArtifacts()}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] asfgit closed pull request #193: MNG-6529 - ProjectBuild.build(projectsList, ...) ignores request.isResolveDependencies()
asfgit closed pull request #193: MNG-6529 - ProjectBuild.build(projectsList,
...) ignores request.isResolveDependencies()
URL: https://github.com/apache/maven/pull/193
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
b/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
index a6590463a0..35a4e9f596 100644
---
a/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
+++
b/maven-core/src/main/java/org/apache/maven/project/DefaultProjectBuilder.java
@@ -371,7 +371,7 @@ private ModelSource createStubModelSource( Artifact
artifact )
{
noErrors =
build( results, new ArrayList(), projectIndex,
interimResults, request,
- new HashMap() ) && noErrors;
+ new HashMap(), config.session ) &&
noErrors;
}
finally
{
@@ -572,7 +572,8 @@ private void populateReactorModelPool( ReactorModelPool
reactorModelPool, List results,
List projects,
Map projectIndex,
List interimResults,
- ProjectBuildingRequest request, Map
profilesXmls )
+ ProjectBuildingRequest request, Map
profilesXmls,
+ RepositorySystemSession session )
{
boolean noErrors = true;
@@ -587,15 +588,21 @@ private boolean build( List
results, List p
List modules = new ArrayList<>();
noErrors =
-build( results, modules, projectIndex,
interimResult.modules, request, profilesXmls ) && noErrors;
+build( results, modules, projectIndex,
interimResult.modules, request, profilesXmls, session )
+&& noErrors;
projects.addAll( modules );
projects.add( project );
project.setExecutionRoot( interimResult.root );
project.setCollectedProjects( modules );
+DependencyResolutionResult resolutionResult = null;
+if ( request.isResolveDependencies() )
+{
+resolutionResult = resolveDependencies( project, session );
+}
-results.add( new DefaultProjectBuildingResult( project,
result.getProblems(), null ) );
+results.add( new DefaultProjectBuildingResult( project,
result.getProblems(), resolutionResult ) );
}
catch ( ModelBuildingException e )
{
diff --git
a/maven-core/src/test/java/org/apache/maven/project/ProjectBuilderTest.java
b/maven-core/src/test/java/org/apache/maven/project/ProjectBuilderTest.java
index 5511cb1a4d..18f22bd297 100644
--- a/maven-core/src/test/java/org/apache/maven/project/ProjectBuilderTest.java
+++ b/maven-core/src/test/java/org/apache/maven/project/ProjectBuilderTest.java
@@ -20,6 +20,8 @@
*/
import java.io.File;
+import java.util.Collections;
+import java.util.List;
import java.util.Properties;
import org.apache.maven.AbstractCoreMavenComponentTestCase;
@@ -30,6 +32,7 @@
public class ProjectBuilderTest
extends AbstractCoreMavenComponentTestCase
{
+@Override
protected String getProjectsDirectory()
{
return "src/test/projects/project-builder";
@@ -84,4 +87,43 @@ public void testVersionlessManagedDependency()
// this is expected
}
}
+
+public void testResolveDependencies()
+throws Exception
+{
+File pomFile = new File(
"src/test/resources/projects/basic-resolveDependencies.xml" );
+MavenSession mavenSession = createMavenSession( null );
+ProjectBuildingRequest configuration = new
DefaultProjectBuildingRequest();
+configuration.setRepositorySession(
mavenSession.getRepositorySession() );
+configuration.setResolveDependencies( true );
+
+// single project build entry point
+ProjectBuildingResult result = lookup(
org.apache.maven.project.ProjectBuilder.class ).build( pomFile, configuration );
+assertEquals( 1, result.getProject().getArtifacts().size() );
+// multi projects build entry point
+List results = lookup(
org.apache.maven.project.ProjectBuilder.class ).build(
Collections.singletonList( pomFile ), false, configuration );
+assertEquals( 1, results.size() );
+MavenProject mavenProject = results.get( 0 ).getProject();
+assertEquals( 1, mavenProject.getArtifacts().size() );
+}
+
+public void testDontResolveDependencies()
+throws Exception
+{
+File pomFile = new File(
"src/test/resources/projects/basic-resolveDependencies.xml"
[jira] [Closed] (MJAVADOC-554) Running javadoc:aggregate twice throws MavenReportException
[
https://issues.apache.org/jira/browse/MJAVADOC-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte closed MJAVADOC-554.
---
Resolution: Fixed
Assignee: Robert Scholte
Fix Version/s: 3.0.2
Fixed in
[07f78348dec43fddf253339085379e05e9efba89|https://gitbox.apache.org/repos/asf?p=maven-javadoc-plugin.git;a=commit;h=07f78348dec43fddf253339085379e05e9efba89]
Thanks for the patch!
> Running javadoc:aggregate twice throws MavenReportException
> ---
>
> Key: MJAVADOC-554
> URL: https://issues.apache.org/jira/browse/MJAVADOC-554
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.2
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Assignee: Robert Scholte
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.0.2
>
> Attachments: testcase.zip
>
>
> # Open the attached testcase
> # Run {{mvn clean install}}
> # Run {{mvn javadoc::aggregate -e}} (the first time will succeed)
> # Repeat {{mvn javadoc::aggregate -e}}
> # Exception will be thrown:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.2-SNAPSHOT:aggregate
> (default-cli) on project javadoc-maven-report-exception: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.0.2-SNAPSHOT:aggregate
> (default-cli) on project javadoc-maven-report-exception: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.failOnError
> (AbstractJavadocMojo.java:6247)
> at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:333)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1916)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
>
[jira] [Commented] (MJAVADOC-554) Running javadoc:aggregate twice throws MavenReportException
[
https://issues.apache.org/jira/browse/MJAVADOC-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728980#comment-16728980
]
Hudson commented on MJAVADOC-554:
-
Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » master #108
See
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/master/108/
> Running javadoc:aggregate twice throws MavenReportException
> ---
>
> Key: MJAVADOC-554
> URL: https://issues.apache.org/jira/browse/MJAVADOC-554
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.2
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Labels: pull-request-available
> Attachments: testcase.zip
>
>
> # Open the attached testcase
> # Run {{mvn clean install}}
> # Run {{mvn javadoc::aggregate -e}} (the first time will succeed)
> # Repeat {{mvn javadoc::aggregate -e}}
> # Exception will be thrown:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.2-SNAPSHOT:aggregate
> (default-cli) on project javadoc-maven-report-exception: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.0.2-SNAPSHOT:aggregate
> (default-cli) on project javadoc-maven-report-exception: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.failOnError
> (AbstractJavadocMojo.java:6247)
> at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:333)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1916)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at
[jira] [Commented] (MJAVADOC-554) Running javadoc:aggregate twice throws MavenReportException
[
https://issues.apache.org/jira/browse/MJAVADOC-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728970#comment-16728970
]
Hudson commented on MJAVADOC-554:
-
Build succeeded in Jenkins: Maven TLP » maven-javadoc-plugin » MJAVADOC-554 #3
See
https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-554/3/
> Running javadoc:aggregate twice throws MavenReportException
> ---
>
> Key: MJAVADOC-554
> URL: https://issues.apache.org/jira/browse/MJAVADOC-554
> Project: Maven Javadoc Plugin
> Issue Type: Bug
> Components: javadoc
>Affects Versions: 3.0.2
> Environment: Maven 3.6.0
> maven-javadoc-plugin 3.0.2-SNAPSHOT (required for Java 11 support)
>Reporter: Gili
>Priority: Major
> Labels: pull-request-available
> Attachments: testcase.zip
>
>
> # Open the attached testcase
> # Run {{mvn clean install}}
> # Run {{mvn javadoc::aggregate -e}} (the first time will succeed)
> # Repeat {{mvn javadoc::aggregate -e}}
> # Exception will be thrown:
> {code:java}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-javadoc-plugin:3.0.2-SNAPSHOT:aggregate
> (default-cli) on project javadoc-maven-report-exception: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-javadoc-plugin:3.0.2-SNAPSHOT:aggregate
> (default-cli) on project javadoc-maven-report-exception: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:566)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoExecutionException: An error has
> occurred in Javadoc report generation:
> C:\Users\Gili\Documents\3rdparty\javadoc-maven-report-exception\target\site\apidocs\src\module1
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.failOnError
> (AbstractJavadocMojo.java:6247)
> at org.apache.maven.plugins.javadoc.JavadocReport.doExecute
> (JavadocReport.java:333)
> at org.apache.maven.plugins.javadoc.AbstractJavadocMojo.execute
> (AbstractJavadocMojo.java:1916)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:56)
> at
[jira] [Commented] (WAGON-537) Maven transfer speed of large artifacts is slow due to unsuitable buffer strategy
[ https://issues.apache.org/jira/browse/WAGON-537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16728965#comment-16728965 ] Michael Osipov commented on WAGON-537: -- You can do that alreay. Build 3.3.0-SNAPSHOT, manually update them POM of 3.6.1-SNAPSHOT and there you go. > Maven transfer speed of large artifacts is slow due to unsuitable buffer > strategy > - > > Key: WAGON-537 > URL: https://issues.apache.org/jira/browse/WAGON-537 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-provider-api >Affects Versions: 3.2.0 > Environment: Windows 10, JDK 1.8, Nexus Artifact store > 100MB/s > network connection. >Reporter: Olaf Otto >Assignee: Michael Osipov >Priority: Major > Labels: perfomance > Fix For: 3.3.0 > > Attachments: wagon-issue.png > > > We are using maven for build process automation with docker. This sometimes > involves uploading and downloading artifacts with a few gigabytes in size. > Here, maven's transfer speed is consistently and reproducibly slow. For > instance, an artifact with 7,5 GB in size took almost two hours to transfer > in spite of a 100 MB/s connection with respective reproducible download speed > from the remote nexus artifact repository when using a browser to download. > The same is true when uploding such an artifact. > I have investigated the issue using JProfiler. The result shows an issue in > AbstractWagon's transfer( Resource resource, InputStream input, OutputStream > output, int requestType, long maxSize ) method used for remote artifacts and > the same issue in AbstractHttpClientWagon#writeTo(OutputStream). > Here, the input stream is read in a loop using a 4 Kb buffer. Whenever data > is received, the received data is pushed to downstream listeners via > fireTransferProgress. These listeners (or rather consumers) perform expensive > tasks. > Now, the underlying InputStream implementation used in transfer will return > calls to read(buffer, offset, length) as soon as *some* data is available. > That is, fireTransferProgress may well be invoked with an average number of > bytes less than half the buffer capacity (this varies with the underlying > network and hardware architecture). Consequently, fireTransferProgress is > invoked *millions of times* for large files. As this is a blocking operation, > the time spent in fireTransferProgress dominates and drastically slows down > the transfers by at least one order of magnitude. > !wagon-issue.png! > In our case, we found download speed reduced from a theoretical optimum of > ~80 seconds to to more than 3200 seconds. > From an architectural perspective, I would not want to make the consumers / > listeners invoked via fireTransferProgress aware of their potential impact on > download speed, but rather refactor the transfer method such that it uses a > buffer strategy reducing the the number of fireTransferProgress invocations. > This should be done with regard to the expected file size of the transfer, > such that fireTransferProgress is invoked often enough but not to frequent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MSHARED-661) Remove manifest entry "Built-By" for reproducible builds
[ https://issues.apache.org/jira/browse/MSHARED-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hervé Boutemy updated MSHARED-661: -- Description: Maven-archiver automatically creates "Built-By: ", "Build-Jdk: " and "Created-By: " Manifest entries. In the frame of a reproducible build (cf. MNG-6276) these entries make the build not reproducible. Maven-archiver should propose an option to disable the creation of these non-reproducible manifest entries. was: Maven-archiver automatically creates "Built-By", "Build-Jdk" and "Created-By" Manifest entries. In the frame of a reproducible build (cf. MNG-6276) these entries make the build not reproducible. Maven-archiver should propose an option to disable the creation of these non-reproducible manifest entries. > Remove manifest entry "Built-By" for reproducible builds > > > Key: MSHARED-661 > URL: https://issues.apache.org/jira/browse/MSHARED-661 > Project: Maven Shared Components > Issue Type: Wish > Components: maven-archiver >Affects Versions: maven-archiver-3.3.0 >Reporter: Zlika >Assignee: Michael Osipov >Priority: Minor > Fix For: maven-archiver-3.3.1 > > > Maven-archiver automatically creates "Built-By: ", "Build-Jdk: > " and "Created-By: " Manifest > entries. > In the frame of a reproducible build (cf. MNG-6276) these entries make the > build not reproducible. > Maven-archiver should propose an option to disable the creation of these > non-reproducible manifest entries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] hboutemy commented on issue #193: MNG-6529 - ProjectBuild.build(projectsList, ...) ignores request.isResolveDependencies()
hboutemy commented on issue #193: MNG-6529 - ProjectBuild.build(projectsList, ...) ignores request.isResolveDependencies() URL: https://github.com/apache/maven/pull/193#issuecomment-449937896 sorry, I completely overlooked your answer MNG-6529 branch on official maven.git repo updated, waiting for the Jenkins job to finish, then I'll get the consensus to merge on master Thank you and Merry Christmas This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
