Gradle - don't specify version in included dependencies names

Declare a dependency without a version

Gradle lets you declare a dependency without a version but you have to define a dependency constraint, which basically is the definition of your dependency version. This is commonly used in large projects:

dependencies { implementation 'org.springframework:spring-web' } dependencies { constraints { implementation 'org.springframework:spring-web:5.0.2.RELEASE' } } 

Declare a dynamic version

Another option is to declare a dynamic version by using the plus operator. This allows you to use the latest relase of a dependency while you pack your application. Doing so is potentially dangerous since its bears the risk of breaking the application:

apply plugin: 'java-library' repositories { mavenCentral() } dependencies { implementation 'org.springframework:spring-web:5.+' } 

Declaring a file dependency

If you don't want to rely on a binary repository at all but provide dependencies yourself, you can declare a file dependency, from the directories ant, libs and tools. This allows you to name and version dependencies as you like but you have to maintain them yourself:

configurations { antContrib externalLibs deploymentTools } dependencies { antContrib files('ant/antcontrib.jar') externalLibs files('libs/commons-lang.jar', 'libs/log4j.jar') deploymentTools fileTree(dir: 'tools', include: '*.exe') } 

Note I recommend against removing the versions as they are important diagnostic information when the application doesn't work.

The ear task is an instance of the Ear task type, which in turn is basically a specialised form of the standard Zip task type. All archiving tasks allow you to rename files as they are packed.

For example, the following might work:

ear { rename '(.+)-[^-].+(\\.jar)', '$1$2' lib { rename '(.+)-[^-].+(\\.jar)', '$1$2' } } 

I strongly recommend that you check out the new user manual chapter on Working with files for more information about copying and archiving files. Hopefully I'll remember to update this answer with the non-release-candidate link once Gradle 4.7 is out.

Also, if you have any feedback on that chapter let me know.

EDIT Based on OP's feedback, I discovered that the Ear task uses a child copy specification for the JARs in the earlib configuration. Child specifications are independent of both the main one and other child specs, so the main rename() doesn't apply to the earlib files. That's why we add a rename() via the lib {} block.