Get, backup and re-import list of Plugins

[childnode]

Hi,

is there something to get a full, machine readable list of installed plugins, perhaps their configuration and their state (inactive / active)?

is there something where I can re-import this to a system?!

Reason: Bugfixing JIRA instance (Workflows) and Plugin Development. Really hard to "duplicate" a remote Machine where I have some (anonymous) data dumps from but just a list of plugins the the comments of the anon-entities.xml.
So everytime I fire up an test instance, I have to install plugins manually before importing the DB Dump.

To clarify what is needed:
The Way I look / search for: get an XML / Text list of Plugins and Plugin configuration via UPM (what plugins are are installed but disabled or even which macros of plugins are disabled in Confluence) and then reimporting this list into a second system.

Another use-case: pre-production and production system when testing plugins

[FagnerF]

Hi Childno.de,

There is a way to look at plugins used by users and system. Furthermore their status (disable/enable).

You can find it by going to your JIRADirectory\Home\Log\atlassian-jira.txt.

• Open the file
• Find: User Plugins.

There is User plugins list:

___ User Plugins ____

Number : 20
Atlassian Bonfire - JIRA Plugin : com.atlassian.bonfire.plugin
Version : 2.5.3
Status : enabled
Vendor : Atlassian
Description : Bonfire - Agile Testing

Also, the plugins used by the system:

__ System Plugins ___

Regarding "is there something where I can re-import this to a system?!"

I'd recommend to take a look at Managing JIRA's plugin.

I hope it helps.

[childnode]

sure, log is where I get it usally from but still have to import each plugin manually. Copying the plugin directories is often not possible due to server restrictions.

The Way I look / search for: get an XML / Text list of Plugins and Plugin configuration via UPM (what plugins are are installed but disabled or even which macros of plugins are disabled in Confluence) and then reimporting this list into a second system.

Another use-case: pre-production and production system when testing plugins

[childnode]

clarified what is needed above in question