I am using Maven and my configuration (which is most likely the default) produces this:
That means my compiled code is 4% of the file. Largest inflation was caused by the GitHub API library - I am strongly considering that I'll just drop it.
But my question is about the small file, not the big one. Maven creates it for a reason right? Could I maybe somehow distribute it and have it work on clients' computers? Why does it exist and what useful can be done with that?
java is a main starting point which has main(String args[]) method inside. pom. xml file in which we will add Maven Plugins which will build executable . jar project with all included dependancies.
The maven jar plugin provides the capability to build jars files, if you define that your project is packaged as a jar file, maven will call implicitely to this plugin. We don´t need to define it inside pom. xml it will be downloaded and executed when maven needs it. Despite that, we can define it inside pom.
The value jar-with-dependencies tells Maven to build a JAR file with dependencies which is another term for a Fat JAR. The executions XML element tells Maven which Maven build phase and goal this Maven plugin should be executed during. The maven-assembly-plugin should always be executed during the package phase.
jar'. The resulting 'jar' file contains the compiled java class files as well as the files from src/main/resources. Usually there is no need to mentioned the 'maven-jar-plugin' explicit cause it's bound to the Maven Build Life Cycle. For full documentation, click here.
Given your question, your Maven project is most likely a jar
project that uses the maven-assembly-plugin
to generate an uber-jar. In your output, there are 2 different files that are the result of 2 completely different process.
autoclient-3.0.jar
is what's called the main artifact. This is the primary result of the Maven build. It consists of the compiled classes in your project alone, packaged into a jar
by the maven-jar-plugin
. You have this file because your project has the jar
packaging. In Maven, the jar
packaging automatically bind goals to build phases of the default lifecycle: among others, it includes an invocation of the jar:jar
goal, which creates this main JAR. But you have to realize that this JAR only contains your classes. If you try to run the code, it will probably fail because the dependencies won't be there. What's its purpose if you can't run it then? Well, its purpose is to serve as a library for other projects, not as executable code.
Take, for example, a utility library that you would like to create: this library is not intended to be ran directly, it's intended to be used as a dependency for another project which will be executable. With the notion of transitive dependencies, Maven will automatically include in the buildpath of the other project your library and all its transitive dependencies. As such, your library does not need to embed its dependencies directly: they will be resolved correctly during the build of the other project.
autoclient-3.0-jar-with-dependencies.jar
is what's called an additional artifact. jar-with-dependencies
is a classifier that is used to distinguish this artifact from the main one. It is the result of the execution of the maven-assembly-plugin
with the predefined jar-with-dependencies
descriptor file. This artifact consists of the compiled classes of your project and all the direct and transitive dependencies of your project. An uber-jar (or fat jar) is really that: it aggregates all the dependencies and your code inside one big jar. The advantage is that you don't need to distribute separately the dependencies, they are already included in the JAR. But do note that its purpose is not to serve as a library, it is to be used as executable code.
Note that for a single project, it could make sense to keep both JAR: one intended to be used as a library (the main JAR) and the other intended to be used as runnable JAR.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With