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
  • Component/s: Component framework, Launcher
  • 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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Christophe DENEUX made changes - Tue, 26 Mar 2013 - 15:05:02 +0100
Field Original Value New Value
Status New [ 10000 ] Open [ 10002 ]
Priority Major [ 3 ]
Christophe DENEUX made changes - Tue, 26 Mar 2013 - 15:07:47 +0100
Fix Version/s 4.2.0 [ 10356 ]
Description 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,
* {{petals-container-studio}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals container into the Petals Studio,
* {{petals-container-default}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals as usual,
* {{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
* {{petals-esb-default-deb}}: The current assembly of Petals ESB, as Debian package, to install to run Petals on command line
* {{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).

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}} 		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 extension_
* {{petals-container-studio}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals container into the Petals Studio, _without extension_
* {{petals-container-default}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals as usual, _without extension_
* {{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, _including also all existing extensions_
* {{petals-esb-default-deb}}: The current assembly of Petals ESB, as Debian package, to install to run Petals on command line, _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), _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}}
Christophe DENEUX made changes - Tue, 26 Mar 2013 - 15:08:58 +0100
Description 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 extension_
* {{petals-container-studio}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals container into the Petals Studio, _without extension_
* {{petals-container-default}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals as usual, _without extension_
* {{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, _including also all existing extensions_
* {{petals-esb-default-deb}}: The current assembly of Petals ESB, as Debian package, to install to run Petals on command line, _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), _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}} 		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 extension_*
* {{petals-container-studio}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals container into the Petals Studio, *_without extension_*
* {{petals-container-default}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals as usual, *_without extension_*
* {{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, *_including also all existing extensions_*
* {{petals-esb-default-deb}}: The current assembly of Petals ESB, as Debian package, to install to run Petals on command line, *_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), *_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}}
Christophe DENEUX made changes - Tue, 26 Mar 2013 - 15:27:04 +0100
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
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
Christophe DENEUX made changes - Tue, 26 Mar 2013 - 19:39:10 +0100
Description 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 extension_*
* {{petals-container-studio}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals container into the Petals Studio, *_without extension_*
* {{petals-container-default}}: An assembly of the {{petals-microkernel}} and selected internal component implementations to run a Petals as usual, *_without extension_*
* {{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, *_including also all existing extensions_*
* {{petals-esb-default-deb}}: The current assembly of Petals ESB, as Debian package, to install to run Petals on command line, *_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), *_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}} 		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}}
Hide
Permalink
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
Christophe DENEUX made changes - Wed, 27 Mar 2013 - 10:34:22 +0100
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Permalink
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

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
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
2h 47m
1
Christophe DENEUX
Tue, 26 Mar 2013 - 15:05:02 +0100
Open Open In Progress In Progress
22m 2s
1
Christophe DENEUX
Tue, 26 Mar 2013 - 15:27:04 +0100
In Progress In Progress Resolved Resolved
19h 7m
1
Christophe DENEUX
Wed, 27 Mar 2013 - 10:34:22 +0100



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
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.