Thinking about repository (or should I say repositories) structure. Having a github 'organisation' means that potentially we can have multiple repositories under the same umbrella project, if it makes sense.

Currently everything is contained in a single 'repository', even though there are actually two steps to the build process, (1) the bundles, server integration and documentation, and (2) the Eclipse plugins and update site.

This has the benefit that the tools can be built directly after the main distribution, and therefore pick up the relevant bundles from the local maven repo.

So one possible restructuring could be to separate out the tools from the other components. However this may mean that the tools are built only from bundles found in the nexus repository - so not so convenient for doing nightly builds. Or possibly the hudson builds are still combined, just not the repositories? The way the build jobs function does not necessarily need to reflect the separation of components into different repositories.

If the repositories are separated, i.e. tools and other components, we then need to consider the dependencies. The tools only have dependencies on the bundles, although in the future it may be that the tools include an Eclipse Help version of some of the documentation.

So it is possible the bundles and documentation could also be separated out - leaving (JBoss) server integration as a separate repository?

Is there a benefit in managing all of these aspects of the project as separate repositories, or is it better to have them as one source tree that is versioned together?

One possible reason for a single repository is more immediate feedback when changes have impacted other integration points - this would be detected on doing the complete build - however as the build gets larger, then it also takes longer. If we have separate repositories, then it may not be until changes are checked in, and continuous build jobs triggered, that an issue is detected - but this is why we have continuous builds.

One reason for considering this is that the bundles are target environment independent - integration into Eclipse tools and JBoss server are just two possibilities. So rather than bundle all together, it enables the bundles to be developed as a separate project, with other repositories being created to deal with other IDEs, or servers, etc.

Given the benefit of git is that it is a distributed versioning system, it would probably be beneficial to keep the size of each repository small and managable, so a developer does not have to download components they are not interested in.

Will be setting up the initial repository(ies) soon, so any thoughts appreciated.

Jeff Yu wrote:

 

IMHO, one thing may need to consider is that: do users need to install the JBoss server integration as well when they install the savara?

The answer is no - it should be possible to leverage the core Savara bundles in any environment - embedded into an application or within any server/container.

Jeff Yu wrote:

 

If the answer is No, then we have a good reason to split it into a separate repository. Also, if we plan to have another server integration, like Tomcat, we may need to put the JBoss specific implementation into separate repository, while keep the SPI (or API) into the original repository.

This may need some thought, because if (for example) we wanted to support different servers, then some capabilities are going to be server specific, and some will be technology specific.

For example, in the various server environments, we need to be able to manage the database configuration. This may be server specific to some extent, but there may also be common aspects - should we have a repository per server type? In which case where should the common integration related parts go? Possibly a separate 'integration-core' repository?

The other type of integration (based on tech) could be for example JAX-WS. This may be deployable to a number of different client app and server environments - but equally may have server specific configurations.

So do we want separate repositories per server type (e.g. jboss, tomcat, etc.) and a shared 'integration-core' repository, or is this too much? The alternative would be to put all the integration aspects into a single repository, with a deployment mechanism capable of dealing with the different server environments?

Another option is to put the common integration aspects (which may include JAX-WS integration) into the bundles repository, but then this repository would not just be for OSGi bundles, it would be for environment independent components - which might make more sense. So one 'savara-core' repo, and another one or more repos for server integration, depending upon whether we see benefit in a per environment repository, or just another single repo for integration (e.g. savara-integration) - and then of course the savara-eclipse-tools repo.

I would propose that we currently have:

1) savara-core - all common functionality, including the OSGi bundles that will be made available via nexus

2) savara-eclipse-tools - Eclipse plugins to enable the core capabilities to be used in an Eclipse environment

3) savara-web-tools - Web based tooling, interaction activity UI, integration with repository, etc

4) savara-integration - hooks into client and server environments (initially just jboss).

5) savara-docs - documentation

If we find that the savara-integration repo (or the deployment mechanism) is becoming too complex due to multiple supported servers, we could then look at splitting them out.

If this plan sounds reasonable, there is just one issue - how to build the deployment package to include (3), (4) and (5). Where does the responsibility lie to pull in the relevant artifacts and build the package? Relying on savara-core is easy, as it can pull the bundles from nexus, savara-eclipse-tools are fine because they build their own package (i.e. update site). So thought needs to be given to the last three.

Jeff Yu wrote:

 

These structure looks good to me. I am just not sure if it is good to have a repo for doc, as I believe the docs should be along with the functionality repo. For example, we may have a user guide for savara-integration, and another user guide for web-tools, because the savara-integration may not have same release cycle as savara-integration, how to deal with the doc's release cycle?

Would it be better that we just put the docs into their own repo, instead of having one separate repo.

Agree, better to put docs co-located with the functionality. The only problem is that some of the current docs may be relevant in multiple places, so may need some thought on the best way to break them up.

Jeff Yu wrote:

we will need to have a Savara-Assembly repo (maybe better has this as a module in one of above repo) to pull all of needed artifacts, and then produce a proper distro.

Not sure I like having a separate repo just for this. I might have been looking at this the wrong way around - thinking that the web tools needed to be packaged with the server integration and docs.

However if docs are now local to the functionality, then I think it would probably be better just to have separate distributions for 'savara-integration' and 'savara-web-tools' repos - so keeps it nice and simple