Documentation for JIRA 6.3 EAP developer (EAP) releases only. Not using this? See below:
(JIRA 6.2.x documentation | JIRA OnDemand documentation | earlier versions of JIRA)

Skip to end of metadata
Go to start of metadata

This documentation is now on the Atlassian Developers wiki.

19 Comments

  1. Regarding the REST api changes:   I'm glad to see methods for manipulating role membership on Jira projects.   One thing I don't see, however, is the ability to query whether a given user has a given role on a specific project.   It would be very useful to find out if a user has a particular role membership without having to attempt to add or delete the user from the role.

  2. The JIRA 4.3 and 4.4 plugin dev notes are very useful and this page looks like it's going to be good too. To make the information easier to find, how about splitting this page into child pages before release time?

  3. Where can we find an example of a basic pom.xml with the new dependencies? In particular, are we now supposed to depend on jira-api instead of atlassian-jira?

    1. Where can we find an example of a basic pom.xml with the new dependencies?

      If you are creating a new plugin, you should still follow the instructions at http://confluence.atlassian.com/display/DEVNET/Setting+up+your+Plugin+Development+Environment
      and create a blank project with pom.xml using the atlas-create-jira-plugin command in the Atlassian Plugin SDK.

      If you have an existing plugin, then you should still be able to use your existing pom.xml.

      Either way, you will want to change the "jira.verson" setting to the required 5.0-milestone eg:

    2. In particular, are we now supposed to depend on jira-api instead of atlassian-jira?

      We would recommend that you try to move to jira-api.

      All the code that used to live in atlassian-jira is now split into two separate modules: jira-api and jira-core.
      If you depend on "atlassian-jira" you will get all the code from both, meaning you will get both API and implementation classes.

      If your plugin only depends on jira-api, then you can feel safe that it will continue to work when we release later versions.
      If you are using classes from jira-core, then these are considered implementation, and there is a risk that these can change without warning.

      Now, splitting the codebase into API and implementation is something that we started in v4.3, but we have only really done in earnest in v5.0, so no doubt there will be some "teething problems".
      If there are classes you are relying on that are not in the jira-api module, or you have any other questions or comments please let us know either here, or on the API feedback issue on JAC.

       

      See also: Java API Policy for JIRA 5.0 onwards

  4. Anonymous

    The link for See the Remote Issue Links development page for more details does not seem to point anywhere reasonable...

    1. Hi there,

      That content's now live.

      Cheers,

      Giles.

  5. The two images of the custom field type hierarchy refer to extranet links that are not public outside Atlassian.

    1. Those images have been fixed. 

      Thanks for letting us know,
      Brydie

      1. Thanks. Any chance of an key to what the colors mean in the old image. I see the red/green in the new.

        1. Removed relationships are marked in red, and new relationships are marked in green.

  6. Hi,

    Our plugin is depends on GreenHopper (LinkContext, LinkProvider). Do you have a version of GreenHopper availble that is compatible with JIRA 5.0? I have a "linkContext.getUser()" that does not compile since it returns the old osuser.

    Best regards,

    -Bjarni

    1. Hi Bjarni,

      Nicholas from the GreenHopper team here. Great to hear you are using the LinkProvider!

      Can you tell me which plugin you are working on, it would be good to have an idea of where the LinkProvider is being used.

      We don't plan to provide a tested and compatible build for JIRA 5.0 until after our release of GreenHopper 5.8 in October. In the interim you may wish to use this early build, please keep in mind that this is not tested or compatible. 

      Thanks Bjarni.

      Regards,
      Nicholas Muldoon 

      1. Hi Nicholas,

        I'm working on Tempo and your alpha build works just fine for compiling at least (smile)

        Thanks,

        -Bjarni

  7. Hi,

    I'm trying to use the new streams as is described here: http://confluence.atlassian.com/display/JIRA/How+to+add+activities+to+the+Third+Party+feed+(Java+API)

    The problem is that version "5.0" of the "streams" is not available in the repositories.  I did find "5.0-rc1" but then I get an exception at startup because of version mismatch. What shall I do?

    Thanks,

    -Bjarni

    1. In milestone 5 of JIRA 5.0 (5.0-m5) we are bundling the '5.0.rc1' version of Streams.   Until JIRA 5.0 final and the associated version of Streams 5.0 is released you will need to use 5.0.rcX versions of Streams.

      1. Hi Paul,

        I am trying to use the 5.0.rcX version of streams but then I get a version mismatch at startup.

        Here is a snippet from my pom.xml


        And here is what I add to my atlassian-plugin.xml

        ... everything compiles just fine but this is what I get at startup:

        Does this work for you or do I have to wait for JIRA 5.0-m5?

        Best regards,

        -Bjarni

        1. Hi Bjarni, this error is usually to do with the versions of package imports/exports in OSGi. Have a look at the META-INF/MANIFEST.MF in your plugin's jar, what version of com.atlassian.streams.thridparty.api is it attempting to import. The com.atlassian.streams.streams-thirdparty-plugin should be exporting that package at 5.0.0.rc1.

          (You can can also see this info from the OSGi tab in the Plugin's section in Admin.)

          If you are importing something incompatible with what is being exported, you may need to add a specific bundle import instruction to your pom.xml.