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.
Related
I have ended up in a situation where I need to create a Maven Plugin which as part of it's job needs to inspect a number of dependencies and find certain xml files.
(If anyone has a better way of reading files inside an artifact jar, please say so as that will very much also be considered an accepted answer)
I need to inspect a number of known dependencies that I have referenced as org.apache.maven.artifact.Artifact references and find all XML files within them. The only way I know of is to unpack the artifact and search though the file system. I basically need to do exactly what the Maven Dependency Plugin's "unpack" goal does. So how do I use the Maven Dependency Plugin from my own plugin? Do I simply use it as a normal Dependency or is there a more "maven" way of doing it?
EDIT:
I encountered another thing which is close enough to this one that I will update the question instead of posting a new one.
If I need to use an outside dependency, such as Jackson for example, how do I include the dependency for the plugin? It feels wrong to create a fat jar with the dependencies in it. Is there another trick I am missing?
Preface: I've taken over a historically grown multi-module maven project. Now it's time to clean up the dependency versions. Since using version ranges has its problems (first of all, they don't work according to specs; second, they remove the reproducability of a build), I'm moving to introduce the versions-maven-plugin (v2.7).
Currently, I'm trying to get it to update the versions of dependency artifacts using the goal versions:use-latest-releases. It works for the most part, but it keeps finding beta versions to update to -- I'm surprised that they apparently count as "release". I managed to configure the plugin in the super parent pom (a pom.xml in a pom-packaged artifact appropriately named super), which all modules and submodules refer to as parent (sometimes indirectly). I found the option to refer to an xml file containing rules to ignore specific versions or version patterns -- sadly, I cannot put the rules directly into the super parent pom (or I haven't found the option yet).
So here's the question I ended up with: How do I reference a file (according to the docs: "using a wagon URI or classpath URI") that sits next to the pom.xml of the super parent artifact which is packaged in pom format to be installed in Nexus? According to my research, this is not possible.
So let me put it broader: How do I centrally configure the versions-maven-plugin across a multi-module maven project tree to ignore all versions matching the regex .*-b.*?
Ideally, I would not even have to import the super project into my workspace nor have that file laying around on a webserver (I want it associated with the super project, not flying around somewhere).
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've extended an abstract class and implemented a method that I will use with Mule over and over. I want to add it to a library that I will repo on Maven central. It depends on a JAR that's provided in the Mule connector devkit (sdk for Mule connectors). How do I formally publish or tell others publicly that my common library will not work without the earlier dependency too? The dependencies org.json and fasterXML...Jackson..etc.
My code module is an HttpProcessMessage and the over-used method returns a String of formatted JSON. The message POJO gets loaded and then ultimately my method is like a toString() method but more sophisticated.
I would like for this class to be part of a common library that would become part of the community. I wish that my code here would be the foundation and have no dependencies. Now, I'm looking for an answer to address the dependencies and inform the public.
That's one of the main benefits of Maven and other dependency management tools, when your dependency is added to their Maven project, Maven will automatically fetch transitive dependencies. So there is no need to let people know what dependencies you rely on. It will automatically be handled and they can use Maven command if they wish or inspect the maven artefact to determine what transitive dependencies you rely on.
You will need to add the com.faster.xml dependencies and org.json dependencies to your Maven pom.xml and all this information is packaged alongside your Maven artefact and will be stored in a Maven repo.
More info on Maven dependencies here: https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
If they are manually installing the jar outside of Maven/Gradle etc. then theres not much you can do except provide them a detailed README on installation instructions.
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