Liferay versions and correct dependencies

Question

I'm rather new to Liferay, Maven and Java so it may be more of a general question about dependencies. I am maintaining a Liferay portlet that has been migrated from 6.2 to 7.1 and there are a number of Liferay maven dependencies with version numbers (eg. com.liferay.portal.kernel).

How does one know which versions of these dependencies one is to use for the version of the product that they are using?

Is this a typical case where one should always be trying to use the most recent version of dependencies even if the version of the product is a minor release behind?

score 3 · Accepted Answer · answered Aug 26 '19 at 09:29

Probably the easiest thing to do to make sure you compile agains JAR version that is in your target environment is to use the respective BOM (bill of material).

You can have a look at this code sample's POM for Liferay Portal 7.2 for example. Note the dependencyManagement that indicates which BOM to use:

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>com.liferay.portal</groupId>
                <artifactId>release.portal.bom</artifactId>
                <version>${portal.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

Then note how the actual dependency for com.liferay.portal.kernel JAR does not have a version specified.

        <dependency>
            <groupId>com.liferay.portal</groupId>
            <artifactId>com.liferay.portal.kernel</artifactId>
        </dependency>

The JAR version will be taken from the BOM which ensures it will match with the one the given version of Liferay Portal contains.

For comparison, here is the exact same POM but for Liferay Portal 7.1. As you can see the only difference is the portal.version property.

This is good for simplicity, but not suitable for some scenarios. one thing is that it is available for 7.1 GA2+, which exclude a lot of 7.x releases and/our specific distributions. Additionally, you might be interesting in releasing a sing jar for 7.1 GA2 and GA3 and others, in which case you would use a range or go around the dependency versioning using compile only dependencies (at your own risk). I those cases you cannot deffer to this dependency manager. Liferay for instance have several JAR depending on kernel 2.0 for ages (now this is hidden in the source).. — Victor, Aug 26 '19 at 12:42
depending on your company, this is actually understandable, you might have a project that feeds jar to several other projects, from GA1 to GAX or even from 7.0 to 7.2. — Victor, Aug 26 '19 at 12:42
A useful link here: https://mvnrepository.com/artifact/com.liferay.portal/release.portal.bom — Victor, Aug 28 '19 at 02:53

Victor · Answer 2 · 2019-08-28T03:09:45.600

how does one know which versions of these dependencies one is to use for the version of the product that they are using?

There are several ways to know which dependency versions you are using. The simplest one is to open up your bundle's jar files and look at the manifest file.

Of course, opening manifests is pretty tedious. You can use your system's Gogo shell to obtain information about the bundles on a running system.

Or you could look for the dependency on git. Use the Liferay tag that corresponds to your system, and subtract 1 from the minor portion of the version you see in the bnd file.

Finally, the logs can help you telling when a dependency is missing or a package version exists with a mismatch in version numbers.

Personally, I would say that the Gogo shell and App manager option is the easiest way.. but sometimes you are on git already..

is this a typical case where one should always be trying to use the most recent version of dependencies even if the version of the product is a minor release behind?

No, this is not a good thing for you. Although minors portions of the version scheme usually indicate that things are not likely to break, they do. If you use a method that was added in a minor version, on your running system that method will not be available and debugging can be confusing as you will clearly see that you IDE is even auto completing nonexistent stuff.

Additionally, there is no real advantage on using the latest version to compile your modules as the one running on the system is not updated, the one that will be running is the one that comes with your product (if you have not changed it, installed or embedded it even inside your on module... but if you did adjustments on your bundle, then it is up to you to track...).

You can use version ranges like 3.1.+ to build your modules, assuming that modules compiled with that dependency will work with all dot versions of it in a running system. If the dependency is known to be compatible with the older versions of itself, you can use older versions to build while the system will run a newer one. Liferay does this all the time in their own code (sometimes hidden by the word default). Of course, if you do this you will not be able to enjoy the latest features and IDE provided autocomplete and verification.

You also need to be aware that in OSGi based systems, several versions of the same library is possible. Sometimes, only one runs (singletons) but sometimes several will be available on runtime...so, you can pick the latest of the available...

So, in short: do not use the latest version to build if your system will not be running it. Maybe a range works, but you need to check if that dependency actually cares about being compatible inside that range, according to its versioning scheme.

Useful links:

Liferay versions and correct dependencies

2 Answers2