1 Reply Latest reply on Jul 29, 2014 7:58 AM by eric.wittmann

    Tooling repo

    objectiser

      Looking ahead to the next development tasks, there are a number of new UIs that will be created, that are more focused on the development phase of the software lifecycle. Most of these UIs will be related to RTGov (e.g. creating editors for Event Processor Networks, etc), but may also apply to the wider scope of DTGov.

       

      Currently the sub-projects are providing runtime components and admin consoles. We can either add the 'developer focused' tooling as additional UIs within the relevant sub-projects, or create them in a single "tooling" git repo.

       

      Some reasons I prefer the separate repo:

       

      • The tools will be spanning across sub-project boundaries - e.g. when creating an EPN, we might want to reference services available in SRAMP. Although this could still be achieved with the UI being developed in the RTGov repo, it makes it easier to develop reusable capabilities that sit above all of the sub-projects, if defined in a separate repo.
      • As mentioned, the existing repos are more focused on the runtime capabilities, with their UIs primarily for administration/end-user usage. The UIs that would be in the tooling repo are more focused on developers or business analysts that are creating artifacts (e.g. policies). The style of the UIs may be slightly different from the admin consoles - although they would use the same SSO mechanism.

       

      Downsides:

      • If installing just some sub-projects, then we would need some way for the tooling to understand what should be made available to the user
        • shouldn't really be an issue, as the tooling is generally decoupled from the runtime environments. The only exception may be access to a SRAMP repo, which should be optional.

       

      Thoughts?

        • 1. Re: Tooling repo
          eric.wittmann

          I'm in favor of a separate repository.  We can simply build all of the components we need and enable/disable them depending on the discovery of available runtimes (rtgov, dtgov, s-ramp).  I  think that will be much easier than trying to create tooling in all the sub-projects and somehow integrating them.

           

          It also means that the GWT build cycle for the tooling doesn't slow down the builds of the runtimes.  We have enough of that already.