Skip to content

Building and development

Jump to bottom
UrsZeidler edited this page May 31, 2015 · 13 revisions
  • [dependencies](Building and development#dependencies)
    • [building](Building and development#building)
  • [contributing](Building and development#contributing)
    • [providing examples](Building and development#providing-examples)
      • [providing model resources](Building and development#providing-model-resources)
    • [contributing code](Building and development#contributing-code)
      • [contributing plugins](Building and development#contributing-plugins)
    • [write documentation](Building and development#write-documentation)
  • [release cycle](Building and development#release-cycle)
  • [roadmap](Building and development#roadmap)
    • [short objectives](Building and development#short-objectives)
    • [long objectives](Building and development#long-objectives)
  • [api provider](Building and development#api-provider)
  • [localization](Building and development#localisation)

dependencies

The application is developed with eclipse http://eclipse.org/downloads/ currently in version 4.4 luna, I recommend the Eclipse Modeling Tools as it contains most stuff needed.

List of dependencies :

Check out the code with git, simplest to do so is with the eGit plugin in eclipse.

If you are not familiar working with git or egit : EGit-user-guide I would recommend cloning the repository.

After the initial import of the code you need to set up the target platform this provides you with the dependencies necessary to compile.

In build/targetplatform/ you will find the targetplatform for development. You simply open the file in the eclipse targetplatform editor. If you are not familiar with the target platform concept this vogella tutorial is a good overview.

After the target platform has collected all plugins you set it as the targetplatform, finally you will need to set an api base line, and all the compile issues should be solved.

building

The shr5 application is a eclipse product export, I use buckmister in combination with jenkins to create these platform dependent product exports.

The jenkins jobs can be found at build/jenkins , there are three jobs, one to create the target platform(emf-client-platform-git.xml), one to execute the tests(shr5-4.3-tests-git.xml) and one building the product(shr5-4.3-git.xml).

build-pipeline

You import the job via jenkins console. If have an other job pushing a release to github which uses the ant script to do so by calling the target create.release.

contributing

As a software product is a complex artifact of human culture it has very different requirements and so different thinks to do. An uncompleted list follows :

  • contributing code
  • providing examples
  • providing model resources
  • provide artwork
  • provide localization
  • write documentation
  • manage issues and milestones
  • open issues as bugs or features
  • take care of the community
  • spread the word
  • develop new use-cases

A collaboration platform github is, so some of the contributing requires a github account. Feel invited to participate.

another way to support is via bitcoin:

  • 12Fgh416ogMiJsYnXyeYqaEGyEQHcVFSsJ for main support like webspace and service
  • 1B9nJ2eXZJz1UKaVQTeMHriD1LBQsd4CvS for arts and graphics
  • 18BbgDaurToEu6sou5dmBzNUNWAhTH25Tg for localization and spell checking
  • 1JcJK1nLkAZkr4jid6N44L2bYQ7rxPSVYZ tip the coder

as we could use the bitcoin to pay some people to make the tedious spell checking jobs, pay webspace or services or pay for some artwork.

providing examples

To provide examples you simply need to export the resource, you can open an issue and add a link to an external resources like google drive, or send the file, we would prefer zipped, per email to [email protected].

providing model resources

The model resources can be handled in quite the same way, just export and send it to us. export-simple

See the export section for details.

contributing code

As this is one of the main features of github, the process is complete defined. Fork and merge. You don't even need to code, as we use EMF you could also simply extend the ecore models and generate the code. Still fork and merge.

When we integrate the update manager you could simply add your code in an other plugin.

contributing plugins

With the update manager in place you cloud provide an extension via plugin on your own. For acceleo transformations an extension point exist to register the transformation in the default dialog.

write documentation

Working with a tool can only be as good as the knowledge to use it, that makes the documentation to a vital part of a software product.

release cycle

After doing some releases, the following cycle seems reasonable, after 3 weeks we make a release candidate, giving the community one week to find the obvious flaws and bugs. Also bringing the documentation up to date. So we could provide every 4 weeks a new release.

This is a 4 week based cycle with one release candidate.

  • 3 weeks implementing new features
  • one week testing and fixing

In github we manage these via milestones.

roadmap

There are some short terms objectives, but also some more long terms. It is not bad to distinct them from another.

short objectives

The basic objectives are simply in one sentence : Provide a shr5 character editor to create characters conforming to the building rules which can be printed as sheet.

This implies the following :

  • a description of the elements building a character, this we call the model :
    • all the acquirable things
    • the different properties and kinds building a character
    • the rules for character creation
  • a set of editors to define the elements
  • a set of elements as described in the rule books

long objectives

As we have all the data from the characters we could provide game master aid as initiative/state tracking, management of players and none players. Building of scenarios and campaigns.

There are a lot of interesting technologies available around the eclipse platform.

api provider

The shr5rcp is based on plugins with a fine granularity, the different functionality are separated in several jars the structure is quite simple:

Each model has two plugins aka jars, a model jar and a itemprovider jar, see emf how to integrate the technology stack. You could add the model jars to a target platform they are provided by the update-site as separate feature.

For a model description see:

localisation

The localization of the software divided in three different parts

  • The resources, all source Quelle objects can store different names and pages. They can be attached via context menu on the object create-loc

A localization object is defined by it language code, the name and the page. create-loc1 See the Identifiable contract.

  • The application, there are some files where all the strings are stored in a simple name=value format. The model part uses the default resource bundle implementation.
  • The workbench and the eclipse stuff. These are managed by the babel project

To edit the properties files we use the http://essiembre.github.io/eclipse-rbe/ editor. update site

The project resources are located here :

de.urszeidler.shr5.model.edit/plugin.properties

de.urszeidler.shr5.model.edit/plugin_de.properties

de.urszeidler.shr5.management.model.edit/plugin.properties

de.urszeidler.shr5.management.model.edit/plugin.properties

While the gui and printer part uses the eclipse Message NL system Message Bundles

de.urszeidler.shr5.ecp/src/de/urszeidler/shr5/ecp/editor/pages/messages.properties

de.urszeidler.shr5.ecp/src/de/urszeidler/shr5/ecp/editor/pages/messages_de.properties

de.urszeidler.shr5.ecp/src/de/urszeidler/shr5/ecp/printer/messages.properties

de.urszeidler.shr5.ecp/src/de/urszeidler/shr5/ecp/printer/messages_de.properties

So if you want to have the application in your preferred language you need to address these three points, if you lucky the bable resources already exist in a good quality.

Currently german and english are supported.

Home

using:

runtime:

player:

development:

Clone this wiki locally