...
- 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.
Summary of Solution
We need:
- building an attachment (distribution primarily) must build the original, and deploy both.
- type to packaging + classifier mappings (but no need for the reverse)
- binding for the package step (eg ejb-client, tld) - this will also be applicable to deployment, snapshot or not
- binding for the release step (eg sources, javadoc, distributions, etc)
| Info |
|---|
Decision to make here... Rather than going for the forked lifecycle, is it more appropriate to find a nice way to blend it into the main build? |
Building an attachment must build both
TODO
Type -> packaging + classifier mapping
TODO
Attachment at packaging step
Here, a simple call to project.attachArtifact( Artifact artifact ) is appropriate. In the specific use cases:
- ear:ear would create the client based on configuration, and attach it
- a webapp plugin could have a goal, bound to packaging, that when configured published a set of tlds as well as bundled them into a jar
Attachment at release step
We want attachment of sources and javadoc to be the default, but we also want to configure in the attachment of various assemblies.
TODO