JDO
  1. JDO
  2. JDO-684

Fix OSGi Export-Package entries in JDO 3.0 manifest to include version

    Details

      Description

      The manifest for the JDO API project fails to specify package versions in its OSGi Export-Package entry. I've added these & revised the version from 3.0 to 3.0.1, as the 3.0 artifacts have already been published. Without the package-level version specifications, Virgo (Eclipse Equinox + Spring dm Server additions) reports version 0.0.0 for all packages, causing missing bundle dependencies downstream, including DataNucleus.

      Patch to follow bug submission.

      1. JDO-684.patch
        3 kB
        Matthew T. Adams

        Activity

        Hide
        Matthew T. Adams added a comment -

        This patch is relative to branches/3.0. It adds the version specification to the Export-Package manifest entry and revs the JDO version from 3.0 to 3.0.1

        Show
        Matthew T. Adams added a comment - This patch is relative to branches/3.0. It adds the version specification to the Export-Package manifest entry and revs the JDO version from 3.0 to 3.0.1
        Hide
        Matthew T. Adams added a comment -

        It looks like this has already been fixed in the trunk for JDO 3.1.

        Show
        Matthew T. Adams added a comment - It looks like this has already been fixed in the trunk for JDO 3.1.
        Hide
        Andy Jefferson added a comment -

        Bit like this then
        http://www.datanucleus.org/downloads/maven2/javax/jdo/jdo-api/3.0.0/

        Judging by time taken to get a release, I knocked that one together back in October last year.

        => Apply it, and arrange a release

        Show
        Andy Jefferson added a comment - Bit like this then http://www.datanucleus.org/downloads/maven2/javax/jdo/jdo-api/3.0.0/ Judging by time taken to get a release, I knocked that one together back in October last year. => Apply it, and arrange a release
        Hide
        Matthew T. Adams added a comment -

        Yes, Andy. Exactly like that.

        Everyone else: can we please quickly push a 3.0.1 update to JDO to include the OSGi manifest fix that's in this patch? Long term, it would be nice to come up with some tests to confirm proper OSGi manifests in all JDO artifacts. I feel another issue coming on...and there it is: JDO-685.

        Show
        Matthew T. Adams added a comment - Yes, Andy. Exactly like that. Everyone else: can we please quickly push a 3.0.1 update to JDO to include the OSGi manifest fix that's in this patch? Long term, it would be nice to come up with some tests to confirm proper OSGi manifests in all JDO artifacts. I feel another issue coming on...and there it is: JDO-685 .
        Hide
        Matthew T. Adams added a comment -

        After our conf call discussion, I ran bnd against our currently published 3.0 jar (http://repo1.maven.org/maven2/javax/jdo/jdo-api/3.0/jdo-api-3.0.jar) and it's noticing that I missed some other import package statements:

        C:\temp\jdo-bnd>java -jar biz.aQute.bnd.jar print -verify jdo-api-3.0.jar
        One error
        1 : Unresolved references to [javax.naming, javax.rmi, javax.xml.parsers, org.w3c.dom, org.xml.sax] by class(es) on the Bundle-Classpath[Jar:jdo-api-3.0.jar]: [javax/jdo/JDOHelper$12.class, javax
        /jdo/spi/JDOImplHelper.class, javax/jdo/JDOHelper.class]

        I'm going to add these to the manifest as well. New patch attached with those as well. Please review. If ok, I'll commit then begin release process for JDO 3.0.1.

        Show
        Matthew T. Adams added a comment - After our conf call discussion, I ran bnd against our currently published 3.0 jar ( http://repo1.maven.org/maven2/javax/jdo/jdo-api/3.0/jdo-api-3.0.jar ) and it's noticing that I missed some other import package statements: C:\temp\jdo-bnd>java -jar biz.aQute.bnd.jar print -verify jdo-api-3.0.jar One error 1 : Unresolved references to [javax.naming, javax.rmi, javax.xml.parsers, org.w3c.dom, org.xml.sax] by class(es) on the Bundle-Classpath [Jar:jdo-api-3.0.jar] : [javax/jdo/JDOHelper$12.class, javax /jdo/spi/JDOImplHelper.class, javax/jdo/JDOHelper.class] I'm going to add these to the manifest as well. New patch attached with those as well. Please review. If ok, I'll commit then begin release process for JDO 3.0.1.
        Hide
        Matthew T. Adams added a comment -

        After our conf call, I found http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html that discusses "Package Versioning". It's fairly old, and none of the headers specified therein conflict with those specified in the OSGi r4 specification. I have added these headers for completeness with my best guess for their values, although I omitted the "Name:" header, as it was causing bnd to throw errors.

        WRT importing exported packages, section 3.6.6 of the OSGi r4 Core specification discusses importing exported packages. That discussion suggests that our bundle is not a candidate for package substitution, as we mix implementation (JDOHelper) classes with API.

        WRT Bundle-Version, section 3.2.1.19 also says the "Bundle-Version header specifies the version of this bundle." For this release, then, it's "3.0.1".

        WRT singleton bundles, section 3.6.2 says that it "Indicates that the bundle can only have a single version resolved...The Framework must resolve at most one bundle when multiple versions of a singleton bundle with the same symbolic name are installed." I think this means that we should go with the default value, false. It does not address the authoritativeness of a bundle.

        Patch attached, relative to branches/3.0 (other patches were accidentally relative to branches/3.0/api); this patch supercedes all other patches. I would have deleted all other patches, but I don't have the ability or couldn't figure out how to delete attached files.

        Show
        Matthew T. Adams added a comment - After our conf call, I found http://java.sun.com/developer/Books/javaprogramming/JAR/basics/manifest.html that discusses "Package Versioning". It's fairly old, and none of the headers specified therein conflict with those specified in the OSGi r4 specification. I have added these headers for completeness with my best guess for their values, although I omitted the "Name:" header, as it was causing bnd to throw errors. WRT importing exported packages, section 3.6.6 of the OSGi r4 Core specification discusses importing exported packages. That discussion suggests that our bundle is not a candidate for package substitution, as we mix implementation (JDOHelper) classes with API. WRT Bundle-Version, section 3.2.1.19 also says the "Bundle-Version header specifies the version of this bundle." For this release, then, it's "3.0.1". WRT singleton bundles, section 3.6.2 says that it "Indicates that the bundle can only have a single version resolved...The Framework must resolve at most one bundle when multiple versions of a singleton bundle with the same symbolic name are installed." I think this means that we should go with the default value, false. It does not address the authoritativeness of a bundle. Patch attached, relative to branches/3.0 (other patches were accidentally relative to branches/3.0/api); this patch supercedes all other patches. I would have deleted all other patches, but I don't have the ability or couldn't figure out how to delete attached files.
        Hide
        Michael Bouschen added a comment -

        The patch JDO-684.3.patch looks good.

        Just come comments:

        • The Bundle-Vendor should be Apache Software Foundation
        • How about adding a Bundle-Licence entry: Bundle-Licence: Apache Software Licence 2.0
        • Does it make sense to mark the follwing imports as optional, since they are provided by the Java runtime system (meaning the system bundle): javax.rmi, javax.xml.parsers, org.w3c.dom, org.xml.sax;
        Show
        Michael Bouschen added a comment - The patch JDO-684 .3.patch looks good. Just come comments: The Bundle-Vendor should be Apache Software Foundation How about adding a Bundle-Licence entry: Bundle-Licence: Apache Software Licence 2.0 Does it make sense to mark the follwing imports as optional, since they are provided by the Java runtime system (meaning the system bundle): javax.rmi, javax.xml.parsers, org.w3c.dom, org.xml.sax;
        Hide
        Matthew T. Adams added a comment -

        @Michael,

        • Bundle-Vendor changed to "Apache Software Foundation"
        • Bundle-License added
        • javax.rmi, javax.xml.parsers, org.w3c.dom & org.xml.sax are no longer optional

        Patch tested & attached.

        Show
        Matthew T. Adams added a comment - @Michael, Bundle-Vendor changed to "Apache Software Foundation" Bundle-License added javax.rmi, javax.xml.parsers, org.w3c.dom & org.xml.sax are no longer optional Patch tested & attached.
        Hide
        Craig L Russell added a comment -

        Looks good. Just one minor question. The patch updates api/API3.MF which looks fine.

        But it also updates API3.MF. Is this file obsolete? Most of the changes do not appear in this file...

        Show
        Craig L Russell added a comment - Looks good. Just one minor question. The patch updates api/API3.MF which looks fine. But it also updates API3.MF. Is this file obsolete? Most of the changes do not appear in this file...
        Hide
        Matthew T. Adams added a comment -

        @Craig, I take you meant that it also updates api/../JDO3.MF. I included a change to that file for completeness.

        It's used in tck/project.properties, line 21: maven.jar.manifest = $

        {basedir}

        /../JDO3.MF

        Show
        Matthew T. Adams added a comment - @Craig, I take you meant that it also updates api/../JDO3.MF. I included a change to that file for completeness. It's used in tck/project.properties, line 21: maven.jar.manifest = $ {basedir} /../JDO3.MF
        Hide
        Matthew T. Adams added a comment -

        Incorporated changes from conf call feedback on 7 Oct '11. Please review. Once approved, I'll commit & begin release process.

        Show
        Matthew T. Adams added a comment - Incorporated changes from conf call feedback on 7 Oct '11. Please review. Once approved, I'll commit & begin release process.
        Hide
        Matthew T. Adams added a comment -

        Now using version range "[1.0.0,3.0.0)" for javax.persistence.

        Show
        Matthew T. Adams added a comment - Now using version range "[1.0.0,3.0.0)" for javax.persistence.
        Hide
        Matthew T. Adams added a comment -

        Removed typo in javax.persistence Import-Package entry.

        Show
        Matthew T. Adams added a comment - Removed typo in javax.persistence Import-Package entry.
        Hide
        Matthew T. Adams added a comment -

        Reviewed JDO-673 on conf call, so reverted JPA dependency range back to [1.0.0,2.0.0).

        Show
        Matthew T. Adams added a comment - Reviewed JDO-673 on conf call, so reverted JPA dependency range back to [1.0.0,2.0.0).

          People

          • Assignee:
            Matthew T. Adams
            Reporter:
            Matthew T. Adams
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development