What is the Target Platform?

I did an informal poll on the Liferay community Slack channel recently:

I was actually kind of surprised by the majority of votes for the "What is the target platform?" option.

So, inspired by the results of the poll, I'm going to answer the question, What is the Target Platform?

The Target Platform's Roots

So the phrase, "Target Platform", is really a Liferay-only name referring to Maven's Bill Of Materials (BOM) support.

In multi-module projects in Maven, there is a parent project and it identifies the submodules that are part of the project. Each submodule will build an artifact like a JAR or a WAR, but for all intents and purposes it is a complete project in that it defines dependencies, has build goals and generates artifacts.

One problem identified early on, since each submodule declares its dependencies, it could be very easy to end up with individual submodules of the same multi-module project declaring dependencies on different versions of third party artifacts.

The solution to this was to declare dependency versions in the parent project and then leave versions out of the submodules; this way the actual third party artifact version would be "inherited" from the parent project and consistent across all submodules.

What started to happen next, when spinning up another multi-module project, often times you'd want to have the same dependencies from your last multi-module project in the new project (either because the versions are approved by the organization or the version matrix in the previous project worked and you want to leverage that success going forward, etc).

The Bill Of Materials, commonly known as BOMs, was created to move the dependency declarations out of the parent POM so multiple projects (multi-module and single module projects) could use a shared or common set of third party artifact versions.

BOMs and Target Platform

In general, BOMs define an external set of artifacts w/ versions, and Maven and Gradle projects can use the BOMs so the project(s) doesn't have to worry about versions specifically.

For Liferay 7+ development, there are a lot of Liferay artifacts your various modules will be declaring as dependencies. And between versions (7.0, 7.1, 7.2 and the coming 7.3) and even between DXP FixPacks, the version numbers change. It can be hard to find or know what version of a specific API jar is available in a specific Liferay environment that you need to target.

So when you compare these two aspects, BOMs defining an external set of artifacts with versions, and a Liferay target environment with lots of artifacts at defined versions, it should be easy to see how they fit together.

The combination is what Liferay refers to as the Target Platform.

The Target Platform is a set of BOMs which define all of the exposed Liferay and third party artifacts which are available in a specific (often very specific) version of Liferay.

So the Target Platform has a set of BOMs for 7.0 GA5, all of the 7.1 and 7.2 GAs, and will soon be getting the BOMs for the 7.3 GAs. For Liferay DXP, there are BOMs for FixPack 60 onward and Service Packs 7, 8 and 9. For 7.1 and 7.2, there are BOMs for each fix pack and service pack and, when 7.3 is released, those will exist too.

Why You Should Use the Target Platform

If you have already done some Liferay development or are planning to do some Liferay development, it is quickly obvious that there are a lot of new Liferay artifacts to depend upon. Most of the Liferay APIs that used to be defined in the old 6.x's liferay-service.jar have been moved out into their own OSGi-ified module jars, so it is not uncommon to find projects with dependencies on over 20 individual Liferay artifacts. Managing all of those versions manually can be quite time consuming.

The Target Platform takes that manual management of versions off of your plate. You target a specific platform version such as 7.1 GA2, for example, and then you forget about version management for artifacts that Liferay provides.

So the primary reason to use the Target Platform is because it will save you time. Time used during development to find what versions your specific target environment has, time during deployment otherwise used to resolve version availability differences, etc.

If you enable indexing in the Liferay Workspace, your IDE should incorporate the source indexing feature to find Liferay source for the target platform version. This will help with reviewing code and live debugging against the target platform environment.

And finally, upgrading customization modules becomes easier too. When you are upgrading from 7.1 to 7.2, instead of visiting all of your POM files or build.gradle files to tweak the individual versions of each Liferay dependency, you change the target platform version. It's not going to be perfect since dependencies can change names or refactored to new modules that didn't exist in the older version, so there will still be work to do to get the projects back in a buildable state, but it will absolutely save you from the busy work for all of the manual version management.

So I think those are pretty strong reasons to learn about the Target Platform: saving time, IDE integration and simplifying upgrades.

Conclusion

So now we know what the Target Platform is and have some pretty good reasons why we should use it.

The final question might be how can you use the Target Platform?

That one I'm not going to answer directly, instead I'd point you to the following resources:

https://liferay.dev/blogs/-/blogs/transitioning-to-the-target-platform- This is a previous blog post I wrote that shows how to transition projects you may have over to using the Target Platform. It covers Maven and Gradle projects, both in the Liferay Workspace as well as standalone projects.

https://portal.liferay.dev/docs/7-1/tutorials/-/knowledge_base/t/managing-the-target-platform-for-liferay-workspace and https://portal.liferay.dev/docs/7-1/tutorials/-/knowledge_base/t/validating-modules-against-the-target-platform are pointers into Liferay's documentation specifically about using the Target Platform during your builds. The validation section, if you follow it through, can really help you diagnose deployment version issues even before you deploy your artifacts, I really think that section is worth a look.

Anyways, hope this helps explain what the Target Platform is. If you have any questions, feel free to add them here or in the forum or in the Liferay community slack!