Make com.here.platform sdk version in pom.xml generic - maven

How can I mention the version in pom.xml generic ? . Can I make it to download the latest version of dependency automatically ?
<dependency>
<groupId>com.here.platform</groupId>
<artifactId>sdk-bom</artifactId>
<version>1.5.55</version>
<type>pom</type>
<scope>import</scope>
</dependency>

I'm not quite sure what you mean here, if you want to have multiple declarations of this dependency within a single project use dependencyManagement at the projects top level pom. If you simply want to use a variable define a property like so:
<properties>
<com.here.platform.version>1.5.55</com.here.platform.version>
</properties>
and then:
<dependency>
<groupId>com.here.platform</groupId>
<artifactId>sdk-bom</artifactId>
<version>${com.here.platform.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Please add more details so we know what you are asking.

Related

How can I use (refer) transitive dependency's version?

I'm facing a situation that I need to specify one of transitive dependency's version.
With following dependency tree,
A <- B <- C
I need to specify A's version in C's pom.xml
Is there any way to do this? So that I can filter some file like this?
A's version is #{...a.version}
If you want to specify the version of a (possible) transitive dependency, put the dependency into the dependencyManagement section of your POM. Then it is used if the dependency occurs transitively (and silently ignored if no such transitive dependency is found).
It is not possible to directly reference the version of some arbitrary dependency (transient or not).
However, in your parent pom you can define a property:
<properties>
...
<yourCdep.version>
...
</properties>
and add the dependency in to a dependencyManagement section:
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>yourCdep.group</groupId>
<artifactId>yourCdep</artifactId>
<version>${yourCdep.version}</version>
</dependency>
...
</dependencies>
</dependencyManagement>
Remove the version from the dependency in module B as it is now "managed".
The property value in the parent pom will be accessible in both modules A and B.
In particular, this property value can now be applied when resource filtering.
Use <optional>true</optional>:
C -> B -> A
pom(B) :
<dependencies>
<dependency>
<groupId></groupId>
<artifactId>A</artifactId>
<version></version>
<optional>true</optional>
</dependency>
...
</dependencies>
pom(C):
<dependencies>
<dependency>
<groupId></groupId>
<artifactId>B</artifactId>
<version></version>
</dependency>
<dependency>
<groupId></groupId>
<artifactId>A</artifactId>
<version></version>
</dependency>
...
</dependencies>

Dependencies vs DependenciesManagement?

I have gone through differences between dependencymanagement and dependencies in maven but i am still unclear when to use
just dependencies tag in parent pom and when to use dependenciesManagement tag ?
My understanding is when my all child modules need to use same dependency version then we should declare the Dependencies under Dependencies tag(without dependencyManagement tag)
But on other hand if some of the child project need to use different version then we should declare the Dependencies under Dependencies tag(which will be under dependencyManagement tag). then Child modules can refer them with overridden version
Is that correct ?
Declaring a <dependency> within <dependencyManagement> does not set the specified artifact as dependency for any project – parent or childs. It just states: If you want to use this as dependency then you can use it with these settings (version, scope, ...) without having to specify the settings again, and again, and ... You can, however, override a "management" setting in a "real" <dependency> anytime.
See also POM Reference, Dependency Management.
There are two options for a parent POM regarding your second paragraph:
As you describe correctly:
<dependencies>
<dependency>
<groupId>g-id</groupId>
<artifactId>a-id</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
I'd use this for consistency:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>g-id</groupId>
<artifactId>a-id</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>g-id</groupId>
<artifactId>a-id</artifactId>
</dependency>
</dependencies>
Your third paragraph is correct..

Maven issue when overriding an environment specific systemPath property

I experienced issues with a maven build that does not behave the same way if done on Windows (like they were done in the past) or Linux (like I want to do them now).
I want to build a project that has a dependency on another project that pom that itself imports a pom that contains a Windows path.
my project | other project
|
mybuild -------|------> pom --------> pom with systemPath
dependency import
|
But in a nutshell, here is my pom:
<groupId>test.properties</groupId>
<artifactId>buildme</artifactId>
<version>1.0-SNAPSHOT</version>
...
<dependencies>
<dependency>
<groupId>test.properties.installme</groupId>
<artifactId>module</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
</dependency>
</dependencies>
And I depend on a pom that looks like this (not under my control)
<groupId>test.properties.installme</groupId>
<artifactId>module</artifactId>
<version>1.0-SNAPSHOT</version>
...
<dependencyManagement>
<dependencies>
<dependency>
<groupId>test.properties.installme</groupId>
<artifactId>dependency</artifactId>
<version>1.0-SNAPSHOT</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
</dependencies>
and the problem lies in this last pom (not under my control):
<modelVersion>4.0.0</modelVersion>
<groupId>test.properties.installme</groupId>
<artifactId>dependency</artifactId>
<version>1.0-SNAPSHOT</version>
...
<properties>
<com.sun.tools.path>D:/java/jdk1.8.0_65/lib/tools.jar</com.sun.tools.path>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.8</version>
<scope>system</scope>
<systemPath>${com.sun.tools.path}</systemPath>
</dependency>
</dependencies>
</dependencyManagement>
I have no control on the other project in question. I totally agree that a refactoring to use environment variable in place of the hard coded paths would solve my problem.
But instead the Windows path is defined in a property. One would think that overriding the value of the property depending on my platform would be enough. But it is not.
Unfortunately in this precise case case maven seems to behave to behave poorly.
Before applying any property override in any form (in settings.xml, -Dproperty=, redefinition in root pom), maven starts building the effective pom. And during that step, if it finds the pattern I mentioned above (a dependency on another pom that itself imports a pom that contains a Windows path), then it says:
The POM for <groupId>:<artifactId>:jar:<version> is invalid, transitive dependencies (if any) will not be available
As a consequence, my project needs to explicitly define all the dependencies of the second project. And I cannot rely on transitive dependencies which gives me a lot of trouble.
In order to illustrate the issue, I created a minimal example showing the problem. It can be found here:
https://github.com/fabricepipart/test-properties
Do you see any workaround for this?
Any way to override the value of the property and still benefit from the maven transitive dependencies?
Thanks a lot

Maven: Package "brother" projects

I am working on a big set of projects strongly related to each other and looking for a way to reduce to minimimun the maintenance overhead using a good maven configuration.
One of the scenarios which I am currently working on is a set of several small projects inside the same "company project", most of them depending on the others, with a big list of external dependencies in each one.
In order to make it cleaner I created a parent pom, set all of them as modules and created a big list of dependencies inside the parent's dependencyManagement section allowing me to remove most of the version tags inside the project poms.
The next stage for me is to reduce the amount of resulting jars by making use of some plugin, such as one-jar or assembly, in oder to get a signle jar from one of those projects containing all the others inside. However, this led me to having an enourmous jar with tons of external libraries inside, most of them already provided by the running environment.
I know that adding the <scope>provided</scope> tag to the declaration of external dependencies would do the job, but I would like to avoid having dozens of these tags in my poms.
So the questions are:
Is there any way to define a default scope, so I can use compile scope only in the libs which I want included?
Then, instead of having this:
<dependencyManagement>
<dependency>
<groupId>any.external</groupId>
<artifactId>lib</artifactId>
<version>1.0</version>
<scope>provided</scope> <!--Skip Inclusion-->
</dependency>
<dependency>
<groupId>any.external</groupId>
<artifactId>cool-lib</artifactId>
<version>1.0</version>
<scope>provided</scope> <!--Skip Inclusion-->
</dependency>
<dependency>
<groupId>another.external</groupId>
<artifactId>lib</artifactId>
<version>1.0</version>
<scope>provided</scope> <!--Skip Inclusion-->
</dependency>
<dependency>
<groupId>my.company</groupId>
<artifactId>some-dependency</artifactId>
<version>1.0</version>
</dependency>
</dependencyManagement>
I could have this (note that the difference will come when we have only 10 internal projects to include, but more than 100 external libs):
<dependencyManagement>
<dependency>
<groupId>any.external</groupId>
<artifactId>lib</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>any.external</groupId>
<artifactId>cool-lib</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>another.external</groupId>
<artifactId>lib</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>my.company</groupId>
<artifactId>some-dependency</artifactId>
<version>1.0</version>
<scope>compile</scope><!-- Include It! -->
</dependency>
</dependencyManagement>
Or better: Maybe I'm skipping something and there is already a way to tell maven: "Include only the jars generated within the current project"?
Remember that all modules are "brothers", included as modules of the same parent, and compiled at the same time.
Many thanks in advance!
Carles

How to make maven versions:use-latest-versions step up import scoped entry in dependencyManagement?

We use the maven versions plugin to keep our versions up to date by regularly mvn versions:use-latest-versions. In our poms we have an import scoped dependency to another POM that looks like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>se.company.maven</groupId>
<artifactId>maven-third-party-dependencies</artifactId>
<version>0.0.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
When we run mvn versions:use-latest-versions all our dependencies (and other entries in dependencyManagement) get stepped up except this one. Is there a way to get the versions plugin to step up this kind of entry?
It does work when you put the version of the import-scoped dependency in a property, and use the versions:update-properties goal.
Your example pom would then look like this:
<properties>
<my.dependency.version>0.0.1</my.dependency.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>se.company.maven</groupId>
<artifactId>maven-third-party-dependencies</artifactId>
<version>${my.dependency.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Could you be hitting one of the problems mentioned in the FAQ?
To rephrase it here, is the artifact which is not getting stepped a local artifact, which is not deployed to a repository manager? If so, you can resolve this by setting up a repository manager.

Resources