Uploaded image for project: 'Felix'
  1. Felix
  2. FELIX-620

manifest goal of maven-bundle-plugin ignores _include instruction

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • maven-bundle-plugin-1.4.1
    • maven-bundle-plugin-1.4.2
    • Maven Bundle Plugin
    • None
    • Maven version: 2.0.7
      Java version: 1.5.0_13-rev
      OS name: "sunos" version: "5.11" arch: "x86"

    Description

      It appears to me that if I just invoke manifest goal of maven-bundle-plugin, it ignores _include instruction, where as if I use bundle goal, it is used by the plugin. There are various ways to test it. The easiest seems to be using a non-existent file name. Attached are two sets of pom files, pom.xml uses bundle goal, where as pom.xml.notworking uses manifest goal. While using the first one, bnd complains about missing osgi.bundle3 file, where as it does not report any such error while using the first one. That makes me think that the manifest Mojo is not sending the file name to bnd.

      I am attaching a very simple test case along with a README describing the issue.

      Attachments

        1. Felix-620.zip
          6 kB
          Sanjeeb Kumar Sahoo

        Activity

          Test case along with README

          sahoo Sanjeeb Kumar Sahoo added a comment - Test case along with README

          Actually the include instruction is being processed, but the manifest goal is not reporting the errors/warnings from Bnd.
          I have just added code to report these errors/warnings, and the testcase now behaves the same for both of the goals.

          mcculls Stuart McCulloch added a comment - Actually the include instruction is being processed, but the manifest goal is not reporting the errors/warnings from Bnd. I have just added code to report these errors/warnings, and the testcase now behaves the same for both of the goals.

          That's good. But, as I mentioned in the README, the problem is not about missing warning. I also felt that manifest goal was not processing the instructions file. To reproduce this, please do the following (copied and pasted from the README):
          Just change pom.xml to use osgi.bundle and
          pom.xml.notworking to use osgi.bundle2. Both these files exist. Now generate
          two jars one with each pom.xml. Look at their manifest files. The one created
          with bundle goal has only sahoo.osgitest2.foo.api exported, where as the one
          with manifest goal exports sahoo.osgitest2.foo.impl as well as api package. So,
          it completely ignored the instructions found in osgi.bundle2 file.

          sahoo Sanjeeb Kumar Sahoo added a comment - That's good. But, as I mentioned in the README, the problem is not about missing warning. I also felt that manifest goal was not processing the instructions file. To reproduce this, please do the following (copied and pasted from the README): Just change pom.xml to use osgi.bundle and pom.xml.notworking to use osgi.bundle2. Both these files exist. Now generate two jars one with each pom.xml. Look at their manifest files. The one created with bundle goal has only sahoo.osgitest2.foo.api exported, where as the one with manifest goal exports sahoo.osgitest2.foo.impl as well as api package. So, it completely ignored the instructions found in osgi.bundle2 file.

          No - it does read the instructions from osgi.bundle2 (you can confirm this by adding a unique entry like "TEST:ME") - the issue here is actually that the manifest goal is overwriting the included property with a default export based on the contents of the jar, because it checks for the existence of the export instruction in the original POM instructions rather than the merged instructions.

          BTW, there is also a typo in osgi.bundle2 where it uses "_exportcontents", rather than "-exportcontents".

          Instructions inside included files are processed by Bnd, so it expects the notation described on Peter's website (http://aqute.biz/Code/Bnd#directives) i.e. "exportcontents". However, because XML doesn't allow tags that start with '' we can't have <-exportcontents> in the POM, so instead we accept <_exportcontents> and transform this internally to "-exportcontents" before passing it onto Bnd. But this is only for the POM to get around the XML tag restriction.

          mcculls Stuart McCulloch added a comment - No - it does read the instructions from osgi.bundle2 (you can confirm this by adding a unique entry like "TEST:ME") - the issue here is actually that the manifest goal is overwriting the included property with a default export based on the contents of the jar, because it checks for the existence of the export instruction in the original POM instructions rather than the merged instructions. BTW, there is also a typo in osgi.bundle2 where it uses "_exportcontents", rather than "-exportcontents". Instructions inside included files are processed by Bnd, so it expects the notation described on Peter's website ( http://aqute.biz/Code/Bnd#directives ) i.e. " exportcontents". However, because XML doesn't allow tags that start with ' ' we can't have <-exportcontents> in the POM, so instead we accept <_exportcontents> and transform this internally to "-exportcontents" before passing it onto Bnd. But this is only for the POM to get around the XML tag restriction.

          Thanks for pointing out the typo in osgi.bundl2. Will the merge behavior of the manifest goal be addressed as part of this issue, or do you want a separate issue (enhancement request) to be filed?

          sahoo Sanjeeb Kumar Sahoo added a comment - Thanks for pointing out the typo in osgi.bundl2. Will the merge behavior of the manifest goal be addressed as part of this issue, or do you want a separate issue (enhancement request) to be filed?

          Fixed in trunk - manifest goal now follows export instructions from included property files.

          mcculls Stuart McCulloch added a comment - Fixed in trunk - manifest goal now follows export instructions from included property files.

          Thanks for fixing the bug so quickly. When is the next version of maven-bundle-plugin scheduled to be released?I can plan my activity accordingly.

          sahoo Sanjeeb Kumar Sahoo added a comment - Thanks for fixing the bug so quickly. When is the next version of maven-bundle-plugin scheduled to be released?I can plan my activity accordingly.

          No firm date yet - but at least by the end of July, if that's any help.

          mcculls Stuart McCulloch added a comment - No firm date yet - but at least by the end of July, if that's any help.

          This is available for testing in the latest 1.4.2-SNAPSHOT, I expect to start the release vote tomorrow

          mcculls Stuart McCulloch added a comment - This is available for testing in the latest 1.4.2-SNAPSHOT, I expect to start the release vote tomorrow

          Fixed in latest release of the maven-bundle-plugin (1.4.3)

          mcculls Stuart McCulloch added a comment - Fixed in latest release of the maven-bundle-plugin (1.4.3)

          People

            mcculls Stuart McCulloch
            sahoo Sanjeeb Kumar Sahoo
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: