Handling properties in Maven POM

Old Forum Archive
1

Hello, I have POMs like the following in a repository where the version is defined to be a property (${library-core}).

<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>
    <parent>
    <groupId>com.company</groupId>
    <artifactId>master-project</artifactId>
    <version>1.0.Final</version>
    </parent>
    <groupId>com.company</groupId>
    <artifactId>library-core</artifactId>
    <packaging>jar</packaging>
    <version>${library-core}</version>
    <name>library-core</name>
    <description>Library</description>
    ...............................................
    <profiles>
    <profile>
    <id>1.0</id>
    <activation>
    <activeByDefault>true</activeByDefault>
    </activation>
    <properties>
    <library-core>1.1.0</library-core>
    </properties>
    </profile>
    </profiles>

When a gradle build depends on this artifact, I get an exception like the following:

java.text.ParseException: inconsistent module descriptor file found in ‘org.gradle.api.internal.externalresource.transfer.ProgressLoggingExternalResourceAccessor$ProgressLoggingExternalResource@76eb235’: bad revision: expected=‘1.1.0’ found=’${library-core}’;

Is there any way to resolve such dependencies?

2

To my knowledge, it is strongly discouraged to have placeholders in published POMs. And I don’t think that Gradle can resolve them.

3

Thanks for the quick response. Can you please share why they are discouraged (for my understanding) ? It seems like the Maven profiles allows a default active profile which resolves this property. It also seems to be related to the way the ivy handler handles this dependency (https://issues.apache.org/jira/browse/IVY-933).

Is it possible to implement a custom dependency handler to resolve this issue?

4

Properties should be resolved before the POM is published. Otherwise, results may differ depending on who consumes the POM. Even Maven behaves differently here depending on which Maven version is used. (Maybe not in this simple case, but in general.)

You can try to set a system property with the same name. As far as I know, Gradle used to resolve them. Otherwise, this will probably require a patch. If it’s easy enough to do, it would be OK to support at least the default profile.

5

I work with Kiran and I’m the one having this problem

I understand your point and I think I’ll have to rewrite all the POM files we deployed to Nexus so as to make them less dynamic and solve this issue however this is a big piece of work. We have currently 1800+ POM files having such dynamic properties and this will take a lot of time to fix this.

I had a look to the Gradle source code and my understanding is Gradle uses Ivy for dependency management. Ivy can disable the check causing this build failure. One needs to set the “checkconsistency” property to false in class org.apache.ivy.plugins.resolver.BasicResolver. Is there a way to set this Ivy’s property from my Gradle build file ? I tried the syntax given here (http://comments.gmane.org/gmane.comp.programming.tools.gradle.user/1741) but this didn’t work.

This workaround would give me some time to fix the POM files.

Thanks

6

If the variable isn’t resolved, dependency resolution will fail. Also, Gradle isn’t using Ivy under the hood anymore.

I see two solutions: Rewrite your POMs (with an automated script), or enhance Gradle’s dependency management to support profiles (in a limited way).

7

OK, makes sense. I’ll go with the first solution then.

Thanks