Message-ID: <465600144.40422.1371607220041.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_40421_382549501.1371607220041" ------=_Part_40421_382549501.1371607220041 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
After almost a year of large-scale deployment in the community, Maven is= poised to improve some of its APIs to improve developer productivity, part= icularly in the realm of plugin development.
Specifically, Maven's artifact-resolution subsystem could be easier to u= se. The following sections will discuss some specific improvements that wou= ld make plugin developers vastly more productive.
Developers often could provide more intuitive plugin implementations if = access to the POM information for a given Artifact instance was readily ava= ilable. Therefore, we should look at providing an accessor method on the Ar= tifact class which will retrieve the associated MavenProject instance for t= hat artifact instance. This should be a relatively easy fix, since we alway= s resolve POMs first, then the artifact itself...which means this informati= on is always available, in some form. An alternative approach might be to p= rovide a utility method to retrieve the MavenProject instance, given some A= rtifact instance parameter.
In many plugins and reports, it would be very useful to have access to t= he subtree of artifacts which were transitively resolved by that artifact i= nstance. Additionally, it might be useful to know which artifact instances = caused the current artifact to be included.
Once again, this information is already constructed in some form during = artifact resolution...we just need to keep track of it, and provide accesso= r methods on the Artifact class (or some utility).
These are simply productivity enhancements for artifact-handling plugins= , and should pose no dramatic hurdles to maintaining backward compatibility= . The main issue right now is that Maven discards some very useful informat= ion during the artifact resolution process; we need to think about capturin= g it for future use. This will have the side effects of making plugin imple= mentations cleaner, and reducing the number of components involved in many = plugins' executions.