Atlassian Confluence blogs atWikiConsulting.com

The City to Surf race in August 2008 was awesome.

The Race

We ran in a moving crowd of 70,000 people through 14 kilometres, witnessing many strange and hilarious costumes. Almost all finished the race in under two hours.

Our Donation

As a team, we donated money to the Shepherd Centre, a charity that helps kids with cochlear implants. Together we donated $974, and Atlassian matched our donations, creating a total donation of $1,948.

Beer

After we finished, we retired to the Lowenbrau in the Rocks for some rehydrating alcohol. While there, we were corralled by an avid customer (he spied our coordinated Atlassian t-shirts). He rushed up to us, saying "You guys are Atlassians, right? Right on! We just upgraded to Confluence 2.8 and it ROCKS!"

Right on, indeed. Here's looking forward to next year!

Photos

TEXT FOR NON-COMPATIBLE BROWSERS HERE

Videos

Disclaimer: Do not watch these videos if you suffer from any form of motion sickness, or react badly to KFC's 'Hot & Spicy' chicken. They are shot by hand, with no 'stabilization" and watching them will likely result in temporary vision damage. Thanks for reading!

Overtaking a Chicken

Rock Band Rocking the Runners

Baffling 'Horse-People of the Apocalypse'

Frat-Boy 'Smurfs'

Powering up Heartbreak Hill

Random Bikini Dudes

Surreal Brass Band Performance

Crossing the Finish

• Comments Off

If you are anything like us with your development processes, then you would probably track all your development work - be they bugs, improvements, or features - in an issue tracker like JIRA. You would also use a CI tool too, like Bamboo, to run builds constantly to make sure that your code base remains in good health - at least most of the time. What we wanted is a nice way to bring our issues and builds together so we have one consolidated view of issues, and builds. This is where Bamboo 2.1 and JIRA comes in.

When you commit your source code, you might typically add in the JIRA issue you are working on into the commit message. Bamboo picks this up, and recognizes that it's a JIRA issue. You can do the link up yourself too, either by commenting on a build in Bamboo, labelling it, or making the link directly. Fear not if you make a mistake, just remove the link and add a new one. This attaches your builds to the issue. In your JIRA issues page, you now get an issue tab showing me the builds that ran for the issue. Artifacts produced by the build are handily available to download, direct from JIRA. You can also view your builds on the version level, and project level too.

One of the issues that we have sometimes faced is figuring out, during the development of a version, when an issue is fixed. In JIRA, an issue may be marked as "fixed" against version X, but while that version X isn't released, it is difficult to find out in which build it actually is fixed. Now with the click of a button, you can get around this by promoting a build linked to an issue as a "fixed" build. It is an easy to track down to the exact build an issue is fixed in.

For most sizable projects in JIRA, you would probably have set up multiple plans to run different builds. Confluence, for example, has plans set up to run unit tests on JDK1.4 or functional tests using Tomcat, to name a few. With the project builds tab panel, you can now get the latest status for all your plans for your project. A plan is determined to be part of the JIRA project, if a build in the plan is related to an issue in the project. This idea is extended further to each version. In the version builds tab panel, you can see how your builds are going for a particular version, based on the fix-for version of the issues your builds are relate to. But what happens when the version is released? Any builds that happen on your plans are no longer affecting the released version. In this case, the version builds tab panel finds the release date, and shows the latest status (snapshot) of each of the affected plans before the release date.

Have you ever wondered which JIRA issues your team is currently working on? In JIRA, you can always use the issue navigator to find the list of issues sorted by last update date. But this doesn't necessarily tell you those issues under active development. Using the issues tab under a plan summary in Bamboo, you can now find out, sorted by date, those issues that you've worked on recently, filtered down by the handy date filters in Bamboo.

For managing release, you can also check out the new JIRA versions release management plugin, developed by Jonathan Djokovic. The plugin uses JIRA's versions to help you automate your release process.

You can start using all these features today, with Bamboo 2.1. Learn more here.

• Comments Off

While the Atlassian User Groups have been popping up all around the globe, here at Atlassian Headquarters in Sydney we have yet to host an AUG. That is until now.

In a little over a month, in time for a much awaited southern hemisphere springtime, Atlassian's Sydney offices will host the inaugural Sydney Atlassian User Group meeting.

The event is open to all users of Atlassian products, interested parties and partners.

Being on home turf, this is sure to be well attended and we want to make it something special. If you're in Sydney or able to get to Sydney in September put the AUG meeting in your diary.

