Differences Between Packaging and Dependency Type
Ref: http://jira.codehaus.org/browse/MNG-257.
I'd like to work through any problems that might arise from the
differences between <packaging> and <type>. Below is the background,
problem statement, and design decision to rectify them. Please add any
additional problems you see, or issues with the design.
Background
In Maven 2.0, projects are keyed uniquely on only groupId and artifactId
for considering what is a project (version does come into it for
determining different versions of a project).
A packaging is specified on pom.xml to signify how to build that
project, and what type of artifact it produces.
For a given packaging, it may produce multiple artifacts that share the
same project information - the main example used is an ejb that also
outputs an ejb-client. There are also some goals that will produce
artifacts from a given project - for example, the assembly/distribution
goals, javadoc and sources.
To be able to depend on only some of those artifacts, <type> on a
dependency may not match packaging - if you declare <type>ejb</type> you
only get the ejb, and if you declare <type>ejb-client</type>, you only
get the ejb-client JAR. The POM can always be located by the
groupId/artifactId/version combination (type is not present in the m2
repo, and the POM is always under /poms/ if using the old layout).
This also means that while type is not considered in whether an project
is unique, it is for a dependency - so you can download tld files with
the same name as the JAR they belong to.
This is pretty sound from general use cases, though there have been a
couple of problems to arise:
- 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 deploy, 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).
Proposed solution
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.
- 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). - 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 by default - it must be
configured to do so, or the goal added
This ensures that a POM is always deployed and updated for every
deployment of anything, and that the primary artifact and anything tied
to it is never orphaned.
It can mean that under the default lifecycle, there will be no snapshots
deployed for a distribution, for example. This simply means you cannot
depend on a distribution where you can a JAR, unless it is tied, which
is reasonable.
This does not affect released artifacts, as they can be released at
different times and still have the same version.