WARNING: This server provides a static reference view of the NetKernel documentation. Links to dynamic content do not work. For the best experience we recommend you install NetKernel and view the documentation in the live system .

Install

Pizza Model

In the pizza model, install is analogous to freezing a prepared pizza topping. The group, name and version of the frozen topping is important since that is the key we'll need when we come to build a pizza.

The NetKernel plugin automatically applies Gradle's 'maven' plugin and so the 'install' task is always available.

A word of warning: in the world of Gradle the install task is conceptually the exact opposite of how we think of install in the NetKernel world. In Gradle/Maven, install takes a built artifact and uploads it to a repository.

The NetKernel plugin defers to Gradle as much as possible, so gradle install is not directly modified by the NetKernel plugin. Therefore executing...

gradle install

will execute the build task dependency and upload the resulting module jar file to the configured upload repository.

If no repository is specified then the built module will be uploaded to the maven local directory (this is usually located in the "/.m2/" directory in your home directory).

Artifact Naming

The name and version of a built module artifact in the repository is automatically set based upon the name and version of the built module.

If your module's URI is urn:com:company:project:module with version 1.1.1 then the artifact in maven will be...

   name:  urn.com.company.project.module
   version: 1.1.1

You may control the group in which the artifact is placed by setting the project.group in build.gradle. Here's an example...

//Apply the NetKernel plugin
apply plugin: 'netkernel'
//Apply the maven plugin (required for uploadArchives)
apply plugin: 'maven'

//Define the project group in which built modules are stored in the repository.
project.group = 'big-corp-skunkworks'

//Provide this buildscript with repositories and dependencies to obtain the netkernel plugin
buildscript {
    repositories {
        mavenLocal()
        mavenCentral()
        maven {
            url "http://maven.netkernel.org/netkernel-maven"
        }
    }

    dependencies {
        classpath group: 'urn.org.netkernel', name: 'gradle.plugin', version: '[0.0.1,)'
    }

netkernel {
    //All configuration for netkernel plugin tasks goes here.
    }

Defining Upload Archives

The NetKernel plugin will install your built module to any defined upload archive. Gradle supports file, http and scp protocols to upload to local and remote repositories. Please refer to Gradle's maven documentation for how to declare upload repositores in your build script.

One tip, we have found that rather than rely on mavenlocal() its best to define a file based repository, as it's unambiguous and also mavenlocal() doesn't seem to always respect the artifact metadata naming consistently. Here's an example...

uploadArchives {
    repositories {
        mavenDeployer {
            repository(url: "file:/home/pjr/maven-repository/")
        }
    }
}

To upload your module to this upload archive you need to use the uploadArchives task (note do not use the install task as this will always target ~/.m2/)

gradle uploadArchives

Note: uploadArchives is a task from the maven plugin which must be declared in order to upload to maven repositories.

Further details for uploading to repositories are in the gradle documentation here section 31.6.2

Repository Metadata

The NetKernel plugin will automatically work out the maven artifact metadata and generate the POM file. This includes understanding that encapsulated class libraries built into the module, can exclude linked library dependencies for runtime deployment. Less monolith, more module.

Alternative Tasks

The install and 'uploadArchives tasks are documented and highlighted since they fit the NetKernel plugin's pizza model. Of course both build, install and uploadArchives, although slightly modified when the 'netkernel' plugin is applied, are still just Gradle tasks and so they can be used in completely different ways in your own build processes.

For example you can copy the built module to a different location. Or even add it to your local NetKernel by copying and then creating an entry in modules.d/

Although on the surface Gradle looks like a build DSL, it is a full Groovy programming environment - so the power to parameterise, configure, extend and adapt the tools is always there.