Follow Us on Twitter

OSB 12c releases op resource niveau bouwen via Maven

Oktober 2016 - Sinds OSB 12c op de markt is, is het een stuk eenvoudiger geworden om OSB releases te bouwen via Maven. Dit is tegenwoordig namelijk een standaard feature voor OSB projecten. Wanneer via JDeveloper een nieuw OSB project wordt aangemaakt, zal ook automatisch een pom.xml bestand worden toegevoegd.

Wanneer het project via Maven wordt gebouwd, zal een jar bestand worden gegenereerd. De extensie van dit bestand zal echter sbar (servicebus archive) zijn.

Hoewel het erg mooi is dat het bouwen van OSB projecten tegenwoordig standaard wordt ondersteund, is de standaard Maven plugin van Oracle toch niet in alle situaties een volledige oplossing voor het bouwen van OSB releases. Dit is bijvoorbeeld het geval wanneer de OSB zich in een situatie bevindt waarin veel ad-hoc wijzigingen op verschillende interfaces moeten worden doorgevoerd. Hierdoor zijn er regelmatig meerdere releases die tegelijkertijd open staan. Deze releases zijn dus nog niet doorgezet naar alle omgevingen van de OTAP-straat. Wanneer er releases worden gemaakt, is het dus van belang dat er heel specifiek aangegeven kan worden welke resources wel en niet in de release moeten worden meegenomen. Het is namelijk niet gewenst dat er onbedoeld resources die nog niet goed getest zijn, worden doorgezet naar andere omgevingen.

Wat zijn de mogelijkheden van de standaard Maven plugin?

Wanneer via JDeveloper een nieuw OSB project aangemaakt wordt, wordt ook direct een pom.xml bestand gegenereerd. Dit pom.xml bestand ziet er als volgt uit:

<?xml version="1.0" encoding="UTF-8"?>
	<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<modelVersion>4.0.0</modelVersion>

	<parent>
		<groupId>com.oracle.servicebus</groupId>
		<artifactId>sbar-project-common</artifactId>
		<version>12.1.3-0-0</version>
	</parent>

	<groupId>nl.whitehorses</groupId>
	<artifactId>Employee</artifactId>
	<version>1.0-SNAPSHOT</version>

	<packaging>sbar</packaging>

	<description/>

</project>

Een release van het OSB project bouwen kan vervolgens eenvoudig worden gedaan door het volgende commando uit te voeren:

mvn clean package -DoracleHome=C:\Oracle\Middleware\Oracle_Home

In het pom.xml bestand zien we dat voor het bouwen van OSB projecten standaard de sbar-project-common plugin van Oracle gebruikt wordt. Naast de elementen die in de bovenstaande pom.xml te zien zijn, ondersteunt deze plugin enkele parameters waarmee de inhoud van het gegenereerde sbar bestand kan worden beïnvloed. Zo is er bijvoorbeeld de mogelijkheid om excludes parameters mee te geven. Hiermee kan worden aangegeven dat bepaalde resources niet aan de release toegevoegd moeten worden.

In eerste instantie lijkt dit wellicht een oplossing voor het eerder beschreven probleem dat niet alle resources altijd in een release moeten worden opgenomen. Met deze excludes parameter kan theoretisch natuurlijk opgegeven worden welke resources niet in je release moeten komen. Wanneer een dergelijke release wordt geïmporteerd via de servicebus console, ontstaat hier echter een probleem. De sbar bestanden die door de standaard Maven plugin worden gegenereerd, genereren het archief namelijk altijd op projectniveau. Wanneer een release op projectniveau gebouwd wordt, en bepaalde bestanden zitten wel in een project dat al op de OSB gedeployed is, maar niet in het sbar bestand dat geïmporteerd wordt, zal de OSB de ontbrekende bestanden verwijderen van de OSB.

Welke functionaliteit mist er in de standaard Maven plugin?

Zoals eerder beschreven, is het via de standaard Maven plugin niet mogelijk om expliciet aan te geven, welke resources wel en niet in een sbar bestand moeten worden opgenomen. Daarnaast kunnen via deze plugin ook alleen releases op projectniveau gebouwd worden. De gewenste situatie voor het bouwen van sbar bestanden via Maven is eigenlijk heel simpel: Via Maven is het gewenst om dezelfde opties te hebben als wanneer een sbar bestand via JDeveloper gebouwd wordt.

Screenshot JDeveloper

In de bovenstaande screenshot zijn deze gewenste functionaliteiten allen te zien:

  1. Er kan worden aangegeven op welk Export level de release gebouwd moet worden: Project level of resource level.
  2. Door middel van de vinkjes is aangegeven welke resources wel en niet in het sbar bestand worden opgenomen.
  3. In één release kunnen meerdere projecten worden gebouwd.

