Maven introduced a very useful idea – “virtual” versions: SNAPSHOT, LATEST, RELEASE. While this is an interesting and powerful feature, I’ve found that people still don’t have a firm grasp of how virtual version work and of some of the problems with SNAPSHOT versions. Depending on how you use and/or understand it, this feature can cut both ways. In this post, I take a closer look at Maven’s Virtual Versions and try to provide some clarity and definition. Continue reading →

They say that one picture is worth a thousand words, so I shut up:

Mercury is a serious attempt to:

• Decouple major Maven components, making them available as stand-alone building blocks rather then having Maven as as one big monolith, not usable outside of its environment.
• Artifact – clearly separate an Artifact from its metadata.
• Repository – convert a repository into active component. It used to give back just pathOf(), now it accepts GAV collections and gives back either metadata or full blown Artifacts.
• Transport – an API in development.
• DependencyTreeBuilder main API for dependency graph creation and conflict resolution.
• Decouple container, so that these components are just plain pojos.
• Introduce Jetty-based HTTP/HTTPS and WebDAV transactional transport layer.
• Asynchronous downloads and uploads. One of the few successful usages of Java NIO in OSS.
• Transactional operations – all-or-nothing for file sets.
• Move integrity control into transport layer, upper level components should not care about these details.
• Abstract out metadata cache, provide at least one implementation there.
• Integrate these changes back to Maven 3.x to make it even better platform than it is right now (if it is possible to be better )

Currently Mercury can already be used for accessing repositories, and conflict resolution is under testing.