Spring Data JPA
  1. Spring Data JPA
  2. DATAJPA-178

Ensure Spring Data JPA & QueryDSL work in OSGi

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Works as Designed
    • Affects Version/s: 1.1 RC1
    • Fix Version/s: None
    • Component/s: Core, Infrastructure
    • Environment:
      JDK 1.6.0_30, Win 7 & Ubuntu 11.10, all 64-bit

      Description

      Spring Data JPA expresses dependencies on QueryDSL JPA, but I'm having trouble loading these in OSGi. I'm getting several resolution errors due to the various packages that QueryDSL JPA depends on.

      Although this seems like it's more to be blamed on QueryDSL, I'm still entering an issue here to track it. Judging by the number of QueryDSL-related issues found in Spring Data JPA, this seems more like a process or coordination issue with QueryDSL than a technical one.

      I'll enter an issue at QueryDSL as well to encourage coordination between the two projects.

        Activity

        Hide
        Oliver Gierke added a comment -

        The simple story is: we're creating OSGi manifests that are valid. We can't be responsible for the manifests of libraries we depend on. So it's best to keep track of that in the according libraries bug tracker. Otherwise we get flooded with tickets claim about OSGi issues of any JAR that might be used in combination with ours.

        Show
        Oliver Gierke added a comment - The simple story is: we're creating OSGi manifests that are valid. We can't be responsible for the manifests of libraries we depend on. So it's best to keep track of that in the according libraries bug tracker. Otherwise we get flooded with tickets claim about OSGi issues of any JAR that might be used in combination with ours.
        Hide
        Oliver Gierke added a comment -

        On a side note: we are in close contact with Timo and the Querydsl team in general, so if there's anything we can do on our side we'll get that sorted out. Having that said, feel free to open a ticket in case you spot any issues with the manifests we ship. I just don't think it's reasonable to have a general "please work together" ticket - we already do and thus cannot actually bring this ticket to a reasonable solution in any way (closing it at as resolved some point I mean).

        Show
        Oliver Gierke added a comment - On a side note: we are in close contact with Timo and the Querydsl team in general, so if there's anything we can do on our side we'll get that sorted out. Having that said, feel free to open a ticket in case you spot any issues with the manifests we ship. I just don't think it's reasonable to have a general "please work together" ticket - we already do and thus cannot actually bring this ticket to a reasonable solution in any way (closing it at as resolved some point I mean).
        Hide
        Matthew T. Adams added a comment -

        Understood. Perhaps specifying a more liberal version range in SD JPA 1.1.x's *Maven* dependency on QueryDSL might help, since the release frequency of QueryDSL has been a bit higher lately.

        How about [2.3.0,3.0.0), like it is in the SD JPA bundle manifest?

        Timo claims that the OSGi manifest is improved in 2.3.2. See https://groups.google.com/forum/#!topic/querydsl/ht-FcJd88lg and https://github.com/mysema/querydsl/pull/73.

        The two major things I came across are that some libraries QueryDSL depends on aren't OSGi-ified (like net.sourceforge.collections:collections-generic:4.01) and that it seems some dependencies which appear to be compile-time-only dependencies are required at runtime (codegen, findbugs, & others). Those Maven scopes need to be "provided", not "compile", I believe.

        I'll point Timo at this comment as well.

        Show
        Matthew T. Adams added a comment - Understood. Perhaps specifying a more liberal version range in SD JPA 1.1.x's * Maven * dependency on QueryDSL might help, since the release frequency of QueryDSL has been a bit higher lately. How about [2.3.0,3.0.0), like it is in the SD JPA bundle manifest? Timo claims that the OSGi manifest is improved in 2.3.2. See https://groups.google.com/forum/#!topic/querydsl/ht-FcJd88lg and https://github.com/mysema/querydsl/pull/73 . The two major things I came across are that some libraries QueryDSL depends on aren't OSGi-ified (like net.sourceforge.collections:collections-generic:4.01) and that it seems some dependencies which appear to be compile-time-only dependencies are required at runtime (codegen, findbugs, & others). Those Maven scopes need to be "provided", not "compile", I believe. I'll point Timo at this comment as well.
        Hide
        Oliver Gierke added a comment -

        I don't get the connection between the Maven version and the OSGi version you imply. We state 2.3.0 as Maven dependency version, resulting in an OSGi version range of [2.3.0, 3.0.0). So you can use any Querydsl version >= 2.3.0 with it from a Maven point of view and anything up to 3.0.0 from an OSGi point of view.

        All other observations you took are completely Querydsl related.

        Show
        Oliver Gierke added a comment - I don't get the connection between the Maven version and the OSGi version you imply. We state 2.3.0 as Maven dependency version, resulting in an OSGi version range of [2.3.0, 3.0.0) . So you can use any Querydsl version >= 2.3.0 with it from a Maven point of view and anything up to 3.0.0 from an OSGi point of view. All other observations you took are completely Querydsl related.
        Hide
        Oliver Gierke added a comment -

        In other words: what is the problem you face SD JPA could help you with/improve?

        Show
        Oliver Gierke added a comment - In other words: what is the problem you face SD JPA could help you with/improve?
        Hide
        Matthew T. Adams added a comment -

        Ah, when I wrote that, I'd forgotten about the Maven-version-to-OSGi-version-range translation done by maven-bundle-plugin.

        QueryDSL is a good & mature product. Pragmatically speaking, I just want there to be minimal OSGi friction for SD users that choose to use QueryDSL!

        I suppose from SD JPA's perspective, there's not much more that you can do except advise Timo. Thanks!

        Show
        Matthew T. Adams added a comment - Ah, when I wrote that, I'd forgotten about the Maven-version-to-OSGi-version-range translation done by maven-bundle-plugin. QueryDSL is a good & mature product. Pragmatically speaking, I just want there to be minimal OSGi friction for SD users that choose to use QueryDSL! I suppose from SD JPA's perspective, there's not much more that you can do except advise Timo. Thanks!

          People

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

            Dates

            • Created:
              Updated:
              Resolved: