Using Maven to build fat-jar library.

[Claude Moore]

I'm really a newbie of maven, so sorry if this question is too silly....
As far as I know maven is a very good tool for managing deployment, build, and more important - at least for me - for managing JAR dependencies. Willing to use it in Java EE projects, I made some experiments and I have to admit that I found Maven by far more complex than I would have expected. Despite the fact that "complexity" isn't a good reason to learn something , I wonder if it may be a reasonable approach to use Maven only to manage dependencies and to build fat Jars (with Maven shade plugin), so that I can include created artifacts as library in web projects.
Is there anyone that used a similar approach ? What about pro and cons ?

Thanks in advance.

[German Gonzalez-Morris]

I reckon, never I'd liked to use fat jars. Although it can be easier to deploy (and manage), it hides the current libraries you are using, and that's solved with <dependencies> in Maven.

It is not complex Maven, maybe you need to think more functional than Ant (for instance).

[Stephan van Hulst]

Why would you want to use a fat jar? Modularity is good!

[Tim Holloway]

I'm not sure what you're attempting.

If you're looking to product a "super jar" (Jar of Jars) that can be included into a WAR or EAR, that won't work. The enhanced classloader can scan inside the jars in /WEB-INF/lib, but unless you provide a classloader of your own inside the webapp then jars inside the /WEB-INF/lib jars will not themselves be scanned.

In Maven you can define a base jar that pulls in a lot of secondary jars as dependencies, but they'll all go into the flat library directory in the product being produced. Although not all people are comfortable with having a bunch of dependencies being fetched indirectly like that.

[Claude Moore]

Tim Holloway wrote:I'm not sure what you're attempting.

If you're looking to product a "super jar" (Jar of Jars) that can be included into a WAR or EAR, that won't work. The enhanced classloader can scan inside the jars in /WEB-INF/lib, but unless you provide a classloader of your own inside the webapp then jars inside the /WEB-INF/lib jars will not themselves be scanned.

In Maven you can define a base jar that pulls in a lot of secondary jars as dependencies, but they'll all go into the flat library directory in the product being produced. Although not all people are comfortable with having a bunch of dependencies being fetched indirectly like that.

Well, I found a plugin (maven:shade) which seems to explode jar grabbed from dependecies and repackaging them in a single jar... so there is no "jar of jars". That won't work, indeed.

[Claude Moore]

German Gonzalez-Morris wrote:I reckon, never I'd liked to use fat jars. Although it can be easier to deploy (and manage), it hides the current libraries you are using, and that's solved with <dependencies> in Maven.

It is not complex Maven, maybe you need to think more functional than Ant (for instance).

Well, as I previously mentioned, I started with creating a complete EAR (EAR, WAR, EJB and EJBClient) with Maven. I have to admit that mine was not a brilliant idea - I should have started with something simpler - but I wanted to be brave...
I found it overhelming, and still I'm not able to create anything working, while creating an EAR project with Eclipse is straighforward.

Without archetypes, the whole thing seems a jungle. With archetypes, the whole thing still seems a jungle... For example I tried an archetype (ear-javaee7) and I can't understand why it uses Java EE 6

Can you give me an hint on how to proceed ?

[Tim Holloway]

There's a whole bunch of archetypes, some in the main repos, some in odd corners of the world. They prototype many different types of projects. JAR projects. Web projects. Camel projects, on and on. I've even built a few of my own.

And within those broad categories, there are different flavors. Some web projects pull in Hibernate. Some pull in JSF or Struts. Some pull in Hibernate, Spring AND JSF.

And, unfortunately, many of them pull in out-of-date components.

An archetype is a starting point, but as often as not, I either build a POM from scratch or rob one of my existing ones. That way I (hopefully) don't have to put up with Maven's version of DLL Hell where I find what versions of Hibernate won't work with which versions of Spring, which log managers hate everybody and so forth.

[Claude Moore]

Thanks Tim for your reply and sorry for the delay in getting back to you.
At a first glance, I had just the impression that with Maven you may risk to get into a Jar Hell... but on the other hand I'm just a beginner so my point of view is biased by unexperience.
I'm used to use Eclipse Java EE project so a Maven EE project is a good starting point for an headache :-)
I was puzzled to see that some archetypes are out of date or - at least for what I can understand - are not working properly (why an archetype named ear-javaee7 when used creates a Java EE 6 project, so that I have to change manually properties ?)

I think that your approach with maven is the only reasonable: acquiring the right experience with it and then adapt one's well known POM files to start from...

[Jesper de Jong]

Different people have different preferences.

