...
This does not affect released artifacts, as they can be released at
different times and still have the same version.
Declaring the type in a dependency
It is envisaged that the type could encapsulate the extra information about the classifier. ie, ejb-client is a type that maps to the packaging ejb with the classifier "client".
However, there are a few interesting points here:
- have decided to make groupId/artifactId unique, regardless of type. Therefore, type is not required to lookup an artifact at all (though it would be helpful in indicating what type the artifact is when reading the pom)
- the above could mean that type could be replaced by by something solely to identify the classifier
- if not, then either the type needs to map to a packaging + classifier, or a classifier field needs to be added
- if the type is being mapped, this needs to be quite flexible - ie a plugin can provide its own, but this means that arbitrary classifiers can't be used. This has positives and negatives of its own.
I am in favour of using type mappings, at least to start with. The positives are:
- avoids arbitrary classifiers, making artifactId be well considered
- avoids requirement of additional metadata field in the dependency element
Drawbacks: - can't create your own classifiers, must stick to those provided by the plugin producing the artifact
- must build in the mapping to all plugins providing a packaging.