We Keep Coding

Maven BOM dependencies in Gradle

Given that there is a BOM listed in the dependency management of a Maven project Foo like this:
<groupId>someGroup</groupId>
<artifactId>someArtifact-bom</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
<scope>import</scope>
but this BOM comes only into play for a test dependency in a sub-module.
<dependency>
<groupId>someGroup</groupId>
<artifactId>someArtifact</artifactId>
<scope>test</scope>
</dependency>
The artifact declared in the BOM and BOM itself are only available by declaring an additional repository.
If I create a new Maven project and declare the dependency to Foo it gets resolved.
In case I define the very same dependency to Foo in a Groovy project
repositories {
mavenCentral()
}
dependencies {
implementation("myOrg:Foo:1.0")
}
The resolve fails with
- Could not resolve myOrg:Foo-parent:1.0.
- Could not parse POM <mvn-central>/myOrg/Foo-parent-1.0.pom:
- Could not find someGroup:someArtifact-bom:1.0-SNAPSHOT.
...because it does not exist on central.
Of course it can get easily solved by adding the repository, if accessible from the user's project, or putting the BOM and its declared artifacts on central.
I wonder if there are another approach that I couldn't come up with to avoid this problem in the future. An exclude on the dependency definition does not work for BOMs. I can understand this behaviour because a BOM is not a real module.
Just for completeness: After a correct resolve there is no dependency regarding the BOM or its artifact in my project. It is really not needed at all.

To be complete, what you experienced with Gradle looks like the expected behaviour to me.
Gradle will not dynamically add repositories defined by dependencies. This is because it can become a security risk where an added repository could attempt to shadow popular packages with poisoned artifacts.
So the right solution in Gradle is to add the extra repository when required.
With a number of changes that went into how Gradle interprets BOMs and loads Maven POM files, it could very well be that since the BOM is not required, more recent Gradle version will happily ignore it.
But the root problem, transitively adding random repositories, will not be done by any Gradle version.

Thanks to the comment of Corneil du Plessis I took a deeper look in trying out different Gradle versions and a newer one fixed the problem.
Going back later to the original version that made me aware of the problem (5.2.1) it kept resolving the dependency without any error.
To be really sure I cleared the local Gradle caches and re-ran the build with success.
Since I cannot reproduce the issue anymore with either 5.x nor 6.x I am pretty sure that this was related to the cache and the history of Gradle on my machine.
I think it makes sense to answer my question by myself instead of just closing it to leave the information here.

maven is not downloading any dependency that I have add

I have install maven and JDK and tried to create maven project and add some dependencies, as you can see in the screenshot but the dependency is not downloading so I can not import. can you help.

That's because you are using dependencyManagement, where you only specify dependency meta-information, but not the actual dependencies.
More details about managing dependencies via Maven you can find here:
maven dependency mechanism
maven dependency management

Change the version of guice to 4.1.0
What it seems like there is no 4.1
https://mvnrepository.com/artifact/com.google.inject/guice

Java Dependencies of jar files

To resolve issue of dependencies, maven is one of the solution. But maven does not include latest version.
Question:
1) Is there any solution for solving dependency issue other than maven?
2) How can i get latest version in maven?
Thanks to all

I guess you want to include a latest version of a dependency, If that is the case you can use,
Maven tag
<version>LATEST</version>
or
<version>[1.0.0,)</version>
this will get the highest dependency version available grater than 1.0.0.
And note <version>LATEST</version> does not work for maven versions 3.x.

If we are talking about transitive dependencies maven uses dependency which is placed nearest to root.
For example:
A depends on B, B depends on C(v 1.1)
A directly depends on C(1.0).
In that situation, C(1.0) will be included in the application classpath.
More info here and here.
Hope, it will help.

Way to log/alert when Maven 'Dependency mediation' resolves to 'nearest definition' between multiple versions of artifact

I understand that Maven dependency mediation feature determines what version of a dependency will be used when multiple versions are encountered using the "nearest definition" mechanism (closest in the dependency tree). My question is if there is a way to make Maven alert/log it when it does this.
I found that when i was using spring boot & using the starter parent along with other dependencies one of my dependencies got resolved automatically but that caused things to fail at run time which took a while for me to figure out..so was wondering if there is a way to get alerted when Maven does this so i can take some action if needed (explicitly add a dependency, etc.)
Thanks
Muthu

Issues excluding transitive dependency of project reference from eclipse class path

I have several gradle projects in my eclipse workspace. For the sake of simplicity I'm only really interested in 2 of them, let's just use A and B for this.
So the problem I'm having is that Project A has an included dependency on JBoss, which pulls in javax validation-api 1.0.0.GA, and Project B has a dependency on javax validation-api 1.1.0.Final. Since Gradle itself resolves the conflict by using the newer library first, B is happy when built by gradle. But Eclipse itself includes errors which are very distracting while editing.
The correct version of the validation-api jar ends up in B's class path but the problem is that the Gradle IDE plugin changes the project(':A') dependency to a project reference, and Eclipse seems to give the project reference precedence over the external jar. So the old jar is preferred by extension.
I tried adding { exclude module: 'validation-api' } in B's build.gradle for the dependency on A which works according to the output of 'gradle dependencies', however since Eclipse just gets as far as making it a project reference, it won't exclude the jar and the problem remains.
Also per this question I tried adding { transitive = false } and the same thing happens. I don't think even the hack posed there would work for me since the .classpath contains a single reference to the Gradle container so there's nothing to remove.
I've managed to get around this by explicitly including a reference to the correct version of the jar from my gradle cache and then moving it above the Gradle Classpath Container so that eclipse sees that version first.
My question is: Is there a better/more generic way to do this? Preferably one that I can commit to source control without breaking other people's builds or requiring them to manually modify paths or properties somewhere? There is another project with what appears to be a similar issue so something I can fix in the build.gradle file would be awesome.
Worst case scenario, I could probably switch to IntelliJ if that behaves itself better than the Eclipse-Gradle integration?

These kind of transitive dependency issues are long-standing problem with Gradle Eclipse integration (both in STS tooling and also commandline generated .classpath metadata from Gradle's Eclipse plugin. The problem is the way that Eclipse computes transitive classpaths.
Only recently we found a reasonable solution to this problem. Actually there are now two solutions, one better than the other but depending on your situation you might want to use either of them.
The first solution is a bug fix that changes the classpath order of project dependencies so that they are no longer 'preferred' over jar dependencies PR-74. To get this fix you may need to install gradle tooling from a snapshot update site because the fix went in after 3.6.3.
This solution doesn't fix the real problem (you still have the 'wrong' stuff on the classpath) but just makes it less likely to cause real problem in your projects.
The second solution is to enable use of the 'Custom Tooling API model' PR-55 introduced in STS 3.6.3. This is a bit experimental and only works for recent version of Gradle, at least 1.12 but probably better to use 2.x. It also only works for projects that have 'Dependency management' enabled (if not enabled you are using the .classpath generated by Gradle's eclipse plugin which has the same 'broken' classpath issues as the STS tooling).
The 'custom tooling model' is really the better solution in principle as it fixes the way gradle classpath get mapped to eclipse projects so that project dependencies are no longer exported and each project gets its own classpath considering dependencies conflict resolution.
To enable this go to "Window >> Preferences >> Gradle" and enable checkbox "Use Custom Tooling Model".