I like being able to build a single JAR with the Maven Shade plugin that contains all dependencies, because it makes deployment much easier. Instead of having to install a directory full of JAR files and carefully setting up the classpath, etc. I only need to copy one JAR file and starting the program is very easy with: java -jar myprogram.jar

[Claude Moore]

Jesper de Jong wrote:Different people have different preferences.

I like being able to build a single JAR with the Maven Shade plugin that contains all dependencies, because it makes deployment much easier. Instead of having to install a directory full of JAR files and carefully setting up the classpath, etc. I only need to copy one JAR file and starting the program is very easy with: java -jar myprogram.jar

Does it work even in a Java EE context ?

[Tim Holloway]

Claude Moore wrote:

Jesper de Jong wrote:Different people have different preferences.

I like being able to build a single JAR with the Maven Shade plugin that contains all dependencies, because it makes deployment much easier. Instead of having to install a directory full of JAR files and carefully setting up the classpath, etc. I only need to copy one JAR file and starting the program is very easy with: java -jar myprogram.jar

Does it work even in a Java EE context ?

No, but you don't need Shade in J2EE. A WAR is already set up to act that way courtesy of the J2EE architectural standards.

[Comal Rajagopalaratnam Muthukumar]

Jesper de Jong wrote:Different people have different preferences.

I like being able to build a single JAR with the Maven Shade plugin that contains all dependencies, because it makes deployment much easier. Instead of having to install a directory full of JAR files and carefully setting up the classpath, etc. I only need to copy one JAR file and starting the program is very easy with: java -jar myprogram.jar

Hi
The following example builds a single jar file from the pom.xml

You may try further as required if it is of use for making it fat.I tried the same but invain

Thanks
As
CRMK

- <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion> 
  <groupId>com.mkyong.core.utils</groupId> 
  <artifactId>dateUtils</artifactId> 
  <packaging>jar</packaging> 
  <version>1.0-SNAPSHOT</version> 
  <name>dateUtils</name> 
  <url>http://maven.apache.org</url> 
- <properties>
  <jdk.version>1.7</jdk.version> 
  <junit.version>3.8.1</junit.version> 
  </properties>
- <dependencies>
- <dependency>
  <groupId>junit</groupId> 
  <artifactId>junit</artifactId> 
  <version>${junit.version}</version> 
  <scope>test</scope> 
  </dependency>
  </dependencies>
- <build>
  <finalName>dateutils</finalName> 
- <plugins>
- <!--  download source code in Eclipse, best practice 
  --> 
- <plugin>
  <groupId>org.apache.maven.plugins</groupId> 
  <artifactId>maven-eclipse-plugin</artifactId> 
  <version>2.9</version> 
- <configuration>
  <downloadSources>true</downloadSources> 
  <downloadJavadocs>false</downloadJavadocs> 
  </configuration>
  </plugin>
- <!--  Set a compiler level 
  --> 
- <plugin>
  <groupId>org.apache.maven.plugins</groupId> 
  <artifactId>maven-archetype-plugin</artifactId> 
  <version>1.2</version> 
- <configuration>
  <source>${jdk.version}</source> 
  <target>${jdk.version}</target> 
  </configuration>
  </plugin>
- <!--  Make this jar executable 
  --> 
- <plugin>
  <groupId>org.apache.maven.plugins</groupId> 
  <artifactId>maven-archetype-plugin</artifactId> 
- <configuration>
- <archive>
- <manifest>
  <mainClass>com.mkyong.core.utils.App</mainClass> 
  </manifest>
  </archive>
  </configuration>
  </plugin>
  </plugins>
  </build>
  </project>

[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for
com.mkyong.core.utils:dateUtils:jar:1.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found d
uplicate declaration of plugin org.apache.maven.plugins:maven-archetype-plugin @
 line 56, column 13
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten t
he stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support buildin
g such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building dateUtils 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ dateUtils
---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] Copying 0 resource
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ dateUtils ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ da
teUtils ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources,
i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory D:\Program Files\java\jdk1.7.0_07\bin
\apache-maven-3.3.9\src\test\resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ dateUti
ls ---
[INFO] No sources to compile
[INFO]
[INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ dateUtils ---
[INFO] No tests to run.
[INFO]
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ dateUtils ---
[INFO] Building jar: D:\Program Files\java\jdk1.7.0_07\bin\apache-maven-3.3.9\ta
rget\dateutils.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 11.765 s
[INFO] Finished at: 2016-05-27T01:38:47-07:00
[INFO] Final Memory: 7M/17M
[INFO] ------------------------------------------------------------------------