Skip to end of metadata
Go to start of metadata

Keep this page up to-to-date


Some crucial notes on what new devs need to know about the project.
Let's keep the development documentation to the minimum and on this page only as much as possible.

Coding style

We use tab to indent because that's what it's meant for. No weird formatting rules, prefer concise over expanded and elaborated. We don't have a strict style guide so don't worry about it too much. Follow Tapestry coding style (not formatting!) where possible (for example don't expect null, don't check for null). Avoid unnecessary code like plague and refactor mercilessly. Do not auto-format (all lines of) existing code, do not use @author tags.


The code has been moved to Github. Similarly, we are in the process of moving CI builds from Codehaus' Bamboo to Travis-ci. Travis is far easier to set up than Bamboo. You just need to turn on the build at and commit the .travis.yml file with contents "language: java" to tell it that this is a Java build.


Tynamo site is a combination of Confluence and Maven originated content. Maven sites should be published to public_html/constant/sites/<module name> (note that permissions for /sites was set manually by Codehaus support so don't remove it). Unity, the front-end Codehaus site renderer, renders static content under /constant/ folder the same way as regularly for Confluence content.

Currently, the Maven site is published from an external CI system (controlled by kaosko) when changes happen, but not more often than every 24 hours (it's a Hudson system). It's difficult to automate the same with current Codehaus infrastructure because you cannot control credentials.
tynamo-parent is published to /constant/sites/. tapestry-model is published to /constant/sites/tapestry-model and other modules should follow the same convention.

CI & development snapshots

Since HAUS-1986 was resolved, we can deploy snapshots via http with the credentials already configured on Bamboo. However, some existing build may still deploy via file protocol to, if you see that's the case you can simply update the module to use a new version of our parent pom to upgrade to the new mechanism. You need to have Bamboo rights to create and modify jobs.

Release process

Since tynamo-parent 0.0.5 which is using the codehaus parent pom, the release process was changed from blind releases to staged releases. You need a PGP key to sign the release, see Apache's instructions for creating one. Release process follows the standard Apache/Maven release process (see instructions) except our releases are staged at

The usual issue to trip over is setting up your environment for providing PGP key & passphrase. The good news is that this is a one-time cost if you do it properly. Staging for us is mostly a final check before the release - if you are happy with the release, just go ahead and close and release from Nexus. If you are unsure about the contents, close the staging repo, then send the link to the dev list and ask others to verify. The usual Codehaus credentials work on Nexus.

Every individual module has to be releasable by running mvn -B release:prepare release:perform (although up to you if you run it in parts and/or without -B), otherwise the release configuration is wrong. If there are failures in the release process, they should be fixed immediately for the next release. Currently we keep archetype-catalog.xml at the root of the dav folder (to make it accessible via The archetype-catalog.xml file needs to be manually updated after the achetype module release (because of Versions of Tynamo dependencies in examples module also need to be manually updated.

Announcements need to be done manually as well. Github picks up and displays the tags, edit Github release notes for the particular tag to edit release notes manually. Once you've released the module, it takes around 24 hours before the released artifacts are synched to Central. Announcement should be done only after the release is available through Central. This gives us time to do final manual check-ups after the release. If any major issues are found after the release, we should simply abandon the release, leave it unannounced and push out a new release. You should always make the announcements in at least four places: on our home page (as a Confluence blog post),, and on Twitter (kaosko owns the twitter handle tynamo_org but you can use your own handle). Twitter announcements need to use the hashtag #tapestry5.

If the archetype GA coordinates changes or we publish other archetypes, we need to update the Maven archetype wiki page.

Branding and marketing

Any project, free-of-charge or not, needs to market their offerings. has a strong brand recognition within the Tapestry community but is practically non-existent in the wider web, even just among other Java developers. We simply need more back links to from a variety of content, not just from and Any of the confluence pages need to mention the following keywords at least once: Apache, Tapestry 5, Java and framework, and include one or more links to

  • No labels