The programme is sketched out on the event page and includes talks by Atlassian CEOs Mike Cannon-Brookes and Scott Farquhar and real customers talking about their experiences with different products.

If you're interested in participating or have some ideas or perhaps something to present in one of the birds-of-a-feather sessions, get in touch.

Links to further details and RSVP are on the Sydney Atlassian User Group event page.

• Comments Off

Confluence third-party developers are likely to start running into mentions of "Plugins 2.0" in existing code and in future milestone releases. As such, I thought it might be a good idea to give you a quick heads-up on what is happening in Atlassian HQ, and how this is going to affect plugin authors.

The short version:

1. We are moving to an OSGi-based plugin system.
2. You don't have to know OSGi to write a plugin, and
3. existing plugins will continue to work fine, but
4. if you want to leverage OSGi, you can.

Why OSGi?

Since the days of Confluence 1.0, we've been building our own plugin system alongside Confluence, imaginatively named "atlassian-plugins". This library started off as a way to add new macros to Confluence's wiki markup, but developers quickly demanded more, so the plugins system grew to cover more of Confluence's APIs, load their own dependencies, and support dynamic loading and unloading of modules.

There are a number of plugin feature requests outstanding, though:

• more robust Spring component plugins
• the ability for plugins to depend on each other
• control over plugin load order
• the ability for plugins to define their own extension points
• more consistent plugin APIs between products

Any one of these would require a significant rewrite of the existing plugin system. Luckily, the Java community has already done a lot of the work for us in the form of OSGi.

OSGi is the de facto standard for Java component/plugin systems. It provides APIs for deploying plugins, managing their lifecycles and dependencies, and keeping plugins isolated from each other. It's widely deployed and robustly tested: any Java developer who uses the Eclipse IDE is already using OSGi every day.

Backwards Compatibility

OSGi is very different to the existing plugins system, so we wanted to ensure that developers could continue to write Confluence plugins without having to learn OSGi. Converting an existing plugin into a "2.0 plugin" will involve making one small change to the atlassian-plugins.xml file, and Confluence will do the hard work of generating the OSGi manifest for you.

Some plugin types may behave differently in the 2.0 container. For example, component plugins currently add their beans to Confluence's main Spring context, in 2.0 they will be deployed in separate contexts using Spring Dynamic Modules. We will try, however, to keep things as consistent as possible.

Plugins that don't have the 2.0 flag set will continue to be loaded by the old plugin loader, and work the same way they always have. I suspect some time in the reasonably distant future we will drop support for "1.0 plugins", but that's not even on any roadmap for now. It is likely, however, that future improvements to the plugin system will be 2.0-only.

Roadmap

The current, tentative plan is that the next major release of Confluence (late 2008) will have experimental support for Plugins 2.0. It will be available, and we may be making use of it internally, but third party developers will have to remember that it is a brand new system, largely untested in the wild, that may change radically over the course of the release.

That said, if you enjoy living on the bleeding edge we will looking for feedback from implementors, especially regarding which Confluence packages and components we make available to plugins. Look for the feature in Confluence 2.10 milestone releases.

By early 2009, we should have everything bedded down properly and Plugins 2.0 will be the New Way of Doing Things.

Documentation

Right now, there isn't any. Which is fine because you wouldn't be able to do anything with it now anyway. Don and Sarah are slaving over a hot wiki so that by the time you can take advantage of the new plugin system, it will be nicely documented for you.

JSR-277

JSR-277 is the Java Community Specification Request for dynamic modules. There is a significant overlap between JSR-277 and OSGi, but it's not clear yet whether this will be one of those situations where the de facto and de jure standards converge (like Hibernate and JPA), or stay messily separate (like log4j and the Java Logging API). Regardless, since JSR-277 is going to be included in Java 7 at the earliest and Confluence has only just been able to embrace Java 5, we have some time before this becomes an issue for us.

• Comments Off

Today's an auspicious day for Confluence fans - Confluence 2.9 is out in the wild, with a gaggle of new features, 140 resolved issues and two wickedly cool plug-ins: the Office Connector, which lets users edit Confluence pages with Microsoft Office and OpenOffice clients (free for all customers), and the SharePoint Connector, which allows SharePoint and Confluence to share content and generally get cozy with each other (available as a for pay add-on).

New in 2.9

Confluence 2.9 has a few important and targeted improvements:

