Uploaded image for project: 'Tools (JBoss Tools)'
  1. Tools (JBoss Tools)
  2. JBIDE-11166

Supporting multi-module projects in OpenShift Deployment

    XMLWordPrintable

Details

    • Hide
      OpenShift tooling now works with multi-module maven projects. One caveat is that if your root project is just a "pom" project it will not show up as an independent deployed module under the server but doing Publish will perform the right git commit/push as needed.
      Show
      OpenShift tooling now works with multi-module maven projects. One caveat is that if your root project is just a "pom" project it will not show up as an independent deployed module under the server but doing Publish will perform the right git commit/push as needed.
    • Not Required

    Description

      POH5 archetype recently got updated and became the first project layout that requires support for multimodule project layouts.

      What they have is the following:

      Aggregator Project "AP" includes two child projects "A" and "B".

      This is the simplest case - but you could also easily have more complex layouts,
      i.e. AP includes another aggregatorproject QAP which nest other child projects.

      But the key point is that the "root" in OpenShift is considered the Aggegator project.

      And this is the kind of layout we would need to support, and I see the following things we need to check/implement to make it happen:

      A) The "magic" project on our OpenShift server adapter should be allowed to be any kind of project as long as it has git enabled on it.
      B) OpenShift Server Adapter should not deploy any child of Aggregator as binary by default
      C) Import of OpenShift Application should be sure it will actually import a multimodule project.
      D) Import of OpenShift App when using existing App would need to do some validity checks and somehow ensure the child projects gets available if they aren't imported (maybe a warning is enough?)

      I belive A and C should be trivially implemented if not already.

      B should be as simple as checking the phyiscal location. i.e. if A is a subdir within AP then dont deploy. i.e. /Users/max/ap is parent for project A stored in /Users/max/ap/x/y/z/a

      D is the hard part.

      Attachments

        Issue Links

          Activity

            People

              rob.stryker Rob Stryker (Inactive)
              manderse@redhat.com Max Andersen
              Isaac Rooskov Isaac Rooskov (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: