Message-ID: <1330569055.36495.1408818175182.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_36494_2103225525.1408818175182" ------=_Part_36494_2103225525.1408818175182 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
JDK 6+ : Make sure that you do not use code constructs that require JDK =
7 or higher.
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.
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 c= ommit text like in this example
to run the test suite on spring configuration only or
to combine running the engine testsui= te on an Activiti config as well as on a Spring config
If you run the checkspring profile, t= he spring module will copy the engine tests over to the spring module befor= e compiling and running the tests. Those tests are deleted in the 'pa= ckage' build phase
If you need to debug spring configura= tion test cases, just execute a
in the activiti-spring module, then r= efresh your IDE and the classes and spring configuration will be in your ac= tiviti-spring project ready to be debugged.
In some situations, it might be practical to check in while some tests a= re still failing. In that situation, make sure that the tests are exc= luded 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. &nb= sp;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 test= ing.
More about the QA and CI infrastructure can be found here: QA and CI Guide
Typical initial setup:
There are plenty of online resources =
for git. A good one is [<=
g/book]. IntelliJ has good IDE support. Eclipse has some very active develo=
pment in [EGit|http://www.eclipse.org/egit/], but only =
basic features currently (things are moving very fast). Most people find&nb=
code>gitx (Mac only) =
very useful for visualization (launch with
for best results).
As a rule with GIT you do not make ch= anges directly to remote branches, but rather you create your own local bra= nch 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 ind=
ividual changes look at
To checkout someone else's remote bra= nch for collaboration:
When you are ready to merge with the = remote master (dev trunk):
There are many combinations of comman= ds that achieve the same end result as that last sequence. Your preferred w= orkflow might be different, and of course any time there are conflicts it w= ill have to change (GIT is quite good at telling you what it thinks is wron= g in a conflict).