Hoe werkt de standaard Maven plugin?

Om uit te zoeken hoe de standaard Maven plugin verbeterd of uitgebreid kan worden, is het handig om globaal te snappen hoe de standaard Maven plugin werkt. Deze plugin van Oracle maakt gebruik van de Configjar tool voor het bouwen van releases. Heel globaal worden de volgende stappen uitgevoerd:

  1. Er wordt een settings.xml bestand gegenereerd.
  2. Hiernaast wordt ook een configjar.bat bestand gegenereerd. Deze wordt door de Maven plugin gebruikt om de daadwerkelijke Configjar tool te starten en zo het sbar archief te genereren. Dit batchscript voert de volgende stappen uit:
    • Uitvoeren $ORACLE_HOME/osb/tools/configjar/setenv.bat script. Dit script zorgt ervoor dat er enkele zaken worden ingesteld, zoals het Java classpath.
    • Uitvoeren $ORACLE_HOME/osb/tools/configjar/configjar.bat. Hieraan wordt ook als parameter het pad naar het gegenereerde settings bestand meegegeven. Dit is de daadwerkelijke Configjar tool die ervoor zorgt dat het archief gegenereerd wordt.

Standaard ziet het gegenereerde settings.xml bestand er als volgt uit:

<?xml version="1.0" encoding="UTF-8"?>
<p:configjarSettings xmlns:p="http://www.bea.com/alsb/tools/configjar/config">
	<p:source>
		<p:project dir="C:\JDeveloper\mywork\Whitehorses\Employee"/>
		<p:fileset>
			<p:exclude name="*/overview.xml"/>
			<p:exclude name="*/pom.xml"/>
			<p:exclude name="*/.settings/**"/>
			<p:exclude name="*/.data/**"/>
		</p:fileset>
	</p:source>
	<p:configjar jar=" C:\JDeveloper\mywork\Whitehorses\Employee\.data\maven\sbconfig.sbar">
		<p:projectLevel includeSystem="false">
			<p:project>Employee</p:project>
		</p:projectLevel>
	</p:configjar>
</p:configjarSettings>

Genereren van eigen settings.xml bestand voor de Configjar tool

Hoewel het in de standaard Maven plugin niet mogelijk is om OSB projecten op resourceniveau te bouwen, wordt dit door de Configjar tool wel standaard ondersteund. Om deze feature ook via Maven te ondersteunen is het dus enkel nodig om een eigen settings.xml bestand te genereren in plaats van het settings.xml bestand dat door de standaard Maven plugin wordt gegenereerd.

Hiervoor is een custom Maven plugin gemaakt, die een uitbreiding is op de standaard Maven plugin. In deze eigen Maven plugin wordt de eerste stap (het genereren van het settings.xml bestand) door eigen code gedaan. De Java code die wordt uitgevoerd om het configjar.bat script te genereren, en via dit script de Configjar tool te starten, blijft echter uitgevoerd worden via de code uit de standaard Maven plugin.

In dit eigen settings.xml bestand worden 2 dingen anders gedaan dan in het standaard bestand:

  1. Er wordt ook gebruik gemaakt van include tags in plaats van enkel de exclude tags.
  2. In plaats van het projectLevel element, wordt nu het resourceLevel element gebruikt.

Het settings.xml bestand dat nu gegenereerd wordt, is hieronder te zien. Hierin zien we dat er 2 resources aan het sbar bestand toegevoegd zullen worden: De GetEmployee pipeline en proxy. Daarnaast is ook te zien dat de release op resource niveau gebouwd zal worden.

<?xml version="1.0" encoding="UTF-8"?>
	<p:configjarSettings xmlns:p="http://www.bea.com/alsb/tools/configjar/config">
	<p:source>
	<p:project dir="C:\JDeveloper\mywork\Whitehorses\Employee"/>
	<p:fileset>
	<p:include name="**/Pipeline/GetEmployee.pipeline"/>
	<p:include name="**/Proxy/GetEmployee.proxy"/>
	<p:exclude name="*/overview.xml"/>
	<p:exclude name="*/pom.xml"/>
	<p:exclude name="*/.settings/**"/>
	<p:exclude name="*/.data/**"/>
	</p:fileset>
	</p:source>
	<p:configjar jar="C:\JDeveloper\mywork\Whitehorses\Employee\.data\maven\sbconfig.sbar">
	<p:resourceLevel includeDependencies="false"/>
	</p:configjar>
</p:configjarSettings>

Meerdere projecten bouwen in één release

