IllegalStateException: RedundantDependencyVersionsRule with maven expressions

[lewisd32]

IllegalStateException: RedundantDependencyVersionsRule with maven expressions

[lewisd32]

This should be fixed now, in 0.0.8-SNAPSHOT. (You'll need to build it yourself though, it's not deployed anywhere).
I'll do another release once I'm able to merge in your new rules.

[lkwg82]

I can confirm!

[Stephan202]

It seems this issue isn't fixed completely, at least when using ${project.version} and/or ${project.groupId}:

[INFO] --- lint-maven-plugin:0.0.8:check (validate-pom) @ bulgarian-stemmer ---
 WARN [RedundantDependencyVersionsRule:81] 2013-10-28 08:47:47,500 - java.lang.IllegalStateException: Could not resolve Dependency {groupId=${project.groupId}, artifactId=engine, version=null, type=jar} using path dependencies[groupId='${project.groupId}' and artifactId='engine' and type='jar']
 WARN [RedundantDependencyVersionsRule:81] 2013-10-28 08:47:47,512 - java.lang.IllegalStateException: Could not resolve Dependency {groupId=${project.groupId}, artifactId=engine, version=${project.version}, type=jar} using path dependencyManagement/dependencies[groupId='${project.groupId}' and artifactId='engine' and type='jar']

[lkwg82]

Hi,

can you give a sample pom.xml and the complete call, plz

Cheers Lars

[Stephan202]

Hi Lars,

I tried to find a minimal example. I can reproduce it by running mvn lint:check on the following POM:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>com.lewisd</groupId>
    <artifactId>example</artifactId>
    <version>0.0.8</version>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>${project.groupId}</groupId>
                <artifactId>lint-maven-plugin</artifactId>
                <version>${project.version}</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>lint-maven-plugin</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>${project.groupId}</groupId>
                <artifactId>lint-maven-plugin</artifactId>
                <version>${project.version}</version>
                <executions>
                    <execution>
                        <id>validate-pom</id>
                        <goals>
                            <goal>check</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <rules>
                        <excludes>
                            <exclude>OSS*</exclude>
                        </excludes>
                    </rules>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

[lewisd32]

Yep, it looks like this isn't completely fixed. I may have to find a completely different approach for the bit of code that's causing this, as I'm not sure the current approach can be fixed.

[lkwg82]

I'll have a look into this.

[lewisd32]

Thanks Lars, appreciate it. If you want to discuss any potential solutions, I'd be happy to offer whatever insight I can.

The maven project exposes two models, the "original" model, which maps very closely to the pom.xml, and a resolved model, which has properties replaced (among other things). From what I remember, most rules walk the resolved model, so that they can see the resolved version number, for when the pom.xml has properties in . However, at some point (I don't remember why, at the moment) the plugin has to find the equivalent element in the original element, which is where this is failing.

Maybe the xml file location could be used to more accurately find the original element. Or, maybe it doesn't actually need to find the original element, since I can't remember right now why it was doing that.