3 Replies Latest reply on Sep 14, 2006 12:55 PM by starksm64

    Integration of new deployers into MC-VDF-WORK

      I've partially integrated the new deployer stuff into MC-VDF-WORK

      What is left to do:

      1) Service ClassLoader Deployer - UCL ClassLoading
      I'm going to assume for now that we are creating a UCL
      like the old sar deployer did. In fact, for now, I'm going to use
      this as THE classloader deployer.

      2) The profile service api needs updating to the new deployers
      and vfs api.

      3) Some tests :-)

        • 1. Re: Integration of new deployers into MC-VDF-WORK
          starksm64

          An spi to convert a raw deployment archive into a DeploymentContext is missing from the updated MainDeployer. I have to go to the AbstractDeploymentContext implementation in plugins to associate a raw deployment archive to a DeploymentContext via a VirtualFile.

          For the jsr88 aspect of the profile service I at least need a way to obtain the StructureDeployer to populate the AbstractDeploymentContext given the deployment VirtualFile to add to the profile. A mapping of the ManagedObject(s) for the DeploymentContext is also missing.

          • 2. Re: Integration of new deployers into MC-VDF-WORK

            I know. The DeploymentContext is just a big fat interface of rubbish.
            It needs at least 4 different views:
            1) The structure view
            2) The deployment view
            3) The management view
            4) The profile view
            +
            5) The internal view of the MainDeployer of which the others
            are facades.

            I would have prefered to have had time to prototype the whole
            deployment layer and its interaction with the profile service etc.

            Instead we are doing it incremently.

            • 3. Re: Integration of new deployers into MC-VDF-WORK
              starksm64

              Ok, I think we need to add placeholder methods for these views so we can move this to head and will be able to refactor the monolithic contract instead of trying to introduce new contracts.