Subversion structure going forward

[objectiser]

Currently 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?

[jeff.yuchang]

I agreed that have sub-projects could have more flexibility. but it also adds complexity when we do release and development.I strongly agreed that we separate out the tool.

So I think maybe we just split it into four sub-projects. (As it represents different aspects of our project, and doesn't have the dependency on each other)

Eclipse design tools
web design tools
runtime
runtime governance.

And in the runtime governance, it has modules as following
governance framework
governance console
governance jbossesb etc

we can use the maven profile to help us doing so. Same goes to the runtime sub-project.

What do you think?

[objectiser]

Sounds good, although I think we now have to think about good names for the modules:

Possibly this structure:

design
- eclipse
- web
runtime
- jbossesb
validator
- common
- console
- jbossesb
- riftsaw
- etc

that way we have three clear categories - design tools, runtime components and validator. The change from 'runtime governance' to validator is to avoid confusion with the 'runtime' modules, as technically this is also in support of runtime governance. And 'validator' as opposed to 'monitor', because I think that was the preferred term in Overlord.

If this structure is ok, then next point to clarify - each of these sub-modules will then have its own trunk/tags/branches?

I think it makes sense for the design modules (eclipse and web) as these will be independently distributed and installed. Similarly, runtime/jbossesb - each runtime support technology is going to be selected independently based on an organisations needs.

What about validator?

[jeff.yuchang]

"objectiser" wrote:
Sounds good, although I think we now have to think about good names for the modules:

Possibly this structure:

design
- eclipse
- web
runtime
- jbossesb
validator
- common
- console
- jbossesb
- riftsaw
- etc

that way we have three clear categories - design tools, runtime components and validator. The change from 'runtime governance' to validator is to avoid confusion with the 'runtime' modules, as technically this is also in support of runtime governance. And 'validator' as opposed to 'monitor', because I think that was the preferred term in Overlord.

I agreed with this structure. how about we are using 'tool' instead of 'design'?

"objectiser" wrote:

If this structure is ok, then next point to clarify - each of these sub-modules will then have its own trunk/tags/branches?

I think it makes sense for the design modules (eclipse and web) as these will be independently distributed and installed. Similarly, runtime/jbossesb - each runtime support technology is going to be selected independently based on an organisations needs.

What about validator?

I also agreed that we have its own trunk/tags/branches for the eclipse and web. but I tend to like keep the runtime as one, which means it will contains the jbossesb etc, like jbpm4 in the future. we will build jbossesb, jbpm4 (for example) into different modules in our distribution, users are able to choose from that. Otherwise, it will lead too many top level modules. say jbpm4, riftsaw etc in the future, and each top-level module just has some classes. I don't think it is a good idea to have fine-grain top-level module. what do you think?

with regard to the validator, I think it is as same as runtime. keep them as one, and then build them into different modules into distribution.
what do you think?

[objectiser]

Sounds good - do you have time to make this change soon, or should I? I could do it over the next couple of days, if you are busy.

[jeff.yuchang]

I can do this sometime this afternoon, or tomorrow. Does it sound ok?

-Jeff

[objectiser]

That would be great, thanks.