Now that the core bundles are separated into a separate git repository, I have also setup a separate hudson job to build these bundles.

The idea being that hudson jobs will also be setup for the savara-integration and savara-tools-eclipse repositories, which will be dependent (and therefore triggered) by the savara-core hudson job, to propagate changes that may occur in the core bundle, and ensure there is no adverse effect on the two jobs that use those bundles (i.e. integration and tools eclipse).

The issue is that each of these jobs could be run on different servers, and even if not, they each use a local maven repository, to ensure suitable isolation from other jobs running on the server.

So (for example), a change may be applied to the core bundles, which will trigger a core build, which would then propagate to trigger a build of the integration and eclipse tools projects. However these dependent projects would pull in the latest snapshot artifacts from the Nexus repo, as opposed to the latest version of the core bundles built by the other hudson job.

One approach might be to publish the snapshot on each successful completion of the savara-core hudson job? Not sure if this is possible, and how it would be configured.

However even if this was possible, we would need to consider whether this should only occur on snapshots, or whether it would be valid for releases aswell? Although Nexus would be holding the non-snapshot artifacts in a staging area, so the other hudson jobs may not be able to access them without some manual changes.

The easiest solution would be to build the savara-core bundles as part of each of the dependent jobs? This may be a workable solution for the nightly builds, but might cause problems when doing releases.

One issue with this approach is that the hudson job configuration allows multiple git repositories to be defined, but you can only specify a sub-folder once in the git section, not on a per repository basis.

So the fetched repositories would be overwriting common files in the top level folder (e.g. pom.xml).

One approach might be to publish the snapshot on each successful completion of the savara-core hudson job? Not sure if this is possible, and how it would be configured.

However even if this was possible, we would need to consider whether this should only occur on snapshots, or whether it would be valid for releases aswell? Although Nexus would be holding the non-snapshot artifacts in a staging area, so the other hudson jobs may not be able to access them without some manual changes.

Thoughts?

Will the ' Trigger parameterized build on other projects' option in the Hudson job help? we can attach these three nodes into one hudson node, without by specifying the maven repo, these three maven repository can be shared, I believe.

Personally, I would prefer publishing the snapshot on eacu successful completion of savara-core. One possible is that we can use the 'Invoke batch tasks ' option to run the 'mvn clean deploy', one drawback would that we have to use a username & password to be able to publish the snapshots. :-(

Triggering the dependent builds is useful if the dependent build can pick up the latest version of the core artifacts. Don't really want to rely on the same hudson node being used with shared local repo.

I think publishing using the exec script should be ok, as I presume the exec script will not be executed if the previous step fails?

In the case of the savara-core job, I think we could just manually publish releases, to avoid having to configure hudson with nexus username/password.

No I'm suggesting that we do the publish step - when it is a snapshot version it will deploy ok, but if a non-snapshot version, then it would fail. So in this case we would do a manual publish outside of hudson.

Not sure, as I tried this out and the deploy failed, but not on the first one - so seems to indicate it was able to publish the snapshot for some of the modules. Just need to investigate why it had problems later.

So for now I will remove this step, and so have to treat each project as separate - so if the Eclipse tools or integration job need to access updated core artifacts, these will need to be manually deployed first.

If anyone has any thoughts on a solution to the above, then we can try it again.