Petals ESB Container

Reorganize container projects in expectation of creating the petals micro kernel

Details

  • Type: Task Task
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 4.1.0
  • Fix Version/s: 4.2.0
  • Security Level: Public
  • Description:
    Hide

    In expectation of creating the petals micro kernel, it is needed to re-organize the petals-kernel-api that contains an API used by launcher to start a container, and an API to implement internal component.

    In the new organization we introduce following expected projects (it's an example to determine the project names):

    • petals-local-transporter-default : The current implementation of the local transporter (perhaps new implementations could occur, they will name 'petals-local-transporter-xxx')
    • petals-remote-transporter-nio : the curren implementation of the remote transporter using NIO
    • petals-remote-transporter-ws : a potential future implementation of the remote transporter using SOAP over HTTP(S) (ie: web-service)
    • petals-microkernel-api: The API of {{petals-microkernel) to implement internal components and to implement Petals extensions
    • petals-microkernel: The Petals microkernel containing the internal components that can't be implemented differently and the mechanisms to load implementation of other components and extensions
    • petals-container-junit: An assembly of the petals-microkernel and selected internal component implementations to run a Petals container into a JUnit test, without Petals µKernel extension, but with default logging extensions
    • petals-container-studio: An assembly of the petals-microkernel and selected internal component implementations to run a Petals container into the Petals Studio, without Petals µKernel extension, but with default logging extensions
    • petals-container-default: An assembly of the petals-microkernel and selected internal component implementations to run a Petals as usual, without Petals µKernel extension, but with default logging extensions
    • petals-launcher-api: The API to create Petals launcher, to start/stop a container
    • petals-launcher-junit: The JUnit API able to launch (start and stop) a container into a JUnit test
    • petals-launcher-default: The existing launcher to start Petals on command line
    • petals-esb-default-zip: The current assembly of Petals ESB, as ZIP file, to install to run Petals on command line, based on petals-container-default and including also all existing Petals µKernel extensions
    • petals-esb-default-deb: The current assembly of Petals ESB, as Debian package, to install to run Petals on command line, based on petals-container-default and without extension that are provided by their own package.
    • petals-esb-junit: The JUnit API overriding petals-launcher-junit to launch a pre-configured Petals ESB (only one container running with the default value on local host), based on petals-container-junit without extension.

    The re-organization affect: petals-microkernel-api, petals-microkernel, petals-container-default, petals-launcher-api, petals-launcher, petals-esb-default-zip and petals-esb-default-deb

    Show
    In expectation of creating the petals micro kernel, it is needed to re-organize the petals-kernel-api that contains an API used by launcher to start a container, and an API to implement internal component. In the new organization we introduce following expected projects (it's an example to determine the project names):
    • petals-local-transporter-default : The current implementation of the local transporter (perhaps new implementations could occur, they will name 'petals-local-transporter-xxx')
    • petals-remote-transporter-nio : the curren implementation of the remote transporter using NIO
    • petals-remote-transporter-ws : a potential future implementation of the remote transporter using SOAP over HTTP(S) (ie: web-service)
    • petals-microkernel-api: The API of {{petals-microkernel) to implement internal components and to implement Petals extensions
    • petals-microkernel: The Petals microkernel containing the internal components that can't be implemented differently and the mechanisms to load implementation of other components and extensions
    • petals-container-junit: An assembly of the petals-microkernel and selected internal component implementations to run a Petals container into a JUnit test, without Petals µKernel extension, but with default logging extensions
    • petals-container-studio: An assembly of the petals-microkernel and selected internal component implementations to run a Petals container into the Petals Studio, without Petals µKernel extension, but with default logging extensions
    • petals-container-default: An assembly of the petals-microkernel and selected internal component implementations to run a Petals as usual, without Petals µKernel extension, but with default logging extensions
    • petals-launcher-api: The API to create Petals launcher, to start/stop a container
    • petals-launcher-junit: The JUnit API able to launch (start and stop) a container into a JUnit test
    • petals-launcher-default: The existing launcher to start Petals on command line
    • petals-esb-default-zip: The current assembly of Petals ESB, as ZIP file, to install to run Petals on command line, based on petals-container-default and including also all existing Petals µKernel extensions
    • petals-esb-default-deb: The current assembly of Petals ESB, as Debian package, to install to run Petals on command line, based on petals-container-default and without extension that are provided by their own package.
    • petals-esb-junit: The JUnit API overriding petals-launcher-junit to launch a pre-configured Petals ESB (only one container running with the default value on local host), based on petals-container-junit without extension.
    The re-organization affect: petals-microkernel-api, petals-microkernel, petals-container-default, petals-launcher-api, petals-launcher, petals-esb-default-zip and petals-esb-default-deb
  • Environment:
    -

Activity

Hide
Christophe DENEUX added a comment - Wed, 27 Mar 2013 - 12:12:04 +0100
Show
Christophe DENEUX added a comment - Wed, 27 Mar 2013 - 12:12:04 +0100 Developer guide updated: https://doc.petalslink.com/display/petalsesbsnapshot/Source+code+tree
Hide
Christophe DENEUX added a comment - Wed, 27 Mar 2013 - 10:34:22 +0100

Done in trunk

Show
Christophe DENEUX added a comment - Wed, 27 Mar 2013 - 10:34:22 +0100 Done in trunk
Hide
Christophe DENEUX added a comment - Tue, 26 Mar 2013 - 19:15:33 +0100

Don't forget to rename Java package

Show
Christophe DENEUX added a comment - Tue, 26 Mar 2013 - 19:15:33 +0100 Don't forget to rename Java package
Hide
Christophe DENEUX added a comment - Tue, 26 Mar 2013 - 15:05:02 +0100
  • petals-kernel becomes petals-microkernel from which some Fractal components will be externalized later.
  • petals-kernel-api is exploded into petals-launcher-api and petals-microkernel-api
  • petals-container-default is created as depending on petals-microkernel and existing externalized implementations
  • petals-launcher is renamed petals-launcher-default
  • petals-esb becomes petals-esb-default-zip, depends on petals-container-default and includes all existing extensions
  • petals-esb-deb becomes petals-esb-default-deb and depends on petals-container-default
Show
Christophe DENEUX added a comment - Tue, 26 Mar 2013 - 15:05:02 +0100
  • petals-kernel becomes petals-microkernel from which some Fractal components will be externalized later.
  • petals-kernel-api is exploded into petals-launcher-api and petals-microkernel-api
  • petals-container-default is created as depending on petals-microkernel and existing externalized implementations
  • petals-launcher is renamed petals-launcher-default
  • petals-esb becomes petals-esb-default-zip, depends on petals-container-default and includes all existing extensions
  • petals-esb-deb becomes petals-esb-default-deb and depends on petals-container-default

People

Dates

  • Created:
    Tue, 26 Mar 2013 - 12:17:51 +0100
    Updated:
    Wed, 27 Mar 2013 - 12:12:05 +0100
    Resolved:
    Wed, 27 Mar 2013 - 10:34:22 +0100