[jira] [Commented] (MDEP-204) go-offline fails to resolve artifact available in maven reactor
[ https://issues.apache.org/jira/browse/MDEP-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921029#comment-16921029 ] Maarten Mulders commented on MDEP-204: -- I've made an attempt to rewrite this goal. It passes existing integration tests, and the one that I've added for this issue. There's a PR [at GitHub|https://github.com/apache/maven-dependency-plugin/pull/20]. > go-offline fails to resolve artifact available in maven reactor > --- > > Key: MDEP-204 > URL: https://issues.apache.org/jira/browse/MDEP-204 > Project: Maven Dependency Plugin > Issue Type: Bug > Components: go-offline >Affects Versions: 2.0, 2.1 > Environment: maven 2.1.0 >Reporter: Stevo Slavic >Priority: Major > Attachments: mvn-dependency-go-offline-failing-example.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Attached is example project, for which IMO dependency:go-offline should be > able to resolve all dependencies as they are only intermodule dependencies > within same multimodule project which haven't been installed yet but are > available in maven reactor so can be considered as resolvable in offline mode > - instead dependency:go-offline fails to resolve these dependencies. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[GitHub] [maven-dependency-plugin] mthmulders opened a new pull request #20: [MDEP-204] Rewrite go-offline goal w/ integration test
mthmulders opened a new pull request #20: [MDEP-204] Rewrite go-offline goal w/ integration test URL: https://github.com/apache/maven-dependency-plugin/pull/20 Following this checklist to help us incorporate your contribution quickly and easily: - [X] Make sure there is a [JIRA issue](https://issues.apache.org/jira/browse/MDEP) filed for the change (usually before you start working on it). Trivial changes like typos do not require a JIRA issue. Your pull request should address just this issue, without pulling in other changes. - [X] Each commit in the pull request should have a meaningful subject line and body. - [X] Format the pull request title like `[MDEP-XXX] - Fixes bug in ApproximateQuantiles`, where you replace `MDEP-XXX` with the appropriate JIRA issue. Best practice is to use the JIRA issue title in the pull request title and in the first line of the commit message. - [X] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [X] Run `mvn clean verify` to make sure basic checks pass. A more thorough check will be performed on your pull request automatically. - [ ] You have run the integration tests successfully (`mvn -Prun-its clean verify`). If your pull request is about ~20 lines of code you don't need to sign an [Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) if you are unsure please ask on the developers list. To make clear that you license your contribution under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) you have to acknowledge this by using the following check-box. - [X] I hereby declare this contribution to be licenced under the [Apache License Version 2.0, January 2004](http://www.apache.org/licenses/LICENSE-2.0) - [ ] In any other case, please file an [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf). This pull request fixes [MDEP-204](https://issues.apache.org/jira/browse/MDEP-204), where the `go-offline` goal did not work for multi-module projects with modules depending on other modules in the reactor. This was caused by the fact that it used Mavens internal dependency resolution mechanism without filtering out the artifacts that are already in the reactor. I've added a custom filter for that, and the plugin now only resolves those artifacts that the filter didn't remove. 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] (MSOURCES-120) Reproducible Builds: make entries in output jar files reproducible (order + timestamp)
[
https://issues.apache.org/jira/browse/MSOURCES-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16921017#comment-16921017
]
Plamen Totev commented on MSOURCES-120:
---
I think I found the root cause. In order to set the Zip entry timestamp Plexus
Archiver calls \{{java.util.zip.ZipEntry#setTime}}. If you follow the method
logic you'll see it actually calls {{java.util.zip.ZipUtils#javaToDosTime}}
{code:java}
Instant instant = Instant.ofEpochMilli(time);
LocalDateTime ldt = LocalDateTime.ofInstant(
instant, ZoneId.systemDefault());
{code}
So actually the resulting ZIP archive depends on the build machine time zone.
> Reproducible Builds: make entries in output jar files reproducible (order +
> timestamp)
> --
>
> Key: MSOURCES-120
> URL: https://issues.apache.org/jira/browse/MSOURCES-120
> Project: Maven Source Plugin
> Issue Type: New Feature
>Affects Versions: 3.0.1
>Reporter: Hervé Boutemy
>Priority: Major
>
> since a jar file is a zip file, entries order and timestamp are a natural
> source of non Reproducible Builds:
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=74682318
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[GitHub] [maven-surefire] dejan2609 commented on issue #233: [SUREFIRE-1494] default provider for JUnit4 integration tests is changed (from 'surefire-junit4' to 'surefire-junit47')
dejan2609 commented on issue #233: [SUREFIRE-1494] default provider for JUnit4 integration tests is changed (from 'surefire-junit4' to 'surefire-junit47') URL: https://github.com/apache/maven-surefire/pull/233#issuecomment-527205391 2. also, I am (almost) certain that I have what it takes for this pair: ``` maven-surefire\surefire-its\src\test\resources\junit4-runlistener\pom.xml maven-surefire\surefire-its\src\test\java\org\apache\maven\surefire\its\JUnit4RunListenerIT.java ``` All what I did here is that I changed testJUnit4RunListener() provider value from` surefire-junit4` to `surefire-junit47` (similar/same as above, but here this may be just enough) 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] dejan2609 edited a comment on issue #233: [SUREFIRE-1494] default provider for JUnit4 integration tests is changed (from 'surefire-junit4' to 'surefire-junit47')
dejan2609 edited a comment on issue #233: [SUREFIRE-1494] default provider for JUnit4 integration tests is changed (from 'surefire-junit4' to 'surefire-junit47') URL: https://github.com/apache/maven-surefire/pull/233#issuecomment-527205154 1. Ok, I need some explanation for this and hence I picked a Java class and corresponding pom.xml (i.e. test methods and their corresponding surefire-junit provider version values): ``` maven-surefire\surefire-its\src\test\resources\junit44-dep\pom.xml maven-surefire\surefire-its\src\test\java\org\apache\maven\surefire\its\JUnitDepIT.java ``` | java test method | surefire junit version | | --- | --- | | testJUnit44Dep() | surefire-junit4 | | testJUnit44DepWithSneaky38 | _activates maven profile **provided381**_| | testJUnit47Dep() | surefire-junit47 | | testJUnit48Dep | surefire-junit47 | Now, what I did so far is to simply switch testJUnit44Dep() surefire junit provider value from `surefire-junit4` to `surefire-junit47` (too good to be true, I assume). 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] dejan2609 commented on issue #233: [SUREFIRE-1494] default provider for JUnit4 integration tests is changed (from 'surefire-junit4' to 'surefire-junit47')
dejan2609 commented on issue #233: [SUREFIRE-1494] default provider for JUnit4 integration tests is changed (from 'surefire-junit4' to 'surefire-junit47') URL: https://github.com/apache/maven-surefire/pull/233#issuecomment-527205154 1. Ok, I need some explanation for this and hence I picked a Java class and corresponding pom.xml (i.e. test methods and their corresponding surefire-junit provider version values): ``` maven-surefire\surefire-its\src\test\resources\junit44-dep\pom.xml maven-surefire\surefire-its\src\test\java\org\apache\maven\surefire\its\JUnitDepIT.java ``` | java test method | surefire junit version | | --- | --- | | testJUnit44Dep() | surefire-junit4 | | testJUnit44DepWithSneaky38 | _activates maven profile provided381_| | testJUnit47Dep() | surefire-junit47 | | testJUnit48Dep | surefire-junit47 | Now, what I did so far is to simply switch testJUnit44Dep() surefire junit provider value from `surefire-junit4` to `surefire-junit47` (too good to be true, I assume). 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-6663) overriding parent dependency management doesn't work for transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920828#comment-16920828 ] Gabriel Belingueres commented on MNG-6663: -- Redefine the library version property set in parent pom with this: 1.3.50 > overriding parent dependency management doesn't work for transitive > dependencies > > > Key: MNG-6663 > URL: https://issues.apache.org/jira/browse/MNG-6663 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.6.1 >Reporter: Alireza Ghassemi >Priority: Major > Attachments: pom.xml, pom.xml > > > overriding the dependencies of a parent POM is possible by setting the > dependency version explicitly in the child POM which makes sense; since a > parent POM is "suggesting" dependency versions for children that don't know > which version to use and a child that knows exactly which version they need > can ignore their parents "suggestion". however that is not the case for > transitive dependencies of the dependency explicitly versioned in the child. > example POM: > [^pom.xml] > mvn dependency:tree output: > [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.31:compile > [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.2.71:compile > [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.2.71:compile > [INFO] | - org.jetbrains:annotations:jar:13.0:compile > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.2.71:compile > expected: > [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.31:compile > [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.3.31:compile > [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.3.31:compile > [INFO] | - org.jetbrains:annotations:jar:13.0:compile > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.3.31:compile > > since 'kotlin-stdlib-jdk8:1.3.31' was compiled with 'kotlin-stdlib:1.3.31' > runtime exceptions will happen; yet nobody needs 'kotlin-stdlib:1.2.71' -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (MNG-6663) overriding parent dependency management doesn't work for transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920792#comment-16920792 ] Alireza Ghassemi edited comment on MNG-6663 at 9/2/19 11:37 AM: [~belingueres] I updated the [^pom.xml] with your suggestion but it results in: [INFO] — maven-dependency-plugin:3.1.1:tree (default-cli) @ kotlin-test — [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.50:compile [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.2.71:compile [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.3.50:compile [INFO] | - org.jetbrains:annotations:jar:13.0:compile [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.2.71:compile so that doesn't fix this, it seems. was (Author: ravenblackdusk): [~belingueres] I updated the [^pom.xml] with your suggestion but it results in: [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ kotlin-test --- [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT [INFO] \- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.50:compile [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.2.71:compile [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.3.50:compile [INFO] | \- org.jetbrains:annotations:jar:13.0:compile [INFO] \- org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.2.71:compile > overriding parent dependency management doesn't work for transitive > dependencies > > > Key: MNG-6663 > URL: https://issues.apache.org/jira/browse/MNG-6663 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.6.1 >Reporter: Alireza Ghassemi >Priority: Major > Attachments: pom.xml, pom.xml > > > overriding the dependencies of a parent POM is possible by setting the > dependency version explicitly in the child POM which makes sense; since a > parent POM is "suggesting" dependency versions for children that don't know > which version to use and a child that knows exactly which version they need > can ignore their parents "suggestion". however that is not the case for > transitive dependencies of the dependency explicitly versioned in the child. > example POM: > [^pom.xml] > mvn dependency:tree output: > [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.31:compile > [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.2.71:compile > [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.2.71:compile > [INFO] | - org.jetbrains:annotations:jar:13.0:compile > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.2.71:compile > expected: > [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.31:compile > [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.3.31:compile > [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.3.31:compile > [INFO] | - org.jetbrains:annotations:jar:13.0:compile > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.3.31:compile > > since 'kotlin-stdlib-jdk8:1.3.31' was compiled with 'kotlin-stdlib:1.3.31' > runtime exceptions will happen; yet nobody needs 'kotlin-stdlib:1.2.71' -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MNG-6663) overriding parent dependency management doesn't work for transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920792#comment-16920792 ] Alireza Ghassemi commented on MNG-6663: --- [~belingueres] I updated the [^pom.xml] with your suggestion but it results in: [INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ kotlin-test --- [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT [INFO] \- org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.50:compile [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.2.71:compile [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.3.50:compile [INFO] | \- org.jetbrains:annotations:jar:13.0:compile [INFO] \- org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.2.71:compile > overriding parent dependency management doesn't work for transitive > dependencies > > > Key: MNG-6663 > URL: https://issues.apache.org/jira/browse/MNG-6663 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.6.1 >Reporter: Alireza Ghassemi >Priority: Major > Attachments: pom.xml, pom.xml > > > overriding the dependencies of a parent POM is possible by setting the > dependency version explicitly in the child POM which makes sense; since a > parent POM is "suggesting" dependency versions for children that don't know > which version to use and a child that knows exactly which version they need > can ignore their parents "suggestion". however that is not the case for > transitive dependencies of the dependency explicitly versioned in the child. > example POM: > [^pom.xml] > mvn dependency:tree output: > [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.31:compile > [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.2.71:compile > [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.2.71:compile > [INFO] | - org.jetbrains:annotations:jar:13.0:compile > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.2.71:compile > expected: > [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.31:compile > [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.3.31:compile > [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.3.31:compile > [INFO] | - org.jetbrains:annotations:jar:13.0:compile > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.3.31:compile > > since 'kotlin-stdlib-jdk8:1.3.31' was compiled with 'kotlin-stdlib:1.3.31' > runtime exceptions will happen; yet nobody needs 'kotlin-stdlib:1.2.71' -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (MRESOLVER-93) StackOverflowError by PathRecordingDependencyVisitor
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920791#comment-16920791
]
Tomo Suzuki commented on MRESOLVER-93:
--
[~tibordigana] How about "StackOverflowError by PathRecordingDependencyVisitor"?
> StackOverflowError by PathRecordingDependencyVisitor
> -
>
> 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: 10m
> 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] [Updated] (MNG-6663) overriding parent dependency management doesn't work for transitive dependencies
[ https://issues.apache.org/jira/browse/MNG-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alireza Ghassemi updated MNG-6663: -- Attachment: pom.xml > overriding parent dependency management doesn't work for transitive > dependencies > > > Key: MNG-6663 > URL: https://issues.apache.org/jira/browse/MNG-6663 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.6.1 >Reporter: Alireza Ghassemi >Priority: Major > Attachments: pom.xml, pom.xml > > > overriding the dependencies of a parent POM is possible by setting the > dependency version explicitly in the child POM which makes sense; since a > parent POM is "suggesting" dependency versions for children that don't know > which version to use and a child that knows exactly which version they need > can ignore their parents "suggestion". however that is not the case for > transitive dependencies of the dependency explicitly versioned in the child. > example POM: > [^pom.xml] > mvn dependency:tree output: > [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.31:compile > [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.2.71:compile > [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.2.71:compile > [INFO] | - org.jetbrains:annotations:jar:13.0:compile > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.2.71:compile > expected: > [INFO] foo.bar:kotlin-test:jar:1.0-SNAPSHOT > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.3.31:compile > [INFO] +- org.jetbrains.kotlin:kotlin-stdlib:jar:1.3.31:compile > [INFO] | +- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.3.31:compile > [INFO] | - org.jetbrains:annotations:jar:13.0:compile > [INFO] - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.3.31:compile > > since 'kotlin-stdlib-jdk8:1.3.31' was compiled with 'kotlin-stdlib:1.3.31' > runtime exceptions will happen; yet nobody needs 'kotlin-stdlib:1.2.71' -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (MRESOLVER-93) StackOverflowError by PathRecordingDependencyVisitor
[
https://issues.apache.org/jira/browse/MRESOLVER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated MRESOLVER-93:
-
Summary: StackOverflowError by PathRecordingDependencyVisitor (was:
PathRecordingDependencyVisitor to handle 3 cycles)
> StackOverflowError by PathRecordingDependencyVisitor
> -
>
> 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: 10m
> 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.
[jira] [Created] (MNG-6755) Console remains colored on build failed
Peter Rader created MNG-6755: Summary: Console remains colored on build failed Key: MNG-6755 URL: https://issues.apache.org/jira/browse/MNG-6755 Project: Maven Issue Type: Bug Components: Command Line Environment: windows Reporter: Peter Rader Attachments: bbbug.png If a build failed the console remains in colors used by the CLI. This problem occourse occasionally. Reproducable often if a resource is locked. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Comment Edited] (MJAVADOC-602) "Aggregating Javadocs For Multi-Projects" code snippet is garbled and tag example is missing
[
https://issues.apache.org/jira/browse/MJAVADOC-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16920464#comment-16920464
]
Falko Modler edited comment on MJAVADOC-602 at 9/2/19 9:20 AM:
---
[~rfscholte]: It is {{mvn validate -Pbuild-delivery-javadoc}}.
{code:xml|title=Full profile}
build-delivery-javadoc
${basedir}/someproject/portal/delivery/target/portal-delivery-${revision}-javadoc.zip
true
validate
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
validate
false
false
-Xdoclint:none
false
private
true
...
maven-antrun-plugin
build-javadoc-zip
run
validate
false
{code}
was (Author: famod):
[~rfscholte]: It is {{mvn validate -build-delivery-javadoc}}.
{code:xml|title=Full profile}
build-delivery-javadoc
${basedir}/someproject/portal/delivery/target/portal-delivery-${revision}-javadoc.zip
true
validate
maven-javadoc-plugin
true
aggregate-javadoc
aggregate-no-fork
validate
false
false
-Xdoclint:none
false
private
true
...
maven-antrun-plugin
build-javadoc-zip
run
validate
false
{code}
> "Aggregating Javadocs For Multi-Projects" code snippet is garbled and
> tag example is missing
> -
>
> Key: MJAVADOC-602
> URL: https://issues.apache.org/jira/browse/MJAVADOC-602
> Project: Maven Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Falko Modler
>Priority: Major
> Attachments: javadoc-aggregation-doc-formatting.PNG
>
>
> After MJAVADOC-134, I was trying to find out how to migrate my working 2.10.4
> aggregation setup to 3.1.0.
> It seems [the respective
> documentation|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/aggregate.html]
> was extended with the info of [this JIRA
>
[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:
--
Fix Version/s: 1.4.2
> 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: 10m
> 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 visited set.
>
[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=16920686#comment-16920686
]
Tibor Digana commented on MRESOLVER-93:
---
[~suztomo]
Can you find a better title for this bug?
Users will read the release notes and I guess they would not know what's going
on in this issue. Thx.
> 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
> 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: 10m
> 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!
>
[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-527045121 Any objections to merge this PR? The local build is successful. 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
