The latest version of Tridion (SDL Tridion Sites 9) is now fully supported by DD4T for Microsoft.NET. Read here how easy it is to upgrade.
After playing around with installing SDL Tridion Sites 9 from scratch I wanted to know more about the database upgrade steps of this latest release when upgrading from an older version of Tridion.
SDL supports upgrading to SDL Tridion Sites 9 from one of the following versions directly:
- SDL Web 8.5 (also known as SDL Tridion Sites 8.5)
- SDL Web 8 with Cumulative Update 1
- SDL Tridion 2013 SP1 HR1 (Hotfix Rollup 1)
SDL Tridion Sites 9, part of SDL Tridion DX, introduces several changes and new features for managing digital experiences. Of course, we were eager to install the new version and play with it.
Here are some of the things we noticed when installing SDL Tridion Sites 9 that perhaps you didn’t know.
UPDATE: you can now run the Tridion deployer in your IDE if you are on Tridion 9 also! Instructions below have been modified to show the differences between SDL Web 8.5 and Tridion 9. Now on to the story.
Whenever you publish a page, component or another type of item in Tridion, the item is first published, then transported and finally deployed. SDL offers various ways to extend or modify this deployment process. All you need to do is write some custom java code. The most commonly used extension points are deployer modules and storage DAOs. You can find more about this here and here.
In this post I’m not going to explain what these extensions are and what you can do with them. Instead, I will focus on how to develop this type of extension effectively. As always with Java (in my experience at least), the code is easy but the environment is hard. But if you follow these instructions, you will be able to run your customizations locally, make sure they get triggered, and even perform step-through debugging on your code. Pure bliss!
These days the standard way to get your java libraries is through Maven. However, sometimes you still need to deal with jar files that aren’t available through Maven at all. Perhaps some software vendor has provided a set of jars, or you have a custom build that you aren’t allowed to publish at all.
If this is the case, you could just reference the jars on the file system, the old school approach. But you can also mavenize them yourself, and store them in your local Maven repository (which can be found in your user profile folder, in the folder .m2). That makes it possible to reference these libraries in a pom.xml or in a build.gradle file, giving you all the advantages of modern dependency management.