Note that this guideline was written for GoogleCode, it needs adjustments for github.

Table of Contents Requirements Eclipse Git Maven Desired results JUnit tests Directory structure (assembly) Inkscape extensions Publish deliverables API for dibl-tiles

A development environment requires a Git client and a Maven client, standalone and/or integrated in an IDE. Some subprojects require Java-6+, the inkscape sub project requires an installed Inkscape instance.

DiBL uses the integration manager workflow for version control, you can create your public clone here or somewhere else.

Eclipse is just one of the IDE's you can use.

Recommended plugin:

• ObjectAid to keep the class diagram up to date and use it for navigation.

The following scenarios are intended for Eclipse users new to Git and/or Maven.

• Right click in the "git repositories" view and paste the URL of your public clone
• It will show up as the "origin" repository
• Add the primary project with remote name "blessed" and URL http://code.google.com/p/dibl/
• You might want to add a password to the repositories
• The staging view is your friend to manage your commits.

Stay posted on changes in the project, fetch/pull/merge these changes from "blessed/master" before issuing a request to pull your changes back into the project.

The git scenario describes how to obtain a local folder `dibl` containing the folders `.git` and `src` and the files `.gitignore` and `pom.xml`. The dibl project should not yet be in the project explorer. If it got there as a side effect of another cloning scenario, you might have to remove from the project explorer it and import it properly:

• File menu - maven - existing maven project - browse to the local dibl folder
• Check the projects you are interested in
• Build the projects with the master build (its starts with the sub projects that create zip/tar.gz files to install) or build each project one by one. Anyway: right click an imported project - run as - maven build... - fill in the goals "clean install". Or use the command "`mvn clean install`".

The screenshot below shows the desired result.

Many test are not much more than smoke tests if just executed. Visually examine the diagrams produced in the target folders. If they are different from the template, look like a diagram and don't have internal loose ends, they are usually OK.

The directory structure of the subprojects look like but don't yet exactly match the suggested standard structure.

Note that some of the projects have a folder src/main/assembly. These folder have a dist.xml file that packages compilation results and the rest of the assembly folder in a zip respective a tar.gz. This xml file may put the version number of the pom file in some of the files. So far, the created packages are neither installers nor executables. So a wiki page and/or readme file in te package should explain installation and execution.

See http://wiki.inkscape.org/wiki/index.php/Script_extensions

You might not want to copy the .inx and .py files between the Inkscape extension folder (the execution environment) and the local git repository of DiBL (the IDE environment). In a unix/OS-X environment you can create links from inkscpae files to git files with the command

ln -s <git-file> <inkscape-file>

A change in a .inx file requires a restart of Inkscape, to test a change in a .py file, you can even keep the dialog open.

Suggestion for files related to a specific extension: repeat the extension name in the assembly/dist tree.

• remove -SNAPSHOT from the project version in the pom file
• build the project
• copy the zip / tar.gz to the git repository* of code.google.com/p/dibl.download/, move previous versions into the older-versions folder
• increase the version number in the pom file and restore the -SNAPSHOT suffix
• push the changes to the dibl and dibl.download repositories

*: Sadly both github and googlecode terminated their download facilities and the source forge download turned into an ad-trap

The API is the heart of the main class in the sub project dibl-tiles. It is also demonstrated with tests. The idea in short is:

new TemplateDoc(inputStream).replaceBoth(stitches, tuples).write(outputStream);

But you can also replace just the stitches, replacing just [InputFiles#Nodes_/_Tuples] is not implemented. A node in a diagram is only replaced if the resulting stitch/tuple combination exists as a label in the pile of stitches. This pile is more or less a stack of tiles as illustrated by the logo of the project.