• Improved search: we've simplified the Search screen to make it easier to find what you're looking for, and Confluence by default now searches across all spaces and object types (pages, news items, comments and more). Filtering results - by Space, object type, date or contributor - is a piece of cake.
• Beautiful charts: we've radically refreshed the charting engine and the new charts generated by the Chart macro are simply gorgeous. Lots of formats and chart types are supported, and your friends will now ask if you're a graphic designer in addition to a financial wizard.
• Auto save: small but important enhancement to display a time stamp of the last saved draft right by the save button. No more wondering.
• Build a Gallery: the improved Gallery macro helps you display a pictures sets visually on a page. Easy to use, and comes with a fancy lightbox to view individual photos.
• Updated Demonstration Space: we added a ton of spit-and-polish to the demonstration space bundled within Confluence. The space includes simple, straightforward demonstrations of Confluence's capabilities and an easy to follow tutorial for newbies.
• 140 end user driven fixes and improvements: the dev team has been busy. There's a complete list of all the other goodies here.

Introducing the Office Connector

Along with Confluence 2.9, today we announced the Office Connector, a completely sweet piece of integration magic. The Office Connector brings Confluence to the masses, and lets anyone participate in creating and editing Confluence pages just using Microsoft Word (or OpenOffice). It does some pretty slick things with Excel and PowerPoint too. In fact, ever heard of SlideShare? We'll you could create SlideShare for your company using Confluence and the Office Connector. The technology for the Office Connector comes from Benryan Software, a plugin developer that Atlassian acquired in July, 2008.

Here's a video of the Office Connector in action:

SharePoint Connector goes into Production

And finally, we're pleased to announce the official release of the SharePoint Connector. This connector basically allows Confluence to search across SharePoint TeamSites, and embed content from SharePoint TeamSites into Confluence pages. And conversely, the Connector includes two Confluence-specific WebParts that allows SharePoint to embed Confluence content into TeamSites. One WebPart displays a navigation tree view of a specific Confluence space, and the other displays specific content from a Confluence page (a chart, an image, a section, some text, you name it), or just the entire page. Check it out at http://www.atlassian.com/sharepoint.

Here's a video of the SharePoint Connector in action:

More to come

These plug-ins complement the growing and powerful catalog of extensions to Confluence, made by some of the coolest new companies in the business, like Gliffy, Balsamic, Theme Builder, Approvals workflow Be sure to check those out as well.

Believe it or not, Confluence 3.0 is going to be even hotter. Stay tuned...

• Comments Off

Mark your calendar and please join us on August 26, 2008 when we have a conversation with plugin developer, Dan Hardiker of Adaptavist.

Having committed over 25 free plugins*, Dan is one of the most prolific plugin developers in the Atlassian community. In this live webinar, Dan will discuss and demonstrate some of his favorite plugins, including Statistical Analysis, Advanced Search, User Security Management, and Form Mail. And we'll try to do all that in under 30 minutes... wish us luck!

By way of introduction, we asked Dan 5 questions:

I like to code in ______

Whatever cracks the nut without requiring a pneumatic drill. Java primarily but Javascript, Python, PHP, Ruby all have their uses!

JSR-666 is ______

Simultaneously cool and scary. I suspect it's the mark of the beast, or at least the label on Charles' undergarments.

When I'm not coding I'm _____

Thinking about what I have coded, what I'm going to code and finishing off my plans for a cloning machine / time bubble creation theory.

I also keep up with my passions for producing & mixing dance music and psychology.

My favourite t-shirt is _____

The 'sudo' shirt available from xkcd. If only they did a 'bobby tables' one.

My advice for other plugin developers is _____

4 things:

1. Nothing is impossible, but some things just aren't worth the effort.
2. Try to understand what lies beneath - get to know the APIs and what they do.
3. Keep it a simple as you can to achieve the effect you want.
4. The obvious / fastest / easiest way isn't always the best way.

Meet Dan on Tuesday August 29, discover some cool Confluence plugins you may not have heard about, and learn about developing your own plugins.

---

* And assisted with many others, and wrote the original Plugin Repository for Confluence, and... well, his accomplishments are many!

• Comments Off

Enterprise wikis and Internet wikis (of which Wikipedia and Wikitravel are examples) provide the same basic function - the ability to edit content in a web browser - but they differ in several significant ways:

1. Spaces

Internet wikis often have all content housed in one "place," so that any user can see the entirety of the site's content all together. Enterprise wikis allow for information to be organized in spaces (individual wikis that are part of the enterprise wiki) based on project, department, team, etc., and access to those spaces can be granted to specific users.

2. Security

Internet wikis are often open for anyone to read and edit, sometimes without even requiring one to login. Enterprise wikis are typically not open to the public or partially open, i.e. some spaces are open but others are not. To access an enterprise wiki, you have to login, and your account has to have permissions set so that you can access particular spaces. Permissions can also be set at the page level, so that a person might login, access a particular space, and have editing rights on some pages, but only viewing rights on others.

