Standalone jar executable client Maven 2 artifact resolver based on Eclipse Aether.
Version latest was released January 10, 2017
A standalone executable jar which uses Eclipse Aether libraries to query and optionally download via HTTP(S) an artifact from a remote Maven 2 format repository.
The program resolves artifacts with:
The build uses a modified https://github.com/dmitart/scriptjar to compile and generate a single uber jar executable.
So you need Groovy to build it.
The scriptjar modification I made was to optionally include resources in the jar, in this case some log configuration.
A simple bash script wraps the build process.
No. The program is provided as-is, as an example. Feel free to fork it and adjust to your own tooling environment.
This program is meant as an example alternative client side only replacement for the following Nexus Repository Manager 2.x REST resources:
It demonstrates how you can use a standalone client to accomplish a similar result as the Nexus 2.x REST APIs against any remote Maven 2 format repository accessible over HTTP including Nexus 2 or 3.
Yes. It is expected a search and component REST API will eventually be available.
The main limitation of this is it only gets the highest version by comparing all known versions from the remote - which is not necessarily the often wanted 'latest deployed' version from your CI tool.
This only works if the remote is properly implementing a Maven 2 repository format with proper maven-metadata.xml files.
If the remote repository has Maven metadata that is not giving you results you expect, this tool cannot fix that.
Sure, the program doesn't mind. As long as you understand simple stuff like
1.7-SNAPSHOT is higher than
1.6 release for example.
Example, to get the latest timestamped snapshot of all
1.7-SNAPSHOT versions, just specify
1.7-SNAPSHOT as the actual version.
Does the script accept these? Grudgingly yes...but I feel dirty.
First, some short history.
These version names are pseudo values, no longer directly supported in Maven 3 or Nexus 3 - their use encourages non-repeatable builds.
The terms were defined as:
LATEST: get the highest version, snapshot or release. Some people expect this to match the value in the
<latest> element inside maven-metadata.xml. THIS IS BAD!.
RELEASE ( using Apache Maven 2.x ): get the version inside the
<release> element in the GA level maven-metadata.xml file on the remote. THIS IS BAD!.
RELEASE ( using Nexus 2 REST API and this script ): get the highest release version.
LATEST is easy to simulate - the program converts this to an open ended version range.
RELEASE is implemented as get the highest non-snapshot/non-temporary version from the entire list of available versions.
For a longer history, maybe this helps.
Versions are compared lexicographically with some special cases.
A good resource to understand Apache Maven style versions and ranges in general is this doc:
Also become familiar with getting the highest version using a VersionRange with this tool.
Unqualified program arguments are treated as long form artifact coordinates. You can specify more than one if you like. Surround those in quotes for the best results.
The expected artifact coordinate format is:
If you type an invalid artifact coordinate, you will get a message telling you the expected format.
java -jar artifactResolver.jar @script.args commons-dbutils ERROR: Bad artifact coordinates commons-dbutils, expected format is <groupId>:<artifactId>[:<extension>[:<classifier>]]:<version>
Note: There is one special variation that does not require version - see next section.
The program will accept a special artifact coordinate variation consisting of only groupid and artifactid without a version, extension or classifer value.
In that case, the program treats the request as if you specified an unbounded upper range on the version. In other words a Maven 2 version range equal to
[0,), which means a version no lower than zero and as high a version as is available?
Also the extension and classifier are defaults in this case of jar and empty value respectively.
java -jar artifactResolver.jar @script.args commons-dbutils:commons-dbutils
Sure. All calculations of the range are done entirely on inside this client. The version value of the artifact coordinate can be any valid Maven 2 version range.
Specify a username and password with the -u,--user argument. Example:
java -jar artifactResolver.jar --user admin:admin123 --remote.repo "http://localhost:8081/nexus/content/groups/public/" commons-dbutils:commons:dbutils
The script uses Groovy CliBuilder to process arguments. You can create a file and put arguments, like auth, in that file instead.
script.argsin the same directory as the jar
@prefix and pass the file name as an argument to the script. Each line of the file will be read as if it was passed on the command line. Example:java -jar artifactResolver.jar @script.args commons-dbutils:commons-dbutils
This program is perfect. It's your fault.
At least you can turn on verbose logging using Java system properties.
The Jar responds to log levels set according to system properties a la SimpleLogger.
Example - turn on http client logging:
java -Dorg.slf4j.simpleLogger.log.org.apache.http=DEBUG -jar artifactResolver.jar @script.args commons-dbutils:commons-dbutils
The script caches metadata in the local repo, much like Apache Maven itself would, and it likely hasn't expired yet. Just delete the local repo and try again.
Sure - its almost a copy-pasta of bits inside Aether Demo project.
Well... keep in mind this program can help solve only one use case of getting the 'latest' thing.
There are many other client side tools out there that do similar things ie. ivy cli, grape cli
Apparently though the burden of learning them or the overhead of installing them is too much.
And besides Nexus 2 has a REST API that does what you want.
..and Nexus 3 should get around to having a REST API that does this magic for you eventually.
Sure. It's free though. Free as in Free Range Turkey...the rest is up to you.
Wow. You could have downloaded your favorite artifact by now.