Activiti Developers Guide
- Activiti Developers Guide
- Building a distribution from the source
- Demo setup
Building a distribution from the source
JDK 6+ : Make sure that you do not use code constructs that require JDK 7 or higher.
Building the distribution
- Check out the latest version from Github (more details see http://github.com/Activiti/Activiti)
- Go into the distro subfolder and run the following ant command: 'ant clean distro'
- The distribution can now be found in the target folder.
Setup scripts in the distro
After an distribution is unzipped (or directly in the distro/target/activiti-version directory), a number of scripts are offered to our users as well. Those scripts can be found in [activiti.home]/setup/build.xml and can optionally use settings from [user.home]/.activiti/build.properties
As an example, here's the content of my [user.home]/.activiti/build.properties:
activiti.home, is used in the setup/build.xml. It will work straight from the sources. So you can add the setup from the sources to your ant view in your IDE.
downloads.dir, is used in the setup/build.xml. It allows you to configure a custom location for your directory to download/find tomcat. If you don't specify this, the default is relative to the setup directory (../downloads). So if you use the setup/build from the sources, you might end up downloading tomcat into your sources. If that still would happen, don't check it in!
tomcat.enable.debug is used in setup/build.xml when Tomcat is installed. If the property is specified (whatever value), the parameter 'jpda' will be added to the start commands in Tomcat's 'startup.sh' and 'startup.bat' scripts. That will cause the remote debugging service to listen on port 8000.
skip.deploy.activiti.modeler=true set this property if the Activiti Modeler fetching from net and deployment must be skipped.
Unless before a release or explicitly working on the Activiti Modeler, it's advised to set this property since sometimes a version matching the current trunk version isn't uploaded yet, causing the demo setup to fail.
mvn.executable=mvn.bat on windows you have to set this property to make the calls from the ant build scripts (distro/build.xml and qa/build.xml) to maven work.
activiti.modeler.download.url: To work with Activiti Modeler or Activiti Cycle on trunk, set the property activiti.modeler.download.url in your [user.home]/.activiti/build.properties to, e.g., http://activiti.org/downloads/activiti-modeler-5.0.beta1.war if you want to use a previous release or something like file:///home/falko/svn/activiti-modeler/dist/activiti-modeler.war if you want to use an own build of the Activiti Modeler.
linux.browser=echo: Set this poperty to echo to prevent the browser from being opened. You also use a different browser than Firefox through this property.
[user.home]/.activiti/tomcat-users.xml To enable the automatic redeployment targets in qa/build.xml, put a tomcat-users.xml in your [user.home]/.activiti directory with the following content:
Eclipse IDE Setup
In order to have BPMN code completion and validation, import BPMN's XML Schemas from activiti-engine/src/main/resources/org/activiti/impl/bpmn/parser into the Eclipse XML Catalog, which can be found in Preferences --> XML --> XMLCatalog.
- In the eclipse directory of the root activiti source directory are some files that should be imported as eclipse preferences. The filenames indicate the dialog that can be used to import them. Those eclipse files indicate the general coding style guidelines.** indents are 2 spaces (no tabs)** sun style braces formatting
- By default, our member field access should be set to protected
As much as possible try to group all related changes into single commits.
Before committing, run the following check to see if all is OK.
In the commit message, start with the jira issue, a space and then the commit text like in this example
Running the test suite using Spring configuration
to run the test suite on spring configuration only or
to combine running the engine testsuite on an Activiti config as well as on a Spring config
If you run the checkspring profile, the spring module will copy the engine tests over to the spring module before compiling and running the tests. Those tests are deleted in the 'package' build phase
If you need to debug spring configuration test cases, just execute a
in the activiti-spring module, then refresh your IDE and the classes and spring configuration will be in your activiti-spring project ready to be debugged.
Checkin when test is failing
In some situations, it might be practical to check in while some tests are still failing. In that situation, make sure that the tests are excluded in the modules pom.xml and that you have created a JIRA issue for it. Reference the jira issue from the pom next to the excluded test. And reference to the pom in the jira issue.
Build file qa/build.xml contains a number of targets for driving the QA. It also contains convenience targets for developers to do integration testing.
More about the QA and CI infrastructure can be found here: QA and CI Guide
To run smoke tests on webapps, the quickest way to get started is using the target test.demo.setup in qa/build.xml
That will also startup h2 and tomcat. So to rebuild, you can use the target test.demo.setup.refresh That target will first shutdown tomcat and h2 and then do a full new demo test setup.
Building the javadocs
Use target build.javadocs in qa/build.xml
Debugging ant task
Typical initial setup:
There are plenty of online resources for git. A good one is [Pro Git|http://progit.org/book]. IntelliJ has good IDE support. Eclipse has some very active development in [EGit|http://www.eclipse.org/egit/], but only basic features currently (things are moving very fast). Most people find
gitx (Mac only) very useful for visualization (launch with
--all for best results).
As a rule with GIT you do not make changes directly to remote branches, but rather you create your own local branch and merge changes from there to the remote branch (via a local mirror). Typical workflow
Keep doing that until you are happy. If you want to tidy up your commits and send them as a batch instead of individual changes look at
git rebase -i .... Now you are ready to share your work. If you want to stay on a branch and collaborate with someone, push up your branch
To checkout someone else's remote branch for collaboration:
When you are ready to merge with the remote master (dev trunk):
There are many combinations of commands that achieve the same end result as that last sequence. Your preferred workflow might be different, and of course any time there are conflicts it will have to change (GIT is quite good at telling you what it thinks is wrong in a conflict).