Chemistry
  1. Chemistry
  2. CMIS-324

OpenCMIS OSGI evolution and build support (Felix vs Tycho)

    Details

    • Type: Task Task
    • Status: Open
    • Priority: Trivial Trivial
    • Resolution: Unresolved
    • Affects Version/s: 0.2.0-incubating
    • Fix Version/s: OpenCMIS 1.0.0
    • Component/s: build&release
    • Labels:

      Description

      Forked from https://issues.apache.org/jira/browse/CMIS-322 to discuss OSGI support in OpenCMIS.

      Status (after 0.2.0-incuating):
      all modules are OSGI enabled with the maven-felix-plugin:

      To discuss:
      what's the best option to build OSGI bundles, distribute and update the Maven (2/3) build accordingly?

      See also comments pasted below.

        Issue Links

          Activity

          Hide
          Felix Meschberger added a comment -

          From the peanut gallery

          • Whether you use Tycho or Maven Bundle Plugin doesn't matter to the end user. What is important is, that the bundles run in any standard OSGi container. Thus using buddy class loading is probably a no-go...
          • If you have a need to extension and need to load classes use ClassLoader.loadClass (instead of Class.forName) and use the extender pattern: have the SPI implementation defined in the META-INF/services/xxxx files and do something similar to what ServiceMix does for bundle-wrapping XML libraries. See http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator/
          Show
          Felix Meschberger added a comment - From the peanut gallery Whether you use Tycho or Maven Bundle Plugin doesn't matter to the end user. What is important is, that the bundles run in any standard OSGi container. Thus using buddy class loading is probably a no-go... If you have a need to extension and need to load classes use ClassLoader.loadClass (instead of Class.forName) and use the extender pattern: have the SPI implementation defined in the META-INF/services/xxxx files and do something similar to what ServiceMix does for bundle-wrapping XML libraries. See http://svn.apache.org/repos/asf/servicemix/smx4/specs/trunk/locator/
          Hide
          Florian Müller added a comment -

          The idea is to allow exchanging an implementation of a SPI, a cache or an authentication provider without touching the code. We could create dummy methods that instanceate the default OpenCMIS classes. We don’t have to call these methods but it might be enough to satisfy a OSGi runtime.

          Show
          Florian Müller added a comment - The idea is to allow exchanging an implementation of a SPI, a cache or an authentication provider without touching the code. We could create dummy methods that instanceate the default OpenCMIS classes. We don’t have to call these methods but it might be enough to satisfy a OSGi runtime.
          Hide
          Florent Guillaume added a comment - - edited

          The code uses in a number of places Class.forName which is problematic in an OSGi environment.
          For instance CmisBindingsHelper uses it for the SPI class. To have this work in an OSGi runtime you need to have the contributed classes (which can pull a lot of dependencies) be some kind of fragment or buddy. I wonder if there's a better way to do it.

          Show
          Florent Guillaume added a comment - - edited The code uses in a number of places Class.forName which is problematic in an OSGi environment. For instance CmisBindingsHelper uses it for the SPI class. To have this work in an OSGi runtime you need to have the contributed classes (which can pull a lot of dependencies) be some kind of fragment or buddy. I wonder if there's a better way to do it.
          Hide
          Gabriele Columbro added a comment -

          Gabriele Columbro added a comment - 28/Feb/11 10:40 Nice to know...I will try it out today, maybe also the -Papache-release mvn release and site procedures (those actually worry me the most). Also, do we have some OSGI enabled modules? And if so, are bundles produced fine with Maven3 or we should consider upgrading to Tycho [1] (not backward compatible and maybe too Eclipse specific)? [1] http://tycho.sonatype.org/

          Stephan Klevenz added a comment - 28/Feb/11 11:33
          All OpenCMIS modules should be OSGi enabled by the Felix plugin currently. I have started to use OpenCMIS within an OSGi environment based on Tycho and I would be interessted to get better OpenCMIS support for Eclipse (including P2 repositories, updatesite and target definition)
          I don't know if such a support can be provided by Felix, too. If yes then I do not see a need for Tycho. In any case the support should be somehow optional

          Show
          Gabriele Columbro added a comment - Gabriele Columbro added a comment - 28/Feb/11 10:40 Nice to know...I will try it out today, maybe also the -Papache-release mvn release and site procedures (those actually worry me the most). Also, do we have some OSGI enabled modules? And if so, are bundles produced fine with Maven3 or we should consider upgrading to Tycho [1] (not backward compatible and maybe too Eclipse specific)? [1] http://tycho.sonatype.org/ Stephan Klevenz added a comment - 28/Feb/11 11:33 All OpenCMIS modules should be OSGi enabled by the Felix plugin currently. I have started to use OpenCMIS within an OSGi environment based on Tycho and I would be interessted to get better OpenCMIS support for Eclipse (including P2 repositories, updatesite and target definition) I don't know if such a support can be provided by Felix, too. If yes then I do not see a need for Tycho. In any case the support should be somehow optional

            People

            • Assignee:
              Gabriele Columbro
              Reporter:
              Gabriele Columbro
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development