Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

Activiti Developers Guide

Table of Contents

Building a distribution from the source

Dependencies

JDK 6+ : Make sure that you do not use code constructs that require JDK 7 or higher.
Maven 3.0.4
Ant 1.8.1

Source Code

http://github.com/Activiti/Activiti

Building the distribution

  1. Check out the latest version from Github (more details see http://github.com/Activiti/Activiti)
  2. Go into the distro subfolder and run the following ant command: 'ant clean distro'
  3. The distribution can now be found in the target folder.

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.

Coding style

  • 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

Commits

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.

Code Block
mvn -Pcheck clean install

In the commit message, start with the jira issue, a space and then the commit text like in this example

Code Block
ACT-826 Fixed all problems in the world

Running the test suite using Spring configuration

Use

Code Block
mvn -Pcheckspring clean install

to run the test suite on spring configuration only or

Code Block
mvn -Pcheck,checkspring clean install

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 

Code Block
mvn -Pcheckspring clean test

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.

QA

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

GIT pointers

Typical initial setup:

No Format
$ git config --global user.name "My Name"
$ git config --global user.email my.email@my.address.com
$ git config --global core.autocrlf input
# All the --global above can be set locally if you prefer
$ git clone ssh://git@git.codehaus.org/activiti-git.git activiti
$ cd activiti
$ git branch -a
... (list of branches)

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 gitkor 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

No Format
# create a new local branch to work from
$ git checkout -b feature/my-new-idea

# edit source code...
$ git status
... (list of changes)

# add all your changes to local index (N.B. -A might not always be appropriate)
$ git add -A .

# commit locally
$ git commit -m "My nice changes"

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

No Format
# if it is new:
$ git push origin feature/my-new-idea

# if you already shared it
$ git push

To checkout someone else's remote branch for collaboration:

No Format
# Make sure you have all the remote changes
$ git fetch

# Or just make sure the branch is there
$ git branch -a
...

# Checkout the branch
$ git checkout origin/feature/my-new-idea

When you are ready to merge with the remote master (dev trunk):

No Format
# get changes from remote repository
$ git fetch

# merge changes onto master (= dev trunk for everyone else)
$ git checkout master
$ git merge origin/master

# merge master onto your features (assuming you are ready to try and push it
# up to the remote repository)
$ git merge feature/my-new-idea

# push changes up to remote repository and move back to local branch to
# continue work
$ git push
$ git checkout feature/my-new-feature

# optionally rebase to keep history clean
$ git rebase master

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).