Subject: Exported From Confluence
Content-Type: text/html; charset=UTF-8
Decoupling of Maven Artifact
Decoupling of Maven Artifact
The artifact mechanism was intended to be a general API for the retrieva=
l of binary artifacts and their accompanying metadata. As such it is intend=
ed to serve as the single body of code, and a single API to manipulate arti=
facts. Currently it is not serving this purpose because two copies of the c=
ode exist in the trunk and the 2.0.x branch of Maven, and a proliferation o=
f complicated uses in various plugins (the site plugin, assembly plugin, st=
aging plugin) and Maven related tools like Archetype. Any who needs artifac=
t resolution ends up duplicating much of the same code which means maintain=
ing a single point of use is becoming increasingly difficult. The API curre=
ntly used for artifact resolution is overly complicated and the only way to=
reign in its use and create something simpler is to place all the code in =
one place and start improving it.
Separate the artifact handling code into a separate trunks/tags/branches=
structure and maintain it from one location. This has the benefit of
- Decoupling the artifact handling code from Maven itself. This makes =
developing plugins easier that require it's use because we are no longer bo=
und to a specific version of Maven.
- We can invite other groups to work on the code. We can eventually pr=
omote it to an official sub-project.
- We can maintain the code from a single location actually giving us a=
fighting chance to improve it.
Once the code is separated I think the following should be done:
- Create a facade that can be used by all external clients. In almost =
all cases people want to retrieve a set of artifacts for a particular scope=
, most predominantly the runtime scope. The best facade that I've seen is t=
he RuntimeDependencyResolver created by Jan Bartel for use in the Jetty plu=
gin. I think this should be the basis of the new API we create. At the very=
least to prevent people from using the artifact components directly as tha=
t's just painful. Jan's facade is far simpler.
- Deprecate all the methods in the current resolver in favor of the fa=
cade for external use. Some users may actually be grabbing metadata, and th=
ey can use the deprecated methods until we expand the officially supported =
API to deal with artifact metadata handling. But for the vast majority of u=
sers the facade Jan has created will do almost everything that is necessary=
- Make sure the decoupled code works with the 2.0.x branch (it should =
be, but how knows because the code from trunk should be used). We can ensur=
e capatibility for as long as necessary but these will be internal methods =
which are known by hard core Maven developers but the one we should not sub=
ject the general population to. All you have to do is watch someone open an=
IDE and look at the ArtifactResolver and watch their facial expression to =
know that we should not be showing these methods to anyone.
We can easily try the decoupled code with the trunk of Maven and then at=
tempt it in the 2.0.x branch, then attempt to use them in the plugins and r=
elease them. I think this is the only way to move toward improving the code=
while making sure it works with everything that has been using this code i=
n the past.
+1: jvanzyl, snicoll, brianfox, jdcasey, kenney