-
Suggestion
-
Resolution: Fixed
-
None
We are in the process of working towards an upgrade to Jira 4. We have a few plugins that we have developed that make use of JIRA Agile information when it is available in an installation. Some examples of the information we access or tasks performed:
- Use of version start dates when available
- Use of master version information when available
- Registration of certain projects with JIRA Agile context on new project creation
In Jira 4, now that the classloaders are segregated with the use of OSGI, it looks like we are having problems accessing the classes we need to make this happen.
As a workaround we have modified the manifest file in the JIRA Agile jar to add the following:
Export-Package: com.pyxis.greenhopper.jira.configurations,com.pyxis.greenhopper.jira.boards.context
This at least solves our first 2 issues (haven't looked into the 3rd item I mention above yet), as we are now able to access these APIs from our plugin. I am no OSGI expert, so not sure if Export-Package is the best route, but can the generated plugin artifacts distributed by Atlassian be created in a way where we can access the APIs from our plugins?
- is detailed by
-
- Closed
-
- Closed
-
- Closed
- is duplicated by
-
- Closed
[JSWSERVER-1853] Make JIRA Agile APIs available to other plugins
| Workflow | Original: JAC Suggestion Workflow [ 3069255 ] | New: JAC Suggestion Workflow 3 [ 3662498 ] |
| Status | Original: RESOLVED [ 5 ] | New: Closed [ 6 ] |
| Workflow | Original: Confluence Workflow - Public Facing v4 [ 2626310 ] | New: JAC Suggestion Workflow [ 3069255 ] |
| Workflow | Original: JIRA PM Feature Request Workflow v2 - TEMP [ 2323509 ] | New: Confluence Workflow - Public Facing v4 [ 2626310 ] |
| Status | Original: Closed [ 6 ] | New: Resolved [ 5 ] |
| Workflow | Original: JIRA PM Feature Request Workflow v2 [ 2041540 ] | New: JIRA PM Feature Request Workflow v2 - TEMP [ 2323509 ] |
| Workflow | Original: JIRA PM Feature Request Workflow v2 - TEMP [ 2032385 ] | New: JIRA PM Feature Request Workflow v2 [ 2041540 ] |
| Workflow | Original: JIRA PM Feature Request Workflow v2 [ 738764 ] | New: JIRA PM Feature Request Workflow v2 - TEMP [ 2032385 ] |
| Labels | Original: atlassian_status jira_4 osgi | New: affects-server atlassian_status jira_4 osgi |
| Backlog Order (Obsolete) | Original: 1820000000 | |
| Workflow | Original: GreenHopper Kanban Workflow v2 [ 302187 ] | New: JIRA PM Feature Request Workflow v2 [ 738764 ] |
| Issue Type | Original: Story [ 16 ] | New: Suggestion [ 10000 ] |
| Priority | Original: Major [ 3 ] |
| Description |
Original:
We are in the process of working towards an upgrade to Jira 4. We have a few plugins that we have developed that make use of Greenhopper information when it is available in an installation. Some examples of the information we access or tasks performed:
# Use of version start dates when available # Use of master version information when available # Registration of certain projects with Greenhopper context on new project creation In Jira 4, now that the classloaders are segregated with the use of OSGI, it looks like we are having problems accessing the classes we need to make this happen. As a workaround we have modified the manifest file in the greenhopper jar to add the following: {code} Export-Package: com.pyxis.greenhopper.jira.configurations,com.pyxis.greenhopper.jira.boards.context {code} This at least solves our first 2 issues (haven't looked into the 3rd item I mention above yet), as we are now able to access these APIs from our plugin. I am no OSGI expert, so not sure if Export-Package is the best route, but can the generated plugin artifacts distributed by Atlassian be created in a way where we can access the APIs from our plugins? |
New:
We are in the process of working towards an upgrade to Jira 4. We have a few plugins that we have developed that make use of JIRA Agile information when it is available in an installation. Some examples of the information we access or tasks performed:
# Use of version start dates when available # Use of master version information when available # Registration of certain projects with JIRA Agile context on new project creation In Jira 4, now that the classloaders are segregated with the use of OSGI, it looks like we are having problems accessing the classes we need to make this happen. As a workaround we have modified the manifest file in the JIRA Agile jar to add the following: {code} Export-Package: com.pyxis.greenhopper.jira.configurations,com.pyxis.greenhopper.jira.boards.context {code} This at least solves our first 2 issues (haven't looked into the 3rd item I mention above yet), as we are now able to access these APIs from our plugin. I am no OSGI expert, so not sure if Export-Package is the best route, but can the generated plugin artifacts distributed by Atlassian be created in a way where we can access the APIs from our plugins? |
| Current Status |
Original:
{panel:title=Atlassian Status as at September 2 2010| borderStyle=solid| borderColor=#ccc| titleBGColor=#49BD5F| bgColor=#E7F4FA}
Update (2-Sept-2010): We are starting to document the plugin points for GreenHopper and build out a [GreenHopper Development Hub|http://confluence.atlassian.com/display/GH/GreenHopper+Development+Hub] (very sparse at the moment). First through the gate is the [GreenHopper LinkProvider Plugin Documentation|http://confluence.atlassian.com/display/GH/GreenHopper+LinkProvider+Plugin+Documentation], any feedback on this functionality should be added to GHS-2451. The GreenHopper LinkProvider is available in GreenHopper 5.2. Short answer; It is our intention to make the source code available for GreenHopper and to provide plugin points for third-party JIRA plugins. We have committed to making source code available by October 2010. Long answer; There are two primary groups who wish to access the source code, customers for debugging and plugin developers. Our primary concern at this stage is that our quick and significant changes to the code may impact customers who wish to develop plugins which rely on GreenHopper. If you are a watcher on this issue and wish to have access to the source code to better integrate with GreenHopper I ask that you add your ideas below or contact me directly. We are keen to work with other plugin developers to get feedback. {panel} |
New:
{panel:title=Atlassian Status as at September 2 2010| borderStyle=solid| borderColor=#ccc| titleBGColor=#49BD5F| bgColor=#E7F4FA}
Update (2-Sept-2010): We are starting to document the plugin points for JIRA Agile and build out a [JIRA Agile Development Hub|https://developer.atlassian.com/display/JIRADEV/JIRA+Agile+Development] (very sparse at the moment). First through the gate is the [GreenHopper LinkProvider Plugin Documentation|http://confluence.atlassian.com/display/GH/GreenHopper+LinkProvider+Plugin+Documentation], any feedback on this functionality should be added to GHS-2451. The GreenHopper LinkProvider is available in GreenHopper 5.2. Short answer; It is our intention to make the source code available for GreenHopper and to provide plugin points for third-party JIRA plugins. We have committed to making source code available by October 2010. Long answer; There are two primary groups who wish to access the source code, customers for debugging and plugin developers. Our primary concern at this stage is that our quick and significant changes to the code may impact customers who wish to develop plugins which rely on JIRA Agile. If you are a watcher on this issue and wish to have access to the source code to better integrate with JIRA Agile I ask that you add your ideas below or contact me directly. We are keen to work with other plugin developers to get feedback. {panel} |
