In my parent pom xml file I have declared some dependencies that are used in most of the children's poms.
However, in one child pom, I don't use these dependencies and I want to find a way in order to exclude them (in order not to be seen as unused dependencies).
Right now, in de dependencies section of child pom I have nothing! Any ideas?
AFAIK there is no way to exclude them.
You can, though, define exceptions in the maven dependency plugin so that they do not appear as "unused". For that, see
http://maven.apache.org/plugins/maven-dependency-plugin/analyze-mojo.html
Related
Is there any reason to use the dependency management section in a child pom? I'm looking at a maven project in my organization that uses inheritance and aggregation, where the parent and child poms both have a dependency management section. Is the child one doing anything?
I found this question really helpful but didn't find the answer to my specific question - Differences between dependencyManagement and dependencies in Maven
It can be used to control the version of transitive dependencies (libraries that your direct dependencies depend on) without adding a direct dependency.
Child POM will add or override dependency management entries of the parent POM.
Keep in mind that you really, really don't want to have different versions of the same dependency in your codebase. So use this feature judiciously. Preferably you should have organization-wide parent POM file with all dependency versions defined and child POMs don't change them.
In a child pom it does not make sense.
In a multi module setup you should control everything for all children in the parent. For example solve version conflicts / excluding transitive dependencies or import BOM files from other frameworks/libraries (for example spring boot/junit 5/etc.) makes handling of those libs including the centralised maintenance location...
I refer to this post as I googled and still have some questions regarding the differences between using the <dependencies> XML tag in the pom.xml vs <dependencyManagement> XML tag in a multi-module Maven project:
https://stackoverflow.com/questions/2619598/differences-between-dependencymanagement-and-dependencies-in-maven#:~:text=Dependency%20Management%20allows%20to%20consolidate,that%20inherits%20a%20common%20parent.
This is a draw.io of the structure of my project - its just a Spring boot/Maven project with a root pom.xml (Parent) and three child modules each with their own POM inheriting from parent POM:
Per that ^ post, it seems that the <dependencyManagement> tag can be used in multi-module Maven projects to centralize the version, scope etc.. of a dependency. The user stated that you still have to re-declare any dependency in the <dependencyManagement> enclosing tag AGAIN in the child module... is this true? if so, why not just use the regular enclosing tag in the parent POM, because then all the child modules will inherit this dependency? I tested this myself with the Spring Boot Starter Parent, and I can see by declaring it in the parent POM of my root project, all the dependencies like spring-core, tomcat-embed-core, etc.. are "injected" into my project and all 3 child modules can use these dependencies
I guess I don't clearly understand the advantage to using <dependencyManagement>tag over regular <dependencies>. And If I understand the Maven POM inheritance correctly, all the Spring Boot Starter dependencies which are declared in the <parent> XML tag in my root POM.xml, are injected into my project and can be used by any child module (which is good and what I want). Also, any dependency declared in my root POM.xml with a <dependency> tag (not inside <dependencyManagement> tag) will be inherited by all child modules, and if I don't want this behavior, I can simply define the dependency in the specific child module that uses that dependency (to avoid repetition).
You can define usual dependencies in the parent, and they are inherited by all children (as you said). If this is the behaviour that you want, then this is fine.
But if you need the dependency only in some of the modules, but you want to make sure that the version is consistent throughout your project, then you can define the version in the dependencyManagement of the parent POM and then add dependency entries (without version) in the modules where you need them.
Looking at the Maven Dependencies with respect to Multiple Parent Ids. If such is the structure of Parent-ids. Note below mentioned all are Maven Projects and each contains its own pom.xml.
Parent-1
Project_1
Project_11
Parent-2
Project_2
Project_22
Scenario 1:
Let us say Project_2 is dependent on Project_1 and Project_11....Then which of the following is true?
1. Add both the dependencies in Parent-2 pom.xml and expect Project_2 to discover sources of Project_1 ? Logic being that Parent-2 is anyways the parent of Project_2 and therefore building Parent-2 would enable all its child to discover the dependencies.
2. Dependency of the Project_2 has to be done at its own level..which means Project_2 pom.xml has to include both Project_1 and Project_11 .
Is there any other way to manage the dependencies?
You can add a dependency to Parent-2, but then it becomes a dependency of both Project_2 and Project_22. This is probably not what you want. So it it would be better to add the dependencies at the level of Project_2.
My project stores its dependencies in a Maven repository. I would like to be able to move certain dependencies to another Maven repository. The move is the easy part. But it's what to move that is difficult for me to get right.
In order for build tools such as Maven or Gradle to be able to use the moved dependency in a build, I need to also transfer (1) transitive dependencies (recursively) and (2) the project's parent POM file, performing (1) again on the parent until all nodes in the dependency graph are exhausted.
This seems like a very common usecase and I'm hedging my bets on the fact it has been implemented many times over.
Question: Are there common libraries that implement this functionality out-of-the-box?
If not, I'll probably have to implement a custom POM parser. Are my assumptions above about what needs to move correct?
The copy-dependencies goal of the maven-dependency-plugin may help you on this task:
Goal that copies the project dependencies from the repository to a defined location.
It also provides an option, addParentPoms to also copy the parent poms required by the build (hence, the whole hierarchy). This option is not enabled by default though.
Moreover, via the different include/exclude options (by group Id, by artifact Id and so on) you may filter what you actually need to move.
Via its excludeTransitive option you may also check whether transitive dependencies are required or not: by default is set to false, hence transitive dependencies will be copied too.
Via its outputDirectory option you can specify where to copy dependencies, transitive dependencies and hierarchy of pom files, according to any specified filter.
You may also be interested in the combination of the purge-local-repository goal of the maven-dependency-plugin, to delete from your local repository whatever required by the project (including transitive dependencies, hierarchy of pom, plugin dependencies) and the go-offline goal to prepare the project for off-line mode, that is, to resolve (download) whatever required. Again, both goals provide include/exclude mechanisms and transitive dependencies management so that you may refine your strategy and outcome.
mvn dependency:list will give you list of all dependencies of your project, including transitive dependencies and dependencies specified in your parent pom.
I have Maven project with multiple submodules. One of these submodules, let's say submodule X depends on all other submodules, as it is Maven Plugin that integrates everything else.
Now I want to use this Maven Plugin during verify stage in my parent POM to do real run of it over entire project (kind of eating own dogfood).
Unfortunatelly I'm getting error:
The projects in the reactor contain a cyclic reference
So how can I make such dogfood integration test for a Maven Plugin submodule?
I would review aggregation and inheritance: they are indeed two different concepts in Maven often used in combination but which can however be used in a complete separated manner as well.
In this case, your plugin submodule is certainly defined as a module in the aggregator pom (that is, it is a submodule). But I also presume the plugin submodule also has as parent pom the aggregator pom as well (that is, the aggregator pom is also the parent pom, which is a normal approach, but not always required).
Is the latter required? You could keep on having the multi-module/aggregator approach without necessarely having the aggregator as parent of the plugin submodule. As such, the plugin subModule would still be a module of the aggregator pom but it would not have as a parent the aggregator pom, decoupling it from it and as such breaking the cyclic dependencies.
Possible drawback: in the aggregator pom you were also defining common things (dependencies management, properties) required also in the plugin submodule. If the case, you would then need to duplicate/review these common settings only for the concerned submodule.
Small suggestion from my side. Cyclic means you have some transitive dependency in your modules. Can please check the dependency tree of your modules and resolve the circular dependency first.