Maven Artifacts

Artifact Properties

The artifacts that Maven (internally) uses has following (for our topic related) properties:

One property worth explaining is a bit of special one: baseVersion that is actually derived/linked to version (or the other way around, depending on the context): for release artifacts, it holds the same value as version, whereas for snapshot artifacts, it holds the “non-timestamped snapshot version”. For example, for snapshot version “1.0-20220119.164608-1”, the baseVersion would have the value “1.0-SNAPSHOT”. So, version and baseVersion are linked, derived from each other, but they have different values only in case of snapshots.

Important note about Artifacts: the fact is an artifact a snapshot or not, should be queried with method Artifact#isSnapshot().

But where do I set Artifact extension?

In short, nowhere. Or maybe “you rarely have to”. Maven POM (where you declare your project, parent project, dependencies, plugins and other), maps those elements onto artifact coordinates with some extra logic.

In case of “project” and “parent project” aka POMs (after POM made into effective POM, ie. parent values inherited):

In case of “build plugins” and “build extensions”, as they are JARs, this is how corresponding elements are mapped (for build extension change the XML path prefix to project/build/extensions/extension[x]):

And finally, in case of “dependencies”, this is the mapping (no, scope is NOT part of artifact coordinates):

Here, we need to make a short detour to explain “type” (of a dependency) and how it becomes artifact extension.

Maven for dependencies defines “type”, that describes what that dependency is (should it be added to classpath and many other things). Plugins and extensions may define new types, that is usually a must for plugins introducing a “packaging” (lifecycle mapping) by providing ArtifactHandler components with name corresponding to type name.

Maven Core out of the box defines following “types” (handled by same named ArtifactHandler components):

From table above, we can see that if we define the dependency type as “war”, we will hit the “war” handler, that will result in using the war extension (which may not be obvious, as the type and extension we end up with are the same, but internally this indirection does happen). The “test-jar” is more obvious, as it translates to jar extension. Finally, the any last row will be used if none above matches, hence in that case your “type” is used just as “extension”, for example you can write <type>tar.gz</type> for dependency, and you will end up with extension tar.gz (all this happens because as there is no artifact handler named “tar.gz” in table above). Still, you should be aware that this table above may be extended by various plugins and extensions you use in your build!

Also, this has “interesting” consequences, consider for example following Artifact: org.project:reusable-test-support:1.0:tests:jar. With type handlers above, maybe surprisingly, the dependency to this very same artifact can be described in two ways:

<dependency>
  <groupId>org.project</groupId>
  <artifactId>reusable-test-support</artifactId>
  <version>1.0</version>
  <classifier>tests</classifier>
</dependency>

and the equivalent dependency would be:

<dependency>
  <groupId>org.project</groupId>
  <artifactId>reusable-test-support</artifactId>
  <version>1.0</version>
  <type>test-jar</type>
</dependency>

Obvious difference is presence of classifier in first case, while in second lack of it but presence of type “test-jar”, that in the other hand, implies classifier of “tests”. In both cases, extension is “jar” (in first it uses the default value for this property, while in second type defines it).

Note: In this very case, using the first way is somewhat “explicit”, and is recommended way. Not so for the cases when type handler carries some important extra information (like some custom packaging), where using type is more appropriate. Simply put, in this case the type “test-jar” is like an alias for ordinary JARs with “tests” classifier.

Summary

In short, this is how various Maven bits like “project”, “parent project”, “plugin”, “extension” and “dependency” have artifact coordinates mapped from POM elements. Using this knowledge, we can always deduce the artifact coordinate of these POM elements.