itools-packager-maven-plugin bundles provided dependencies

[jonenst]

• Do you want to request a feature or report a bug? Arguable..

• What is the current behavior? itools-packager bundles the provided dependencies

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem create a pom project with provided dependencies and configure itools-packager-maven-plugin. For example the powsybl-core/distribution-core has this. The provided dependencies are bundled in the output

• What is the expected behavior? In maven docs: "provided This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime." The provided dependencies should not be bundled.

• What is the motivation / use case for changing the behavior? People expect provided dependencies to not be bundled.

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, spectrum, etc)

(if a question doesn't apply, you can delete it) itools-packager-maven-plugin uses compile+runtime resolution. Why not use runtime resolution ? This should be exactly what we want ? See https://maven.apache.org/developers/mojo-api-specification.html

[geofjamg]

Provided dependencies make sens for instance in an application server where your application run in a container with already provider dependencies. In the itools packaging case, there is no container/running environment. Nothing will be provided and all necessary dependencies have to be copied in the share/java/ folder. I think provided dependencies have to be bundled in itools distribution.

[mathbagu]

I agree with Jon: itools-packager should not package the provided jars. It could be ok for non conflicting jars (only one implementation in the classpath), but it’s not ok for all jars (logging or xml for instance). There is a risk someone forget to add an explicit dependency to pull an implementation and something will be missing at runtime. We should probably log a warning to aware the user?

[geofjamg]

What is missing in the is PR is a description of the real reason of the change request. What is the bug? What is the pain?

[jonenst]

bundling provided dependencies violates the POLA principle https://en.wikipedia.org/wiki/Principle_of_least_astonishment I was very surprised when I found this behavior

[jonenst]

I can confirm the following behaviors:

• Before or after the suggested change (SCOPE_RUNTIME instead of SCOPE_COMPILE_PLUS_RUNTIME) if you add a provided dependency in powsybl-core/commons (ie a transitive dependency of distribution-core), the dependency is not bundled in the package

• After the suggested change, if you remove in distribution-core/pom.xml the provided scope from the handful of artifacts that have it, you get the same package as before the suggested change.

The only consequences of this change is for projects who depend on distribution-core (previously they didn't get the dependencies, after this change they would get them). Is this a supported use case ?

[jonenst]

The people who have added provided dependencies to distribution-core/pom.xml are Author: Luma zamarrenolm@aia.es and Author: baguemat mathieu.bague@rte-france.com