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.
Related
I have a huge amount of local jar dependencies for legacy ant project. The names don't follow artifactId-version-classifier.jar pattern. I want to replace such jars with artifacts from central repository if possible.
Is there a way to do it?
That is usually a lot of work.
You can compute the checksums and look them up. You can also look up the name and the version (if you know it).
Furthermore, the project probably only uses a small fraction as direct dependencies. The rest are transitive dependencies. So if you figure out the direct dependencies (from looking at the code) than resolving those would be enough. Maven will find the transitive ones automatically.
We have a multi-module maven project. I have a use case where I want to know to get a list of all the dependencies which is being used in code with version:
If its declared in pom and being used.
Not declared in pom but still being used (transitively imported).
Bonus would be if the approach can exclude the deps which are being declared in pom but not being used in the code.
Please suggest the best way to achieve this. TIA.
Just use the mvn dependency:tree command.
There's the Maven Dependency Plugin:
The dependency plugin provides the capability to manipulate artifacts. It can copy and/or unpack artifacts from local or remote repositories to a specified location.
with its tree goal:
Displays the dependency tree for this project.
Regarding your bonus there's the analyze goal:
analyzes the dependencies of this project and determines which are: used and declared; used and undeclared; unused and declared.
and the analyze-only goal:
is the same as analyze, but is meant to be bound in a pom. It does not fork the build and execute test-compile.
I want to find all available versions of a dependency in my project using a Mojo. I need this information to create a complete dependency tree where not only the transitive dependencies are included, but also all available versions and then their respective dependencies.
The problem is that I can't simply download each individual metadata file since that would make the plugin too slow. What other ways are there to find all other versions through a Mojo and the Maven plugin API, and how do I achieve it?
Example of tree I'm trying to generate.
If I only look at the components specified in the pom, I will miss out on the dependency a1.0 -> c1.1 and b1.0 -> d1.1.
To clarify what information I am missing; the following graph shows what would appear if I where to simply use dependency:tree.
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.
I have a multi-module maven project that uses some dependencies from netflix. The trouble is that those dependencies are built using gradle and use a runtime scope. When I build my project I then have only the direct dependency loaded but not it's own dependencies.
To fix that I added dependencyManagement entries to transform all the runtime scopes to compile scopes. They usually go in pack of 10 to 20 entries so what I want is to be able to make some pom that would only address this issue and be able to load it any time I need a dependency.
I know this can be done as i've read Maven pull dependencies via middle pom file and How to use POMs as a dependency in Maven? but I was wondering how I may carry those poms inside my current multi-module project.
I'd like to have those in my parent module and avoid needing to create one sub-module per pom. Like pom-dep1.xml, pom-dep2.xml... and have those bundled in my build. Is that possible ?
Thanks