How do you write a JIRA plugin that works across 4.2, 4.3 and 4.4? How can you find the metadata for the JIRA issue creation form? How can you create the issue itself, and attach the screenshot? And how is this going to change in JIRA 5.0 and beyond? This talk will cover all this, and more!
4. Agenda
• What is Bonfire?
3
Saturday, 1 October 2011
5. Agenda
• What is Bonfire?
• Building plugins for
multiple JIRA
versions
3
Saturday, 1 October 2011
6. Agenda
• What is Bonfire?
• Building plugins for
multiple JIRA
versions
• JIRA integration in
Bonfire - problems
and solutions
3
Saturday, 1 October 2011
15. Building multiple JIRA version
supported plugins"
• Why?
• Problem points?
7
Saturday, 1 October 2011
16. Building multiple JIRA version
supported plugins"
• Why?
• Problem points?
• Some Solutions.
7
Saturday, 1 October 2011
17. Maximise your customer base
• Increase the size
of your market
• Should try and
support two
versions back.
Earlier 4.0 4.1 4.2 4.3
8
Saturday, 1 October 2011
18. Multiple JIRA instances
• Deploy to multiple internal
instances
• For example,
https://support.atlassian.com/
is 4.3, where as
https://jira.atlassian.com/ is
4.4.
9
Saturday, 1 October 2011
19. Be ready for upgrades
• Test against EAPs!
• Give feedback.
• Participate in API building
• Support JIRA 5.0 from
launch
10
Saturday, 1 October 2011
33. One build, multiple versions
• Messier code
• No merging
13
Saturday, 1 October 2011
34. One build, multiple versions
• Messier code
• No merging
• Shipping one jar
13
Saturday, 1 October 2011
35. One build, multiple versions
• Messier code
• No merging
• Shipping one jar
• All tests in one branch
13
Saturday, 1 October 2011
36. One build, multiple versions
• Messier code
• No merging
• Shipping one jar
• All tests in one branch
• Know when touching
problem areas
13
Saturday, 1 October 2011
39. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
14
Saturday, 1 October 2011
40. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
3. Non-compile breaking API changes - BuildUtilsInfo
14
Saturday, 1 October 2011
41. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
3. Non-compile breaking API changes - BuildUtilsInfo
4. UI location changes - Web fragment conditions
14
Saturday, 1 October 2011
42. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
3. Non-compile breaking API changes - BuildUtilsInfo
4. UI location changes - Web fragment conditions
5. Compile breaking changes - Reflection
14
Saturday, 1 October 2011
43. Six multi-version plugin
techniques
1. CI using AMPS
2. Javascript / Markup changes - AJS.version
3. Non-compile breaking API changes - BuildUtilsInfo
4. UI location changes - Web fragment conditions
5. Compile breaking changes - Reflection
6. Compile breaking changes - Dynamic module types
14
Saturday, 1 October 2011
44. Continuous Integration
• Run CI against all supported versions
• Use testGroups in AMPS to facilitate this
• Quickly identify compile-time issues introduced
15
Saturday, 1 October 2011
50. Querying JIRA version
• BuildUtilsInfo in JIRA can be used to find the JIRA
version and split the code path
21
Saturday, 1 October 2011
51. Web-fragment Conditions
• Allows you to define a boolean condition as to whether
or not a web-fragment shows up
• IsPriorToJIRAVersion condition to only show web
fragments in certain JIRA versions (uses
BuildUtilsInfo)
22
Saturday, 1 October 2011
53. Compile breaking changes -
Reflection"
• Use this:
• To load a class only present in later versions of JIRA
• To load a class that changes names across JIRA
versions
24
Saturday, 1 October 2011
56. How does this look in JIRA 5?
• JIRA 5.0 removes OSUser
entirely
• Replaced with Crowd user
• Large scale compile time
breaking changes
27
Saturday, 1 October 2011
57. We tried branching
• Approach taken by Bonfire was to drop 4.2 support,
and remove as much OSUser as possible
• Some instances of OSUser couldnʼt be removed
(IssueTabPanel for example)
• Then create a branch, and change the imports for the
branch
28
Saturday, 1 October 2011
58. Deprecation pains
• In JIRA 4.3 / 4.4, use special methods to get crowd
user object
• jiraAuthContext.getUser for OSUser
• jiraAuthContext.getLoggedInUser() for Crowd User
• OSUser based methods are deprecated in 4.3 / 4.4
29
Saturday, 1 October 2011
59. Deprecation pains
• In JIRA 5.0, the better 4.3/4.4
Crowd user methods are now
deprecated (moved to nicer
named methods)
• Doing the right thing yields
lots of warnings
30
Saturday, 1 October 2011
60. Branching sucks!
• For the same reasons outlined before
• No eyes on JIRA 5.0 changes
• Merge pain
• Multiple jars
• How can we fix this?
31
Saturday, 1 October 2011
61. Dynamic module types
• Don Brown created jira4-compat to allow Speakeasy
to support 4.2 -> 5.0 without branching
• Uses dynamic plugin module types to allow for new,
cross version compatible module types
• 4 maven modules, compile different maven modules
based on JIRA version
• FactoryBean Spring Component to inject the correct
dependency 32
Saturday, 1 October 2011
62. Bonfire multi-version
experiences - takeaways
1. Multi-version support - you should be doing it!
2. Donʼt have to branch to do multi-version.
3. The documentation can help!
http://confluence.atlassian.com/display/JIRA/Plugin
+Developer+Notes+for+JIRA+5.0
33
Saturday, 1 October 2011
68. Authentication
• Canʼt store the password
• Ideally, single step
authentication
36
Saturday, 1 October 2011
69. Authentication
• Use JIRA REST
• Returns a cookie
• Use cookie for all future
requests
• Re-authenticate on
cookie timeout
37
Saturday, 1 October 2011
70. Issue metadata
• Need metadata to draw the
issue creation form
• XML-RPC
• Missing fields
• Could not create on some
instances
38
Saturday, 1 October 2011
71. Issue metadata
• Now on custom REST
• Bad: extra code
• Good: In control, works on
all instances, can add new
Bonfire specific features
39
Saturday, 1 October 2011
72. Issue creation
• XML-RPC
• Gaps filled with REST
(e.g. labels)
• SOAP for attachments
40
Saturday, 1 October 2011
73. Issue creation
• Now on custom REST
• Bad: extra code
• Good: In control, works on
all instances, can add new
Bonfire specific features
• Déjà vu?
41
Saturday, 1 October 2011
74. Good news, everyone!
• In JIRA 5.0, neither custom
REST resource would be
required
42
Saturday, 1 October 2011
75. Bonfire Remote API
experiences - takeaways
1. Test on real / complex data!
(use atlas-create-home-zip)
2. Favour REST
3. Donʼt fear custom REST resources
43
Saturday, 1 October 2011