I have multiple projects using gradle. Each one of them generates a separate jar on build. I would like to make multiple fat jars which contains a subset of all the jars? I looked at other answers but they seem really old and hence does not seem to work anymore.
Check out the link here to see how to build an "uberjar." Or at the very least use it as a model for your own uberjar task.
Related
Does anyone know how to make a uber/fat/shade sources-jar (and javadoc-jar) using Gradle?
The generated Jar should not only contain the sources of the current project but also the sources of it's dependencies. I have been looking at, among others, a vanilla way and a way using the Shadow Plugin. Both work great at creating a normal uber/fat/shade jar, but none of them seems to support a way to create a sources-jar.
Use Shadow Plugin. In Maven it is called shade plugin. Does same thing. It produces an executable uber jar!
My problem is similar like this question:
Storm command fails with NoClassDefFoundError after adding jsoup as provided dependency
But I want to know the latest solution and better way to solve this.
I will post the same description in storm user mailing list:
Hi all,
I am building a topology with a load of libraries, such as spring, geotools, etc. Right now, I extract each jar files and pack it into one jar, (as suggested by many forums), using maven. The problem here, each jar sometime has conflicting files, so I have to merge manually. Another thing, though I pack my libraries in jar, storm loads its libraries first. For example, I use guava 16, and storm uses guava 13. My program won't work because guava 13 is loaded.
Current solution is I change the clojure script to put my jar first in the classpath before other jars. Or, I put my jars in lib/ directory.
Is there any simple and reliable way to include jar in Storm? Sorry if this email is too long. I want to make myself clear.
You can use the maven-shade-plugin instead of the maven-assembly-plugin to build your uber-jar. Then, use the relocation feature to move classes into a different package.
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.
I am completely new to Maven and come from an ant world. I am having lots of trouble something that might be really trivial.
I want to have a maven project that is made out of non-code items that I want to ship along my jars. These items are DDL scripts, installer scripts a couple of utility scripts, readmes etc.
I do not want to use "resources" in the corresponding java projects since I do not want them living in the actual product jars. I want them shipped as separate artifacts that just like any other jar.
It is acceptable to bundle them up in a jar or zip, etc.
Is there a way to do this?
Thanks!
Use the build helper plug-in to add additional artifacts to the Maven module.
Check out the answer to the following question
Ok, I found it and it was pretty simple. Just created a project added a simple pom with no plugin pacakging jar and I create the proper dir structure
src/main/resources/...
This builds it into a jar
We are trying to migrate our builds from ant to maven. Project I am working for is using ant since ages. Scripts are real complex where build artifact is a zip file having a definite directory structure. Build creates about 108 unique jars and packages them to this zip file along with many config files and other 3rd party jars.
We need this zip file to be same as now even after migration to Maven. I am just a learner on Maven as of now. My question to you guys is that if there is a way using which I can use one pom.xml to produce more that one jar file, providing list of jars and includes, excludes packages for each.
I googled and found that in case we need multiple jars from one project but different packages, we can do so by placing one pom.xml at each package (jar will be created from this package) and bonding all using dependency management.
But this does not solves my problem, as having 100+ pom.xmls does not seems to be a good idea.
Hope I have made my question clear. Please suggest if there is a way out.
Adding to Udo's answer here's another Sonatype blog posting with a diagram explaining the Maven anti-pattern of generating multiple jars from a single Maven project.
Both articles recommend adopting a modular structure to your code rather than fighting Maven's approach of decoupling large projects into a set of interrelated sub-modules.
Incremental publish approach
Start with looking at the arifacts you actually plan to share. Your mail suggests that the only file you're actually publishing is a large zip file containing 100+ jars and other files?
You could invoke the Maven command-line tool to publish this zip to the Maven repository:
mvn deploy:deploy-file \
-Durl=$REPO_URL \
-DrepositoryId=$REPO_ID \
-DgroupId=org.myorg \
-DartifactId=myproj \
-Dversion=1.2.3 \
-Dpackaging=zip \
-Dfile=myproj.zip
This approach can also be used to publish jars and POMs (containing dependencies). Eventually you'll be overwhelmed with the number of POMs to maintain.... AT which time it would be simpler to restructure the building of that jar into a sub-module.
Alternative to switching build technology
It's very difficult to walk away from a legacy ANT build. These often contain complex, custom and difficult to reproduce build logic. For such projects I recommend using Apache ivy to externalise 3rd party dependencies and share artifacts with other projects (who might be using Maven).
To that end I wrote an ant2ivy script for generating an initial ivy setup, based on the jars that already exist in the ANT project's directory (normally committed alongside the source).
Using ivy doesn't get you away from the fact that it's a good idea to create project sub-modules. However it does enable you to modernise your ANT build.
Update
Yes, there are Maven ANT tasks available. I don't use them because they based on Maven 2. I'm disappointed that we're still waiting for their Maven 3 replacement aether-ant-tasks (Only available from GitHub). Ivy is still the no1 choice for integrating non-Maven clients with a Maven repository
Well you can generate multiple jars out of one project.
Its not really considered best practice. Look at the supplied article and decide it yourself.
In the includes your are not limited to packages, however this surely makes it easier. :)