The "class file version" refers to the version of the JDK that was used to compile the class.

The crowd jar is compiled using Java 6 and Bamboo is compiling your code with Java 5, which then is incompatible with the crowd jar.
You need to configure the Bamboo build to use Java 6.

I am using Bamboo on Atlassian Plugin Studio. The build is fine on my local maschine, but on PlugIns Studio I get the following error message related to com.atlassian.crowd.embedded.api.User.

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
/mnt/bamboo-ebs/bamboo-agent/build-dir/JPRT-PACKAGE-JOB1/src/main/java/jira/plugin/projectroletab/ProjectRoleDetails.java:[5,-1] cannot access com.atlassian.crowd.embedded.api.User
bad class file: /mnt/bamboo-ebs/maven/.m2/repository/com/atlassian/crowd/embedded-crowd-api/2.3.4-m1/embedded-crowd-api-2.3.4-m1.jar(com/atlassian/crowd/embedded/api/User.class)
class file has wrong version 50.0, should be 49.0

See JPRT-PACKAGE-18 for JIRA 5.0-beta1 and JPRT-PACKAGE-18 for JIRA 5.0-beta2.

What's the problem?

Here is an example artifact in Maven - https://maven.atlassian.com/content/repositories/atlassian-public/com/atlassian/jira/plugins/jira-plugin-test-resources/4.4.1/

(Actually Cheryl, that is the old location.)

The "jira-plugin-test-resources" module is used by the Plugin SDK when it fires up the JIRA server that it will install your plugin into.
It consists of a zip file that contains a jira-home including an HSQL database with a JIRA instance already set up in it.

Now in the old days, it lived in a separate source tree to JIRA and was therefore released independantly.
For that reason, you sometimes needed to set a different jira.version and jira.data.version.

Because that was confusing, we have moved jira-plugin-test-resources inside the JIRA source tree (in jira-components/jira-plugins/jira-plugin-test-resources) to ensure it gets released side-by-side with JIRA proper. For this reason, the jira.version and jira.data.version should now always be the same value.

The test resources are supposedly part of the JIRA source tree now at
https://svn.atlassian.com/svn/public/atlassian/jira/plugins/jira-plugin-test-resources/trunk
(But I'm not actually involved with this, so I can't say for sure.)

Thanks, that's good info. I assume the jira-version is what appears in the jira-project/pom.xml file in the version element. Do you happen to know where the jira.data.version gets defined in the JIRA source tree?

Thanks Matt,

I should explain how we release EAP milestones.

During development of each new JIRA version we release an EAP milestone every 2 weeks.
(At the end of each of our fortnightly iterations).
You can see EAP releases notes here:
http://confluence.atlassian.com/display/JIRA/EAP+Releases

We refer to these as either an "EAP" release, or a "milestone" release, so "JIRA 5.0 EAP 4" and "5.0-m4" both mean the same thing.

You can download the latest EAP version of the JIRA server from the EAP Downloads page.
And similarly you can access the milestones of the maven modules for building and testing your plugin.

So the latest milestone is currently 5.0-m4, but we will release 5.0-m5 in a week and a bit.
Also note that as the release stabilises we switch the naming over to beta releases, and release candidates.
These are documented on the page Beta Releases.
When we release "beta 1" you will want to use "5.0-beta1", and for the release candidates the versions will look like "5.0-rc1", etc
Realise that there is no prescribed number of milestones, betas or RCs: they are released according to what is appropriate for the particular release.

As Mark noted elsewhere, the string to use for jira.version is 5.0-m4