Message-ID: <95663204.3978.1410837310306.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_3977_1457003135.1410837310306" ------=_Part_3977_1457003135.1410837310306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
As the assembly is blended into the lifecycle when a release is being pe= rformed, the packaging is already assured.=20
Plugins can specify implementations of type handlers (and many will be i= n the core). These will indicate the packaging and classifier that they bel= ong to. The default implementation will use packaging =3D type, no classifi= er.=20
Here, a simple call to project.attachArtifact( Artifact artifact ) is ap= propriate. In the specific use cases:=20
We want attachment of sources and javadoc to be the default, but we also= want to configure in the attachment of various assemblies.=20
This will also depend on whether it is a snapshot build, or a release bu= ild as to what is actually attached. Profiles should help here.=20
We will introduce a a package-additional step after package, where this = will occur (and they will use project.attachArtifact to trigger installatio= n and deployment). Sources and javadoc will be enabled by default for jar:j= ar 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?)=20
I'd like to work through any problems that might arise from the
di= fferences between <packaging> and <type>. Below is the backgrou= nd,
problem statement, and design decision to rectify them. Please ad= d any
additional problems you see, or issues with the design.
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 speci= fied on pom.xml to signify how to build that
project, and what type o= f artifact it produces.
For a given packaging, it may produce multiple artifacts that share the<=
br /> same project information - the main example used is an ejb that also<=
br /> 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<=
br /> dependency may not match packaging - if you declare <type>ejb&l=
only get the ejb, and if you declare <type>ejb-= client</type>, you only
get the ejb-client JAR. The POM can alw= ays be located by the
groupId/artifactId/version combination (type is= not present in the m2
repo, and the POM is always under /poms/ if us= ing the old layout).
This also means that while type is not considered in whether an project<=
br /> is unique, it is for a dependency - so you can download tld files wit=
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:
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<= br /> should have 1 type that matches exactly, and possibly more types that=
are associated with it. Any type has 0..1 matching packaging.
If a JAR is deployed, then a distribution is deployed - either the POM i=
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 times= tamp
which is not technically correct (especially as it may overwrite= a
Firstly, we differentiate types in the following way:=20
Untied objects can be manually attached, and tied objects can be manuall= y detached. From this, it seems sensible that attachment is only a matter o= f configuration, with sensible defaults, rather than something specific in = the design. Note that there are different scenarios: attachment by configur= ation 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.=20
This ensures that a POM is always deployed and updated for every
d= eployment 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 cann= ot
depend on a distribution where you can a JAR, unless it is tied, w= hich
This does not affect released artifacts, as they can be released at
different times and still have the same version.
It is envisaged that the type could encapsulate the extra information ab= out the classifier. ie, ejb-client is a type that maps to the packaging ejb= with the classifier "client".=20
However, there are a few interesting points here:=20
I am in favour of using type mappings, at least to start with. The posit= ives are:=20