The idea of SEU-as-code is pretty useless without software packages. Instead of inventing somthing totally new from scratch we decided to go for a more simpler solution. The installation of software packages using SEU-as-code is basically a simple copy deployment. The artifacts are based on the original open source release artifacts of the original project, spiced up with some shell scripts or some additional customization scripts.

Building Packages

Building packages is not hard. Again, we mainly use Gradle to build the software packages. A good way to start is to have a look at the package builds that are available at the SEU-as-code Packages GitHub repository. Basically, the process of building your packages consists of five simple steps:

5 Steps of Packaging Process

The first step is usually downloading the original software package artifact from its original site. An archive format is preferred, like ZIP, TAR or GZIP so that it can be easily extracted in the next step. If there is no archive available, then download the MSI or DMG, install it locally once, repackage as archive and continue from here.

plugins {
    id '' version '1.2'


task downloadArchive(type: Download) {
    src ""
    dest "$buildDir"

Next, we extract the previously downloaded artifact into the build directory. Thanks to the power of Gradle this is an easy one. We use the Copy task type together with the zipTree function.

task extractArchive(type: Copy, dependsOn: downloadArchive) {
    from { zipTree("$buildDir/") }
    into "$buildDir/files"

Now it is time to customize the package. Usually this implies added additional shell scripts or setting specific environment variables. Once this is done we can repackage the downloaded and extracted files together with our customizations.

task buildPackageBin(type: Jar, dependsOn: extractArchive) {
    version version
    extension 'jar'
    destinationDir buildDir
    from "$buildDir/files"
    from "files"

Finally, we can publish the created software artifact to an artifact repository such as Nexus. For this we use the standard Maven publishing plugin.

apply plugin: 'maven-publish'

publishing {
    publications {
        gradle(MavenPublication) {
            artifact buildPackage
    repositories {
        // set the properties via -P to publish to your company repo
        maven {
            url = project.hasProperty('nexusUrl') ? project.nexusUrl : ''
            credentials {
                username = project.hasProperty('nexusUsername') ? project.nexusUsername : ''
                password = project.hasProperty('nexusPassword') ? project.nexusPassword : ''

Package Repositories

Since SEU-as-code packages are basically ordinary Maven artifacts, a package repo is required to host the packages. Most of the open source packages in the GutHub packages repository are hosted at Bintray.

Use a dedicated repository. Don’t mix software packages with ordinary Maven artifacts.

But you probably soon find that you may need some customizations that are very specific to your project or even your company. So where do you host your private software package artifacts? You have two options.

  1. Private Company Repository: this option is suitable for generic, company wide artifacts you want to share. For example, we have a custom package for IntelliJ Ultimate deployed at our repo that is used in all of our project SEUs. So probably you also have an artifact repository server like Nexus or Artifactory available at your company you can use.

repositories {
    maven {
        url ''
  1. Local SEU Repository: this options is most useful for small and very SEU or project specific artifacts and customizations. Those artifacts are part of your SEU and should be versioned with the other SEU files.

repositories {
    flatDir { dirs 'repo' }

results matching ""

    No results matching ""