iTools packager: copy files at package root

[jeandemanged]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?

No

What kind of change does this PR introduce?

Bugfix & Feature

Rework of #3443.

What is the current behavior?

• Add Third-party licenses #3443 has issue of looking in parent folder, hence copying licences and 3rd party files does not work for example for powsybl-distribution where we encounter:

[INFO] Copy file /home/runner/work/powsybl-distribution/powsybl-distribution/resources/XIIDM/eurostag-tutorial-example1.xml to /home/runner/work/powsybl-distribution/powsybl-distribution/target/powsybl-distribution-2025.2.1/etc
Warning:  License file /home/runner/work/powsybl-distribution/LICENSE.txt not found
Warning:  License file /home/runner/work/powsybl-distribution/THIRD-PARTY.txt not found
[INFO] Zip package

• We use maven-plugin-testing-harness v3.3.0

What is the new behavior (if this is a feature change)?

• Removed hardcodes on "LICENSE.txt" and "THIRD-PARTY.txt". User can configure the itools packager to copy any desired file via plugin configuration, included and not limited to "LICENSE.txt" and "THIRD-PARTY.txt":

                <configuration>
                    <copyToPackageRoot>
                        <files>
                            <file>${project.basedir}/LICENSE.txt</file>
                            <file>${project.basedir}/THIRD-PARTY.txt</file>
                            <file>${project.basedir}/path/to/some/file.txt</file>
                        </files>
                    </copyToPackageRoot>
                </configuration>

• We use maven-plugin-testing-harness v3.4.0 making tests much cleaner and easier with junit-jupiter instead of junit-vintage-engine

Does this PR introduce a breaking change or deprecate an API?

• Yes

If yes, please check if the following requirements are fulfilled

• The Breaking Change or Deprecated label has been added
• The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

If you were using powsybl-itools-packager-maven-plugin and relying on hardcoded behavior for copying "LICENSE.txt" and "THIRD-PARTY.txt" to your generated package, you must now update the plugin configuration to explicitly include the desired files as in the example below (adjust file paths as necessary):

    <build>
        <plugins>
            <plugin>
                <artifactId>powsybl-itools-packager-maven-plugin</artifactId>
                <executions>
                    <!-- snip -->
                </executions>
                <configuration>
                    <!-- snip -->
                    <copyToPackageRoot> <!-- new configuration to be added -->
                        <files>
                            <file>${project.basedir}/LICENSE.txt</file>
                            <file>${project.basedir}/THIRD-PARTY.txt</file>
                        </files>
                    </copyToPackageRoot>
                </configuration>
            </plugin>
        </plugins>
    </build>

Other information:

[rolnico]

I think that the issue here is more that the "child project" (powsybl-distribution in your example) does not have a LICENSE.txt and a THIRD-PARTY.txt. According to some licenses, we should provide those files as soon as we make an executable (for example), that's why I hardcoded the two files during the itools generation.
However:

• adding the possibility to add more files is nice to have
• Fixing the paths of the files is also of course interesting (looking into the parent folder should be done only if the files are not found in the project directory level)

[jeandemanged]

I think that the issue here is more that the "child project" (powsybl-distribution in your example) does not have a LICENSE.txt and a THIRD-PARTY.txt. According to some licenses, we should provide those files as soon as we make an executable (for example), that's why I hardcoded the two files during the itools generation. However:

• adding the possibility to add more files is nice to have
• Fixing the paths of the files is also of course interesting (looking into the parent folder should be done only if the files are not found in the project directory level)

Hi @rolnico

The issue for powsybl-distribution is that current implementation looks in parent folder always, so even if these files were added, they would not be found at all.

The warning in GitLab CI is

Warning:  License file /home/runner/work/powsybl-distribution/LICENSE.txt not found
Warning:  License file /home/runner/work/powsybl-distribution/THIRD-PARTY.txt not found

But what can be added to powsybl-distribution is:
/home/runner/work/powsybl-distribution/powsybl-distribution/LICENSE.txt
not
/home/runner/work/powsybl-distribution/LICENSE.txt

[rolnico]

I think that the issue here is more that the "child project" (powsybl-distribution in your example) does not have a LICENSE.txt and a THIRD-PARTY.txt. According to some licenses, we should provide those files as soon as we make an executable (for example), that's why I hardcoded the two files during the itools generation. However:

• adding the possibility to add more files is nice to have
• Fixing the paths of the files is also of course interesting (looking into the parent folder should be done only if the files are not found in the project directory level)

Hi @rolnico

The issue for powsybl-distribution is that current implementation looks in parent folder always, so even if these files were added, they would not be found at all.

The warning in GitLab CI is

Warning:  License file /home/runner/work/powsybl-distribution/LICENSE.txt not found
Warning:  License file /home/runner/work/powsybl-distribution/THIRD-PARTY.txt not found

But what can be added to powsybl-distribution is: /home/runner/work/powsybl-distribution/powsybl-distribution/LICENSE.txt not /home/runner/work/powsybl-distribution/LICENSE.txt

Exactly, that's why I said that fixing the paths could be interesting.
What I'm wondering is: can we make adding these files a requirement while not providing fixed paths? Maybe having a specific parameter for each and, if it's not specified by the user, looking for the files in the standard directories (project + parent)?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud