There are different ways to set up dotCMS to run in debug mode, which allows you to hot swap class and code changes (for the most part). You can run dotCMS standalone, from release, and connect to it via remote debugging as described in other documents, or you can run from Eclipse/IntelliJ in debug mode. Either way is effective.
From the Command Line
1. Pull down the dotCMS source
mkdir ~/source cd ~/source
then download the latest dotCMS version from github
git clone https://github.com/dotCMS/core.git
2. Build a dotCMS installation
Once you have pulled down the source code, use gradle to initialize, deploy and build a working dotCMS installation. Gradle supplies a gradle “wrapper” called gradlew that does not require any dependencies.
cd core/dotCMS ./gradlew deployWarTomcat
This will create a “tomcat8” directory under the ~/source folder that is a plain vanilla tomcat 8 installation with dotCMS deployed under the tomcat8/webapps/ROOT directory. Do not start tomcat yet.
In Eclipse (or skip to the Inside IntelliJ documentation)
This doc assumes you have followed the from Command Line dotCMS installation above
Be sure that the latest version of Gradle Buildship is being used. You can check the latest release according to your Eclipse version. This doc was based on a clean installation of the latest Eclipse Neon version and the latest Gradle Buildship release
3. Make sure Gradle Buildship is updated
Inside Eclipse go to Help → Install New Software
4. Add the Gradle Buildship update site if it has not been added yet (Check “Available Software Sites”)
5. Select File → Import
6. In the Gradle directory, choose “Gradle Project”
7. Specify the Project root directory where the dotCMS folder is located and click “Finish”
8. Right-click on the Project and select → Properties → Java Compiler → Errors/Warnings
9. Click on “Enable project specific settings” and verify that under the “Deprecated and restricted API” that the “Forbidden reference (access rules)” is set to Warning.
This doc assumes you have followed the from Command Line dotCMS installation
3. Click on “Import Project”
4. Select build.gradle file from dotCMS path
5. Specify any additional settings if you wish and click OK
6. Set a “Test Resource” path
Go to File → Project Structure → Modules → dotCMS → dotCMS_functionalTest and set src/functional-test/java folder as Test Source, as well as src/functional-test/resources as Test Resource. Then click Apply and OK.
7. Do the same with dotCMS_integrationTest module.
Logging into your dotCMS installation
In a browser, go to
the css will compile and the site should render
In another browser tab, go to
login with email@example.com / admin
Note: using 127.0.0.1 for front end traffic will allow you to login at localhost:8080/admin under a different session. You can also use your browser in incognito mode for the same effect.
New Gradle Tasks and Additional Information:
New gradle tasks:
The ant tasks that used to compile and generate a distribution version were replaced by their equivalent in lower camel case (see the table below). However, under the distribution version the deploy-plugins.sh and the undeploy-plugins.sh have not changed and need to continue to be used to deploy/undeploy plugins. If developing from source then only the commands listed below under “New Tasks” should be used.
|Previous Tasks (before dotCMS 3.7)||New Tasks|
|./gradlew deploy-war-tomcat||./gradlew deployWarTomcat|
|./gradlew deploy-war-tomcat-backup||./gradlew deployWarTomcatBackup|
|./gradlew deploy-war-tomcat-tests||./gradlew deployWarTomcatTests|
|./gradlew deploy-war-tomcat-dev||./gradlew deployWarTomcatDev|
|./gradlew create-dist||./gradlew createDist|
|./gradlew deploy-plugins||./gradlew deployPlugins|
|./gradlew undeploy-plugins||./gradlew undeployPlugins|
Pathing: the path previously used to run Gradle tasks (core) can not be used as of the dotCMS 3.7 version. Now, each task that runs with ./gradlew needs to be executed from core/dotCMS.
New location for dist files:
.tar.gz and .zip files can be found under the core/dist-output directory