Context
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
- Decoupling the artifact handling code from Maven itself. This makes developing plugins easier that require it's use because we are no longer bound to a specific version of Maven.
- We can invite other groups to work on the code. We can eventually promote 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 the RuntimeDependencyResolver created by Jan Bartel for use in the Jetty plugin. 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 that's just painful. Jan's facade is far simpler.
- Deprecate all the methods in the current resolver in favor of the facade for external use. Some users may actually be grabbing metadata, and they can use the deprecated methods until we expand the officially supported API to deal with artifact metadata handling. But for the vast majority of users 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 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:
7 Comments
Brian E Fox
We definitely need a way to invoke resolution in a common way from core and plugins. The facade needs to handle all the permutations like ranges, transitivity, scope etc.
Also, it would be nice if dependency could extend from artifact so that comparisons can be made. Ultimately all dependencies are artifacts, but it is currently a major pain to compare the two objects. If nothing else, the facade should include some mechanism for the comparison.
Unknown User (sni)
Sounds good to me. Note also the case where the transitive deps of a war artifacts need to be included (use case: skinny war -> inclusion in EAR). So far it has been postponed to maven 2.1. Putting this apart is really a good idea.
Paul Gier
This sounds like a good idea. I'm currently using the internal dependency resolution components in a plugin, and it was not very intuitive to figure out how to use it. I would be nice to have a simpler facade that could be used within a plugin.
John Dennis Casey
I think this is a great idea. I should also give us a common place to develop APIs that decorate the essential artifact resolution library, too...like alternative resolver implementations, alternative repository implementations, and even things that might start getting into management of artifacts in a very broad sense.
One thing I'm a bit concerned about though: the concept of artifact scope is a little inadequate at the moment. I'm not sure whether this is a problem if the scope vocabulary being too limited, or if the scope concept itself needs to be modified a bit. There are two things that I can think of off the top of my head pertaining to this, though: integration- and other-testing (the number of types of tests could be arbitrary for a given project), and the problem of when a dependency should be resolved and when it shouldn't. The latter is currently handled (somewhat awkwardly) by ArtifactHandler implementations, but I'd really like to find a way to improve on it.
Unknown User (shane.isbell@gmail.com)
Moving the artifact resolver component out of Maven core is a good idea, as it allows more timely releases of changes not tied to a specific Maven version. The issue that I have is with the technical approach. I think that the reason that people would create a new implementation of the artifact resolver is not that the API doesn't work, but rather that the implementation doesn't work. Trying to find out why the plugins needed different implementations and creating a common implementation - and simpler API - that satisfies those specific needs is a good goal. It still leaves the future developer that needs a different implementation in a situation of copying and modifying the code. In that case, the plugin developer will just toss the simple interface and do whatever they want.
The primary advantage of an artifact resolver component would be if it provided services - security, transaction, preconfigured wagons etc - for a given artifact resolver. In that case, as a plugin developer, I would want to implement the given interfaces because it did buy me something: a number of out-of-the-box services. Otherwise, as an implementer, an interface just becomes a design guideline that I may or may not choose to ignore.
John Dennis Casey
Just something to keep in mind: The way I see it, there is nothing more important for the upcoming refactoring of maven-artifact than to get the essential architecture right. While that does include preserving the dependency tree and opening it up to storage of metadata (POMs need to be reachable from the artifact instance, this is pretty critical)...there is something even more important.
As we move into better multi-language support in Maven, we need to implement a Strategy/Command pattern for repositories themselves. That is, given an artifact's identity, it should be up to the repository implementation itself to resolve that artifact. This includes resolving any intermediary metadata necessary to arrive at a concrete identity and location. Typical java-oriented remote repositories will look absolutely nothing like an RPM database, which will look nothing like a .Net system...yet all have to be available for the artifact resolution process, to grab paths that will be used during the build process.
See the discussion here: http://docs.codehaus.org/display/MAVENUSER/Extending+Pom+to+Include+Artifact+Installation+Instructions
Brett Porter
for the record - I'm in favour.
Two things I want to ensure happen, though: