Extending BaseIssueAction plugin, how do I expose ‘extraIssue’ to velocity?
public class CustomAction extends BaseIssueAction { Issue extraIssue; String run(){ return "v"; } }
<action key="ck" name="CA" view="v"/>
In my experience with JIRA plugins, the key was ensuring extra variables are exposed via public getter methods. Using a direct field, as in your example, often doesn’t work since Velocity picks up on the bean properties provided by these getters. I solved a similar problem by adding a method like public Issue getExtraIssue() { return extraIssue; } which made the extra variable accessible in the velocity template. Additionally, careful examination of the plugin XML configuration and reading the plugin developer documentation helped clarify how and when the Apache Velocity engine accesses these objects.
In my previous experience working with JIRA plugin customization, I realized that simply making the variable public wasn’t enough when using Velocity. Instead, I had to look at how the class method responsible for populating the Velocity context worked. I decided to override the method that adds parameters to the Velocity context and manually insert my extra variable there. This approach gave me more control and ensured that the variable was available. It also helped me troubleshoot issues related to the order of initialization and template rendering.
Based on my experience, the key to successfully exposing an extra variable to Velocity is to follow Java bean conventions. It is important to ensure that any additional field is accessible through a properly defined public accessor method. Also, confirming that the field is fully initialized before the template is rendered is crucial. I faced a similar challenge and realized that even minor configuration issues could lead to the variable not being picked up. Thorough testing and validating the plugin documentation helped in getting the desired result.
i solved it by adding a public getExtraIssue method. make sure the variable is inited before rendering. small mistakes in the xml config can also screw it up.
Another option that worked for me was to override the method responsible for building the Velocity context. In my case, creating a custom method such as getVelocityParams and explicitly putting the extra variable into the resulting map ensured that it was available at rendering time. This strategy circumvents the need for public getter methods and provides a more direct way to manage data initialization within the plugin. The approach is more flexible and helped resolve some timing-related initialization issues I encountered.