If you were asking about Mercury - then I did not notice the post.

Can you give me an example - which posting was not answered?

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

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.

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

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

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.

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.

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?

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.

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