vertx-stack
vertx-stack copied to clipboard
vert-x3
Vert.x stack
when a convergence fails we need to have the full path of dependencies instead of just the path leaves to help fixing the convergence issue. i.e if A -> B...
Bumps [com.google.guava:guava](https://github.com/google/guava) from 30.1.1-jre to 32.0.0-jre. Release notes Sourced from com.google.guava:guava's releases. 32.0.0 Maven <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>32.0.0-jre</version> <!-- or, for Android: --> <version>32.0.0-android</version> </dependency> Jar files 32.0.0-jre.jar 32.0.0-android.jar Guava...
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot] avatar"){kind=avatar}
#### Describe the feature Add a GH feature that on every pull request including a dependency bump, performs the check with the stack for the dependency conflicts. #### Use cases...
It seems that optional=true dependencies that are transitively added force the resolution of the optional dependencies, e.g `vertx-junit5 -> vertx-rx-java2 -> vertx-micrometer-metrics (optional=true)` resolves `vertx-micrometer-metrics` jar It can be reproduced...
the resolver seems to inconsistently resolve transitive, dependencies that are both optional and non optional. For instance - resolving `io.vertx:vertx-stomp:3.1.0` resolves to `io.vertx:vertx-auth-common:3.1.0` - resolving `io.vertx:vertx-auth-common:3.1.0` resolves to a list...
It seems that test scope dependencies are handled and they should be ignored
I just started playing with stack manager `resolve` command. Apparently, there is some issue with the logger used by the stack manager that throws following messages on console: ``` ./vertx.sh...
As discussed [here](https://github.com/vert-x3/vertx-lang-ceylon/issues/21#issuecomment-314398835) I installed `vertx` using `brew`, and it was missing the `vertx-stack.json` file.
