We are in the process of checking whether our projects can be migrated from ant-maven build system to gradle-maven build system. Unfortunately, we have to live with our maven pom’s for sometime before we decide to move fully to gradle because of the scope of the changes. In the meantime, I came across an issue where I need to pass properties to our pom’s for some of our dependencies.
Is there a way I can pass some properties like how i can pass a system property “mvn install -DsomeProperty=someValue”?
I’m trying to understand in which jvm the dependency resolution happens. Does it happen in a test jvm or gradle jvm? I have tried defining systemProperty “someProperty”, “someValue” and System.setProperty("someProperty,“someValue”) as possible solutions. Both didn’t work.
I’m a newbie here so any input will be greatly appreciated.
@bmuschko Are there any plans to do this in future or an alternative solution to this? I need to find a way to make the pom’s get some property arguments when they are resolved.
My personal take on supporting the use of system properties in POMs is that it makes resolving dependencies extremely environment-specific and therefore brittle. A user usually does not know what system properties are evaluated and what values can be passed in without have a look at the POM of each dependency and their transitive dependencies. The end result would be a build that’s not reproducible. I don’t think we’ll support that feature in Gradle.
I understand your view point but right now there is no solution to people who want to migrate to gradle when they have no control to play with their dependency pom’s. I have similar issue with maven profiles. Even though there two approaches provided, if most of your transitive dependency pom’s have maven profiles (most of them third party dependencies), then it’s impossible to change each and everyone of them you need. Probably by allowing to pass system properties during dependency resolution, we can have some sort of control.
You can find more information on how we think about this topic in the blog post “Gradle’s Support for Maven POM Profiles”. I have been working with a lot of organizations that consume external Maven libraries. I’d assume that some of these libraries define profiles in the metadata. However, we never actually ran into issues when resolving those dependencies in migration scenarios. You simply might have to do some extra leg work e.g. manually define a transitive dependency when defined by a profile.
Generally speaking, Gradle’s dependency management abstracts the underlying repository your are resolving from. If we can, we’d like to avoid exposing specific configuration options only available to certain repository types.
@bmuschko When you say that you never ran across this scenario during migration, I’m a little confused.
To give an example, we use com.sikulix:sikulixapi:1.1.0 dependency, which in turn uses a maven profile to figure out the OS family so it can include the appropriate ${sikulix-libs} dependency. Till Variants get implemented, am I expected to modify these pom’s and publish in my artifactory and use ‘if-else’ to resolve it?
In the context of Java, variants are far less common simply because the same code is supposed to work on different platforms. I’d totally understand your concern about resolving libraries for Scala projects though. Do you bundle native libraries within your JARs depending on the operating system?
Till Variants get implemented, am I expected to modify these pom’s and publish in my artifactory and use ‘if-else’ to resolve it?
For now this your best choice. In the long run, we want to bring support for variant-aware dependency management to the JVM in Gradle.