Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-9580

Resources with same path in different plugins override one another

XMLWordPrintable

    • 4
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      If the location of i18n properties in plugins are the same, one file will be loaded and the other will not. For example:

      • plugin 1 contains /i18n.properties
      • plugin 2 contains /i18n.properties

      Only one file will be loaded, and which one depends on the order of plugin loading in Confluence (which is not defined).

      Until this issue is fixed, be sure to put your plugin resources in a namespaced directory structure. That is,

      • /i18n.properties is a bad location
      • /com/example/confluence/myplugin/i18n.properties is a good location.

      The attached two plugins demonstrate this problem.

        1. bulk-actions.tar.gz
          144 kB
        2. bulkactions-1.0-SNAPSHOT.jar
          76 kB
        3. C++AmpSamplesVS12.sln
          11 kB
        4. multi-space-import-export.tar.gz
          305 kB
        5. multispaceimportexport-1.0-SNAPSHOT.jar
          80 kB

            [CONFSERVER-9580] Resources with same path in different plugins override one another

            Gary Weaver added a comment -

            Anatoli,

            That's awesome! Thanks!!

            Gary

            Gary Weaver added a comment - Anatoli, That's awesome! Thanks!! Gary

            Anatoli added a comment - - edited

            Hi Gary,

            You don't need to do anything in the plugins. Now(starting from 3.1-m6) every resource is associated with a particular plugin so resources with the same path in different plugins will not overwrite each other.

            Anatoli.

            Anatoli added a comment - - edited Hi Gary, You don't need to do anything in the plugins. Now(starting from 3.1-m6) every resource is associated with a particular plugin so resources with the same path in different plugins will not overwrite each other. Anatoli.

            Gary Weaver added a comment -

            Noticed that Chris Kiehl marked this as fixed in 3.1-m6. Is this a lucky-charms-magical fix, or is there anything we need to do in our plugins?

            Gary Weaver added a comment - Noticed that Chris Kiehl marked this as fixed in 3.1-m6. Is this a lucky-charms-magical fix, or is there anything we need to do in our plugins?

            Matt Ryall added a comment - - edited

            Updating description to clarify that this is a limitation to do with resource file handling only.

            The namespacing of i18n property keys (as referred to in SUSR-67) is a different issue, but one that we won't be able to fix.

            Matt Ryall added a comment - - edited Updating description to clarify that this is a limitation to do with resource file handling only. The namespacing of i18n property keys (as referred to in SUSR-67 ) is a different issue, but one that we won't be able to fix.

            Matt Ryall added a comment -

            Thanks for raising this, Gary.

            You're right; plugin resources aren't namespaced. This is a problem for i18n resources, velocity templates and a few other things. In the case of i18n we can probably fix it, but the others are not so easy.

            I'll leave this issue open, but in the meantime the best strategy is to use a directory structure to namespace files in different plugins. Using the plugin key as a directory name is one way of doing this.

            Matt Ryall added a comment - Thanks for raising this, Gary. You're right; plugin resources aren't namespaced. This is a problem for i18n resources, velocity templates and a few other things. In the case of i18n we can probably fix it, but the others are not so easy. I'll leave this issue open, but in the meantime the best strategy is to use a directory structure to namespace files in different plugins. Using the plugin key as a directory name is one way of doing this.

              ckiehl Chris Kiehl
              6e54f9dce0da Gary Weaver
              Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: