Subversion structure going forward
objectiser Oct 14, 2009 3:49 PMCurrently the svn structure is based on the Overlord process governance work, which builds a single distribution that contains Eclipse plugins as well as runtime components.
When looking at the roadmap going forward, I wanted to explore whether we need to break down the repository into smaller sub-projects that would each produce a deliverable? Does not necessarily mean that they would be distributed as separate modules, with their own lifecycles (although that is also possible), but means there would be greater flexibility in working out how they should be packaged into a higher level distribution(s)?
For example, in terms of tooling we will be looking to have Eclipse tooling and Web based tooling. These could be contained in separate top level modules in the repository. I think it would especially be a good idea to have the Eclipse plugins separated out, so these can be built and distributed potentially via an update site or potentially as part of JBoss Tools.
In terms of the runtime platforms, at the moment there is the jbossesb 'conversation aware' actions - which represents an execution support capability. In general most governance capabilities will not involve enhancing an execution technology, they will be more involved in the design phase or in monitoring the runtime. So possibly the 'conversation aware' actions are a specific module that might be a candidate for separate distribution?
The final component is the monitoring (or runtime governance) capabilities. This will have a common set of capabilities related to capturing relevant events, comparing them to the architecture model and then presenting the results. However there may be individual components related to the specific technologies being monitored - which may involve some form of plugin architecture. So it may make sense to bundle all of these runtime governance components together - or possibly the event capture and analysis parts may be distributed separately from the console?
Apart from the tool implementation components, there will also be documentation and examples, which will probably need to be local to the component to which they relate.
There may also need to be a top level module for methodology related artifacts.
So potentially we could have top level modules:
Eclipse design tools
Web design tools
jbossesb runtime
Runtime governance framework
Runtime governance console
Runtime governance jbossesb
Runtime governance riftsaw, etc
Thoughts?