Message-ID: <855061812.5373.1411410224829.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5372_1787597506.1411410224828" ------=_Part_5372_1787597506.1411410224828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
We use tab to indent because that's what it's meant for= . No weird formatting rules, prefer concise over expanded and elaborated. W= e 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 pla= gue and refactor mercilessly. Do not auto-format (all line= s of) existing code, do not use @author tags.
The code has been moved to Github. Similarly, we are in the process of m= oving 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 h= ttps://travis-ci.org/profile/tynamo and commit the .travis.yml file wit= h 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 n= ame> (note that permissions for /sites was set manually by Codehaus supp= ort so don't remove it). Unity, the front-end Codehaus site renderer, rende= rs static content under /constant/ folder the same way as regularly for Con= fluence content.
Currently, the Maven site is published from an external CI system (contr=
olled by kaosko) when changes happen, but not more often than every 24 hour=
s (it's a Hudson system). It's difficult to automate the same with current =
Codehaus infrastructure because you cannot control credentials.
tynam= o-parent is published to /constant/sites/. tapestry-model is published to /= constant/sites/tapestry-model and other modules should follow the same conv= ention.
Since HAUS-1986 was resolved, we can deploy snap= shots via http with the credentials already configured on Bamboo. However, = some existing build may still deploy via file protocol to ci.repository.cod= ehaus.org, if you see that's the case you can simply update the module to u= se a new version of our parent pom to upgrade to the new mechanism. You nee= d to have Bamboo rights to create and modify jobs.
Since tynamo-parent 0.0.5 which is using the codehaus parent pom, the re= lease process was changed from blind releases to staged releases. You need = a PGP key to sign the release, see Apache's instru= ctions for creating one. Release process follows the standard Apache/Ma= ven release process (see instruct= ions) except our releases are staged at nexus.codehaus.org.= p>
The usual issue to trip over is setting up your environment for providin= g PGP key & passphrase. The good news is that this is a one-time cost i= f you do it properly. Staging for us is mostly a final check before the rel= ease - if you are happy with the release, just go ahead and close and relea= se 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 Co= dehaus credentials work on Nexus.
Every individual module has to be releasable by running mvn -B relea= se: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 t= he next release. Currently we keep archetype-catalog.xml at the root of the= dav folder (to make it accessible via http://tynamo.org/= archetype-catalog.xml). The archetype-catalog.xml file needs to= be manually updated after the achetype module release (because of= http://jira.codehaus.org/browse/ARCHETYPE-242)= . Versions of Tynamo dependencies in examples module also need to be manual= ly updated.
Announcements need to be done manually as well. Release history should u= se the confluence JIRA component to show resolved issues in a given release= . We don't want to use the changelog plugin, especially for sending announc= ements mails because it takes around 24 hours before 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 shou= ld simply abandon the release, leave it unannounced and push out a new rele= ase. You should always make the announcements in at least four plac= es: on our home page (as a Confluence blog post),= email@example.com, firstname.lastname@example.org= dehaus.org and on Twitter (kaosko owns the tw= itter 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.
Any project, free-of-charge or not, needs to market their offerings. Tyn=
amo.org has a strong brand recognition within the Tapestry community but is=
practically non-existent in the wider web, even just among other Java deve=
lopers. We simply need more back links to Tynamo.org from a variety of cont=
ent, not just from tapestry.apache.org and stackoverflow.com. Any of the co=
nfluence pages need to mention the following keywords at least once: