olle's Comments

Sonatype Blog : What is Mercury?

Thu, 2 Apr 2009 15:10:28 +0000

If you were asking about Mercury - then I did not notice the post. Can you give me an example - which posting was not answered?

Sonatype Blog : What is Mercury?

Thu, 2 Apr 2009 15:06:21 +0000

Main reason is DependencyProcessor. Each Repository is expected to use - potentially different - DependencyProcessor, while VirtualRepositoryReader does not have any as it's a layer on top of other repos with primary goal to merge/integrate data between repositories. It's very similar, but still different

Sonatype Blog : Dirty Tree - Resolved Tree - Resolved Graph

Wed, 1 Apr 2009 22:10:46 +0000

b:b:1 is closer to the root of the tree - it's on level 1, and default policy set mandates : closest / newest, so b:b:1 is selected over b:b:2, which happened to be on level 2 This behavior could be overwritten by configuration, client can specify almost any selection policies.

Sonatype Blog : Dirty Tree - Resolved Tree - Resolved Graph

Wed, 1 Apr 2009 16:43:08 +0000

For dirty and resolved trees - it is Mercury's DependencyBuilder interface. The graph is not implemented yet and will be added later this month, because we work towards exposing these APIs in Maven3. Usage details - check the mercury-plexus project - it wraps all this functionality into a plexus component

Sonatype Blog : What is Mercury?

Mon, 30 Mar 2009 21:24:11 +0000

Post them here for instance. Or subscribe to Maven dev. list (http://maven.apache.org/mail-lists.html) and post them there.

Sonatype Blog : What is Mercury?

Mon, 30 Mar 2009 21:21:59 +0000

Mercury is Artifact/Repository management library, while embedder is entire Maven external interface. Mercury is used by Maven as a library to perform particular functions.

Sonatype Blog : Maven Virtual Versions: Let's Fix this Mess!

Tue, 17 Mar 2009 16:29:13 +0000

Let me first be clear about virtual versions as a whole: they are an excellent source of hard-to-find build errors and should not be treated lightly. While SNAPSHOT is a necessary evil and somewhat eases developer's life, RELEASE and LATEST are pure hell and should be deprecated right away. All 3 grew from the lack of version manipulation tools, and SNAPSHOT at least allows some kind of control - it replaces a partial version and we in general agree that for, say, a jar versioned 2.3-beta-3-SNAPSHOT, all binaries with version starting with 2.3-beta-3-... share common APIs and behavior. Why in the world we assume that any released version of an artifact adheres to the same APIs and behaves the same - remains a mistery to me! This was RELEASE. When we touch LATEST - gloves are off - it can be anything, including the latest SNAPSHOT. So unless we don't have anything else to do - I'd deprecate them on the spot. Now back to the question :) Using virtual version for the parent will today work in Mercury, but it's by mistake - I will remove that. It most probably will not work in Maven2, and that is good. In the question you touch a different subject - how can we refer to the parent and do not spend much time maintaining it. There is no easy answer to this one. I use parent POM for all versions and refer to it from modules 3 levels deeper. It works fine and release plugin takes care of version updates. If you don't use release plugin - it's a very tedious job. M2E will definitely help under Eclipse - you can "Refactor--Rename Artifact" with it.

Sonatype Blog : New Feature: Maven Settings Password Encryption

Sun, 8 Feb 2009 20:00:14 +0000

Implementation is very straightforward. Might be a good idea - property post-processing, but we need to discuss this on the dev list. Can you post it there?

Sonatype Blog : New Feature: Maven Settings Password Encryption

Sun, 8 Feb 2009 19:56:12 +0000

Ian - I had it implemented that way: presumed that passwords should be all encrypted and: - if password was unencrypted - encrypt it - if there was no server password - ask for it and then encrypt That solution required too many moving parts added to maven, and I decided to split it into two parts: - password maintenance - transparent password decryption Normally - password change is a one-time operation and having code that keeps track of that in the core does not make too much sense to me. Especially if I make password maintenance nice and easy - I have a plugin in the works.

Sonatype Blog : New Feature: Maven Settings Password Encryption

Tue, 3 Feb 2009 19:29:34 +0000

In the latest trunk - settings-security.xml's root tag is renamed to <settingsSecurity>

Sonatype Blog : New Feature: Maven Settings Password Encryption

Tue, 3 Feb 2009 17:07:34 +0000

Nothing, I tried to make it clear in the posting - the default solution addresses only local box use cases, and maybe - not all of them - please see the Confluence discussion I mentioned at the beginning. Even the local encryption can be called "strong" only if one uses the relocation feature and maintains a good master password. But what's there is just a tip of the iceberg, I really implemented a framework, that will allow us to enhance this feature a way beyond the current solution. This is a necessary baby step, what happens to address some of the most urgent use cases. And it leads towards more mature solutions. I will discuss those in the future postings on the subject.

Sonatype Blog : New Feature: Maven Settings Password Encryption

Tue, 3 Feb 2009 16:47:30 +0000

Brian - I briefly mentioned it in the JIRA, but not in this post, my bad. Yes - I already have the plugin that eliminates the need for CLI. This CLI is just a temporary ugly tool to close the loop, it enables us use it right away. The plugin addresses the use cases you mentioned, so you are right on the money!

Sonatype Blog : Mercury Ant tasks - HowTo

Fri, 19 Dec 2008 18:20:18 +0000

You can also have a look at this posting

Sonatype Blog : Mercury Ant tasks - HowTo

Fri, 19 Dec 2008 17:30:09 +0000

Mercury is the green field implementation of dependency management and repository access components. Implemented as a library to be used by Maven as well as any other application that would need that functionality. All my old Mercury blog posts seem to have been misplaced, I will restore them. In the meantime you can look at http://docs.codehaus.org/display/MAVEN/Mercury So mercury-ant-tasks is a POC for this library usage and I am working on adding the "old" maven-ant-tasks syntax to them.

Sonatype Blog : Dependency Resolution as a Diagram

Fri, 12 Dec 2008 02:38:56 +0000

some. I do intercept contradictions while building the tree and am working on incorporating explanation function into SAT itself. It will still require interpretation on Mercury side, so I am debating whether explanation belongs to SAT or client. SAT is too formal, so might have to do it in Mercury.