The jahia-dev projects helps you to get all projects related to a specific build of DXM. This project contains references to the correct repository URLs and branches, and will checkout all modules packaged in the standard DXM distribution.
Use the following to get the project from the master branch :
git clone https://github.com/Jahia/jahia-dev.git jahia-dev
cd jahia-dev
./checkout-all.sh
Note that cloning DXM repository can be quite long.
Other scripts are available :
checkout-jahia.sh/.batwill only check out the core repositoriesupdate-all.sh/.batupdate all projectsupdate-jahia.sh/.batupdate only core repositories
To build the installer :
install.sh/.bat installer
Installer is generated in jahia-pack-root/package/jahia-installer-package/target/DigitalExperienceManager-*.jar
You can then launch simply using :
java -jar jahia-pack-root/package/jahia-installer-package/target/DigitalExperienceManager-*.jar
- Copy and customize the settings in
jahia-root/settings.example.xmlinto your Mavensettings.xmlfile. Also you might want to check the jahia-root/README file if you want to learn more about the deployment process. install.sh/.batdeploy.sh/.bat LIST_OF_PROFILES_TO_ACTIVATEmvn jahia:configure -P LIST_OF_PROFILES_TO_ACTIVATE
where LIST_OF_PROFILES_TO_ACTIVATE is something like : jahia-tomcat,jahia-mysql
Make sure that you modify the catalina startup file to include the following lines.
For Windows in the bin/catalina.bat file : set CATALINA_OPTS=%CATALINA_OPTS% -Dsun.io.useCanonCaches=false -Xms2048m -Xmx2048m -XX:MaxPermSize=312m -server -Dhibernate.jdbc.use_streams_for_binary=true -verbose:gc -XX:+HeapDumpOnOutOfMemoryError
For Unix/MacOS/Linux in the bin/catalina.sh file: CATALINA_OPTS="$CATALINA_OPTS -Xms1024m -Xmx1024m -Djava.awt.headless=true -XX:MaxPermSize=256m -server -Dhibernate.jdbc.use_streams_for_binary=true -verbose:gc -XX:+HeapDumpOnOutOfMemoryError"
When retrieving updates from remote repositories in order to update your local copies, you should always rebase your local changes instead of merging to avoid useless branch merging. You could do it explicitly by using either git pull --rebase or git fetch git rebase. Alternatively, if you want this done automatically for you, you can configure git to do so. See https://coderwall.com/p/tnoiug/rebase-by-default-when-doing-git-pull for more details.
jahia is the public repository for DXM Core.
jahia-pack is the public repository for core packaging project.
jahia-dev is the development environment project for community.
Even if you don't have write access to the repositories, you can still do a Pull Request to propose your patch. You need to create a fork of the repositories you want to change. Once your fork is created, you will use it to push your changes and create the Pull Request. Pull Request generic usage can be seen at : https://help.github.com/articles/using-pull-requests/
On https://github.com/Jahia/jahia (or another repository page), click on "Fork" button on the top-right. Jahia Employees can directly fork -private repositories instead of public mirrors.
Once you have forked the project, you clone it locally as you would normally do:
git clone git@github.com:username/jahia.git
This will create a jahia directory on your system.
Once you have forked and locally cloned the project, you need to tell git about the upstream version of your fork.
When you clone a repository locally, git records the remote repository from which the local copy was cloned so that it
knows where to fetch and push code. You can retrieve the list of remote repositories your local copy knows about by
performing git remote -v, which will list the name of known remotes as well as their associated fetch and push
URIs (usually, both the same). By default, the remote repository from which you cloned is named origin. So, in the
above example where you cloned your jahia fork, performing git remote -v will result in the following result:
origin git@github.com:username/jahia.git (fetch)
origin git@github.com:username/jahia.git (push)
Since your local repository is a clone of your fork, you need to be able to make sure it is up to date with the
latest version of the upstream repository. The way to do this is to tell git about another remote source of code: the
upstream repository. As you might have guessed, you do this by adding letting your local copy know about another
remote by performing git remote add <name of the remote> <uri of the remote>. With this setup, we recommend using
upstream as the remote name for the upstream remote repository, as follows:
git remote add upstream git@github.com:Jahia/jahia.git. git remote -v then produces the following result:
origin git@github.com:username/jahia.git (fetch)
origin git@github.com:username/jahia.git (push)
upstream git@github.com:Jahia/jahia.git (fetch)
upstream git@github.com:Jahia/jahia.git (push)
Alternatively, you could rename the upstream version origin and rename your fork fork by performing:
git remote rename origin fork;
git remote rename upstream origin
In the end, it doesn't matter how your remotes are called as long as you know which is which! Remember to perform these operations for each repository you fork and clone locally and for which you want to provide patches. You can read more about remotes and how to work with them at: https://help.github.com/articles/working-with-forks/
In the setup where you fork is called origin and the upstream repository is called upstream, the process to issue
a pull request to provide a patch is as follows:
- Create a branch for your fix, naming it after the JIRA ticket associated with the fix if possible, e.g.
git checkout -b QA-1234 - Add the necessary code (with tests if possible) and commit it to your branch
- Make sure your fork and branch is up to date with respect to the latest changes in the upstream version by pulling the latest changes from upstream into your branch:
git fetch upstream # fetch the latest version of the code from the upstream repository
git checkout master
git merge upstream/master # sync your fork's master with the upstream version (might want to push to origin to update
your fork afterwards)
git checkout QA-1234 # switch to your patch branch
git merge master # sync changes from master
- Fix any conflicts
- Once you're satisfied with your patch, push it to your remote fork:
git push origin QA-1234. This will create a newQA-1234branch in your remote repository (your fork). - Go to github and browse the upstream version of the repository you want to provide a patch for. It should detect that you pushed a new branch to your fork and offer you to create a pull request for that change.
You can learn about the process and philosophy behind collaborating via pull requests by reading: https://help.github.com/categories/collaborating-on-projects-using-issues-and-pull-requests/
