Lets say my project has multiple sub-modules and the structure is something like this:
Parent
- Submodule-A
- Submodlue-B
- Submodule-C
Now both parent and child poms have the same maven property defined in their pom.xml
<properties>
<custom.property>some-value</custom.property>
</properties>
If I run the below command, this would override the value for both parent and its child module
mvn <phase|goals> -Dcustom.property=some-other-value
But How do I override this property only for a specific sub-module's pom?
Related
Let's say I have multiple projects:
- - project1
- - project2
...
- pom.xml
With parent pom being defined as:
<packaging>pom</packaging>
<modules>
<module>project1</module>
<module>project2</module>
...
</modules>
I have the same configuration for actuator in all of the application.ymls of the these projects. Is there any way to somehow take out this common configuration maybe in a new project and then use it as dependency or something like that, so it will be in the one place and not replicated in all of the projects?
I tried creating a new project, placed common configuration in application.yml in the resources and then added this new project as dependency to the parent pom, but it seems like it didn't work out because /actuator/health is showing less info (only status: up) than it was showing when this configuration was in the every project's application.yml file (show-details is activated, actuator dependency is in the pom file), so I assume it doesn't work that way, so how do I do that?
I have two modules, A and B, they are under the same parent. Now A is requiring for B as dependency. I can't just use jar as dependency type because module B is using spring-boot-maven-plugin, so I was wondering how can I set A's pom configuration to make A depend on B's compiled classes not jar?
- root
- A
- src # module A's source code
- target
- classes # module A's compiled classes
- A.jar # module A's compiled jar output
- pom.xml # module A's mvn config
- B
- src # module B's source code
- target
- classes # module B's compiled classes, HOW CAN I IMPORT THESE TO A?
- B.jar # module B's mvn config
- pom.xml # module B's mvn config
- pom.xml # parent mvn config
parent mvn config
...
<modules>
<module>A</module>
<module>B</module>
</modules>
...
module A mvn config
...
<parent>
<!- pointed to parent ->
</parent>
<dependencies>
<dependency>
<groupId></groupId>
<artifactId>B</artifactId>
<scope>??????????????</scope> # WHAT SHOULD I PUT HERE?
<type>???????????????</type> # WHAT SHOULD I PUT HERE?
</dependency>
<dependencies>
...
First of all: When A depends on the classes of some other module, it necessarily depends on the jar. You cannot depend on parts of a module or just the classes.
So let me sketch a solution:
If B is of <packaging>jar</packaging> (standard, also true if no packaging is given), then you can just use it as dependency. You do not need a scope or type entry.
If B is of some other packaging (including spring-defined packaging types, which I am no expert of), then you should not define a dependency from A on B. Instead, you define a third module C, which includes the classes that are used from A and from B and let both of them have a dependency on C.
Don't try to construct dependencies to non-jars. If you need classes, define a module with these classes and use it when the classes are needed.
Here is good information about maven dependency scope and type.
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
This should work fine for you. (Not tested)
<scope>compile</scope>
<type>jar</type>
I have the below project structure
Main Project
--Sub Project 1
- child 1
* pom-child1
- child 2
* pom-child2
* pom-sub-project1
--Sub Project 2
* pom-sub-project2
* main project pom
I had defined few project dependencies in main project pom and referred it in child and sub project poms. But I am finding issues if the pom is not a direct child of the main project pom. Is there a way to resolve it?
Example,
Main Project pom
<packaging>pom</packaging>
<version>dev</version>
<name>parent-project</name>
..
<properties><spring-version>3.1.0.RELEASE</spring-version></properties>
child POM
<parent>
<groupId>com.test.pkg</groupId>
<artifactId>test-proj</artifactId>
<version>${project.version}</version>
</parent>
The ${project.version} isn't resolved if it is not a direct child of a parent pom due to which none of the project dependencies are resolved.
Also, I read about properties-maven-plugin which is used to read properties from external properties file. Can this be used for reading dependency version or is there any other plugin/approach that could be used in this case?
You cannot use
${project.version}
to define your parents version, because the child by default inherits the parents version.
Set the parents version with the valid value and not with a property.
If you do so, it should work and you do not have to specify the childs version, as it will be inherited from the parent.
If, in my maven project's parent pom.xml, it has some property like this:
<properties>
<argLine>some args</argLine>
</properties>
Is it possible in the child to somehow just "augment" that, like
<properties>
<argLine>${parent.argLine} some more args</argLine>
</properties>
Similarly for say, plugin settings, wish I could do something like
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<argLine>${parent.plugin.maven-surefire-plugin.argLine} -Xmx1G</argLine>
</configuration>
I am basically just adding to some setting specified in the parent?
The impetus for this question is I'm wondering how to use the jacoco plugin, and, in the root pom specify some general settings "-Xmx1G" while in the children they can add other child specific parameters to that general one, where necessary. ref: https://stackoverflow.com/a/29975159/32453
I suppose I could just rename the parameter jacoco generates (https://stackoverflow.com/a/25571295/32453 "propertyName" setting, to change it from argLine) and then I could use the parent's ${argLine} and add it to the jacococ one, but my question is still interesting...
Property should be directly to visible in your child's pom: ${argLine}
Use pluginMagement in your parent pom and specify there configs. They will be common for all modules in the parent.
With Maven 3 you can use ${project.parent.propertyName} link
The only way I could think of to do this would be to duplicate the parameter in the parent.
so parent:
<properties>
<argLine>some args</argLine>
<parentArgLine>some args</parentArgLine>
</properties>
Then use
<properties>
<argLine>${parentArgLine} some child args</argLine>
in child.
The problem in my particular case is that a plugin "overrides" a maven variable.
I am working on a maven based project. I have a parent pom file for the parent module and a child pom file for the child module. In parent module I am using a custom property (databaseType) and it is declared in parent pom.
<properties>
<databaseType>${databaseType}</databaseType>
</properties>
While building the application, I am passing it as -D argument and its building successfully. However, when I am creating a maven project in eclipse, I am getting below error in child pom (Though the maven build is happening fine)
Project build error: Resolving expression: '${databaseType}': Detected
the following recursive expression cycle in 'databaseType': [databaseType]
What could be the issue? Any help is appreciated.
The problem is that both the argument you pass with -D and the property have the same name. If you provide the argument, it works because when maven resolves the expression it first finds the provided argument by -D databaseType and then assigns that value to the <databaseType> property. If the argument is missing, maven tries to resolve the expression but only finds the definition of the <databaseType> property in the same pom, which creates a circle.
Maven and Eclipse are either using different approaches to resolve variables here (which might a bug in eclipse) or it's caused by some misconfiguration. I would guess that passing the variable with -D is not working in Eclipse for some reason.
The example doesn't really do anything anyways. If ${databaseType} is available, you shouldn't need to explicitly define the property again. Or use a different property name in the parent pom if it makes sense, like this:
<properties>
<databaseType>${defaultDatabaseType}</databaseType>
</properties>
This doesn't help if the argument is missing though. I would use the enforcer plugin to make sure it the property is defined.