Uploaded image for project: 'Sling'
  1. Sling
  2. SLING-3019

Provide a mechanism to install a bundle based on a directory

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Component/s: IDE
    • Labels:
      None

      Description

      With an IDE integration and incremental builds, it would be great to have a mechanism to install/update a bundle based on the output directory of a project.

      I'll start with a prototype of a bundle which receives post requests containing the path of a local directory. The servlet will then either install or update the bundle from that directory

      For this to work, the scr descriptor files of a project should go into a bundle. So configure the scr plugin like this:
      <plugin>
      <groupId>org.apache.felix</groupId>
      <artifactId>maven-scr-plugin</artifactId>
      <configuration>
      <outputDirectory>$

      {project.build.directory}

      /classes</outputDirectory>
      </configuration>
      </plugin>

        Activity

        Hide
        cziegeler Carsten Ziegeler added a comment -

        Added a first prototype implementation - posting to /system/sling/tooling/install with the parameter "dir" pointing to a directory, installs or updates the bundle from there.

        Show
        cziegeler Carsten Ziegeler added a comment - Added a first prototype implementation - posting to /system/sling/tooling/install with the parameter "dir" pointing to a directory, installs or updates the bundle from there.
        Hide
        rombert Robert Munteanu added a comment - - edited

        Carsten Ziegeler, Stefan Egli - I've taken a look at the implementation and I'm wondering why we make Sling update the bundle based on the local directory, instead of building the jar on the client side and then uploading it.

        Thinking in that direction, couldn't we reuse the Felix/JCR Install mechanisms for uploading bundles?

        The reason I'm asking is that this incremental deploy only works on localhost, and for remote deployments we can only use Maven deployment, which is IMO too slow ( and also still not done right, see SLING-3134 for instance).

        Show
        rombert Robert Munteanu added a comment - - edited Carsten Ziegeler , Stefan Egli - I've taken a look at the implementation and I'm wondering why we make Sling update the bundle based on the local directory, instead of building the jar on the client side and then uploading it. Thinking in that direction, couldn't we reuse the Felix/JCR Install mechanisms for uploading bundles? The reason I'm asking is that this incremental deploy only works on localhost, and for remote deployments we can only use Maven deployment, which is IMO too slow ( and also still not done right, see SLING-3134 for instance).
        Hide
        cziegeler Carsten Ziegeler added a comment -

        Sure, we could upload the whole jar, but this requires more work to do in Eclipse - instead of just doing a simple ping to the server.
        I believe that in the local case, the current mechanism is a little bit faster (we could even improve and create the jar just in memory).
        The alternative would be to post against the web console and let the web console do the stuff (install or update, refresh packages etc.) - this would be the same as the maven sling plugin does ootb

        Show
        cziegeler Carsten Ziegeler added a comment - Sure, we could upload the whole jar, but this requires more work to do in Eclipse - instead of just doing a simple ping to the server. I believe that in the local case, the current mechanism is a little bit faster (we could even improve and create the jar just in memory). The alternative would be to post against the web console and let the web console do the stuff (install or update, refresh packages etc.) - this would be the same as the maven sling plugin does ootb
        Hide
        rombert Robert Munteanu added a comment -

        Fair enough.

        I think that I'd like to have two mechanisms - one which works on local directories, and is simpler, and one which works by POSTing jars, without going through Maven. But that's another discussion.

        Show
        rombert Robert Munteanu added a comment - Fair enough. I think that I'd like to have two mechanisms - one which works on local directories, and is simpler, and one which works by POSTing jars, without going through Maven. But that's another discussion.
        Hide
        egli Stefan Egli added a comment -

        I think that I'd like to have two mechanisms

        +1

        Show
        egli Stefan Egli added a comment - I think that I'd like to have two mechanisms +1
        Hide
        cziegeler Carsten Ziegeler added a comment -

        Yes, I think we should go the full way and enhance the current install bundle to also take a jar via post and install it - so we won't rely on any additional stuff being there (like the web console etc) and the only difference between those two mechanisms would be that the local case first creates the jar and performs the action while the remote gets the jar and performs the exact same action.

        Show
        cziegeler Carsten Ziegeler added a comment - Yes, I think we should go the full way and enhance the current install bundle to also take a jar via post and install it - so we won't rely on any additional stuff being there (like the web console etc) and the only difference between those two mechanisms would be that the local case first creates the jar and performs the action while the remote gets the jar and performs the exact same action.
        Hide
        rombert Robert Munteanu added a comment -

        I'm facing the problem that it's possible to post to /system/sling/tooling/install and get back an 200 OK response since the jar file will simply be uploaded. We could either:

        • respond to GET calls with a well-known JSON reply, like {"status: "OK", "message": "InstallServlet present"}
        • respond to successful POST calls with a well-known JSON reply, like {"status": "OK", "message": "Bundle installed successfully"}

        I see problems with both approaches - first one is check-then-act, second one can leave cruft in the repository, but I slightly lean towards the first.

        Any preferences?

        Show
        rombert Robert Munteanu added a comment - I'm facing the problem that it's possible to post to /system/sling/tooling/install and get back an 200 OK response since the jar file will simply be uploaded. We could either: respond to GET calls with a well-known JSON reply, like {"status: "OK", "message": "InstallServlet present"} respond to successful POST calls with a well-known JSON reply, like {"status": "OK", "message": "Bundle installed successfully"} I see problems with both approaches - first one is check-then-act, second one can leave cruft in the repository, but I slightly lean towards the first. Any preferences?
        Hide
        cziegeler Carsten Ziegeler added a comment -

        I assume with the first solution you mean, that first a GET is done and when it returns the correct answer, you do a POST?
        I personally would go with the second one.
        The IDE does a check if the bundle is installed e.g. when the server is connected / started. From this point one can assume that its available

        Show
        cziegeler Carsten Ziegeler added a comment - I assume with the first solution you mean, that first a GET is done and when it returns the correct answer, you do a POST? I personally would go with the second one. The IDE does a check if the bundle is installed e.g. when the server is connected / started. From this point one can assume that its available
        Hide
        rombert Robert Munteanu added a comment -

        I assume with the first solution you mean, that first a GET is done and when it returns the correct answer, you do a POST?

        Yes, that's right.

        I personally would go with the second one (snip)

        OK, I'll use the second one then. Thanks!

        Show
        rombert Robert Munteanu added a comment - I assume with the first solution you mean, that first a GET is done and when it returns the correct answer, you do a POST? Yes, that's right. I personally would go with the second one (snip) OK, I'll use the second one then. Thanks!
        Hide
        rombert Robert Munteanu added a comment -

        I'm almost ready to commit some changes I've made to reflect the above comments. One thing I'm not sure of is when we need to call packageAdmin.refreshPackages(bundle). I'm sure we need to call it after a bundle is updated, but do we need to call it after it is installed?

        Show
        rombert Robert Munteanu added a comment - I'm almost ready to commit some changes I've made to reflect the above comments. One thing I'm not sure of is when we need to call packageAdmin.refreshPackages(bundle). I'm sure we need to call it after a bundle is updated, but do we need to call it after it is installed?
        Hide
        cziegeler Carsten Ziegeler added a comment -

        Yes, a refresh package after an install helps if other bundles have optional imports which are now satisfied

        Show
        cziegeler Carsten Ziegeler added a comment - Yes, a refresh package after an install helps if other bundles have optional imports which are now satisfied
        Hide
        egli Stefan Egli added a comment -

        Could this be treated as an option? (and eg configured in the wst-server config)

        Show
        egli Stefan Egli added a comment - Could this be treated as an option? (and eg configured in the wst-server config)
        Hide
        rombert Robert Munteanu added a comment -

        I think that for correctness reasons this should be done always. Also, the package exports are refreshed for the deployed bundle only so the performance impact should be minimal.

        Show
        rombert Robert Munteanu added a comment - I think that for correctness reasons this should be done always. Also, the package exports are refreshed for the deployed bundle only so the performance impact should be minimal.
        Hide
        rombert Robert Munteanu added a comment -

        I've implemented the items we've discussed above:

        I'm leaving this open in case anyone spots any implementation mistakes or would like some changes made, but I think the feature set is enough for the current Sling IDE Tooling use cases.

        Show
        rombert Robert Munteanu added a comment - I've implemented the items we've discussed above: Return messages to clients in JSON format in http://svn.apache.org/viewvc?view=revision&revision=1534644 Allow installing/updating a bundle from an uploaded jar file in http://svn.apache.org/viewvc?view=revision&revision=1534645 Some code cleanups in http://svn.apache.org/viewvc?view=revision&revision=1534646 Refresh packages in install/update in http://svn.apache.org/viewvc?view=revision&revision=1534647 I'm leaving this open in case anyone spots any implementation mistakes or would like some changes made, but I think the feature set is enough for the current Sling IDE Tooling use cases.
        Hide
        rombert Robert Munteanu added a comment -

        I consider this fixed. We can always file follow-up issues if needed, but right now I prefer closing and cutting a first release.

        Show
        rombert Robert Munteanu added a comment - I consider this fixed. We can always file follow-up issues if needed, but right now I prefer closing and cutting a first release.

          People

          • Assignee:
            cziegeler Carsten Ziegeler
            Reporter:
            cziegeler Carsten Ziegeler
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development