If it's needed for having SDK build-able without having engine running, I think it should be done.
Juan, I'm not familiar with maven artifacts publishing and I don't think it may be done for nightly builds too.
Can you advise on the process needed and supervise the fix of this bug?

The first step in all this process is making sure that the version numbers of the artifacts are changed correctly when we do a release, that is what bug 1069193 is about. This is the process I suggest to do that:

1. A decision is made of what will be the current release number and what will be the next expected release number.

2. The pom.xml files are changed to remove the SNAPSHOT suffix from the version numbers. These changes to the POM files should be committed to the local repository, and that commit should be tagged with the version number.

3. Immediately after that, a new change is done to set the version number to the next expected release number and add the SNAPSHOT suffix. This is also committed to the local repository.

4. When you are happy with this, and made sure that the build can be performed from that tag, you push the changes to the remote repository.

I will attach a example script that does something like that.

The second step is to upload the artifacts to a public repository. The way to do this depends on how that repository is managed. I suggest to start using the artifactory server that we already have here, as it will be easier/faster for your initial tests:

  http://artifactory.ovirt.org:8081/artifactory

Currently, if I understand correctly, we use that only as a cache, to speed up builds. In order to use it to deploy the artifacts you will need the following:

1. Request that two local repositories are created, one for releases and one for snapshots. Lets assume that they are called ovirt-releases and ovirt-snapshots.

2. Request a user/password for that server with permission to write to those two repositories.

3. Store the user/password in the $HOME/.m2/settings.xml file of the machine/user where you are going to perform the build/upload of the artifacts. Should be something like this:

  <?xml version="1.0" encoding="UTF-8"?>
  <settings
    xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd"
    xmlns="http://maven.apache.org/SETTINGS/1.1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <servers>
      <server>
        <id>ovirt-releases</id>
        <username>the_user</username>
        <password>the_password</password>
      </server>
      <server>
        <id>ovirt-snapshots</id>
        <username>the_user</username>
        <password>the_password</password>
      </server>
    </servers>
  </settings>

4. Add the maven-deploy-plugin to the "plugins" section of the root pom.xml file of the ovirt-engine project, something like this:

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-deploy-plugin</artifactId>
    <version>2.7</version>
  </plugin>

5. Specify the location of the repositories in the "distributionManagement" section of the root pom.xml file of the ovirt-engine project, something like this:

  <distributionManagement>

    <repository>
      <id>ovirt-releases</id>
      <name>oVirt Releases</name>
      <url>http://artifactory.ovirt.org:8081/artifactory/ovirt-releases</url>
    </repository>

    <snapshotRepository>
      <id>ovirt-snapshots</id>
      <name>oVirt Snapshots</name>
      <url>http://artifactory.ovirt.org:8081/artifactory/ovirt-snapshots</url>
      <uniqueVersion>true</uniqueVersion>
    </snapshotRepository>

  </distributionManagement>

6. Run "mvn deploy" to upload the artifacts.

There is no reason, other than disk space, to not do this for nightly builds.

Having the artifacts in this repository already helps, and the SDKs can be built from there. Eventually, once we are familiar with this process we can move the artifacts to a more public repository, like maven central, which has additional requirements like signing the artifacts.

Created attachment 869099 [details]
Example script to perform release commits

Juan, it seems that:

# Remove the SNAPSHOT suffix:
sed -i \
  -e "s|<version>${current}-SNAPSHOT</version>|<version>${current}</version>|g" \
  ${poms}

is not enough, it leave around other variables, take a look at http://gerrit.ovirt.org/25326

I submitted a patch that is convenient in order to use some rather new options of the deploy plugin:

  http://gerrit.ovirt.org/27702

Once the repositories are created in the maven repository artifactory.ovirt.org and this patch is applied, you should be able to upload the artifacts with a simplified procedure:

1. Store the user name and password in your settings file, as described in comment 2.

2. Run the build with some extra flags:

url="http://artifactory.ovirt.org:8081/artifactory"
args="\
deploy \
-DaltReleaseDeploymentRepository=\"ovirt-releases::default::${url}/ovirt-releases\" \
-DaltSnapshotDeploymentRepository=\"ovirt-snapshots::default::${url}/ovirt-snapshots\" \
"
make rpm RPMBUILD_EXTRA_ARGS="--define=\"ovirt_build_extra_flags ${args}\""

This is the ticket for the request to create the ovirt-releases and ovirt-snapshots repositories in artifactory.ovirt.org:

  https://fedorahosted.org/ovirt/ticket/135

(In reply to Juan Hernández from comment #6)
> This is the ticket for the request to create the ovirt-releases and
> ovirt-snapshots repositories in artifactory.ovirt.org:
> 
>   https://fedorahosted.org/ovirt/ticket/135

repositories created

This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.

Looks like this is never going to happen, so closing as WONTFIX.