And this is only about the way Petals parses jbi.xml files.
Get prepared for some reading! 
You could also think about finding a common solution for both the platform and the tooling (Maven, Eclipse, whatever). The best solution would be to have a single module that handles parsing and validation for the CDK. Same thing for every component.
Moreover, the way it is done currently in the server part was designed this way because of the XSD redefine keyword. This feature allowed to redefine an element in XSD 1.0. The idea was to refine the jbi type in the CDK, and then in the component. Unfortunately, but for obvious reasons, this keyword was deprecated in XSD 1.1. Thus, the XML configuration of Petals files relies on dirty hacks and is hardly manageable.
Still for history, even if the redefine keyword seemed a clean solution at the time, JAX-B never supported it. So, basically, the way jbi.xml files are defined never worked efficiently, neither in implementation, nor in design. You either have to use any elements, or you have to create a big XML schema that defines everything (take a look at Petals Studio, there is such one big nasty XSD for the Eclipse XML editor). The current option does not allow modularity and extensibility in an efficient manner.
This organization was implemented by the end of 2007. It has been discussed hundreds of times until 2012, with Roland Naudin, Nicolas Salatgé and many others. Everytime, no action was undertaken because there were so called other priorities. This has also slowed down the creation of tools (Eclipse to not mention it). The studio has its own parser for configuration files (and it's really messy). And in fact, there has been two different parsers implemented (one with a XSD parser, another one based on EMF, both with the intent of generating user interfaces - almost - automatically from the model, which has been another long-time requirement from the team leaders).
IMO, the way jbi.xml files are organized is only good for trash.
The way there are parsed and retrieved in the components and above (CDK, container) is also inefficient. In my last work period on Petals, we were focused on other issues related to user features in exploitation environments (monitoring, logs, etc). But if I had continued to work on Petals, this topic would come number one on the todo-list. If you look at the studio's code on GitHub, there is a branch called properties-model. You will find a plugin called com.ebmwebsourcing.petals.studio.dev.properties. The idea I explored back then was to split the jbi.xml file (keep the standard part, move the CDK configuration in a distinct properties file, and move the component in another properties file). If you look at Petals components, they only have simple properties. Same thing for the CDK, except it has also few (simple) lists. The idea behind the library was to...
- ... define the model in properties files. Parameters are property names. Default values are property values. And types and optionality would be defined in comments with a simple syntax.
- ... simplify the Petals wizards in the studio. Instead of giving parameter values, just select which component version you want to configure through a SU and generate a pre-filled project.
- ... move the project edition entirely in editors. Most of the UI could be generated or enriched from the model.
- ... define core modules, one per CDK version and one per component version. Such a module would contain an annotated properties file that defines the model, Java classes (for additional validators and code generators), plus Java beans to use at runtime in components (that could be generated from the properties model).
These changes would bring three things.
First, drop the base code of the studio from several ten thousands LOC to less than 20K.
Second, have an efficient model and approach when developing components (code generation for the Java beans, conventions for validations, etc).
And last, developing a Petals component would imply (under the hood) prepare the tooling for this component (less development efforts, just integration to complete then).
I do not know whether this is the best option.
But it has the advantage of being simple to understand and to maintain, by modularizing the code, by centralizing the parts for the runtime and tools, by reducing the code base, and by relying on something tailored for "our" needs (and not for hypothetical ones). If you have completed user features and start working on this, a redesign would be welcome (and since this will break everything, that's what I used to call Petals 5). I do not know whether Petals wants to bring back code contributors, but if so, I think this has to be done (with or without properties, whatever...).
My 2 (x10 = 20) cents.
Task
Open
Minor
And this is only about the way Petals parses jbi.xml files.
Get prepared for some reading!
You could also think about finding a common solution for both the platform and the tooling (Maven, Eclipse, whatever). The best solution would be to have a single module that handles parsing and validation for the CDK. Same thing for every component.
Moreover, the way it is done currently in the server part was designed this way because of the XSD redefine keyword. This feature allowed to redefine an element in XSD 1.0. The idea was to refine the jbi type in the CDK, and then in the component. Unfortunately, but for obvious reasons, this keyword was deprecated in XSD 1.1. Thus, the XML configuration of Petals files relies on dirty hacks and is hardly manageable.
Still for history, even if the redefine keyword seemed a clean solution at the time, JAX-B never supported it. So, basically, the way jbi.xml files are defined never worked efficiently, neither in implementation, nor in design. You either have to use any elements, or you have to create a big XML schema that defines everything (take a look at Petals Studio, there is such one big nasty XSD for the Eclipse XML editor). The current option does not allow modularity and extensibility in an efficient manner.
This organization was implemented by the end of 2007. It has been discussed hundreds of times until 2012, with Roland Naudin, Nicolas Salatgé and many others. Everytime, no action was undertaken because there were so called other priorities. This has also slowed down the creation of tools (Eclipse to not mention it). The studio has its own parser for configuration files (and it's really messy). And in fact, there has been two different parsers implemented (one with a XSD parser, another one based on EMF, both with the intent of generating user interfaces - almost - automatically from the model, which has been another long-time requirement from the team leaders).
IMO, the way jbi.xml files are organized is only good for trash.
The way there are parsed and retrieved in the components and above (CDK, container) is also inefficient. In my last work period on Petals, we were focused on other issues related to user features in exploitation environments (monitoring, logs, etc). But if I had continued to work on Petals, this topic would come number one on the todo-list. If you look at the studio's code on GitHub, there is a branch called properties-model. You will find a plugin called com.ebmwebsourcing.petals.studio.dev.properties. The idea I explored back then was to split the jbi.xml file (keep the standard part, move the CDK configuration in a distinct properties file, and move the component in another properties file). If you look at Petals components, they only have simple properties. Same thing for the CDK, except it has also few (simple) lists. The idea behind the library was to...
These changes would bring three things.
First, drop the base code of the studio from several ten thousands LOC to less than 20K.
Second, have an efficient model and approach when developing components (code generation for the Java beans, conventions for validations, etc).
And last, developing a Petals component would imply (under the hood) prepare the tooling for this component (less development efforts, just integration to complete then).
I do not know whether this is the best option.
But it has the advantage of being simple to understand and to maintain, by modularizing the code, by centralizing the parts for the runtime and tools, by reducing the code base, and by relying on something tailored for "our" needs (and not for hypothetical ones). If you have completed user features and start working on this, a redesign would be welcome (and since this will break everything, that's what I used to call Petals 5). I do not know whether Petals wants to bring back code contributors, but if so, I think this has to be done (with or without properties, whatever...).
My 2 (x10 = 20) cents.
- ... define the model in properties files. Parameters are property names. Default values are property values. And types and optionality would be defined in comments with a simple syntax.
- ... simplify the Petals wizards in the studio. Instead of giving parameter values, just select which component version you want to configure through a SU and generate a pre-filled project.
- ... move the project edition entirely in editors. Most of the UI could be generated or enriched from the model.
- ... define core modules, one per CDK version and one per component version. Such a module would contain an annotated properties file that defines the model, Java classes (for additional validators and code generators), plus Java beans to use at runtime in components (that could be generated from the properties model).
These changes would bring three things. First, drop the base code of the studio from several ten thousands LOC to less than 20K. Second, have an efficient model and approach when developing components (code generation for the Java beans, conventions for validations, etc). And last, developing a Petals component would imply (under the hood) prepare the tooling for this component (less development efforts, just integration to complete then). I do not know whether this is the best option. But it has the advantage of being simple to understand and to maintain, by modularizing the code, by centralizing the parts for the runtime and tools, by reducing the code base, and by relying on something tailored for "our" needs (and not for hypothetical ones). If you have completed user features and start working on this, a redesign would be welcome (and since this will break everything, that's what I used to call Petals 5). I do not know whether Petals wants to bring back code contributors, but if so, I think this has to be done (with or without properties, whatever...). My 2 (x10 = 20) cents.