Petals CDK

For the moment, the CDK is both a library and a framework. It is a library because it contains utility classes, interfaces and abtracts classes to develop components. It is a framework because it has a specific configuration, in both components and service-units. This ambiguity does not ease the work with the CDK. I would rather see a split between these two aspects. We would have a CDK library, with interfaces, abstracts classes and utilities. This library would be an extension of the JBI libraries. And we would have a framework, as a code generation and validation tool. This tool could be used in the Petals Maven plug-in and in the studio. In fact, it would replace a part of the current component creation part in the Maven plug-in. It would support a customized generation, depending on the component type (SE, BC), creation patterns, default WSDL, MEP to support, etc. It would generate configuration parsers, code skeletons to complete, configuration file templates and so on. The generated code would rely on the CDK library. It would be independent of any tool or technology (neither the studio, nor Maven). Obviously, the framework should not only support the creation of a component, but also component upgrades. That is to say, it should be done to support iterative developments. One way to do that, would be to have a description file. We complete it and give it to the framework, that creates or updates code. This configuration file would define some component properties and may define which services have to be created or enabled. Updating a component would consist in updating this configuration, going though a code generation step, and complete/correct the implementation. To make things easy to handle, there should be two source folders: one for the entirely generated elements (e.g. interfaces, base parsers) and one for skeletons to complete. Both should support the merge/overwrite of code (tools like JMerge support it). Updating an existing component would replace the interfaces, but keep the implementations. The Java builder (of any IDE) would directly signal what is not synchronized. The most challenging part, like in any code generation tool, would be to find the exact balance between the productivty gains, and the developer's freedom. Given our experience, I think we can find it. Such a change would rather be for a major release of the CDK. But the next CDK upgrades could try to reduce the dsitance between what there is today and what there should be in the future.