Karaf
  1. Karaf
  2. KARAF-1333

Support for M2E workspace resolution via reference: protocol

    Details

      Description

      Eclipse M2E plugin provides a 'workspace resolution' mode where Maven projects in Eclipse workspace are provided as workspace repository which takes precedence over other repositories.

      This leads to situation where artifact file isn't necessarily yet - depending on Mavens current lifecycle phase - provided as .jar but instead as directory pointing to project's output directory.

      <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0" name="example">
          <feature name="example" description="example">
              <bundle>mvn:com/example/dependency/1.0.0</bundle>
              ...
              <bundle>mvn:com/example/project/0.0.1-SNAPSHOT</bundle>
              ...
          </feature>
      </features>
      

      The patches provided in this issue not only takes care of treating directories as exploded .jar files (common approach) but also provisions them with reference: protocol that most of the OSGi frameworks understand as direct filesystem references thus allowing exploded .jars to be installed.

      <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0" name="example">
          <feature name="example" description="example">
              <bundle>mvn:com/example/dependency/1.0.0</bundle>
              ...
              <bundle>reference:file:/~/workspace/example-project/classes/</bundle>
              ...
          </feature>
      </features>
      

      Without intermediate round-trip via OSGi framework's bundle cache the 'workspace resolution' mode now offers also hot code replacement.

      1. FeaturesServiceImpl.patch
        5 kB
        Tuomas Kiviaho
      2. maven-plugin.patch
        14 kB
        Tuomas Kiviaho

        Activity

        Tuomas Kiviaho created issue -
        Hide
        Tuomas Kiviaho added a comment -

        patches contain improvements for both generate and validate goals in backwards compatible manner without new parameters

        Show
        Tuomas Kiviaho added a comment - patches contain improvements for both generate and validate goals in backwards compatible manner without new parameters
        Tuomas Kiviaho made changes -
        Field Original Value New Value
        Attachment FeaturesServiceImpl.patch [ 12521660 ]
        Attachment maven-plugin.patch [ 12521661 ]
        Tuomas Kiviaho made changes -
        Summary Support for M2E workspace reresolution via reference: protocol Support for M2E workspace resolution via reference: protocol
        Description Eclipse M2E plugin provides a 'workspace resolution' mode where Maven projects in Eclipse workspace are provided as workspace repository which takes precedence over other repositories.

        This leads to situation where artifact file isn't necessarily yet - depending on Mavens current lifecycle phase - provided as .jar but instead as as directory pointing to project's output directory.

        The patches provided in this issue not only takes care of treating directories as exploded .jar files (common approach) but also provisions them with reference: protocol that most of the OSGi frameworks understand as direct filesystem references thus allowing exploded .jars to be installed.

        Without intermediate round-trip via OSGi framework's bundle cache the 'workspace resolution' mode now offers also hot code replacement.

        Eclipse M2E plugin provides a 'workspace resolution' mode where Maven projects in Eclipse workspace are provided as workspace repository which takes precedence over other repositories.

        This leads to situation where artifact file isn't necessarily yet - depending on Mavens current lifecycle phase - provided as .jar but instead as as directory pointing to project's output directory.

        The patches provided in this issue not only takes care of treating directories as exploded .jar files (common approach) but also provisions them with reference: protocol that most of the OSGi frameworks understand as direct filesystem references thus allowing exploded .jars to be installed.

        Without intermediate round-trip via OSGi framework's bundle cache the 'workspace resolution' mode now offers also hot code replacement.

        {code:xml}
        <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0" name="example">
            <feature name="example" description="example">
                ...
                <bundle>reference:file:/~/workspace/example/classes/</bundle>
                ...
            </feature>
        </features>
        {code}
        Tuomas Kiviaho made changes -
        Description Eclipse M2E plugin provides a 'workspace resolution' mode where Maven projects in Eclipse workspace are provided as workspace repository which takes precedence over other repositories.

        This leads to situation where artifact file isn't necessarily yet - depending on Mavens current lifecycle phase - provided as .jar but instead as as directory pointing to project's output directory.

        The patches provided in this issue not only takes care of treating directories as exploded .jar files (common approach) but also provisions them with reference: protocol that most of the OSGi frameworks understand as direct filesystem references thus allowing exploded .jars to be installed.

        Without intermediate round-trip via OSGi framework's bundle cache the 'workspace resolution' mode now offers also hot code replacement.

        {code:xml}
        <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0" name="example">
            <feature name="example" description="example">
                ...
                <bundle>reference:file:/~/workspace/example/classes/</bundle>
                ...
            </feature>
        </features>
        {code}
        Eclipse M2E plugin provides a 'workspace resolution' mode where Maven projects in Eclipse workspace are provided as workspace repository which takes precedence over other repositories.

        This leads to situation where artifact file isn't necessarily yet - depending on Mavens current lifecycle phase - provided as .jar but instead as directory pointing to project's output directory.

        {code:xml}
        <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0" name="example">
            <feature name="example" description="example">
                <bundle>mvn:com/example/dependency/1.0.0</bundle>
                ...
                <bundle>mvn:com/example/project/0.0.1-SNAPSHOT</bundle>
                ...
            </feature>
        </features>
        {code}

        The patches provided in this issue not only takes care of treating directories as exploded .jar files (common approach) but also provisions them with reference: protocol that most of the OSGi frameworks understand as direct filesystem references thus allowing exploded .jars to be installed.

        {code:xml}
        <features xmlns="http://karaf.apache.org/xmlns/features/v1.0.0" name="example">
            <feature name="example" description="example">
                <bundle>mvn:com/example/dependency/1.0.0</bundle>
                ...
                <bundle>reference:file:/~/workspace/example-project/classes/</bundle>
                ...
            </feature>
        </features>
        {code}

        Without intermediate round-trip via OSGi framework's bundle cache the 'workspace resolution' mode now offers also hot code replacement.
        Hide
        Tuomas Kiviaho added a comment -

        I noticed that the codebase has had some grooming but the patches still apply with trivial adjustments.

        Show
        Tuomas Kiviaho added a comment - I noticed that the codebase has had some grooming but the patches still apply with trivial adjustments.
        Hide
        Tuomas Kiviaho added a comment -

        http://team.ops4j.org/browse/PAXURL-144 would provide an alternative approach to deal with the issue provided that Pax URL Reference hander is changed so that it will throw exception at getInputstream instead of postponing it to read() method as it currently does. This way features service could remain totally URL agnostic so that installBundle will only be provided a stream to use when it can be achieved.

        URL carrying multiple alternative locations (perhaps using Content-Location header http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14) would require some sort preference/fallback queue for protocols so that correct url is chosen.

        Show
        Tuomas Kiviaho added a comment - http://team.ops4j.org/browse/PAXURL-144 would provide an alternative approach to deal with the issue provided that Pax URL Reference hander is changed so that it will throw exception at getInputstream instead of postponing it to read() method as it currently does. This way features service could remain totally URL agnostic so that installBundle will only be provided a stream to use when it can be achieved. URL carrying multiple alternative locations (perhaps using Content-Location header http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.14 ) would require some sort preference/fallback queue for protocols so that correct url is chosen.
        Jean-Baptiste Onofré made changes -
        Assignee Jean-Baptiste Onofré [ jbonofre ]
        Jean-Baptiste Onofré made changes -
        Fix Version/s 3.0.1 [ 12316945 ]
        Jean-Baptiste Onofré made changes -
        Fix Version/s 3.1.0 [ 12316946 ]
        Jean-Baptiste Onofré made changes -
        Fix Version/s 3.0.2 [ 12326261 ]
        Fix Version/s 3.0.1 [ 12316945 ]

          People

          • Assignee:
            Jean-Baptiste Onofré
            Reporter:
            Tuomas Kiviaho
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development