[GitHub] [maven-resolver] suztomo commented on issue #39: [MRESOLVER-93] PathRecordingDependencyVisitor to handle 3 cycles
suztomo commented on issue #39: [MRESOLVER-93] PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-546074592 Thank you. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959170#comment-16959170
]
Hudson commented on MRESOLVER-93:
-
Build succeeded in Jenkins: Maven TLP » maven-resolver » master #36
See https://builds.apache.org/job/maven-box/job/maven-resolver/job/master/36/
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.3, 1.4.0, 1.4.1
>Reporter: Tomo Suzuki
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 1.4.2
>
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> h1. Solutions
> I came up with three solutions. I pick solution #1 for simplicity.
> h2. 1. Use "parents" to check the cycle, rather than visited set
> This is the simplest. Checking array element member is usually discouraged
> especially for large data set. The implementation should confirm the overhead
> of this solution.
> h2. 2. Use AbstractMapBag/Multiset for visited set
> Creating a new class that extends AbstractMapBag and leverages
> IdentityHashMap. Although this solution would be theoretically more efficient
> than solution #1, I felt it's overkill to create a class just for this
> solution.
> {code:java}
> AbstractMapBag(new IdentityHashMap AbstractMapBag.MutableInteger>()){code}
>
> [https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
>
> IdentityHashMap() would work as a multiset.
> h2. 3. Call visitLeave only when visitEnter is true
> The cause of this bug is
> [DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
> calling visitLeave regardless of visitEnter result.
> I'm not sure how many other visitors rely on visitLeave being called
> regardless of visitEnter result.
> h1. Illustration on why existing algorithm does not catch cycle
> The following illustration is the node traversal for the test case above by
> current algorithm. This illustration tracks the dependency node graph and the
> "visited" set maintained by the visitor.
> * visited set. An internal data structure in PathRecordingDependencyVisitor
> to avoid cycle
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
> * visitEnter(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
> When returning true, the node's children is traversed by the algorithm. This
> function adds the node to visited set.
> * visitLeave(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
> This function removes the node from visited set.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true, meaning that the algorithm traverses this b0's children next.
> B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
> B0's children is "a". Because visited set contains "a", visitEnter(a) returns
> false. This means that the algorithm does not traverse this "a"'s children. A
> is added to visited set (already it has).
> !IMG_0236.jpg|width=438,height=197!
> Now not traversing this "a"'s children, the algorithm calls visitLeave(a).
> This removes "a" from visited
[GitHub] [maven-resolver] Tibor17 commented on issue #39: [MRESOLVER-93] PathRecordingDependencyVisitor to handle 3 cycles
Tibor17 commented on issue #39: [MRESOLVER-93] PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-546062013 @suztomo Thx for contributing! Let's keep next commits comming more. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana closed MRESOLVER-93.
-
Resolution: Fixed
https://gitbox.apache.org/repos/asf?p=maven-resolver.git;a=commit;h=2a1f4a134f7d7784f2a64bf58bddd2732bb599a4
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.3, 1.4.0, 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Fix For: 1.4.2
>
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> h1. Solutions
> I came up with three solutions. I pick solution #1 for simplicity.
> h2. 1. Use "parents" to check the cycle, rather than visited set
> This is the simplest. Checking array element member is usually discouraged
> especially for large data set. The implementation should confirm the overhead
> of this solution.
> h2. 2. Use AbstractMapBag/Multiset for visited set
> Creating a new class that extends AbstractMapBag and leverages
> IdentityHashMap. Although this solution would be theoretically more efficient
> than solution #1, I felt it's overkill to create a class just for this
> solution.
> {code:java}
> AbstractMapBag(new IdentityHashMap AbstractMapBag.MutableInteger>()){code}
>
> [https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
>
> IdentityHashMap() would work as a multiset.
> h2. 3. Call visitLeave only when visitEnter is true
> The cause of this bug is
> [DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
> calling visitLeave regardless of visitEnter result.
> I'm not sure how many other visitors rely on visitLeave being called
> regardless of visitEnter result.
> h1. Illustration on why existing algorithm does not catch cycle
> The following illustration is the node traversal for the test case above by
> current algorithm. This illustration tracks the dependency node graph and the
> "visited" set maintained by the visitor.
> * visited set. An internal data structure in PathRecordingDependencyVisitor
> to avoid cycle
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
> * visitEnter(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
> When returning true, the node's children is traversed by the algorithm. This
> function adds the node to visited set.
> * visitLeave(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
> This function removes the node from visited set.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true, meaning that the algorithm traverses this b0's children next.
> B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
> B0's children is "a". Because visited set contains "a", visitEnter(a) returns
> false. This means that the algorithm does not traverse this "a"'s children. A
> is added to visited set (already it has).
> !IMG_0236.jpg|width=438,height=197!
> Now not traversing this "a"'s children, the algorithm calls visitLeave(a).
> This removes "a" from visited set.
> !IMG_0237.jpg|width=434,height=165!
> B0's children are all traversed. the
[jira] [Assigned] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana reassigned MRESOLVER-93:
-
Assignee: Tibor Digana
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.3, 1.4.0, 1.4.1
>Reporter: Tomo Suzuki
>Assignee: Tibor Digana
>Priority: Major
> Fix For: 1.4.2
>
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> h1. Solutions
> I came up with three solutions. I pick solution #1 for simplicity.
> h2. 1. Use "parents" to check the cycle, rather than visited set
> This is the simplest. Checking array element member is usually discouraged
> especially for large data set. The implementation should confirm the overhead
> of this solution.
> h2. 2. Use AbstractMapBag/Multiset for visited set
> Creating a new class that extends AbstractMapBag and leverages
> IdentityHashMap. Although this solution would be theoretically more efficient
> than solution #1, I felt it's overkill to create a class just for this
> solution.
> {code:java}
> AbstractMapBag(new IdentityHashMap AbstractMapBag.MutableInteger>()){code}
>
> [https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
>
> IdentityHashMap() would work as a multiset.
> h2. 3. Call visitLeave only when visitEnter is true
> The cause of this bug is
> [DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
> calling visitLeave regardless of visitEnter result.
> I'm not sure how many other visitors rely on visitLeave being called
> regardless of visitEnter result.
> h1. Illustration on why existing algorithm does not catch cycle
> The following illustration is the node traversal for the test case above by
> current algorithm. This illustration tracks the dependency node graph and the
> "visited" set maintained by the visitor.
> * visited set. An internal data structure in PathRecordingDependencyVisitor
> to avoid cycle
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
> * visitEnter(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
> When returning true, the node's children is traversed by the algorithm. This
> function adds the node to visited set.
> * visitLeave(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
> This function removes the node from visited set.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true, meaning that the algorithm traverses this b0's children next.
> B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
> B0's children is "a". Because visited set contains "a", visitEnter(a) returns
> false. This means that the algorithm does not traverse this "a"'s children. A
> is added to visited set (already it has).
> !IMG_0236.jpg|width=438,height=197!
> Now not traversing this "a"'s children, the algorithm calls visitLeave(a).
> This removes "a" from visited set.
> !IMG_0237.jpg|width=434,height=165!
> B0's children are all traversed. the algorithm calls visitLeave(b0). This
> removes "b0" from
[jira] [Updated] (MRESOLVER-93) PathRecordingDependencyVisitor to handle 3 cycles
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tibor Digana updated MRESOLVER-93:
--
Summary: PathRecordingDependencyVisitor to handle 3 cycles (was:
StackOverflowError by PathRecordingDependencyVisitor)
> PathRecordingDependencyVisitor to handle 3 cycles
> -
>
> Key: MRESOLVER-93
> URL: https://issues.apache.org/jira/browse/MRESOLVER-93
> Project: Maven Resolver
> Issue Type: Improvement
> Components: resolver
>Affects Versions: 1.3.3, 1.4.0, 1.4.1
>Reporter: Tomo Suzuki
>Priority: Major
> Fix For: 1.4.2
>
> Attachments: IMG_0234.jpg, IMG_0235.jpg, IMG_0236.jpg, IMG_0237.jpg,
> IMG_0238.jpg, IMG_0240.jpg, IMG_0241.jpg, IMG_0242.jpg, IMG_0243.jpg,
> IMG_0244.jpg, IMG_0245.jpg, IMG_0255.jpg, IMG_0256.jpg, IMG_0257.jpg,
> IMG_0258.jpg, IMG_0259.jpg, IMG_0260.jpg, IMG_0261.jpg, IMG_0262.jpg,
> IMG_0263.jpg, IMG_0264.jpg, IMG_0265.jpg, IMG_0266.jpg
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> PathRecordingDependencyVisitor cannot handle dependency graphs that have 3 or
> more cycles such as below:
>
> {code:java}
> gid:a:1 (1)
> +- gid:b:0
> | \- ^1
> +- gid:b:1
> | \- ^1
> \- gid:b:2
>\- ^1
> {code}
> It fails with StackOverflowError or OutOfMemoryError. [Test
> case|https://github.com/suztomo/maven-resolver/commit/31b24dfe240997861e27661a7540546fbe6e0dab].
>
> h1. Solutions
> I came up with three solutions. I pick solution #1 for simplicity.
> h2. 1. Use "parents" to check the cycle, rather than visited set
> This is the simplest. Checking array element member is usually discouraged
> especially for large data set. The implementation should confirm the overhead
> of this solution.
> h2. 2. Use AbstractMapBag/Multiset for visited set
> Creating a new class that extends AbstractMapBag and leverages
> IdentityHashMap. Although this solution would be theoretically more efficient
> than solution #1, I felt it's overkill to create a class just for this
> solution.
> {code:java}
> AbstractMapBag(new IdentityHashMap AbstractMapBag.MutableInteger>()){code}
>
> [https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/bag/AbstractMapBag.html]
>
> IdentityHashMap() would work as a multiset.
> h2. 3. Call visitLeave only when visitEnter is true
> The cause of this bug is
> [DefaultDependencyNode|https://github.com/apache/maven-resolver/blob/47edcfe69c4e52ced4cb93d65b7348b5645cdd68/maven-resolver-api/src/main/java/org/eclipse/aether/graph/DefaultDependencyNode.java#L354]
> calling visitLeave regardless of visitEnter result.
> I'm not sure how many other visitors rely on visitLeave being called
> regardless of visitEnter result.
> h1. Illustration on why existing algorithm does not catch cycle
> The following illustration is the node traversal for the test case above by
> current algorithm. This illustration tracks the dependency node graph and the
> "visited" set maintained by the visitor.
> * visited set. An internal data structure in PathRecordingDependencyVisitor
> to avoid cycle
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L45]).
> * visitEnter(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L100]).
> When returning true, the node's children is traversed by the algorithm. This
> function adds the node to visited set.
> * visitLeave(node): PathRecordingDependencyVisitor's function
> ([link|https://github.com/apache/maven-resolver/blob/0c2373f6c66f20953b1a7e443ea1de8672d1b072/maven-resolver-util/src/main/java/org/eclipse/aether/util/graph/visitor/PathRecordingDependencyVisitor.java#L129]).
> This function removes the node from visited set.
>
> The initial state starts with node "a" and visited set \{a}.
> !IMG_0234.jpg|width=334,height=252!
> First child of a is b0. Because visited does not contain, visitEnter(b0)
> returns true, meaning that the algorithm traverses this b0's children next.
> B0 is added to visited.
> !IMG_0235.jpg|width=359,height=191!
> B0's children is "a". Because visited set contains "a", visitEnter(a) returns
> false. This means that the algorithm does not traverse this "a"'s children. A
> is added to visited set (already it has).
> !IMG_0236.jpg|width=438,height=197!
> Now not traversing this "a"'s children, the algorithm calls visitLeave(a).
> This removes "a" from visited set.
> !IMG_0237.jpg|width=434,height=165!
> B0's children are all traversed. the
[GitHub] [maven-resolver] Tibor17 merged pull request #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
Tibor17 merged pull request #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-indexer] Tibor17 closed pull request #40: When is the next release due?
Tibor17 closed pull request #40: When is the next release due? URL: https://github.com/apache/maven-indexer/pull/40 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-indexer] eolivelli commented on issue #40: When is the next release due?
eolivelli commented on issue #40: When is the next release due? URL: https://github.com/apache/maven-indexer/pull/40#issuecomment-546025584 Yes, the best please is on d...@maven.apache.org mailing list This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-indexer] Tibor17 edited a comment on issue #40: When is the next release due?
Tibor17 edited a comment on issue #40: When is the next release due? URL: https://github.com/apache/maven-indexer/pull/40#issuecomment-546016028 There's been quite a lot of commits done after the latest release. Ask the developers on the dev-mailing list. The developers may want to add something as well, so the due date must be an agreement in the community. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-indexer] Tibor17 commented on issue #40: When is the next release due?
Tibor17 commented on issue #40: When is the next release due? URL: https://github.com/apache/maven-indexer/pull/40#issuecomment-546016028 There's been quite a lot of commits after the latest release. Ask the developers on the dev-mailing list. The developers may want to add something as well, so the due date must be an agreement in the community. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-indexer] gatesn commented on issue #40: When is the next release due?
gatesn commented on issue #40: When is the next release due? URL: https://github.com/apache/maven-indexer/pull/40#issuecomment-546006302 Is there any reason to block the release on that? In the extreme, what's the downside to releasing after every commit? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6759) [REGRESSION] Maven fails to use section from dependency when resolving transitive dependencies in some cases
[
https://issues.apache.org/jira/browse/MNG-6759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959030#comment-16959030
]
Hudson commented on MNG-6759:
-
Build succeeded in Jenkins: Maven TLP » maven » MNG-6759 #4
See https://builds.apache.org/job/maven-box/job/maven/job/MNG-6759/4/
> [REGRESSION] Maven fails to use section from dependency when
> resolving transitive dependencies in some cases
> ---
>
> Key: MNG-6759
> URL: https://issues.apache.org/jira/browse/MNG-6759
> Project: Maven
> Issue Type: Bug
>Affects Versions: 3.6.2
>Reporter: Stig Rohde Døssing
>Assignee: Robert Scholte
>Priority: Major
> Fix For: 3.6.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> With Maven 3.6.2, I get the following error on a project using the ASF parent
> POM version 21:
> {quote}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-remote-resources-plugin:1.5:process
> (process-resource-bundles) on project ChildA: Failed to resolve dependencies
> for one or more projects in the reactor. Reason: Missing:
> [ERROR] --
> [ERROR] 1) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR]
> [ERROR] Try downloading the file manually from the project website.
> [ERROR]
> [ERROR] Then, install it using the command:
> [ERROR] mvn install:install-file -DgroupId=io.confluent
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar
> -Dfile=/path/to/file
> [ERROR]
> [ERROR] Alternatively, if you host your own repository you can deploy the
> file there:
> [ERROR] mvn deploy:deploy-file -DgroupId=io.confluent
> -DartifactId=kafka-avro-serializer -Dversion=1.0 -Dpackaging=jar
> -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
> [ERROR]
> [ERROR] Path to dependency:
> [ERROR] 1) io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR] 2) io.github.srdo:ChildB:jar:0.0.1-SNAPSHOT
> [ERROR] 3) io.confluent:kafka-avro-serializer:jar:1.0
> [ERROR] --
> [ERROR] 1 required artifact is missing.
> [ERROR]
> [ERROR] for artifact:
> [ERROR] io.github.srdo:ChildA:jar:0.0.1-SNAPSHOT
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] apache.snapshots (https://repository.apache.org/snapshots,
> releases=false, snapshots=true),
> [ERROR] central (https://repo.maven.apache.org/maven2, releases=true,
> snapshots=false)
> {quote}
> This build works on Maven 3.6.1. I've put up a reproduction at
> https://github.com/srdo/Maven362RepositoriesRegression
> I've found the following workarounds:
> * Dropping the ASF parent POM. Maybe there's a plugin version in there Maven
> 3.6.2 doesn't like?
> * Copying the section from ChildB into ChildA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[
https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959001#comment-16959001
]
Michael Osipov commented on WAGON-541:
--
[~brianf], I'd concur that in 95%+ the reason phrase will not contain any
better help that then status code itself.
[~hboutemy], I'd evaluate something more standardized like
{{application/problem+json}} if it makes sense before we roll our own error
format.
> Command Line Not Showing ReasonPhrase for Errors
>
>
> Key: WAGON-541
> URL: https://issues.apache.org/jira/browse/WAGON-541
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-http
>Affects Versions: 3.2.0
> Environment: Windows 10
>Reporter: Aurelie Pluche
>Priority: Minor
> Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG,
> MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hi,
> I work in the Azure DevOps Artifacts Packaging team at Microsoft where we
> provide a Maven service to our customers. We often use a Reason-Phrase to
> return information on failed requests to customers. This functionality was
> available in previous versions of maven but seems to have disappeared in
> Maven 3.6.0. Was this intentional?
> I have included screenshots of the cmd line response using two different
> maven versions (3.3.9 and 3.6.0). I intentionally made a call that would
> return a 405 error to be able to get an error response. I also used the same
> package.
> Thanks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-indexer] carlspring commented on issue #40: When is the next release due?
carlspring commented on issue #40: When is the next release due? URL: https://github.com/apache/maven-indexer/pull/40#issuecomment-545988354 There is no scheduled date. I would personally like to see Lucene upgraded the more recent versions of Lucene. Would you be interested in looking into this as well? :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Comment Edited] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958978#comment-16958978 ] Herve Boutemy edited comment on WAGON-541 at 10/24/19 3:48 PM: --- since reason phrase will disappear in the future given http/2, we'll need a replacement for communication between Maven and repository managers: let's find a replacement (a header?) waiting for this replacement definition, its implementation by repository managers, then deployment, we should keep the old HTTP/1.1 Reason Phrase was (Author: hboutemy): since reason phrase will disappear in the future given http/2, we'll need a replacement: let's find a replacement (a header?) waiting for this replacement definition, its implementation by repository managers, then deployment, we should keep the old HTTP/1.1 Reason Phrase > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958978#comment-16958978 ] Herve Boutemy commented on WAGON-541: - since reason phrase will disappear in the future given http/2, we'll need a replacement: let's find a replacement (a header?) waiting for this replacement definition, its implementation by repository managers, then deployment, we should keep the old HTTP/1.1 Reason Phrase > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958976#comment-16958976 ] Brian E Fox commented on WAGON-541: --- " The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status code, mostly out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. A client SHOULD ignore the reason-phrase content. reason-phrase = *( HTAB / SP / VCHAR / obs-text )" Maven is in fact often used effectively as a text client and so the spirit of what is being done here is aligned with that original desire. Until such time as everyone switches over to http/2 there's no good reason to intentionally swallow this data, it can only help the user better understand what is going on. > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-indexer] gatesn opened a new pull request #40: When is the next release due?
gatesn opened a new pull request #40: When is the next release due? URL: https://github.com/apache/maven-indexer/pull/40 (GitHub issues aren't enabled so figured I'd ask via PR) There are a few fixes I'd like to pick up, notably the input stream leak in https://github.com/apache/maven-indexer/commit/13beea98584008efc375e738f2acee08ce367727 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSHARED-505) Add element to to allow for reproducible builds
[
https://issues.apache.org/jira/browse/MSHARED-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958938#comment-16958938
]
Herve Boutemy commented on MSHARED-505:
---
I suppose MSHARED-837 is a replacement for this idea: [~sewe] do you agree to
close?
> Add element to to allow for reproducible builds
> -
>
> Key: MSHARED-505
> URL: https://issues.apache.org/jira/browse/MSHARED-505
> Project: Maven Shared Components
> Issue Type: Improvement
> Components: maven-archiver
>Affects Versions: maven-archiver-3.0.0
>Reporter: Andreas Sewe
>Priority: Major
>
> At the moment, running {{mvn clean install}} on just about any project twice
> produces different JARs, as the files’ timestamps within the archive differ.
> It would be great if the {{}} element would allow for a
> {{}} element to force a timestamp for all files within the archive.
> This would allow uses like
> {{{$env.SOURCE_DATE_EPOCH}}} (see
> https://reproducible-builds.org/specs/source-date-epoch/). Or one could
> populate this using a property set by another plugin (the
> {{buildnumber-maven-plugin}} comes to mind, although its {{build-metadata}}
> goal ATM just gives the current time, not the time when the commit was made.
> Probably worth another request for improvement. ;-))
> AFAICT, this improvement ultimately requires a change to
> {{AbstractZipArchiver.zipFile}} from Plexus, but I've filed it with
> {{maven-archiver}}, as that's the surface visible component.
> Anyway, if this is a change that is of interest to others, I would be willing
> to provide patches to both {{maven-archiver}} and the appropriate plexus
> component.
> FWIW, This is just one step towards reproducible builds. There's also
> MSHARED-494.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958923#comment-16958923 ] Michael Osipov commented on WAGON-541: -- I am referring to the RFC 7230, plain simple. It clearly says the client (Maven here) should ignore and there is nothing wrong to do so. Please read section 3.1.2. HTTP/2 completely dropped the phrase anyway. > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-resolver] Tibor17 commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles
Tibor17 commented on issue #39: [MRESOLVER-93] - PathRecordingDependencyVisitor to handle 3 cycles URL: https://github.com/apache/maven-resolver/pull/39#issuecomment-545939445 The [build](https://builds.apache.org/job/maven-box/job/maven/job/MRESOLVER-93/) for integration tests with maven and resolver will be running after Jenkins restart. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Assigned] (MNG-6771) Please fix license issues on binary distribution
[
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enrico Olivelli reassigned MNG-6771:
Assignee: Enrico Olivelli
> Please fix license issues on binary distribution
>
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Assignee: Enrico Olivelli
>Priority: Major
> Labels: licenses
>
> Please feel free to adjust the priority, however
> [http://www.apache.org/legal/release-policy.html#licensing] says that license
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J
> ([http://www.slf4j.org|http://www.slf4j.org/])
> org.slf4j:jcl-over-slf4j:jar:1.7.25
> License: MIT License (MIT)
> [http://www.opensource.org/licenses/mit-license.php]
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT:
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/])
> org.slf4j:slf4j-api:jar:1.7.25
> License: MIT License (MIT)
> [http://www.opensource.org/licenses/mit-license.php]
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
> Here's license for SLF4j: [https://www.slf4j.org/license.html]
> It requires to include slf4j copyright notice, however, Maven fails to do
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it
> almost never points to a true license. It is extremely unlucky that someone
> would copyright their work as "Copyright (c) "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/])
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
> License: Eclipse Public License, Version 1.0 (EPL-1.0)
> [http://www.eclipse.org/legal/epl-v10.html]
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus
> every re-distribution MUST retain ASM copyright notice.
> Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license])
> which is MIT-licensed. Maven fails to comply with jsoup license.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MNG-6771) Please fix license issues on binary distribution
[
https://issues.apache.org/jira/browse/MNG-6771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958919#comment-16958919
]
Enrico Olivelli commented on MNG-6771:
--
I am picking up this issue
> Please fix license issues on binary distribution
>
>
> Key: MNG-6771
> URL: https://issues.apache.org/jira/browse/MNG-6771
> Project: Maven
> Issue Type: Bug
> Components: General
>Affects Versions: 3.6.2
>Reporter: Vladimir Sitnikov
>Priority: Major
> Labels: licenses
>
> Please feel free to adjust the priority, however
> [http://www.apache.org/legal/release-policy.html#licensing] says that license
> clearance is a must, thus I report this as a Blocker.
> {quote}Every ASF release MUST comply with ASF licensing policy. This
> requirement is of utmost importance
> {quote}
> I downloaded apache-maven-3.6.2-bin.zip, and I see the following issues with
> it (note: there might be more):
> h2. 1) jcl-over-slf4j:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - JCL 1.2 implemented over SLF4J
> ([http://www.slf4j.org|http://www.slf4j.org/])
> org.slf4j:jcl-over-slf4j:jar:1.7.25
> License: MIT License (MIT)
> [http://www.opensource.org/licenses/mit-license.php]
> (lib/jcl-over-slf4j.license){quote}
> The license for the artifact is most likely Apache 2.0 rather than MIT:
> [https://github.com/qos-ch/slf4j/tree/master/jcl-over-slf4j]
> h2. 2) slf4j-api:1.7.25
> in apache-maven-3.6.2/LICENSE:
> {quote} - SLF4J API Module ([http://www.slf4j.org|http://www.slf4j.org/])
> org.slf4j:slf4j-api:jar:1.7.25
> License: MIT License (MIT)
> [http://www.opensource.org/licenses/mit-license.php]
> (lib/slf4j-api.license){quote}
> Maven does not comply with SLF4j license.
> Here's license for SLF4j: [https://www.slf4j.org/license.html]
> It requires to include slf4j copyright notice, however, Maven fails to do
> that
> h2. 3) MIT license
> [http://www.opensource.org/licenses/mit-license.php] must not be used as it
> almost never points to a true license. It is extremely unlucky that someone
> would copyright their work as "Copyright (c) "
> h2. 4) org.eclipse.sisu.inject:0.3.3
> in apache-maven-3.6.2/LICENSE:
> {quote} - org.eclipse.sisu.inject
> ([http://www.eclipse.org/sisu/org.eclipse.sisu.inject/])
> org.eclipse.sisu:org.eclipse.sisu.inject:eclipse-plugin:0.3.3
> License: Eclipse Public License, Version 1.0 (EPL-1.0)
> [http://www.eclipse.org/legal/epl-v10.html]
> (lib/org.eclipse.sisu.inject.license){quote}
> The link to eclipse.org/sisu responds with 404.
> sisu might have their own copyright notices that should be retained, however
> Maven re-distributes none of them (org.eclipse.sisu.inject.site-0.3.3.zip has
> notice.html file which is not present in Maven re-distribution)
> h2. 5) ASM in org.eclipse.sisu.inject-0.3.3.jar
> lib/org.eclipse.sisu.inject-0.3.3.jar bundles ASM. ASM is MIT licensed, thus
> every re-distribution MUST retain ASM copyright notice.
> Maven re-distributes ASM and fails to comply with ASM license.
> h2. 6) jsoup in wagon-http-3.3.3-shaded.jar
> lib/wagon-http-3.3.3-shaded.jar bundles jsoup ([https://jsoup.org/license])
> which is MIT-licensed. Maven fails to comply with jsoup license.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338595339 ## File path: surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java ## @@ -220,6 +228,13 @@ public void rerunStillFailing() assertEquals( 0, summary.getTestsSucceededCount() ); assertEquals( 0, summary.getTestsAbortedCount() ); assertEquals( 3, summary.getTestsFailedCount() ); +failDisplays.clear(); +for ( TestExecutionSummary.Failure failure : summary.getFailures() ) Review comment: Pls use brackets. We will use the checkstyle on tests which would fail the build if you do not type brackets. Thx This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958912#comment-16958912 ] Brian E Fox commented on WAGON-541: --- [~michael-o] I can't tell who or what you are referring to here? The Reason Phrase is meant for the humans, the RFC is saying "don't write code that tries to interpret the reason-phrase text". Nothing being requested here is trying to do counter to the spec, on the contrary, we're saying the HUMANS need this reason phrase, it's why it exists in the spec. Maven should not swallow or hide this, which it didn't do until recently. > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338594796 ## File path: surefire-providers/surefire-junit-platform/src/test/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProviderTest.java ## @@ -220,6 +228,13 @@ public void rerunStillFailing() assertEquals( 0, summary.getTestsSucceededCount() ); assertEquals( 0, summary.getTestsAbortedCount() ); assertEquals( 3, summary.getTestsFailedCount() ); +failDisplays.clear(); +for ( TestExecutionSummary.Failure failure : summary.getFailures() ) +failDisplays.add( failure.getTestIdentifier().getDisplayName() ); +assertEquals( 3, failDisplays.size() ); +assertTrue( failDisplays.contains( "Fails twice" ) ); Review comment: LGTM This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on a change in pull request #249: Surefire-1701: Fix @DisplayName breaking reruns
Tibor17 commented on a change in pull request #249: Surefire-1701: Fix
@DisplayName breaking reruns
URL: https://github.com/apache/maven-surefire/pull/249#discussion_r338561545
##
File path:
surefire-providers/surefire-junit-platform/src/main/java/org/apache/maven/surefire/junitplatform/JUnitPlatformProvider.java
##
@@ -187,12 +188,12 @@ private LauncherDiscoveryRequest
buildLauncherDiscoveryRequestForRerunFailures(
LauncherDiscoveryRequestBuilder builder = request().filters( filters
).configurationParameters(
configurationParameters );
// Iterate over recorded failures
-for ( TestIdentifier identifier : adapter.getFailures().keySet() )
+for ( TestIdentifier identifier : new HashSet<>(
adapter.getFailures().keySet() ) )
{
// Extract quantified test name data
String[] classMethodName = adapter.toClassMethodNameWithoutPlan(
identifier );
-String className = classMethodName[1];
-String methodName = classMethodName[3];
+String className = classMethodName[0];
Review comment:
yes, right, we can do it after this PR. And we do not need to have Jira
issue for a small internal code improvement.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communicatio
Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545905632 @jon-bell Let me have a look. Additionally, I will try to rebase the branch. I think we have to do a bit more than in my abstraction because the `accept` should wait for the client response and we should grab `channelId` from the client's data otherwise we would not know the client we are talking to. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545905632 @jon-bell Let me have a look. I will try to rebase the branch. I think we have to do a bit more than in my abstraction because the `accept` should wait for the client response and we should grab `channelId` from the client's data otherwise we would not know the client we are talking to. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MRELEASE-799) update-versions fails when the project artifact is used with a version other than the current snapshot
[
https://issues.apache.org/jira/browse/MRELEASE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958869#comment-16958869
]
Roman Ivanov commented on MRELEASE-799:
---
issue is still reproducible. See details on attempt to bump version of plugin
in checkstyle project - https://github.com/checkstyle/checkstyle/pull/7217
Yes we use different version of ourself/itself in special plugin, but it is
valid usage.
To reproduce, bump maven-release-plugin version to 2.5.3
Command:
{code}
mvn -e release:prepare -DdryRun=true --batch-mode -Darguments='-DskipTests
-DskipITs \
-Djacoco.skip=true -Dpmd.skip=true -Dspotbugs.skip=true -Dxml.skip=true \
-Dcheckstyle.ant.skip=true -Dcheckstyle.skip=true -Dgpg.skip=true'
{code}
output:
{code}
[INFO]
[INFO] Building checkstyle 8.26-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-release-plugin:2.5.3:prepare (default-cli) @ checkstyle ---
[INFO] Verifying that there are no local modifications...
[INFO] ignoring changes on: **/pom.xml.releaseBackup, **/pom.xml.next,
**/pom.xml.tag, **/pom.xml.branch, **/release.properties, **/pom.xml.backup
[INFO] Executing: /bin/sh -c cd /home/rivanov/java/github/romani/checkstyle &&
git rev-parse --show-toplevel
[INFO] Working directory: /home/rivanov/java/github/romani/checkstyle
[INFO] Executing: /bin/sh -c cd /home/rivanov/java/github/romani/checkstyle &&
git status --porcelain .
[INFO] Working directory: /home/rivanov/java/github/romani/checkstyle
[WARNING] Ignoring unrecognized line: ?? release.properties
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] Transforming 'checkstyle'...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1.337 s
[INFO] Finished at: 2019-10-24T05:44:02-07:00
[INFO] Final Memory: 21M/384M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on
project checkstyle: The artifact (com.puppycrawl.tools:checkstyle) requires a
different version (8.26) than what is found (8.18) for the expression
(maven.sevntu-checkstyle-check.checkstyle.version) in the project
(com.puppycrawl.tools:checkstyle). -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on
project checkstyle: The artifact (com.puppycrawl.tools:checkstyle) requires a
different version (8.26) than what is found (8.18) for the expression
(maven.sevntu-checkstyle-check.checkstyle.version) in the project
(com.puppycrawl.tools:checkstyle).
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
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.MojoFailureException: The artifact
(com.puppycrawl.tools:checkstyle) requires a different version (8.26) than what
is found (8.18) for the
[GitHub] [maven-surefire] jon-bell commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
jon-bell commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545877859 @Tibor17 This current PR that we are commenting on [is currently not compilable](https://travis-ci.org/apache/maven-surefire/builds/578466293?utm_source=github_status_medium=notification). I would like to write a connector that is compatible with the interface that you've built here, but I can't compile the interface that you've built here. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communicatio
Tibor17 edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545852743 Hello guys, @rpdai @jon-bell Sorry that I am late. This week we are attending the ApacheCon in Berlin. Last week we were working on Alpine Linux & JSK11 issues related to Docker Maven builds. We made an improvement where Surefire is tolerant to the issues with JDK11/busybox and we will make one more improvement. We fixed SUREFIRE-1584 and a new related issue is going to be finished. We provide the support for JDK 13 and 14, so this should be a big release in M4. Therefore we were a bit idle in the PR. Back to our problem. We understand that people would like to run the forked JVMs on remote hosts or docker containers. Some people like using messaging, etc. So we introduced extensions in this PR which exist and these extensions `should` approach you to do this. The last thing we are missing is the default implementation of the extensions and there I would prefer using neutral socket implementation with a pure `AsynchronousServerSocketChannel`. Can we write a connector together in separate repo (not in Apache) and then we would adopt it to Surefire? I think we should fork our communication apart because there will be a lot of anoying technical talks with details. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
Tibor17 commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545852743 Hello guys, @rpdai @jon-bell Sorry that I am late. This week we are attending the ApacheCon in Berlin. Last week we were working on Alpine Linux & JSK11 issues related to Docker Maven builds. We made an improvement where Surefire is tolerant to the issues with JDK11/busybox and we will make one more improvement. We fixed SUREFIRE-1584 and a new related issue is going to be finished. We provide the support for JDK 13 and 14, so this should be a big release in M4. Therefore we were a bit idle in the PR. Back to our problem. We understand that people would like to run the forked JVMs on remote hosts or docker containers. Some people like using messaging, etc. So we introduced extensions in this PR which exist and these extensions `should` approach you to do this. The last thing we are missing is the default implementation of the extensions and there I would prefer using neutral socket implementation with a pure `AsynchronousServerSocketChannel`. Can we write a connector together in separate repo (not in Apache) and then we would adopt it to Surefire? I think we should fork our communication apart because there will be a lot of anoying technical talks with details. The default implementation should This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project
[
https://issues.apache.org/jira/browse/MNG-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958731#comment-16958731
]
Michael Osipov commented on MNG-6793:
-
You would drastically reduce the download time.
> Sharing local repo for dependencies and a separate local repo for project
> -
>
> Key: MNG-6793
> URL: https://issues.apache.org/jira/browse/MNG-6793
> Project: Maven
> Issue Type: Wish
> Components: Bootstrap Build
>Reporter: Daniel Qian
>Priority: Minor
> Labels: features
>
> When I use Jenkins to build project I have to make each Job to use its own
> local repo (a local dir in the workspace) to prevent concurrent build error:
> {{withMaven(}}
> {{ mavenLocalRepo: '.local-m2-repo'}}
> {{) {}}
> {{ sh 'mvn clean install -P docker,integration-test'}}
> {{ }}}
> Besides, I have to cleanup workspace after build to save disk space.
> So every time the build starts it have to download all the dependencies and
> that really cost a lot of time.
> So I think it will be nice If maven could share a local repo for dependencies
> and a separate local repo for current built project.
> Then we can save time of download dependencies and also provide isolation to
> prevent concurrent build error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MDEP-656) Upgrade plexus-utils to 3.3.0
[ https://issues.apache.org/jira/browse/MDEP-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958713#comment-16958713 ] Hudson commented on MDEP-656: - Build succeeded in Jenkins: Maven TLP » maven-dependency-plugin » master #38 See https://builds.apache.org/job/maven-box/job/maven-dependency-plugin/job/master/38/ > Upgrade plexus-utils to 3.3.0 > - > > Key: MDEP-656 > URL: https://issues.apache.org/jira/browse/MDEP-656 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project
[
https://issues.apache.org/jira/browse/MNG-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958701#comment-16958701
]
Daniel Qian commented on MNG-6793:
--
We have a Nexus server but not on Jenkins server. But I didn't get your point,
how would that be helpful to this situation?
> Sharing local repo for dependencies and a separate local repo for project
> -
>
> Key: MNG-6793
> URL: https://issues.apache.org/jira/browse/MNG-6793
> Project: Maven
> Issue Type: Wish
> Components: Bootstrap Build
>Reporter: Daniel Qian
>Priority: Minor
> Labels: features
>
> When I use Jenkins to build project I have to make each Job to use its own
> local repo (a local dir in the workspace) to prevent concurrent build error:
> {{withMaven(}}
> {{ mavenLocalRepo: '.local-m2-repo'}}
> {{) {}}
> {{ sh 'mvn clean install -P docker,integration-test'}}
> {{ }}}
> Besides, I have to cleanup workspace after build to save disk space.
> So every time the build starts it have to download all the dependencies and
> that really cost a lot of time.
> So I think it will be nice If maven could share a local repo for dependencies
> and a separate local repo for current built project.
> Then we can save time of download dependencies and also provide isolation to
> prevent concurrent build error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (WAGON-541) Command Line Not Showing ReasonPhrase for Errors
[ https://issues.apache.org/jira/browse/WAGON-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958691#comment-16958691 ] Michael Osipov commented on WAGON-541: -- Citing from RFC 7230, *2014-06*: bq. A client SHOULD ignore the reason-phrase content. So folks, you had five years to get used to it. > Command Line Not Showing ReasonPhrase for Errors > > > Key: WAGON-541 > URL: https://issues.apache.org/jira/browse/WAGON-541 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-http >Affects Versions: 3.2.0 > Environment: Windows 10 >Reporter: Aurelie Pluche >Priority: Minor > Attachments: MvnCmdLineV339.PNG, MvnCmdLineV339V2.PNG, > MvnCmdLineV360.PNG, MvnCmdLineV360V2.PNG > > Time Spent: 10m > Remaining Estimate: 0h > > Hi, > I work in the Azure DevOps Artifacts Packaging team at Microsoft where we > provide a Maven service to our customers. We often use a Reason-Phrase to > return information on failed requests to customers. This functionality was > available in previous versions of maven but seems to have disappeared in > Maven 3.6.0. Was this intentional? > I have included screenshots of the cmd line response using two different > maven versions (3.3.9 and 3.6.0). I intentionally made a call that would > return a 405 error to be able to get an error response. I also used the same > package. > Thanks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNG-6584) Maven version 3.6.0 does not show ReasonPhrase anymore
[ https://issues.apache.org/jira/browse/MNG-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958692#comment-16958692 ] Michael Osipov commented on MNG-6584: - Citing from RFC 7230, *2014-06*: bq. A client SHOULD ignore the reason-phrase content. So folks, you had five years to get used to it. > Maven version 3.6.0 does not show ReasonPhrase anymore > -- > > Key: MNG-6584 > URL: https://issues.apache.org/jira/browse/MNG-6584 > Project: Maven > Issue Type: Bug >Affects Versions: 3.6.0 >Reporter: Lucas Ludueño >Priority: Major > Fix For: 3.6.3, 3.6.x-candidate > > > Hi! I noticed that version 3.6.0 does not show the ReasonPhrase anymore (for > example when you run mvn deploy to a custom Maven service). > With version 3.5.0 the ReasonPhrase is shown in a message like: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on > project mule-module-tooling-service: Failed to deploy artifacts: Could not > transfer artifact > 2b34662a-6937-4581-b954-71ba35a53519:mule-module-tooling-service:jar:mule-plugin:2.1.3 > from/to exchange-repository > (http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven): Failed to > transfer file: > http://maven:8088/2b34662a-6937-4581-b954-71ba35a53519/maven/2b34662a-6937-4581-b954-71ba35a53519/mule-module-tooling-service/2.1.3/mule-module-tooling-service-2.1.3-mule-plugin.jar. > Return code is: 400, ReasonPhrase: my-custom-ReasonPhrase. -> [Help 1] > I am not completely sure if the ReasonPhrase has been removed intentionally. > If the answer is no, can you fix it? If the answer is yes, how can I simulate > the behavior to indicate to someone what was happening? > > Thanks!! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MNGSITE-379) Unable to get example of Maven 3 lifecycle extension to work
[
https://issues.apache.org/jira/browse/MNGSITE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958677#comment-16958677
]
Andreas Brieg commented on MNGSITE-379:
---
[~hboutemy] thanks for pointing me there.
I had a look at this. Building and running this project works for me too.
However I found out that this also never tests in the integration tests that
the {{ExecutionListener}} is actually insantiated and listening to events. The
build fails after applying patch [^test-execution-listener-logging.patch]
since there is no output of the execution listener in the captured log. Since I
would like to create an extension with an execution listener listening this
seems to be a problem with some maven component.
> Unable to get example of Maven 3 lifecycle extension to work
>
>
> Key: MNGSITE-379
> URL: https://issues.apache.org/jira/browse/MNGSITE-379
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Andreas Brieg
>Priority: Major
> Attachments: maven-extension-usage.zip,
> test-execution-listener-logging.patch, test-extension.zip
>
>
> I'm trying to create an extension for maven following the description on
> [https://maven.apache.org/examples/maven-3-lifecycle-extensions.html.]
> However I'm unable to get this to work. I have attached the extension I
> created based on the example description as [^test-extension.zip].
> After running {{mvn install}} on the extension and trying to use the
> extension in an example project like in [^maven-extension-usage.zip] the
> execution listener implemented in the extension is not loaded nor listening
> to any event.
> When looking in the artifact created for the extension I see that there is a
> generated {{META-INF/plexus/components.xml}} contained as expected.
> {code}
>
>
>
>
> org.apache.maven.execution.ExecutionListener
> default
> org.example.testextension.Foo
>
> false
>
>
>
> {code}
> Maven also tries to download the extension from the repo when building
> {{maven-extension-usage}}.
> Where is the error here and what should the example page for a maven
> extension better document?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MNGSITE-379) Unable to get example of Maven 3 lifecycle extension to work
[
https://issues.apache.org/jira/browse/MNGSITE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Brieg updated MNGSITE-379:
--
Attachment: test-execution-listener-logging.patch
> Unable to get example of Maven 3 lifecycle extension to work
>
>
> Key: MNGSITE-379
> URL: https://issues.apache.org/jira/browse/MNGSITE-379
> Project: Maven Project Web Site
> Issue Type: Bug
>Reporter: Andreas Brieg
>Priority: Major
> Attachments: maven-extension-usage.zip,
> test-execution-listener-logging.patch, test-extension.zip
>
>
> I'm trying to create an extension for maven following the description on
> [https://maven.apache.org/examples/maven-3-lifecycle-extensions.html.]
> However I'm unable to get this to work. I have attached the extension I
> created based on the example description as [^test-extension.zip].
> After running {{mvn install}} on the extension and trying to use the
> extension in an example project like in [^maven-extension-usage.zip] the
> execution listener implemented in the extension is not loaded nor listening
> to any event.
> When looking in the artifact created for the extension I see that there is a
> generated {{META-INF/plexus/components.xml}} contained as expected.
> {code}
>
>
>
>
> org.apache.maven.execution.ExecutionListener
> default
> org.example.testextension.Foo
>
> false
>
>
>
> {code}
> Maven also tries to download the extension from the repo when building
> {{maven-extension-usage}}.
> Where is the error here and what should the example page for a maven
> extension better document?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (MDEP-656) Upgrade plexus-utils to 3.3.0
[ https://issues.apache.org/jira/browse/MDEP-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise closed MDEP-656. Resolution: Done > Upgrade plexus-utils to 3.3.0 > - > > Key: MDEP-656 > URL: https://issues.apache.org/jira/browse/MDEP-656 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MDEP-656) Upgrade plexus-utils to 3.3.0
[ https://issues.apache.org/jira/browse/MDEP-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958665#comment-16958665 ] Karl Heinz Marbaise commented on MDEP-656: -- Done in [bac42d9f3bbefe265b4fa3fe9cb5d6fca289237e|https://gitbox.apache.org/repos/asf?p=maven-dependency-plugin.git;a=commitdiff;h=bac42d9f3bbefe265b4fa3fe9cb5d6fca289237e] > Upgrade plexus-utils to 3.3.0 > - > > Key: MDEP-656 > URL: https://issues.apache.org/jira/browse/MDEP-656 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] rpdai edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
rpdai edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545808393 @jon-bell that sounds fantastic to me, and I can see you have put a lot of work and thought into it. Much more sense than Netty for this use case, Netty makes more sense for a longer running server, e.g. a HTTP server or a message broker. For short lived Maven processes Netty seems a very big hammer. I think this vindicates your test results @Tibor17. > I would be very happy to take [our fast, Java socket-based implementation](https://github.com/gmu-swe/maven-surefire/pull/2) and refactor it to use the abstractions that you've created here for managing the communication, and re-apply those changes to `maven2surefire-jvm-communication`. However, your branch `maven2surefire-jvm-communication` is currently not compiling correctly, and I am not sure what the most appropriate fix will be. Please let me know if this would be a useful contribution, and if so, how to proceed based on the broken status of this branch. Sounds like this next step needs your input @Tibor17? When you are both ready, feel free to @ me and I will try to build and test against our big multi-module build and redirect STDOUT from tests too; it's quite a complex real world test. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] rpdai edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
rpdai edited a comment on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545808393 @jon-bell that sounds fantastic to me, and I can see you have put a lot of work and thought into it. Much more sense than Netty for this use case, Netty makes much more sense for a longer running server, e.g. a HTTP server or a message broker. For short lived Maven processes it seems a very big hammer. I think this vindicates your test results @Tibor17. > I would be very happy to take [our fast, Java socket-based implementation](https://github.com/gmu-swe/maven-surefire/pull/2) and refactor it to use the abstractions that you've created here for managing the communication, and re-apply those changes to `maven2surefire-jvm-communication`. However, your branch `maven2surefire-jvm-communication` is currently not compiling correctly, and I am not sure what the most appropriate fix will be. Please let me know if this would be a useful contribution, and if so, how to proceed based on the broken status of this branch. Sounds like this next step needs your input @Tibor17? When you are both ready, feel free to @ me and I will try to build and test against our big multi-module build and redirect STDOUT from tests too; it's quite a complex real world test. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [maven-surefire] rpdai commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
rpdai commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545808393 @jon-bell that sounds fantastic to me, and I can see you have put a lot of work and thought into it. Much more sense than Netty for this use case, Netty makes much more sense for a longer running server, e.g. a HTTP server or a message broker. For short lived Maven processes it seems a very big hammer. I think this vindicates your test results @Tibor17. > I would be very happy to take [our fast, Java socket-based implementation](https://github.com/gmu-swe/maven-surefire/pull/2) and refactor it to use the abstractions that you've created here for managing the communication, and re-apply those changes to `maven2surefire-jvm-communication`. However, your branch `maven2surefire-jvm-communication` is currently not compiling correctly, and I am not sure what the most appropriate fix will be. Please let me know if this would be a useful contribution, and if so, how to proceed based on the broken status of this branch. Sounds like this next step needs your input @Tibor17? When you are both ready, feel free to @ me and I will try to build and test against our big multi-module build and redirect STDOUT too; it's quite a complex real world test. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MNG-6793) Sharing local repo for dependencies and a separate local repo for project
[
https://issues.apache.org/jira/browse/MNG-6793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958646#comment-16958646
]
Michael Osipov commented on MNG-6793:
-
Please use a local Nexus instance for that. Do you have one?
> Sharing local repo for dependencies and a separate local repo for project
> -
>
> Key: MNG-6793
> URL: https://issues.apache.org/jira/browse/MNG-6793
> Project: Maven
> Issue Type: Wish
> Components: Bootstrap Build
>Reporter: Daniel Qian
>Priority: Minor
> Labels: features
>
> When I use Jenkins to build project I have to make each Job to use its own
> local repo (a local dir in the workspace) to prevent concurrent build error:
> {{withMaven(}}
> {{ mavenLocalRepo: '.local-m2-repo'}}
> {{) {}}
> {{ sh 'mvn clean install -P docker,integration-test'}}
> {{ }}}
> Besides, I have to cleanup workspace after build to save disk space.
> So every time the build starts it have to download all the dependencies and
> that really cost a lot of time.
> So I think it will be nice If maven could share a local repo for dependencies
> and a separate local repo for current built project.
> Then we can save time of download dependencies and also provide isolation to
> prevent concurrent build error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MDEP-656) Upgrade plexus-utils to 3.3.0
[ https://issues.apache.org/jira/browse/MDEP-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MDEP-656: - Summary: Upgrade plexus-utils to 3.3.0 (was: Upgrade plexus-utils to 3.2.1) > Upgrade plexus-utils to 3.3.0 > - > > Key: MDEP-656 > URL: https://issues.apache.org/jira/browse/MDEP-656 > Project: Maven Dependency Plugin > Issue Type: Dependency upgrade >Affects Versions: 3.1.2 >Reporter: Karl Heinz Marbaise >Assignee: Karl Heinz Marbaise >Priority: Minor > Fix For: 3.1.2 > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [maven-surefire] jon-bell commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication.
jon-bell commented on issue #240: [SUREFIRE-1658] TCP/IP Channel for forked Surefire JVM. Extensions API and SPI. Polymorphism for remote and local process communication. URL: https://github.com/apache/maven-surefire/pull/240#issuecomment-545798173 Hi @Tibor17 and @rpdai, I have great interest in this feature too, and we have hacked out a proof-of-concept to use sockets to communicate between the two JVMs, and observed significant speedups when running tests with `reuseForks=false`. @Col-E and I did some very detailed profiling of the latency between `ForkStarter` and `ForkedBooter` and found that most of the delay was coming on *shutdown* thanks to the JVM's enforced blocking timeout when reading from `stdin`. This in-depth response to a StackOverflow post ["Blocking on stdin makes Java processes take 350ms or more to exit"](https://stackoverflow.com/a/48979347/) explains the issue in great detail. We confirmed with @gliga (who was the researcher at UT Austin who reported [Surefire-1516](https://issues.apache.org/jira/browse/SUREFIRE-1516)) that switching from stdin/stdout to sockets effectively removes the startup/teardown latency that they observed as well. When we implemented this, we felt uncomfortable asking you to merge these changes in because we realized that there would need to be some invasive changes to throughout `maven-surefire-common`. However, now that we see this PR and branch, it looks like thankfully, you have already implemented some re-architecting to allow us to more easily change from using stdin/stdout to sockets. I would be very happy to take [our fast, Java socket-based implementation](https://github.com/gmu-swe/maven-surefire/pull/2) and refactor it to use the abstractions that you've created here for managing the communication, and re-apply those changes to `maven2surefire-jvm-communication`. However, your branch `maven2surefire-jvm-communication` is currently not compiling correctly, and I am not sure what the most appropriate fix will be. Please let me know if this would be a useful contribution, and if so, how to proceed based on the broken status of this branch. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (MSHADE-251) Add skip parameter to shade goal
[ https://issues.apache.org/jira/browse/MSHADE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16958591#comment-16958591 ] Björn Michael commented on MSHADE-251: -- A _skip_ parameter exists in several plugins, is a common idiom in maven ecosystem and increases flexibility a lot. Furthermore changes to the code are little. Please rethink your stance. > Add skip parameter to shade goal > > > Key: MSHADE-251 > URL: https://issues.apache.org/jira/browse/MSHADE-251 > Project: Maven Shade Plugin > Issue Type: New Feature >Reporter: Jonathan Haber >Priority: Minor > > Most Maven plugins have a skip parameter but not the shade plugin. Our > use-case is that we have multiple ways of packaging apps for deployment > (using the shade plugin is one such way). We have these packaging plugins > defined in our shared parent POM and projects can use Maven properties to > control which ones to skip and which to execute. > We've added this feature on our fork (which you can view > [here|https://github.com/HubSpot/maven-plugins/compare/3fb23118d33d842e56a05cc94388d0b40f1bd7e3...811af68429b3728eaef1f8fc42a32bdb2571a8b1]). > It's not much code and having a skip parameter can be a lifesaver when you > need it, so I was hoping this feature could get added. Let me know what you > think. > Thanks, > Jonathan -- This message was sent by Atlassian Jira (v8.3.4#803005)
