We have a small project with some heavy-weight dependencies (e.g. Spring) of which we only use small parts. Therefore, the JAR we get when packing with all dependencies weighs several megabytes, even for out two-class-server. This seems unnecessary.
Is there a way to restrict JAR assembly to actually used (class) files?
You can use the maven-shade-plugin to create a Jar-with-dependencies (your project and the dependencies merged into one big jar) while limiting the classes or packages that are added to that jar. See the includes / excludes page for reference.
If you don't want to manually specify what needs to be included, perhaps there is a way to integrate ProGuard with your build.
It's not possible to include only classes which are used. But you can exclude dependencies from your depencies to reduce the JAR size. Only drawback: you need to know what you can exclude and what not.
Related
maven-shade-plugin includes the dependencies unpacked within the uber jar, which makes sense because of the shading that is involved.
Is there a way to allow for a specific 'safe' dependency to be included as a whole jar (not unpacked into classes)? I could not see such a thing in the docs.
My project inherits it's compile dependencies from parent and I have no control over it - can't change them to provided. Additionally, I have added another dependency 'a:b:1.0.0' to my project's pom. I want to include only 'a:b:1.0.0' with it's own dependencies (recursively ) to my uber jar.
Seems like neither assembly nor shade plugin doesn't support such case.
How this could be done ?
Thanks
Shading recursively has some significant disadvantages. Especially, the problem of duplicate files from multiple dependencies being overwritten with only a single version of the file. This can cause some pretty annoying problems to troubleshoot at runtime. You'd be better off using something like spring boot to build a standalone jar where instead of shading files into a single hierarchy, will embed dependent libraries into itself as a subdirectory and include on the classpath for you.
http://docs.spring.io/spring-boot/docs/current/maven-plugin/repackage-mojo.html
I am currently working in a Java project, and we use maven to build the final jar. There are two ways to build the jars as we all know, i.e. one single jar with-dependencies, and a jar without dependencies. In the latter case, we need to add dependent jars to the classpath as well.
In principle both can work, personally I prefer one jar with dependencies, but in the project team members decided to use separate jar without dependencies. So hereby I would like to know which choice is better?
This question has no answer, since it depends on what you need to do.
If you're writing an utility package or component, that could be a dependency of another project, then there's no point in having all the dependencies inside it - it's better to leave dependency resolution to a dependency manager, like Maven.
If you, instead, are writing a full application packaged as a jar, I mean something with a MainClass that can be executed with java -jar myjar, then having the dependencies together will make distribution easier.
Consider that, for instance, if you're writing a webapp, that'll be packaged as a WAR, it normally comes with dependencies.
My project inherits default configuration from spring-boot-starter-parent . The command mvn package generates so-called uber Jar, which contains all the application compiled code plus all the dependencies from the dependency tree.
The problem is that there are too many dependencies copied into the target Jar file. I tried to control that by setting some of dependencies' scope to compile, but that didn't work.
Is it possible to control what dependencies will be taken into the final Jar file?
Thanks!
The ueberjar only contains the dependencies that you specifically asked for. I'm not sure what else you are looking for. If you are using "starter" poms as dependencies (no-one forces you to do that) then you are perhaps selecting more than you will strictly need at runtime. We do try to be conservative about the transitive of the starters, but the whole point of them is that they have transitive dependencies that might be useful. Like I said, you don't have to use them if you don't like them.
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.