-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cant handle managed dependencies #9
Comments
@warmuuh Thanks for the report. Can you give a sample invocation of |
no, sorry, as i did not upload the project to any public repository. |
Certainly possible, though it would surprise me. The dependency versions which were used to build the requested project should match the ones desired by that artifact at runtime according to Maven, including versions gleaned by dependency management. If you find time to create an MCVE, I would greatly appreciate it!
There are several reasons:
|
i setup an example demonstrating this issue here: |
Thanks @warmuuh, that is helpful! Indeed, the transitive dependency versions do not match, due to nuances of Maven's support for managed dependencies. I have created a gist which succinctly illustrates the problem, as well as a workaround I found. I also posted a question on StackOverflow about it, since the need for this workaround seems extreme to me. I implemented the workaround (c17b8f5) as a new An aside about uber-JARsNote that Spring Boot, by default, creates executable fat JARs which are not intended to be reused from other projects as dependencies (see this SO thread for details). Since jrun works by reusing the requested project as a dependency, this could be problematic for you (though I don't know Spring Boot well, so cannot really comment more concretely how/why). You can avoid potential problems by adding the following to your project POM's <executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
<configuration>
<classifier>exec</classifier>
</configuration>
</execution>
</executions> In theory, this lets your project be reused as a normal dependency now, although it will still suffer from the aforementioned dependency version skew due to how Maven's dependency management feature currently works, unless you pass the new |
'-m' works fine, thanks for implementing it, really useful. |
This updates the following dependencies: * imagej-common: 0.28.0 -> 0.28.1 * scijava-search: 0.5.0 -> 0.6.0 The imagej-common update simply brings in newer transitive dependencies. For those importing the pom-scijava bill of materials, this does not matter. But for those depending on ImageJ directly without using the BOM, it affects which version of the scijava-table component (and versions of other components) gets selected by Maven. I consider this to be a bug in Maven; see: * https://stackoverflow.com/q/45041888/1207769 * https://issues.apache.org/jira/browse/MNG-5761 * https://gist.github.com/ctrueden/d058330c8a3687317806ce8cc18332c3 * scijava/jgo#9
And set it to True by default. This flag is necessary for the SciJava BOM to be respected. See also scijava/jgo#9.
This issue has been mentioned on Image.sc Forum. There might be relevant details there: |
This issue has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/jgo-dependency-tree-inconsistent-with-in-project-dependency-tree/79347/3 |
It lookes like it ignores managed dependency entries in parent poms.
common usecase is spring/spring boot applications, it then picks the wrong versions and application does not start.
example:
parent => org.springframework.boot:spring-boot-starter-parent:2.0.0.M1
which includes managed dependency for e.g. jackson-core:2.9.0.pre3 but jrun picks 2.6.1
The text was updated successfully, but these errors were encountered: