Aaron Mulder wrote:
On Mon, 26 Jan 2004, Jeremy Boynes wrote:
So for 88 to be useful, the vendor must support having all their DD information in one file? But the RI does not that...
Now you are being dense.
Seemed so, so Aaron and I had a not-so-quick chat. Summary says:
88 assumes that all configuration information is saved in one file created by DeploymentConfiguration.save(OutputStream). This should contain all information needed by the plugin/server to convert a 'naked' input file into a runnable configuration.
This is a change from the way most vendors currently store information in the module files themselves - a 'dressed' module.
Backward compatibility can be obtained by having the plugin read additional information out the 'dressed' source during distribute. We could support this style of deployment by:
* reading the deployment plan supplied to distribute
* seeing that the plan did not contain our information for a module
* looking in the module archive for a vendor dd
* picking suitable defaults if they are missing
What we don't get is vendor neutral conversion from old-style dressed archives to the new 'naked' + stack of clothes model. A tool could do that but it would up to the tool.
Although it does not mandate it, the spec recommends that the format of the deployment plan is XML. If we assume that, then we can use the current method of determining the module type from the deployment plan - this parses the stream and uses the root element to decide.
I think this is workable. Now we need to define a mechanism whereby module deployment plugins can hook their DConfigBeans into the deployment core and generate an XML form of their configuration. We also need to provide a mechanism for merging these together when the modules are packaged together into an EAR.
-- Jeremy
