Skip to content

Profile based multimodule project fails to update correctly #344

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
KKrzysieq opened this issue Apr 15, 2019 · 2 comments
Closed

Profile based multimodule project fails to update correctly #344

KKrzysieq opened this issue Apr 15, 2019 · 2 comments
Labels

Comments

@KKrzysieq
Copy link

Given this project structure:
-> parent-project
| --> a-sub-project
| --> b-sub-project

each sub-project has the below pom:

<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.demo</groupId>
        <artifactId>parent-project</artifactId>
        <version>1.0-SNAPSHOT</version>
    </parent>
    <artifactId>sub-project</artifactId>
</project>

On the other hand the parent project has this pom:

    <artifactId>parent-project</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>pom</packaging>

    <profiles>
        <profile>
            <id>a-sub-project</id>
            <activation>
                <activeByDefault>false</activeByDefault>
                <property>
                    <name>subproject</name>
                    <value>a</value>
                </property>
            </activation>
            <modules>
                <module>a-sub-project</module>
            </modules>
        </profile>
        <profile>
            <id>b-sub-project</id>
            <activation>
                <activeByDefault>false</activeByDefault>
                <property>
                    <name>subproject</name>
                    <value>b</value>
                </property>
            </activation>
            <modules>
                <module>b-sub-project</module>
            </modules>
        </profile>
    </profiles>

When I specify on command line that I want to update the version for the parent and b-sub-project, I would call this:

mvn -Dsubproject=b versions:set -DnewVersion=1.1-SNAPSHOT

The result is that I get two poms' versions updated, but not the correct ones - it updates the parent, as expected, but also a-sub-project instead of b-sub-project. Interestingly, running this:

mvn -Dsubproject=b versions:revert

assuming I would've manually or otherwise made the b-sub-project also change version to 1.1-SNAPSHOT and have a pom.xml.versionsBackup file to revert to, the revert operation impacts the correct files - b-sub-project and parent. It looks like versions:set goal will go through subdirectories alphabetically without regard to what's actually supposed to happen.

@github-actions
Copy link

This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 30 days.

@github-actions github-actions bot added the Stale label Sep 29, 2022
@andrzejj0
Copy link
Contributor

The result is that I get two poms' versions updated, but not the correct ones - it updates the parent, as expected, but also a-sub-project instead of b-sub-project. Interestingly, running this:

The report is invalid. Both submodules are affected by the set target. The reason is that the target isn't using Maven to process dependencies and is thus ignoring active profile information. Revert is now actually reverting this behaviour instead of relying on Maven to process submodules, resulting in all affected files being reverted.

@slachiewicz please close.

@slachiewicz slachiewicz closed this as not planned Won't fix, can't repro, duplicate, stale Oct 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants