In JIRA's early days (I'd have to dig through the history be sure exactly when, but it was somewhere in the 4.x line), there was only the "atlassian-jira" artifact. This contained all of the JIRA code, and plugin developers had no way of knowing what code they used would change and under what circumstance.
This caused a lot of problems both for the JIRA development team and plugin developers. The JIRA developers did not know what changes they could make without breaking plugins, and the plugin developers did not know what was safe to use without getting broken by upgrades.
We then introduced the Java API Policy for JIRA, which defined a clear contract for how we separate what we consider internal details (jira-core) from what we think plugin developers should talk to (jira-api). The lines blur in a few places because this was introduced retroactively, and where we've noticed this you will often find things in jira-api marked as @Internal to make it as clear as we can that even though for some reason we had to include it, we consider that class or method to be an internal detail that we are free to change.
In the absence of any annotation or documentation to the contrary, then, jira-api is the module containing the classes that we intend to hold stable within a major version, and jira-core contains things that plugin developers should not use unless they run into a problem that cannot be solved any other way (in which case, they should open an improvement request so we can hopefully fix that).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.