Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.1, 1.3.0, 2.0.0-M2
    • Fix Version/s: 1.3.0, 2.0.0-M2
    • Component/s: build / infrastructure
    • Labels:
      None
    • Patch Info:
      Patch Available

      Description

      Use the maven-bundle-plugin to generate the OSGi bundle metadata in the manifest.mf.

      1. OPENJPA-1062.patch
        8 kB
        Donald Woods
      2. OPENJPA-1062-bundle_only.patch
        6 kB
        Donald Woods
      3. OPENJPA-1062-bundle_only.patch
        7 kB
        Donald Woods
      4. OPENJPA-1062-itests.patch
        27 kB
        Donald Woods

        Issue Links

          Activity

          Hide
          Donald Woods added a comment -

          Patch that corrects some maven scope settings and adds the bundle metadata to the openjpa.jar, while leaving openjpa-all.jar w/o any bundle metadata due to problems using both maven-shade-plugin and maven-bundle-plugin in the same pom.xml.

          Show
          Donald Woods added a comment - Patch that corrects some maven scope settings and adds the bundle metadata to the openjpa.jar, while leaving openjpa-all.jar w/o any bundle metadata due to problems using both maven-shade-plugin and maven-bundle-plugin in the same pom.xml.
          Hide
          Craig L Russell added a comment -

          Are you sure the scope settings are wrong in openjpa-jdbc/pom.xml? What is the compile-time dependency on postgresql, ant, and hsqldb?

          Similar question on openjpa-lib/pom.xml ant and log4j dependency.

          Similar question on openjpa-kernel/pom.xml ant and websphere dependency.

          Show
          Craig L Russell added a comment - Are you sure the scope settings are wrong in openjpa-jdbc/pom.xml? What is the compile-time dependency on postgresql, ant, and hsqldb? Similar question on openjpa-lib/pom.xml ant and log4j dependency. Similar question on openjpa-kernel/pom.xml ant and websphere dependency.
          Hide
          Donald Woods added a comment -

          Thanks for taking the time to review, which was why I attached the patch instead of just committing it. All the junit tests passed and I could have read the dependencies wrong, but here is what I based the changes on -
          By marking <scope>compile</scope>, then those dependencies are only used at compile time and are not included as maven transitive dependencies, which helps maven-bundle-plugin create more accurate bundle metadata. If you look at the openjpa/pom.xml and openpa-all/pom.xml, the list of dependencies in there are the true runtime dependencies (minus any Derby/JDBC drivers.)
          openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J, Commons-logging and No logging.
          openjpa-kernel - WebSphere jars are only for compile time of WAS container integration support and are not included in the binary distribution.
          openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary and HSQLDictionary classes, which must be provided at runtime by the user/app supplying the required JDBC driver. Ant is only needed when calling the enhancer or reverse mapping tool from Ant.
          I still want a couple more eyes to look at this (like maybe Mike) and I want to run some more tests before committing.

          Show
          Donald Woods added a comment - Thanks for taking the time to review, which was why I attached the patch instead of just committing it. All the junit tests passed and I could have read the dependencies wrong, but here is what I based the changes on - By marking <scope>compile</scope>, then those dependencies are only used at compile time and are not included as maven transitive dependencies, which helps maven-bundle-plugin create more accurate bundle metadata. If you look at the openjpa/pom.xml and openpa-all/pom.xml, the list of dependencies in there are the true runtime dependencies (minus any Derby/JDBC drivers.) openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J, Commons-logging and No logging. openjpa-kernel - WebSphere jars are only for compile time of WAS container integration support and are not included in the binary distribution. openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary and HSQLDictionary classes, which must be provided at runtime by the user/app supplying the required JDBC driver. Ant is only needed when calling the enhancer or reverse mapping tool from Ant. I still want a couple more eyes to look at this (like maybe Mike) and I want to run some more tests before committing.
          Hide
          Donald Woods added a comment -

          Updated patch that only adds the bundle metadata to openjpa.jar and doesn't change any of the dependency scopes, but does add one missing openjpa.jar dependency on openjpa-slice.

          Show
          Donald Woods added a comment - Updated patch that only adds the bundle metadata to openjpa.jar and doesn't change any of the dependency scopes, but does add one missing openjpa.jar dependency on openjpa-slice.
          Hide
          Craig L Russell added a comment -

          > By marking <scope>compile</scope>, then those dependencies are only used at compile time and are not included as maven transitive dependencies, which helps maven-bundle-plugin create more accurate bundle metadata.

          My understanding is different. I understand that if you have a compile-time dependency, then it's a permanent dependency that carries through test, integration, and runtime. But I'm not a maven expert.

          > openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J, Commons-logging and No logging.

          So if you have a requirement that might be needed at runtime (e.g. log4j) and you can compile without it, it should be marked as provided.

          > Ant is only needed when calling the enhancer or reverse mapping tool from Ant.

          So ant should be a test dependency or a provided dependency.

          > openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary and HSQLDictionary classes

          This is interesting. These are open source libraries so there's no harm in including them. It just struck me as odd that we would have a hard dependency on these database-specific libraries, but upon reflection, I think you're right to include them as compile dependencies.

          > I still want a couple more eyes to look at this (like maybe Mike) and I want to run some more tests before committing.

          +1

          Show
          Craig L Russell added a comment - > By marking <scope>compile</scope>, then those dependencies are only used at compile time and are not included as maven transitive dependencies, which helps maven-bundle-plugin create more accurate bundle metadata. My understanding is different. I understand that if you have a compile-time dependency, then it's a permanent dependency that carries through test, integration, and runtime. But I'm not a maven expert. > openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J, Commons-logging and No logging. So if you have a requirement that might be needed at runtime (e.g. log4j) and you can compile without it, it should be marked as provided. > Ant is only needed when calling the enhancer or reverse mapping tool from Ant. So ant should be a test dependency or a provided dependency. > openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary and HSQLDictionary classes This is interesting. These are open source libraries so there's no harm in including them. It just struck me as odd that we would have a hard dependency on these database-specific libraries, but upon reflection, I think you're right to include them as compile dependencies. > I still want a couple more eyes to look at this (like maybe Mike) and I want to run some more tests before committing. +1
          Hide
          Donald Woods added a comment -

          Update patch that only adds the bundle metadata to openjpa.jar and install/starts in Apache Felix 1.8.0 after you install the dependencies first (which I'll doc on the wiki after committing.)

          Show
          Donald Woods added a comment - Update patch that only adds the bundle metadata to openjpa.jar and install/starts in Apache Felix 1.8.0 after you install the dependencies first (which I'll doc on the wiki after committing.)
          Hide
          Michael Dick added a comment -

          >> By marking <scope>compile</scope>, then those dependencies are only used at compile time and are not included as maven >>transitive dependencies, which helps maven-bundle-plugin create more accurate bundle metadata.

          >My understanding is different. I understand that if you have a compile-time dependency, then it's a permanent dependency that carries >through test, integration, and runtime. But I'm not a maven expert.

          That's my understanding as well.

          Compile is the heaviest dependency type and will carry through all phases.

          Provided is similar to compile but the jar won't included in any artifacts downstream. It will be passed along as a transitive 'provided' dependency though. This scope used for things that you compile against but don't want to redistribute (ie something that is part of the JDK, or the WebSphere UOW API - which is only used with WebSphere).

          I'm not a OSGi bundling expert, but I'd expect the maven-bundle-plugin to ignore 'provided' dependencies.

          >> openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J, Commons-logging and No logging.

          > So if you have a requirement that might be needed at runtime (e.g. log4j) and you can compile without it, it should be marked as >provided.

          If we don't need a component at compile time but is required at runtime then the scope should be runtime. If it's optional at runtime then it should be test (if tests need it) or not included at all. I think log4j fits the latter category, I'd have to check though.

          >> Ant is only needed when calling the enhancer or reverse mapping tool from Ant.

          >So ant should be a test dependency or a provided dependency.

          +1

          >> openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary and HSQLDictionary classes

          >This is interesting. These are open source libraries so there's no harm in including them. It just struck me as odd that we would have a >hard dependency on these database-specific libraries, but upon reflection, I think you're right to include them as compile dependencies.

          I think these are really 'provided' dependencies we should only instantiate the dictionaries if we're going to connect to PostgreSQL or HSQL and I'd rather not redistribute them.

          >> I still want a couple more eyes to look at this (like maybe Mike) and I want to run some more tests before committing.

          >+1

          The patch you committed looks good, but the scoping looks mostly correct as is (exception for log4j).

          What sort of tests are you running to verify the resultant bundle (forgive me if this is in another JIRA - haven't checked as close as I should)? Are there any problems that occur with 'provided' dependencies, but don't with 'compile' ones?

          Show
          Michael Dick added a comment - >> By marking <scope>compile</scope>, then those dependencies are only used at compile time and are not included as maven >>transitive dependencies, which helps maven-bundle-plugin create more accurate bundle metadata. >My understanding is different. I understand that if you have a compile-time dependency, then it's a permanent dependency that carries >through test, integration, and runtime. But I'm not a maven expert. That's my understanding as well. Compile is the heaviest dependency type and will carry through all phases. Provided is similar to compile but the jar won't included in any artifacts downstream. It will be passed along as a transitive 'provided' dependency though. This scope used for things that you compile against but don't want to redistribute (ie something that is part of the JDK, or the WebSphere UOW API - which is only used with WebSphere). I'm not a OSGi bundling expert, but I'd expect the maven-bundle-plugin to ignore 'provided' dependencies. >> openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J, Commons-logging and No logging. > So if you have a requirement that might be needed at runtime (e.g. log4j) and you can compile without it, it should be marked as >provided. If we don't need a component at compile time but is required at runtime then the scope should be runtime. If it's optional at runtime then it should be test (if tests need it) or not included at all. I think log4j fits the latter category, I'd have to check though. >> Ant is only needed when calling the enhancer or reverse mapping tool from Ant. >So ant should be a test dependency or a provided dependency. +1 >> openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary and HSQLDictionary classes >This is interesting. These are open source libraries so there's no harm in including them. It just struck me as odd that we would have a >hard dependency on these database-specific libraries, but upon reflection, I think you're right to include them as compile dependencies. I think these are really 'provided' dependencies we should only instantiate the dictionaries if we're going to connect to PostgreSQL or HSQL and I'd rather not redistribute them. >> I still want a couple more eyes to look at this (like maybe Mike) and I want to run some more tests before committing. >+1 The patch you committed looks good, but the scoping looks mostly correct as is (exception for log4j). What sort of tests are you running to verify the resultant bundle (forgive me if this is in another JIRA - haven't checked as close as I should)? Are there any problems that occur with 'provided' dependencies, but don't with 'compile' ones?
          Hide
          Donald Woods added a comment -

          >>> By marking <scope>compile</scope>, then those dependencies are only used at compile time and are not included as maven >>transitive dependencies, which helps maven-bundle-plugin create more accurate bundle metadata.
          >
          >> My understanding is different. I understand that if you have a compile-time dependency, then it's a permanent dependency that carries >through test, integration, and runtime. But I'm not a maven expert.
          >
          > That's my understanding as well.
          >
          > Compile is the heaviest dependency type and will carry through all phases.
          >
          > Provided is similar to compile but the jar won't included in any artifacts downstream. It will be passed along as a transitive 'provided' dependency though. This scope used for things that you compile against but don't want to redistribute (ie something that is part of the JDK, or the WebSphere UOW API - which is only used with WebSphere).
          >
          > I'm not a OSGi bundling expert, but I'd expect the maven-bundle-plugin to ignore 'provided' dependencies.

          Unfortunately, the m-b-p is using code dependencies (package imports) over maven scopes, so I ended up having to mark the optional/provided dependencies as do not import.

          >
          >>> openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J, Commons-logging and No logging.
          >
          >> So if you have a requirement that might be needed at runtime (e.g. log4j) and you can compile without it, it should be marked as >provided.
          >
          > If we don't need a component at compile time but is required at runtime then the scope should be runtime. If it's optional at runtime then it should be test (if tests need it) or not included at all. I think log4j fits the latter category, I'd have to check though.
          >

          log4j is required at compile time but optional at runtime, so I'll update it to provided.

          >>> Ant is only needed when calling the enhancer or reverse mapping tool from Ant.
          >
          >> So ant should be a test dependency or a provided dependency.
          >
          > +1

          Ant is already marked as provided, so no changes needed there.

          >
          >>> openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary and HSQLDictionary classes
          >
          >> This is interesting. These are open source libraries so there's no harm in including them. It just struck me as odd that we would have a >hard dependency on these database-specific libraries, but upon reflection, I think you're right to include them as compile dependencies.
          >
          > I think these are really 'provided' dependencies we should only instantiate the dictionaries if we're going to connect to PostgreSQL or HSQL and I'd rather not redistribute them.
          >
          >>> I still want a couple more eyes to look at this (like maybe Mike) and I want to run some more tests before committing.
          >
          >> +1
          >
          > The patch you committed looks good, but the scoping looks mostly correct as is (exception for log4j).
          >
          > What sort of tests are you running to verify the resultant bundle (forgive me if this is in another JIRA - haven't checked as close as I should)? Are there any problems that occur with 'provided' dependencies, but don't with 'compile' ones?
          >

          I've been using visual inspection of the created MANIFEST.MF, along with install/start the bundle in Apache Felix, to see which bundle dependencies are being marked as required imports versus what we expect at runtime.

          Thanks for reviewing and helping with the scope settings.

          Show
          Donald Woods added a comment - >>> By marking <scope>compile</scope>, then those dependencies are only used at compile time and are not included as maven >>transitive dependencies, which helps maven-bundle-plugin create more accurate bundle metadata. > >> My understanding is different. I understand that if you have a compile-time dependency, then it's a permanent dependency that carries >through test, integration, and runtime. But I'm not a maven expert. > > That's my understanding as well. > > Compile is the heaviest dependency type and will carry through all phases. > > Provided is similar to compile but the jar won't included in any artifacts downstream. It will be passed along as a transitive 'provided' dependency though. This scope used for things that you compile against but don't want to redistribute (ie something that is part of the JDK, or the WebSphere UOW API - which is only used with WebSphere). > > I'm not a OSGi bundling expert, but I'd expect the maven-bundle-plugin to ignore 'provided' dependencies. Unfortunately, the m-b-p is using code dependencies (package imports) over maven scopes, so I ended up having to mark the optional/provided dependencies as do not import. > >>> openjpa-lib - Log4J is optional, as there are LogFactoryAdapter impls for Log4J, Commons-logging and No logging. > >> So if you have a requirement that might be needed at runtime (e.g. log4j) and you can compile without it, it should be marked as >provided. > > If we don't need a component at compile time but is required at runtime then the scope should be runtime. If it's optional at runtime then it should be test (if tests need it) or not included at all. I think log4j fits the latter category, I'd have to check though. > log4j is required at compile time but optional at runtime, so I'll update it to provided. >>> Ant is only needed when calling the enhancer or reverse mapping tool from Ant. > >> So ant should be a test dependency or a provided dependency. > > +1 Ant is already marked as provided, so no changes needed there. > >>> openjpa-jdbc - Postgresql and Hsqldb are only compile time depends for the PostgresqlDictionary and HSQLDictionary classes > >> This is interesting. These are open source libraries so there's no harm in including them. It just struck me as odd that we would have a >hard dependency on these database-specific libraries, but upon reflection, I think you're right to include them as compile dependencies. > > I think these are really 'provided' dependencies we should only instantiate the dictionaries if we're going to connect to PostgreSQL or HSQL and I'd rather not redistribute them. > >>> I still want a couple more eyes to look at this (like maybe Mike) and I want to run some more tests before committing. > >> +1 > > The patch you committed looks good, but the scoping looks mostly correct as is (exception for log4j). > > What sort of tests are you running to verify the resultant bundle (forgive me if this is in another JIRA - haven't checked as close as I should)? Are there any problems that occur with 'provided' dependencies, but don't with 'compile' ones? > I've been using visual inspection of the created MANIFEST.MF, along with install/start the bundle in Apache Felix, to see which bundle dependencies are being marked as required imports versus what we expect at runtime. Thanks for reviewing and helping with the scope settings.
          Hide
          Michael Dick added a comment -

          >Unfortunately, the m-b-p is using code dependencies (package imports) over maven scopes, so I ended up having to mark the optional/provided dependencies as do not import.

          That's unfortunate, might be a bug in m-b-p or at least mentioning to them..

          Could we roll some validation with Apache Felix into the openjpa-integration module, or would the new openjpa-all be the right place?

          Show
          Michael Dick added a comment - >Unfortunately, the m-b-p is using code dependencies (package imports) over maven scopes, so I ended up having to mark the optional/provided dependencies as do not import. That's unfortunate, might be a bug in m-b-p or at least mentioning to them.. Could we roll some validation with Apache Felix into the openjpa-integration module, or would the new openjpa-all be the right place?
          Hide
          Donald Woods added a comment -

          > Could we roll some validation with Apache Felix into the openjpa-integration module, or would the new openjpa-all be the right place?

          Already working on it, as a new openjpa-integration/osgi-itest module. Taking longer than expected, due to the complex setup required to run junits using Felix, but I'm close....

          Show
          Donald Woods added a comment - > Could we roll some validation with Apache Felix into the openjpa-integration module, or would the new openjpa-all be the right place? Already working on it, as a new openjpa-integration/osgi-itest module. Taking longer than expected, due to the complex setup required to run junits using Felix, but I'm close....
          Hide
          Donald Woods added a comment -

          Patch of the OSGi integration tests, which still need some more work, but wanted to capture them here and check-in to trunk, so I can switch back to OPENJPA-1068 for now...

          Show
          Donald Woods added a comment - Patch of the OSGi integration tests, which still need some more work, but wanted to capture them here and check-in to trunk, so I can switch back to OPENJPA-1068 for now...
          Hide
          Pinaki Poddar added a comment -

          This change has modified OpenJPA examples to bring in OSGi dependency. Building examples now requires felix.
          Given that the examples are user visible artifacts – have these actions been discussed before being implemented?

          Show
          Pinaki Poddar added a comment - This change has modified OpenJPA examples to bring in OSGi dependency. Building examples now requires felix. Given that the examples are user visible artifacts – have these actions been discussed before being implemented?
          Hide
          Craig L Russell added a comment -

          > This change has modified OpenJPA examples to bring in OSGi dependency. Building examples now requires felix.

          I have no objection to packaging the examples using Felix. But I do agree with Pinaki and object to modifying the simple example to depend on Felix.

          I suggest a new example program that shows how to integrate Felix if users want to do that.

          Show
          Craig L Russell added a comment - > This change has modified OpenJPA examples to bring in OSGi dependency. Building examples now requires felix. I have no objection to packaging the examples using Felix. But I do agree with Pinaki and object to modifying the simple example to depend on Felix. I suggest a new example program that shows how to integrate Felix if users want to do that.
          Hide
          Donald Woods added a comment -

          Agree. I'm backing out the changes from openjpa-example and will use OPENJPA-1101 to create a OSGi exmaple for integration testing.

          Show
          Donald Woods added a comment - Agree. I'm backing out the changes from openjpa-example and will use OPENJPA-1101 to create a OSGi exmaple for integration testing.

            People

            • Assignee:
              Donald Woods
              Reporter:
              Donald Woods
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development