Introducing the Mega-Jar!

A new dev tool to simplify your dependency tracking.

What is the Mega-Jar?

So the Liferay Dev Tools team recently included a new feature that they refer to as a "fat" jar, but I'm giving it the name Mega-Jar!

This is a new single dependency that you can use in your Maven pom.xmls and Gradle build.gradle files, replacing all of the atomic dependencies with a single "one Mega-Jar to rule them all" dependency.

So basically your build.gradle file can go from:

dependencies {
	compile group: "biz.aQute.bnd", name: "biz.aQute.bndlib", version: "3.5.0"

	compileOnly group: "com.liferay", name: "com.liferay.application.list.api"
	compileOnly group: "com.liferay", name: "com.liferay.asset.api"
	compileOnly group: "com.liferay", name: "com.liferay.asset.display.page.api"
	compileOnly group: "com.liferay", name: "com.liferay.asset.display.page.item.selector.api"
	compileOnly group: "com.liferay", name: "com.liferay.asset.info.display.api"
	compileOnly group: "com.liferay", name: "com.liferay.asset.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.comment.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.dynamic.data.mapping.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.expando.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.flags.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.frontend.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.frontend.taglib.clay"
	compileOnly group: "com.liferay", name: "com.liferay.frontend.taglib.soy"
	compileOnly group: "com.liferay", name: "com.liferay.frontend.taglib.util"
	compileOnly group: "com.liferay", name: "com.liferay.info.api"
	compileOnly group: "com.liferay", name: "com.liferay.item.selector.api"
	compileOnly group: "com.liferay", name: "com.liferay.item.selector.criteria.api"
	compileOnly group: "com.liferay", name: "com.liferay.item.selector.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.petra.reflect"
	compileOnly group: "com.liferay", name: "com.liferay.petra.string"
	compileOnly group: "com.liferay", name: "com.liferay.petra.function"
	compileOnly group: "com.liferay", name: "com.liferay.reading.time.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.rss.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.social.bookmarks.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.trash.api"
	compileOnly group: "com.liferay", name: "com.liferay.trash.taglib"
	compileOnly group: "com.liferay", name: "com.liferay.portal.validation.api"

	compileOnly group: "com.liferay.portal", name: "com.liferay.portal.kernel"
	compileOnly group: "com.liferay.portal", name: "com.liferay.util.taglib"
	
	compileOnly group: "javax.portlet", name: "portlet-api"
	compileOnly group: "javax.servlet.jsp", name: "jsp-api"
	
	compileOnly group: "jstl", name: "jstl"
	
	compileOnly group: "org.osgi", name: "org.osgi.service.component.annotations"
	
	compileOnly group: 'org.slf4j', name: 'slf4j-api'
	
	compileOnly project(":modules:kangaroo:kangaroo-api")
}

down to:

dependencies {
	compile group: "biz.aQute.bnd", name: "biz.aQute.bndlib", version: "3.5.0"

	compileOnly group: "com.liferay.portal", name: "release.portal.api"

	compileOnly group: "jstl", name: "jstl"
	
	compileOnly group: 'org.slf4j', name: 'slf4j-api'
	
	compileOnly project(":modules:kangaroo:kangaroo-api")
}

A lot shorter, right? For Maven, it's going to be the similar principle; instead of itemized <dependency /> elements in the pom, you'll have the main dependency on the Mega-Jar.

And now let's say we have a requirement that we're going to add support for, say, a file upload. If we were not using the Mega-Jar, we'd have to find out what module from Liferay provides that API, group: "com.liferay", name: "com.liferay.upload.api" in this case, add it to our build.gradle.

With the Mega-Jar, we don't have to worry about it because it's already in there.

If you're developing for Liferay DXP, use "release.dxp.api" instead of "release.portal.api" for your Mega-Jar reference.

What is in the Mega-Jar?

As you can see from the example, not everything is going to be in the Mega-Jar. All of the Liferay API and SPI modules will be in there, but none of the implementation or web jars are going to be in there.

The com.liferay.portal.kernel and com.liferay.portal.impl jars are in there, as well as the various util jars (bridges, java, and taglib), and you'll also find the Commerce API & SPI jars in there if you are using 7.3+.

There are some 3rd party jars in there too:

  • Jackson
  • Swagger Annotations
  • The Portlet 3, Servlet 3, Validation and RESTful Web Service API jars are in there.
  • JSoup 1.10
  • The OSGi modules that Liferay normally exposes (core, DS, Config Admin, annotations, whiteboard, etc).

You can find the complete list of what is in the Mega-Jar by actually downloading the jar from https://repository.liferay.com/nexus/content/repositories/liferay-public-releases/com/liferay/portal/release.portal.api/ for Liferay CE or https://repository.liferay.com/nexus/content/repositories/liferay-public-releases/com/liferay/portal/release.dxp.api/ for Liferay DXP. Open the jar and look for the versions.txt file that is in the root folder. It lists every dependency that has been included into the Mega-Jar for the release you're developing at.

Conclusion

It's easy to see how the Mega-Jar will make a developer's life a lot easier, but honestly I'm not sure what I think about it just yet.

In the example earlier we were adding a dependency for upload for a requirement, but from the dependencies you can't really tell what the module will depend upon. Did I introduce a dependency on the push notifications API in my code change? You certainly can't tell from the Mega-Jar inclusion if I did or didn't.

So while it is an aid for development, it removes some context from the module at the same time.

I guess it's like import java.util.*; you know that the class is using something from java.util, you just don't have any idea what or how much it is using.

For some developers and teams, this may not be a concern, so I'm blogging about this even though I'm not sold on it myself.

I hope that you, or your team, can benefit from the Mega-Jar if you're okay with it.

0