Need to break dependency on jira-core

Description

JIRA Charting Plugin is currently depending on several jira-core classes and needs to stop doing so. In most cases, it was simply doing things The Wrong Way™, like using ComponentManager instead of ComponentAccessor or I18nBean instead of I18nHelper. I have addressed these problems, but there is still one dependency left, which is the one that initially prompted me to look at this.

FirstResponseDateSearcher extends the jira-core class DateTimeRangeSearcher. This is a little bit curious because the closely related DateRangeSearcher is in jira-api and explicitly marked @PublicApi and @PublicSpi as I would expect. told me in chat that "None of those JQL helper objects where designed to be used in API [...] They got moved because some plugins used them."

Ok, that's fair. However...

I've never tried to create my own custom field type. From what I can tell, things are a bit backwards because when you create a custom field, you have to pick the searcher you want it to use, but the searcher has to opt-in as recognizing that custom field type to be considered. This leads to the following chain of problems:

  • JCHART wants to introduce a calculated custom field type called "Date of First Response", and it wants it to be searchable

  • It would like to simply rely on DateTimeRangeSearcher, but since DateTimeRangeSearcher does not recognize the "Date of First Response" custom field type, it does not advertise itself as able to deal with it, even though functionally it's perfectly capable of doing so.

  • Therefore, JCHART depends on jira-core and creates a FirstResponseDateSearcher that does absolutely nothing except extend DateTimeRangeSearcher to get its functionality, and does the needful in its atlassian-plugin.xml to get that searcher to appear for "Date of First Response" custom fields.

This is obviously backwards. I can understand that a searcher only wants to work on custom field data that it knows is in the right format, and maybe there's a better solution that I'm just not seeing, but I don't think it's reasonable to ask custom field plugins to duplicate the logic of DateTimeRangeSearcher in their own plugins instead of extending the one that we provide. What exactly do we expect a new date/time custom field to do? Here are the options I see for moving this forward:

  1. Maybe I just plain don't understand this and the "Date of First Response" custom field type has better options already available for getting DateTimeRangeSearcher's functionality by specifying the right magic incantation in atlassian-plugin.xml.

  2. Change the FirstResponseDateSearcher to extend DateRangeSearcher instead of DateTimeRangeSearcher. I don't honestly know how they differ beyond the obvious guess as to what resolution they surface. Maybe this is fine; I'm just worried about negative functional impact.

  3. Surface DateTimeRangeSearcher as @PublicApi/@PublicSpi. We've already done this for DateRangeSearcher. I would argue that whether or not these were orginally intended to be consumed in this way is nowhere near as important as the need to make ourselves a fully functional development platform with boilerplate code surfaced whenever it's needed, and it seems to be needed here.

  4. Copy the code that makes DateTimeRangeSearcher function into FirstResponseDateSearcher verbatum, which is disgustingly WET.

Barring a simpler solution, I say we own up and commit to making DateTimeRangeSearcher a PublicSpi so that it provides that minimal boilerplate with the full protection of our API commitment, regardless of its original intent.

Environment

None

Testing Notes

None

Status

Assignee

Unassigned

Reporter

Chris Fuller

Labels

None

Add-on Type

None

Team

None

CC

None

Risk factor

None

QA Kickoff Status

None

QA Demo Status

None

Priority

Major