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.
Related
We have a EAR project which has a WAR project. Maven is used, so pom.xml. As typical of any project, this project also contains a big feature (say Job Scheduling "JBS") among many other features. As it is planned to retire this whole project in the near future, it is discouraged heavily to spend much on working on this project (whether bugs or enhancements).
Therefore, for the sake of running the (JBS) feature as a separate application, the whole EAR project was duplicated (also to save time/cost). As a result, all the Java packages and classes (necessary for JBS project) were duplicated. In this situation, if we update one or more classes in the main project, this (JBS) feature project/application gets outdated (and needs update).
The fact is that this JBS feature project ONLY requires many packages of Java classes (from the main EAR-WAR project), and do not require 99% of the web modules and others. I am removing all the unnecessary things from JBS project. Then I would like to create a JAR library with all the java classes, so JBS project can have a dependency on this JAR.
I do not know if it is a good idea to separate these classes out of the main project (to create another Java project). I would like to continue to have these classes as part of the main project. Then, it will be good, as and when one or more of these classes are changed, a new version of the JAR will be generated (right away). And the JBS project would then make use of this updated JAR.
How can we accomplish this? I understand, through maven, we can do a build/package jar/war/ear on a project of that nature. I am not an expert with maven (and did not learn it systematically).
But, is there a way to create one or more JARs additionally from inside WAR pom.xml? In other words: I mean pom.xml of WAR will create a WAR. In addition to creating a WAR, can maven help create additional JAR? Or can maven create two packages out of one pom.xml?
Or should I create a separate module in the main project with all these packages/classes, and have its own pom.xml to generate the necessary JAR? For this, most probably I need to modify the structure of the main project. I would like to avoid this unless there is no way out.
Can you advice?
It seems like the best thing for you would be to create a multi-module project that both contains the JAR and the other project. This way, you can easily change/build them together, but you create separate artifacts.
this is a more conceptual question:
I want to create an application which uses the WALA framework, which itself is packaged as a eclipse plugin, built with maven-tycho. When I try to add this as an dependency no transitive dependency gets resolved, because they are covered by the tycho build.
This is the pom of the WALA project I need at least https://github.com/wala/WALA/blob/master/com.ibm.wala.core/pom.xml
Should my application be a OSGI Bundle itself or can I create a regular jar with it without having much trouble? Which approach is more practical?
If I have seen it correctly, wala.core has only two dependencies wala.util and wala.shrike (util has none, shrike depends on util). So you might as well simply include all three dependencies in your project.
On the long haul, however, you might should indeed consider creating an osgi application instead.
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.
I am using the hector & astyanax projects. These projects used to require maven, and now astyanax requires gradle.
I would like to statically link one of these projects to my java project (which is not built using maven/gradle). I am not interested in updating the version of astyanax every time they make a new release. I am not interested in mavenizing/gradelizing my own project.
So, two problems arise: 1. Getting the astyanax jars. 2. Getting the depenedency Jars.
At first, not having time to thoroughly understand maven (get off my lawn!), I copied all of the jar files in my global .maven directory into my project, and linked to them. Problem is, it's a pretty messy solution.
Is there an easier way to get all jars needed to use a gradle/maven library? (While I don't mind using gradle to build astyanax, I don't want to use it to build my own project).
Getting jars for distribution, seems like a very basic use case, am I missing a simple way here?
astyanax is published to maven central as com.netflix.astyanax:astyanax:1.56.42. Any build tool (Grails, Maven, Gradle, Buildr, SBT) that resolves from Maven can make a dependency on Astyanax and have its dependencies transitively downloaded. That fact that it's built with Gradle doesn't change how it's consumed.
From your question, it's unclear how you want to resolve these libraries. If you don't want to use a tool (Grails, Maven, Gradle, Buildr, SBT), then you'll have to manually navigate every dependencies and its dependencies from Maven Central. It's quite uncommon for a modern java project to manually download dependencies anymore, the practicalness given the complex dependencies graph make it prohibitive.
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.