I have two dependencies imported via Maven that both import a common library, but at different versions but the versions are not compatible with each other. Essentially the problem described in this post:
But unfortunately for me, the solution is not as simple as the blog post describes, because there isn't a common version of package Z that works for both dependencies.
Skipping the poor design decisions that led to this point as I don't control any of these libraries, I'm looking to repackage one of the top-level dependencies and shade all of its dependencies so it can essentially use its own, isolated version of Z. Is this possible to accomplish with Maven?
One solution I have considered is isolating all the classes that depend on package Y and putting them in a separate application and shipping that as a shaded jar which X imports, however I'm wondering if there's a simpler way to accomplish that.
As everyone has suggested you can use the maven-shade-plugin. Open source projects handle this by creating one maven sub project for each dependency that needs to be shaded. So in your case you would need 3 maven projects:
One for shading dependency Y
One for shading dependency G
One for your original project. Your original project includes the artifacts created in 1. and 2. as dependencies.
Your maven project hierarchy would look like this:
project
pom.xml
shade-Y
pom.xml
shade-G
pom.xml
application
pom.xml
An example of a project which has a maven sub project for shading a dependency is here. Look at the shaded-ning19 folder to see how to create a dedicated maven project for shading a dependency.
Related
I want to publish a common build script which i will include across various projects in my application.
This will contain only the common set of dependencies, i.e dependencies with particular versions that will be common across all the artifacts in my enterprise application..
My applications will refer to this file from the url.
How can i achieve this?
EDIT1: my exploration in this direction is based on this answer on SO:
How to share a common build.gradle via a repository?
There are a few different options for this.
One is to publish a project with the dependencies you want to share defined as API dependencies. Projects that depend on this will inherit the dependencies.
Or you could write and publish a Gradle plugin that will configure your projects with the common dependencies. Projects can apply the plugin, and will automatically be configured in a certain way. (You don't need to publish a plugin to do this - first try creating a project-local buildSrc convention plugin.)
I would actually recommend neither of these approaches.
It's easy to get into a tangled web of dependency hell when transitive dependencies are inherited. It's likely that at some point some dependency will clash, and excluding dependencies can be a big headache, and will easily cancel out any benefit in trying to reduce a little duplication.
Additionally, it's nice when a project is explicit about its dependencies. Being able to look at a build.gradle.kts and understand exactly what dependencies are set is very convenient.
Instead, what I would recommend is controlling the versions of common dependencies in a central location. This can be achieved with the Java Platform plugin. This plugin can be applied to a single build.gradle.kts file, and it lists all versions of all possible dependencies. (It can also import existing Maven BOMs, like the Spring Boot BOM).
Now, all subprojects can add a platform dependency on the 'Java Platform' project.
dependencies {
// import the platform from a Maven repo
implementation(platform("my.company:my-shared-platform:1.2.3"))
// or import a platform from a local project
implementation(platform(":my-project:version-platform"))
// no need to define a version, if it's defined in the platform
implementation("com.fasterxml.jackson.core:jackson-databind")
}
This is the best of both worlds. Projects can be explicit about their dependencies, retain autonomy, while the versions can be aligned across independent projects.
I have a situation at the moment where I have:
Project A which is built into a fat jar using Maven assembly plugin.
Project B which uses the jar built in Project A. It is added to the project as a resource and launched in a separate process using a process builder.
I wonder if it's possible to achieve similar behaviour using just one Maven project. I.e build the jar containing only the classes and dependencies required for project A, and then build the rest of the project with the prebuilt jar.
Sorry if I'm not being very clear here.
This is against a few of Maven's core concepts:
One project, one model (POM). Two projects (A, B), two models (POMs).
There's one artifactId in a POM. What is a second artifact (jar) supposed to be named?
One project leads to one artifact. There is no additional "prebuilt jar" built within the very same project.
Dependencies are for the whole project (and possible sub-module projects). I'm not aware of how to "containing only the classes and dependencies required for project A".
Artifacts are stored:
in <project>/target temporarily
in the local Maven repository (default: ~/.m2/repository)
possibly in a remote Maven repository
... while resources are taken from <project>/src/main/resources during the build.
There might be some tricky solutions (which have possibly pitfalls, too) to achieve this if one thinks about it thoroughly. But I'd never ever recommend such.
I am in my project reusing an open source maven-based component that includes a bunch of shaded (e.g, using the maven-shade plugin) direct and transitive dependencies in the component uber-jar. Unfortunately some of those dependencies clash with dependencies that my own project has. Specifically, the component's dependencies transitively include servlet-api 2.x whereas I need 3.x in my project - and they appear to be in the same namespace. The component's top-level dependency that pulls in servlet-api (lucene-demo) is actually not needed for the functionality of the component, so I'd be happy to remove it if possible. My project is built with Gradle.
What is the recommended way of dealing with this type of situation? Is there any way of removing the offending dependencies from the reused uber-jar when I build my own project? Or should I rebuild the reused component myself, excluding the troublesome dependency? If so, can this be done in an automatic manner, such that I don't need to maintain my own fork of the open source component? The component is presently hosted in GitHub and published via Maven Central.
(As you might understand, I'm a bit of a beginner to both Maven and Gradle, so don't worry about dumbing things down).
Very new to Maven, can someone please explain to me the difference between using maven modules vs just adding a dependency to your maven project to another maven project in your workspace? When would you use one over the other?
A dependency is a pre-built entity. You get the artifact for that dependency from Maven Central (or Nexus or the like.) It is common to use dependencies for code that belongs to other teams or projects. For example, suppose you need a CSV library in Android. You'd pull it as a dependency.
A Maven module gets built just like your project does. It is common to use Maven modules for components that the project owns. For example, maybe your project creates three jar files.
A dependency can be thought of as a lib/jar (aka Artifact in Maven parlance) that you need to use for building and/or running your code.
This artifact can either be built by your one of the modules of your multi module project or a third party pre-build library (for example log4j).
One of the concepts of maven is that each module is going to output a single artifact (say a jar). So in case of a complex project it is good idea to split your project to multiple modules. And these modules can be dependent on each other via declared dependencies.
See http://books.sonatype.com/mvnex-book/reference/multimodule-sect-intro.html for example of how a web app is split to parent and child modules and how they are linked.
One of the most confusing aspects of Maven is the fact that the parent pom can act as both a parent and as an aggregator.
99% of the functionality you think about in Maven is the parent pom aspect, where you inherit things like repositories, plugins, and most importantly, dependencies.
Dependencies are hard, tangible relationships between your libs that are evaluated during each build. If you think of your software as a meal, it's basically saying A requires ingredient B.
So let's say you're preparing lasagne. Then your dependency chain would look something like this:
lasagne
<- meatSauce
<- groundBeef
<- tomatoPaste
<- cheese
<- noodles
The key thing is, each of the above items (meatSause, groundBeef, cheese, etc) are individual builds that have their individual set of dependencies.
By contrast, the only section of your pom that pertains to aggregation is the modules section:
<modules>
<module>meatSauce</module>
<module>groundBeef</module>
<module>tomatoPaste</module>
<module>cheese</module>
<module>noodles</module>
</modules>
Aggregation simply tells your build engine that it should run these 5 builds in rapid succession:
groundBeef -> tomatoPaste -> cheese -> noodles -> meatSauce
The main benefit of aggregation is the convenience (just click build once) and ensuring the builds are in the correct order (e.g. you wouldn't want to build meatSauce before tomatoPaste).
Here's the thing though: even if you organize the libs as standalone projects without module aggregation, your build will still come out the same provided you build in the correct order.
Moreover, both Jenkins and Eclipse have mechanisms for triggering builds if a dependent project has changed (e.g. changing groundBeef will automatically trigger meatSauce).
Therefore if you're building out of Jenkins or Eclipse, there is no need for aggregation
We are relatively new to Maven and now face a problem.
We have a Maven project (projectA) whose JAR is the dependency of several other projects. Some of the other projects are some custom web container while others are not, so some of projectA's dependency jars are provided in the case of the custom web container, but should be runtime scope in the case of other projects. We currently use exclusion list to filter out the provided jars in the case of the custom web container.
We are wondering if it would be better to use maven profiles. We know how to create the profiles with different dependencies (actually same dependencies different scope), and in both profiles, the built projectA jar is identical bit-wise. But what we don't know is, when we deploy/release the projectA jar artifact to a maven repository, what should the pom.xml look like? For these web container projects, the pom.xml should not include the provided jars, but for other projects, the pom.xml should include these jars.
We can use a different name for the jar in each profile and deploy each with a different pom.xml, but since these jars are identical bit-wise, it doesn't seem like a perfect solution. So we thought there's gotta be a better solution to this problem, only that we don't know since we are relatively new to Maven. Thanks.
The POM is the POM. You seem to be talking about managing transitive dependencies in other projects that reference "A". Your options in Maven are fairly limited:
You can use exclusions to remove transitive dependencies that you don't want.
You can declare dependencies in "A" as "provided", but this is only really correct if that jar actually is provided in A's target environment. It's primarily intended for Java EE api dependencies, like servlet-api, which are provided by containers and prohibited from being included in WAR files.
You can declare dependencies as optional, which is what people usually mean when they say "provided", and manually include those dependencies in the places where they're needed.
I'd personally choose the "optional" route because it's the job of each project to pull in the dependencies it needs, and if something is optional when using "A", it just means things that use "A" have to explicitly choose whether they'll use that optional part of it. This tends to be the best fit when building an artifact that has multiple, differing use cases.
For additional help in this area, you can also use the maven enforcer plugin to ban certain dependencies from builds so that you don't accidentally get jars that you don't want.