3. Integration

Enterprise wikis are designed to allow user account, group, and access information to be provisioned from authentication and authorization systems like LDAP and Active Directory, so that a person can login to the enterprise wiki with the same credentials that they use to access email, the company network, etc.

4. Typical Uses

Enterprise wikis are often used for:

• collaboratively building documentation
• creating and maintaining knowledge bases
• project management
• gathering tacit knowledge (knowledge not related to any specific project but essential to getting things done in an organization)
• meeting management, from agenda to minutes and action items.

Generally, an enterprise wiki will be used in a much wider variety of ways than an Internet wiki, because it is intended to support the wide-ranging needs of the people within an organization. Internet wikis tend to be used primarily for one main application, as is the case with Wikipedia.

5. Contribution Level

On public wikis, we often speak of the 90-9-1 Theory, which explains that 90% of users will "lurk" or simply browse pages, 9% will contribute occasionally, and 1% will contribute frequently, and account for most of the contributions to the wiki.

On an enterprise wiki, the contribution level is much higher based on the fact that people are contributing as part of the daily course of their work, as opposed to voluntarily contributing to a public, Internet wiki. This contribution isn't necessarily compulsory, as a top-down mandate will usually hinder more than help wiki adoption. Instead, it's the result of well-executed wiki adoption strategies that place the wiki at the center of the core activities of a team, such as meeting management, building a support knowledge base, or collaboratively writing documentation for a product.

• Comments Off

At OSCON a couple weeks ago, I started a conversation with one attendee about continuous integration. It was a practice he wasn't that familiar with. He knew the names of some open source CI servers, but hadn't heard of Bamboo, our CI build server. Another guy at the table overheard the conversation and said, "Isn't Bamboo the one that offers build telemetry?"

He also asked about how Bamboo integrates with our other products. "Integration is not an easy thing, it's harder than everyone thinks," he said. (I may be mangling the precise wording, but it's not too far off!)

Well today we're launching Bamboo 2.1 and are happy to announce that this release tightens up the integration with JIRA, making at least one of our customers happier. :)

The integration makes it easy to get an update on the status of each project. Are your projects going to be on schedule or held up? What issues are causing the most problems? Which issues have been resolved most easily? These are the types of questions that Bamboo 2.1 + JIRA help solve.

For example, when you integrate JIRA with Bamboo 2.1...

• Bamboo will still automatically link an issue to your build when you specify it in your commit message, but it will now also pick up related JIRA issue keys that have been included in build comments and labels.
• You can flag when a particular JIRA issue is fixed in a project version and make the build artifacts available (and downloadable) right from the JIRA issue.
• Real-time tracking of the builds for a project or version has been included in this release of Bamboo.
• Get a detailed view of which issues are linked to completed builds and which issues were worked on recently.

---

For full detail on 2.1, refer to the release notes.

Or, you can download an evaluation copy, get pricing, and read about Bamboo features.

Got questions? Don't hesitate to ask.

• Comments Off

At Agile 2008, Atlassian partner, Pyxis Technologies will be demoing GreenHopper, GreenPepper, JIRA and Confluence. The new release of GreenHopper 3.0 has many new and improved features including "Quick Card Creation". Stop by booth 824 for a demo.

On Wednesday, Pyxis will sponsor a Texas Hold'em poker tournament! If you are lucky, you might win a prize from Atlassian.

Also, be sure to check out VersionOne's integration with JIRA.

• Comments Off

A few days ago, we rolled out a significant update to our hosted development tool, JIRA Studio.

First, we've upgrade JIRA Studio to Confluence 2.8. Laura posted all the details about 2.8 earlier, but in brief, Confluence 2.8 features an updated user interface focused on making our Wiki easier to use (and look at), better searching, and more, for a total of over 90 improvements. Check out Laura's Post for more details on Confluence 2.8.

Speaking of search, this update to JIRA Studio includes Studio-wide searching. The search box found on every page now allows you to search across Issues, Wiki pages, Reviews, and Code. And you can filter the results based on Project. Have a look:

Performance was another focus of this update, and you'll see big improvements in the Source and Review tabs.

Finally, we now allow certain 3rd party plugins to be installed into your JIRA Studio Instance. Currently we support Gliffy and EditGrid for Confluence. EditGrid and Gliffy licenses are, as they say, sold separately. Check out the JIRA Studio Plugin Policy for complete details.

• Comments Off