...
- inconsistency could lead to confusion
- guaranteeing snapshots match versions
- does anybody have anything to add?
Inconsistency:
I believe this is ok. The naming was different to ensure it is clear
that they can be different, and packaging IS A SUBSET of <type>,
guaranteeing they can be handled consistently. Any value of packaging
should have 1 type that matches exactly, and possibly more types that
are associated with it. Any type has 0..1 matching packaging.
Snapshots:
If a JAR is deploydeployed, then a distribution is deployed - either the POM is
republished (so the snapshot is bumped up and the JAR is orphaned), or
it is not and the published dist is orphaned, or reuses the timestamp
which is not technically correct (especially as it may overwrite a
previous distribution).
...
Discussion
Firstly, we differentiate types in the following way:
- that specified by packaging
- other types "tied" to the packaging (eg ejb-client and ejb)
- other types only generated by particular optional goals (eg distribution)
Note that these are not fixed: you might declare a property that forces
"sources" to be tied to "jar" for that project, so you always deploy
sources, but this would not be the default. This could be achieved by
simply binding sources:deploy to the deploy phase.
Untied objects can be manually attached, and tied objects can be manually detached. From this, it seems sensible that attachment is only a matter of configuration, with sensible defaults, rather than something specific in the design. Note that there are different scenarios: attachment by configuration is appropriate for ejb client, but when set it should always happen. For distributions, sources, etc it is appropriate to only attach at release - they do not need to be deployed for snapshots.
- deploying a distribution MUST deploy the JAR - ie, any deployment must
deploy both the POM and the artifact of the packaging (+ anything tied
to it, like an ejb-client or sources). - deploying an artifact MUST deploy any "tied" artifacts - eg, deploying
an EJB must deploy its client - deploying an artifact NEED NOT deploy any "untied" artifacts - eg,
deploying a JAR doesn't deploy sources the distribution by default - it must be
configured to do so, or the goal added
...
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".
...
- 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.