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
mercury-ant-tasks is an Ant wrapper for Mercury functionality, that provides a lot of Mercury functionality inside ant scripts. Continue reading
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.
For a long time I’ve been perplexed by what is going inside Maven, what’s there under the hood. Later I started learning the code and it gave me some perspective. Then I wrote a chunk of code – Mercury, but the exact understanding of what is happening inside is still hard to grasp: the code base is rather big and logic rather complex for a human mind to follow all the details.
All that, plus the necessity to provide tool integration, led to the idea to introduce an event framework into Mercury. All major processing object implement EventGenerator interface, that allows client code to register MercuryEventListener implementations and unRegister them as well. Continue reading