Like this:

Dependencies’ version element define version requirements, used to compute effective dependency version. Version requirements have the following syntax:

1.0: “Soft” requirement on 1.0 (just a recommendation, if it matches all other ranges for the dependency)
[1.0]: “Hard” requirement on 1.0
(,1.0]: x <= 1.0
[1.2,1.3]: 1.2 <= x <= 1.3
[1.0,2.0): 1.0 <= x = 1.5
(,1.0],[1.2,): x = 1.2; multiple sets are comma-separated
(,1.1),(1.1,): this excludes 1.1 (for example if it is known not to work in combination with this library)

Suggested:
Setup JFrog QA and Prod repos in organization.
JFrog QA pulls files from public repos on demand basis or periodic basis.
Builds will be tested and make sure that there are no corrupted jars and all are having proper required license.

Developers can point JFrog QA repo.
When build need to happen in Junkins/Hudson…it uses JFrog Prod.
Developers need to inform admins about required files.
Admins assure integrity of required jars to push to JFrog prod.
Also they will validated required licensing issues for given jars.
This is more safest and controlled way to control final artifacts which are going into production.

Like this:

Gradle is an open source build automation system that builds upon the concepts of Apache Ant and Apache Maven and introduces a Groovy-based domain-specific language (DSL) instead of the XML form used by Apache Maven for declaring the project configuration.[2] Gradle uses a directed acyclic graph (“DAG”) to determine the order in which tasks can be run.

Gradle was designed for multi-project builds which can grow to be quite large, and supports incremental builds by intelligently determining which parts of the build tree are up-to-date, so that any task dependent upon those parts will not need to be re-executed.

The initial plugins are primarily focused around Java,[3] Groovy and Scala development and deployment, but more languages and project workflows are on the roadmap.
Source: https://en.wikipedia.org/wiki/Gradle

Notes:
1. Time to move to Gradle instead of Maven for new projects. In Maven we need to write plugins. Here easy to code directly, because it is Groovy Language.
2. Advanced features
3. Support for Java/Scala/Groovy combinational projects (Didn’t checked Maven)

Possible Issues:
1. Too much customization kills over a period of time.
2. Gradle is selling tutorials and Enterprise version. We may end up with payments in case of complex issues.
3. Better not to deviate from standard Java folder structures

– build required branch
– deploy to given server
– build for given Profile
– restart Tomcat
– take backups
– run regression tests’
– run puppet
– run liquibase changes
– no limit on what we can to with this plugin

This type of customization gives control to Engineering teams / QA teams to build and deploy on demand basis without any support from deployment team.