A while ago I blogged about running your custom deployer logic in a Java IDE. That article was based on my experiences with SDL Web 8.5 (aka Tridion 8.5) and the *.bat file and pom.xml that were given in that article were based on this version.
Total, I’m here to tell you that the same thing is possible in Tridion 9.
The process of creating components in Tridion has always been very different from creating pages. When you create a component you are guided by a schema, which provides strict guidelines. However, when you want to create a page, you start off with a tabula rasa – essentially a blank sheet of paper.
This changes with the introduction of regions and page schemas. Here’s how. Continue reading
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.
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.