The JBossDTF wiki is pretty minimal right now. It's basically a repository for whatever DTF related stuff is floating though my head. As it grows it will no doubt take on a more sophisticated structure, such as having more than one page. The current info is useful mainly to developers of the project.  If you are looking for end user docs, please come back later as there are non yet.

The initial release to open source is done as of April 14th 2008. The next task is to stabilize the code far enough that is can be used to run tests for the JBossTS 4.4.CR1 release. Once that's done (~2wks) we can tag a release (what version number to start from?) and then start thinking about doing more radical changes.

Roadmap:

We don't have any in-house developer time dedicated to this right now, but the wish list as and when we have time to work on it looks something like this:

• better docs and out of box experience so new users/contributors find life easier.

• replace JavaRMI with something else (JBoss Remoting?) or at least make its use more robust. One connection per method call rapidly uses up sockets. No backoff/retry on remote calls causes problems. In short, it's the bane of my life and I want it gone

• re-architect component model to use JBoss Microcontainer

• Hibernate for db abstraction. Seam for web interface?

• secure the web interface to the point where we can make our in-house instances publicly visible so the community can see the results of test runs for JBoss projects e.g. JBossTS.

• ability to configure large batches of testdefs and testselections. The 'one at a time' web interface is too limiting for large installations. This is closely related to the use of db sequence based id numbers as identifiers, which is a pain.

• Amazon EC2 plugin to allow test nodes to be provisioned dynamically in the cloud. (Well we need some sexy fun stuff on the list!)

Code repository structure

• trunk is the main development line. In general it is not stable except as we approach a release milestone.

• each release results in a tag under /tags/  generally DTF_a_b_c_XX[Y|y] where a, b and c are numbers and XX is one of BETA, CR (candidate release), GA (general availability i.e. a stable release) or SP (service pack, i.e. a minor patch to a GA). BETA, CR and SP releases should be followed by a number to indicate ordering. The astute reader will observe that this causes lexicographic ordering of tags to be equivalent to date ordering for most cases. examples: DTF_1_2_3_BETA4, DTF_2_4_2_GA. Once created, tags should never be altered.

• releases that need maintaining over a longer term get a branch under /branches/, created from their release tag (usually a GA) and with the same name as the tag minus any trailing version number. This branch may be further tagged to create later maintenance releases e.g. trunk -> tags/DTF1_0_0_GA -> branches/DTF_1_0_0_GA -> FixesMadeOnBranch -> tags/DTF_1_0_0_SP1 or perhaps tags/DTF_1_0_1_GA if the changes are larger.

• /workspace/ provides a scratch area for experimental work too radical for even the trunk. Developers should create a dir with a suitable name under this and copy the code into it. Directories in this hierarchy that are named with a developer's id can be used as they see fit and should not be written by other developers. examples /workspace/jboss_remoting_integration, /workspace/jhalliday/

• checkins to trunk or the maintenance branches should include in the commit message the JIRA id of the task they relate to. If that means creating a new JIRA task for the purpose then so be it. The full JIRA url is fine too.  examples: DTF-123, http://jira.jboss.com/jira/browse/DTF-456  This is done because the fisheye JIRA plugin uses the JIRA id from the commit message to associate the code changes to the tasks in the JIRA web interface, which is very handy.

About the code

• Code is Java 1.5 or later. There are no other coding standards right now. Put the brackets wherever the heck you like

• The build system is ant. You need to download this separately.

• We use mysql (5.0) and tomcat (6.0), which you also need to download separately.

• Other 3rd party dependency libraries are in /lib/  Remember to update the /lib/README.txt with version info, homepage of the project and license info if you add things or change versions.

• Our code is released under LGPL 2.1.  Make sure new files have an appropriate copyright/license header by copying it from an existing file.

• We use the org.jboss.dtf. package space. This includes for java source and e.g. configuration property names etc.