What is the equivalent of the maven scope "import"?

Hi, I am trying to migrate a maven project to gradle. In my pom.xml I have that :


How can I translate that in gradle?

Cheers, Tibo

There is no direct equivalent. A popular idiom for managing common dependencies (and as such a replacement for ‘dependencyManagement’) is to list dependency declarations in a map. I recommend to search the forum for answers to similar questions. To enforce certain versions, you can use ‘resolutionStrategy.force()’ (see the DSL reference). As for import, Gradle doesn’t currently have such a concept. You will have to list all dependencies in the build script, or script your own solution (get the POM, parse it, add Gradle dependency declarations to, say, aforementioned map).

Ouch I have to say, that’s a deception. In my case, arquillian needs a lot of dependencies and I don’t want to pollute my gradle script with that. IMHO, that’s really a failure of Gradle in the way that it is not fully compatible with maven dependencies. Knowing also that the import scope is not new, it has been introduced in maven 2.0.9 (4 years ago).

I will maybe try to code a solution and to let you know :wink: For the moment, gradle showed me a limit that that forces me to keep building my project with maven…

Gradle’s goal is to have decent Maven compatibility, not to replicate every Maven feature in existence. Some Maven features just don’t fit, and this is one of them. Fortunately, Gradle is flexible enough so that you can almost always script a custom solution.

Thinking more about this, Gradle could provide an API that allows to resolve the ‘dependencies’ and/or ‘dependencyManagement’ sections of a POM, without downloading the artifacts. This information could then be used by the build script author to, for example, force the versions of those dependencies.

I am using Arquillian with Gradle and it works fine except when trying to resolve external libraries. For that I have to add several ancillary BOMs. Has anybody come up with a solution to import a BOM to get the additional dependencies specified there?

A BOM, as I understand, is a list of dependencies that have to be added without the need to resolve any transitive dependencies. It seems that all that is there to do is to extract the list of dependencies specified in the BOM and add them to the list of gradle dependencies. I will appreciate any pointer on how to approach this.

Peter, I spoke with Hans and Luke at RWX about this. I think this is something we need to do. I know here at JBoss we’re creating quite a lot of BOMs to help people get started and use the correct versions. If gradle could slurp that up and then build the deps and force them it would go a long way.

We talked about creating an extension, but the hard part about doing this in an extension is you need to get the effective pom to make sure you’re getting every dependency and version :frowning: (this bom maybe references another bom which has a parent pom etc). Any thoughts? I’d love to help out with this effort.

A BOM, as I understand, is a list of dependencies that have to be added without the need to resolve any transitive dependencies.

I’m pretty sure that transitive dependencies have to be resolved.

I agree that Gradle should support BOMs. Other devs are probably better qualified to comment on the details of how this could be achieved.

Has there been any headway with BOMs? I’d like to add Richfaces to my project using the Richfaces guide:


No, BOMs aren’t supported.

I’m confused. According to the user guide, this should be supported (see below).

I just converted all of my libraries projects to Gradle, and now I need to convert my Richfaces project. Not good. How would you suggest I accomplish this, keeping in mind the BOM dependency configuration I use from the above link.

Gradle User Guide:

Chapter 1. Introduction Full support for your existing Maven or Ivy repository infrastructure.

2.1. Features Gradle fully supports your existing Maven or Ivy repository infrastructure for publishing and retrieving dependencies.

Chapter 47. Build Setup Plugin The Gradle Build Setup plugin can be used to bootstrap the process of creating a new Gradle build. It supports creating brand new projects of different types as well as converting existing builds (e.g. An Apache Maven build) to be Gradle builds.

50.1. Introduction Full Compatibility with Maven and Ivy: If you have defined dependencies in a Maven POM or an Ivy file, Gradle provide seamless integration with a range of popular build tools.

It’s a known limitation, and I don’t know of a solution other than specifying the (direct) dependencies directly in the build script. If you are interested in working on BOM support for Gradle, let us know.

I’ll raise my hand for development

I am in fact interested in developing this as I am also interested in importing arquillian dependencies. I have recently moved to Gradle from Maven and so know a bit about the maven dependency hierarchy. I imagine this support could be achieved easily through groovy’s rich xml support and a bit of research into how the effective pom is constructed.

I would love to develop the code against Gradles source and if you have any suggestions as to where i should place the experiment then let me know. also if i am to create a pull request when accomplished, who would i need to speak with? one more thing, if you have feature reporting software then let me know if i can be assign a feature ticket.

I ran into this issue as well when trying to compile arquillian dependencies with Gradle. In the jar execution phase, I get:

Could not copy MANIFEST.MF to ‘C:\workspace-ggts\arquillian\build\tmp\jar\MANIFEST.MF’.

java.util.zip.ZipException: The JAR/ZIP file (C:\Users\904783.gradle\caches\modules-2\files-2.1\org.jboss.shrinkwrap.resolver\shrinkwrap-resolver-depchain\2.0.0\dfa4e3db4c9752371b1873a728bb0fffd58437f7\shrinkwrap-resolver-depchain-2.0.0.pom) seems corrupted, error: error in opening zip file

Because the latest version of arquillian-container-osgi depends on a pom file, like this:








And Gradle tries to treat the pom like a jar/zip file.

As it stands now, I’m going to be forced to use Maven for this project.

Also, while creating this comment, I found that I had to manually replace < with < for it to actually display my xml tags.

Has there been any progress on this? I’m running into similar issues in a project I’m working on. IMO one of the goals of Gradle needs to be enough support for Maven so that it can be introduced into an existing Java build environment. This is clearly a gap in that support.

Just doesn’t fit? Don’t you mean that we just haven’t got to that yet?

This plugin allows Gradle to use BOMs for controlling versions.


Unfortunately, I don’t know of a good solution for the ‘import’ scope problem.