Page History

...

The artifact mechanism was intended to be a general API for the retrieval of binary artifacts and their accompanying metadata. As such it is intended to serve as the single body of code, and a single API to manipulate artifacts. Currently it is not serving this purpose because two copies of the code exist in the trunk and the 2.0.x branch of Maven, and a proliferation of complicated uses in various plugins (the site plugin, assembly plugin, staging plugin) and Maven related tools like Archetype. Any who needs artifact resolution ends up duplicating much of the same code which means maintaining a single point of use is becoming increasingly difficult. The API currently 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.

Solution

...

Separate the artifact handling code into a separate trunks/tags/branches structure and maintain it from one location. This has the benefit of

...

• 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 ensure 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 subject 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 attempt it in the 2.0.x branch, then attempt to use them in the plugins and release 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 in the past.

Votes

+1: jvanzyl, snicoll, brianfox, jdcasey, kenney
+0:
-1: