Checks performed before the release of a new version

Releasing a new version of a software system is always a thrill.

Here they come some checks due before every new version can leave the warm and fuzzy staging repository:

1. First things first

Preparing and staging a good release candidate means that we have to build all the artifacts in the proper order.

The same order applies to the subsequent testing process:

1. entando-core-engine
2. entando-core-webapp
3. entando-plugins-parent
4. entando-archetype-plugin-generic
5. entando-archetype-portal-generic

2. entando-core-engine

If we are checking a staged release candidate, the unit tests successfully passed. Two times.
Thus, checking a staged entando-core-engine means using the other artifacts trying to spot some bugs of the core-engine.

Other checks

• Version in the POM

3. entando-core-webapp

Just like entando-core-engine, entando-core-webapp is a requirement for the other artifacts. Thus, the checking process is pretty the same.

Other checks

• Version in the POM
• Dependencies in the POM

4. entando-plugins-parent

A staged release candidate of entando-plugins-parent, means a bunch of plugins declared stable and ready to ship.
Thus, the main concern regards the inclusion in a real portal. And this takes us to the checks for entando-archetype-portal-generic

Other checks

• Version in the POM of the parent and every staged plugin
• Dependencies in the POM of the parent and every staged plugin

5. entando-archetype-plugin-generic

• Version in the POM of the archetype
• Dependencies in the POM of the to-be-plugin
• Go straight and try to create a new plugin
• Add it under the sources of the staged tag of entando-plugins-parent

From the parent

• Test-init
• mvn clean install

From the new plugin

• mvn clean install

6. entando-archetype-portal-generic

• Version in the POM of the archetype
• Dependencies in the POM of the to-be-portal
• Go straight and try to create a new portal
• Check the filters, looking for the version of Entando
• Configure all the filters for your system
• ant PG-db-full-update
• mvn clean jetty:run
• ant WAR-build
• deploy the target/.war to a local tomcat
• check if it works
• ant WAR-build-standalone
• cd target
• java -jar <standalone-jar-name> -httpPort=8080 -resetExtract
• check if it works

How to test a staged release

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">

<!--

1. backup your ~/.m2/settings.xml
   cp ~/.m2/settings.xml ~/.m2/settings.xml.orig.restore.me.after.qa

2. replace it with this file
   cp THIS_FILE ~/.m2/settings.xml

3. remove ALL the contents of ~/.m2/repository/
   rm -rf ~/.m2/repository/*

Done.
Now your maven will use the staged artifacts.

Also, in order to use the staged archetypes, the usual command is modified as follows:
mvn archetype:generate -DarchetypeCatalog=https://oss.sonatype.org/content/repositories/orgentando-546/archetype-catalog.xml
-->

<profiles>
  <profile>
    <id>release-qa</id>
    <!-- this section must be customized with new proper data for every new release -->
    <repositories>
      <repository>
        <id>release-3.2.0</id>
        <name>release-3.2.0</name>
        <!-- this url comes from the staging process to oss.sonatype.org -->
        <url>https://oss.sonatype.org/content/repositories/orgentando-546/</url>
     </repository>
    </repositories>
  </profile>
</profiles>

 <activeProfiles>
   <activeProfile>release-qa</activeProfile>
 </activeProfiles>

</settings>