* the first occurrence. So when we're in lenient/compat mode, we have to deal with such broken POMs and mimic
         * the way 2.x works. When we're in strict mode, the removal of duplicates just saves other merging steps from
         * aftereffects and bogus error messages.
         */
        List<Dependency> dependencies = model.getDependencies();

import org.apache.maven.api.services.model.ModelVersionParser;

import static org.apache.maven.internal.impl.Utils.nonNull;

/**
 * A wrapper class around a resolver version that works as model version parser as well.
 */
@Named
@Singleton
public class DefaultVersionParser implements VersionParser {
    private final ModelVersionParser modelVersionParser;

    @Inject

import org.apache.maven.api.services.VersionParser;
import org.apache.maven.model.version.ModelVersionParser;

import static org.apache.maven.internal.impl.Utils.nonNull;

/**
 * A wrapper class around a resolver version that works as model version parser as well.
 */
@Named
@Singleton
public class DefaultVersionParser implements VersionParser {
    private final ModelVersionParser modelVersionParser;

    @Inject

 can be offered to be opened together with the current project.
 problems with the current solution are:
 1. information is duplicate. once in POM's dependencies and once in the
 maven.multiproject.includes property.
 2. it works without problems only for projects with relative paths, e.g., from
 one CVS repository.. for projects from multiple SCM repositories it's harder
 to maintain the same relative links on all developer computers.