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)
Building an attachment must build both
As the assembly is blended into the lifecycle when a release is being performed, the packaging is already assured.
Type -> packaging + classifier mapping
Plugins can specify implementations of type handlers (and many will be in the core). These will indicate the packaging and classifier that they belong to. The default implementation will use packaging = type, no classifier.
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 deploy step
We want attachment of sources and javadoc to be the default, but we also want to configure in the attachment of various assemblies.
This will also depend on whether it is a snapshot build, or a release build as to what is actually attached. Profiles should help here.
We will introduce a a package-additional step after package, where this will occur (and they will use project.attachArtifact to trigger installation and deployment). Sources and javadoc will be enabled by default for jar:jar by the jar packaging lifecycle bindings. These will currently just check for the existence of SNAPSHOT as to whether they will do anything, but in future they should always do their task, and only be bound when in release mode (unless the user has specifically bound them somehow?)
Original Discussion - Differences Between Packaging and Dependency Type
Ref: http://jira.codehaus.org/browse/MNG-257
.
...
- 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.
...