Met de hierboven beschreven extensie op de Maven plugin is het mogelijk om per project een release met de gewenste resources te bouwen. Via JDeveloper is het echter ook mogelijk om meerdere projecten in één release toe te voegen. Dit kan bereikt worden door een assembly project.

Hiervoor moeten alle OSB projecten aan een parent project worden toegevoegd als module. Hierdoor is het mogelijk om alle losse OSB projecten te bouwen. Hierna moet het Maven assembly project gebouwd worden. Deze haalt alle eerder gebouwde OSB projecten op als dependency, pakt de sbar bestanden uit en voegt de inhoud van deze bestanden toe aan een nieuw sbar bestand.

Iets soortgelijks kan worden gedaan door middel van de ZipArchiver van het Plexus archiver project. Deze kan gebruikt worden om archief bestanden (zoals ZIP en JAR) samen te voegen. Deze kan in theorie ook de gegenereerde sbar bestanden samenvoegen. De moeilijkheid in het samenvoegen van verschillende sbar bestanden is echter het ExportInfo bestand. Dit bestand beschrijft de inhoud van het archief en wordt gebruikt door de servicebus console bij het importeren van een sbar bestand. Wanneer resources wel in het sbar bestand zitten, maar niet in het ExportInfo bestand vermeld worden, zal de OSB deze bestanden niet vinden en dus ook niet importeren.

Om dit op te lossen is een implementatie van de Plexus AbstractArchiver gemaakt, die qua functionaliteit erg op die van de Plexus ZipArchiver lijkt. Het grote verschil is echter dat wanneer een ExportInfo bestand gevonden wordt, deze niet direct aan het nieuwe sbar archief wordt toegevoegd. Pas als alle overige bestanden aan het archief zijn toegevoegd, worden alle ExportInfo bestanden samengevoegd en toegevoegd aan het archief.

Releases bouwen vanuit Jenkins

Om het bouwen van releases nog makkelijker te maken is in Jenkins een build job aangemaakt die via het Maven parent project alle losse OSB projecten bouwt. Vervolgens wordt ook het Maven assembly project uitgevoerd om de daadwerkelijke release te bouwen. Om de build job uit te voeren is het belangrijk dat de OSB ook geïnstalleerd is op de machine waarvandaan de job wordt uitgevoerd.

Wat hierbij echter duidelijk merkbaar was, was dat het bouwen van een release via Jenkins aanzienlijk trager was, dan wanneer dit lokaal via Maven werd gedaan. De machine waarop Jenkins de build job uitvoert, was een (virtuele) Linux machine.

Dit wordt veroorzaakt doordat de random nummergenerator erg traag kan zijn op machines die onvoldoende entropie hebben. Het versnellen van deze build job via Jenkins kan, wanneer dit optreedt, worden gedaan door de volgende regel toe te voegen aan het $ORACLE_HOME/osb/tools/configjar/setenv.sh bestand op de server waarop de Jenkins job wordt uitgevoerd:

OSB_OPTS="$OSB_OPTS -Djava.security.egd=file:/dev/./urandom"

Conclusie

Hoewel het bouwen van OSB projecten via Maven tegenwoordig standaard wordt ondersteund door Oracle, zijn er ook enkele features die wel gewenst zijn, maar nog niet door de standaard Maven plugin van Oracle worden ondersteund. Dit zijn voornamelijk de volgende punten:

  1. Het bouwen van projecten op resourceniveau in plaats van op projectniveau.
  2. Expliciet aangeven welke bestanden wel (en niet) in een release moeten worden opgenomen.
  3. In één release meerdere projecten bouwen.

Het is mogelijk om de bovenstaande punten te ondersteunen door een eigen Maven plugin te creëren. Deze kan worden gebruikt om een eigen settings.xml bestand te genereren, waarmee via de Configjar tool een archief gebouwd wordt.

Daarnaast kan een eigen implementatie van de Plexus AbstractArchiver gebruikt worden om meerdere OSB projecten samen te voegen tot één release. Hierbij worden dan ook alle ExportInfo bestanden samengevoegd en als één ExportInfo bestand toegevoegd aan het gegenereerde sbar bestand.

Na het uitvoeren van alle hierboven beschreven stappen is het mogelijk om via Maven dezelfde opties te gebruiken bij het opbouwen via sbar bestanden als wanneer dit via JDeveloper gedaan wordt.

Waardering:
 
Tags:

Reacties

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.

Meer informatie over formaatmogelijkheden

CAPTCHA
Deze vraag is om te testen of u een persoon bent en om spam te voorkomen
Image CAPTCHA
Enter the characters shown in the image.