[[_kiedeployingsection]]
= Deploying

== KieBase


The `KieBase` is a repository of all the application's knowledge definitions.
It will contain rules, processes, functions, and type models.
The `KieBase` itself does not contain data; instead, sessions are created from the `KieBase` into which data can be inserted and from which process instances may be started.
The `KieBase` can be obtained from the `KieContainer` containing the `KieModule` where the `KieBase` has been defined.

.KieBase
image::KIE/BuildDeployUtilizeAndRun/KieBase.png[align="center"]


When the `KieBase` needs to resolve types that are not in the default class loader, it will be necessary to create a `KieBaseConfiguration` with an additional class loader and pass it to `KieContainer` when creating a new `KieBase` from it.

.Creating a new KieBase with a custom ClassLoader
====
[source,java]
----
KieServices kieServices = KieServices.Factory.get();
KieBaseConfiguration kbaseConf = kieServices.newKieBaseConfiguration( null, MyType.class.getClassLoader() );
KieBase kbase = kieContainer.newKieBase( kbaseConf );
----
====

== KieSessions and KieBase Modifications


KieSessions will be discussed in more detail in section "Running". The `KieBase` creates and returns `KieSession` objects, and it may optionally keep references to those.
When `KieBase` modifications occur those modifications are applied against the data in the sessions.
This reference is a weak reference and it is also optional, which is controlled by a boolean flag.

== KieScanner


The `KieScanner` allows continuous monitoring of your Maven repository to check whether a new release of a Kie project has been installed.
A new release is deployed in the `KieContainer` wrapping that project.
The use of the `KieScanner` requires kie-ci.jar to be on the classpath.

.KieScanner
image::KIE/BuildDeployUtilizeAndRun/KieScanner.png[align="center"]


A `KieScanner` can be registered on a `KieContainer` as in the following example.

.Registering and starting a KieScanner on a KieContainer
====
[source,java]
----
KieServices kieServices = KieServices.Factory.get();
ReleaseId releaseId = kieServices.newReleaseId( "org.acme", "myartifact", "1.0-SNAPSHOT" );
KieContainer kContainer = kieServices.newKieContainer( releaseId );
KieScanner kScanner = kieServices.newKieScanner( kContainer );

// Start the KieScanner polling the Maven repository every 10 seconds
kScanner.start( 10000L );
----
====


In this example the `KieScanner` is configured to run with a fixed time interval, but it is also possible to run it on demand by invoking the `scanNow()` method on it.
If the `KieScanner` finds, in the Maven repository, an updated version of the Kie project used by that `KieContainer` it automatically downloads the new version and triggers an incremental build of the new project.
At this point, existing ``KieBase``s and ``KieSession``s under the control of `KieContainer` will get automatically upgraded with it - specifically, those ``KieBase``s obtained with `getKieBase()` along with their related ``KieSession``s, and any `KieSession` obtained directly with `KieContainer.newKieSession()` thus referencing the default ``KieBase``.
Additionally, from this moment on, all the new ``KieBase``s and ``KieSession``s created from that `KieContainer` will use the new project version.
Please notice however any existing `KieBase` which was obtained via `newKieBase()` before the KieScanner upgrade, and any of its related ``KieSession``s, will not get automatically upgraded; this is because ``KieBase``s obtained via `newKieBase()` are not under the direct control of the ``KieContainer``. 

The `KieScanner` will only pickup changes to deployed jars if it is using a SNAPSHOT, version range, the LATEST, or the RELEASE setting.
Fixed versions will not automatically update at runtime.

In case you don't want to install a maven repository, it is also possible to have a `KieScanner` that works
by simply fetching update from a folder of a plain file system. You can create such a `KieScanner` as simply as

====
[source,java]
----
KieServices kieServices = KieServices.Factory.get();
KieScanner kScanner = kieServices.newKieScanner( kContainer, "/myrepo/kjars" );
----
====

where "/myrepo/kjars" will be the folder where the `KieScanner` will look for kjar updates. The jar files placed in this folder
have to follow the maven convention and then have to be a name in the form `\{artifactId}-\{versionId}.jar`.

== Maven Versions and Dependencies


Maven supports a number of mechanisms to manage versioning and dependencies within applications.
Modules can be published with specific version numbers, or they can use the SNAPSHOT suffix.
Dependencies can specify version ranges to consume, or take advantage of SNAPSHOT mechanism.

StackOverflow provides a very good description for this, which is reproduced below.

http://stackoverflow.com/questions/30571/how-do-i-tell-maven-to-use-the-latest-version-of-a-dependency[http://stackoverflow.com/questions/30571/how-do-i-tell-maven-to-use-the-latest-version-of-a-dependency]

NOTE: Since Maven 3.x metaversions RELEASE and LATEST are no longer supported for the sake of reproducible builds.

See the POM Syntax section of the Maven book for more details.

http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html[http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html ]

http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-project-dependencies.html

Here's an example illustrating the various options.
In the Maven repository, com.foo:my-foo has the following metadata:

[source,xml]
----
<metadata>
  <groupId>com.foo</groupId>
  <artifactId>my-foo</artifactId>
  <version>2.0.0</version>
  <versioning>
    <release>1.1.1</release>
    <versions>
      <version>1.0</version>
      <version>1.0.1</version>
      <version>1.1</version>
      <version>1.1.1</version>
      <version>2.0.0</version>
    </versions>
    <lastUpdated>20090722140000</lastUpdated>
  </versioning>
</metadata>
----


If a dependency on that artifact is required, you have the following options (other version ranges can be specified of course, just showing the relevant ones here): Declare an exact version (will always resolve to 1.0.1): 
[source]
----
<version>[1.0.1]</version>
----
 Declare an explicit version (will always resolve to 1.0.1 unless a collision occurs, when Maven will select a matching version): 
[source]
----
<version>1.0.1</version>
----
 Declare a version range for all 1.x (will currently resolve to 1.1.1): 
[source]
----
<version>[1.0.0,2.0.0)</version>
----
 Declare an open-ended version range (will resolve to 2.0.0): 
[source]
----
<version>[1.0.0,)</version>
----
 Declare the version as LATEST (will resolve to 2.0.0): 
[source]
----
<version>LATEST</version>
----
 Declare the version as RELEASE (will resolve to 1.1.1): 
[source]
----
<version>RELEASE</version>
----
Note that by default your own deployments will update the "latest" entry in the Maven metadata, but to update the "release" entry, you need to activate the "release-profile" from the Maven super POM.
You can do this with either "-Prelease-profile" or "-DperformRelease=true" 

== Settings.xml and Remote Repository Setup


The maven settings.xml is used to configure Maven execution.
Detailed instructions can be found at the Maven website:

http://maven.apache.org/settings.html

The settings.xml file can be located in 3 locations, the actual settings used is a merge of those 3 locations.

* The Maven install: `$M2_HOME/conf/settings.xml`
* A user's install: `${user.home}/.m2/settings.xml`
* Folder location specified by the system property `kie.maven.settings.custom`


The settings.xml is used to specify the location of remote repositories.
It is important that you activate the profile that specifies the remote repository, typically this can be done using "activeByDefault":

[source,xml]
----
<profiles>
  <profile>
    <id>profile-1</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    ...
  </profile>
</profiles>
----


Maven provides detailed documentation on using multiple remote repositories:

http://maven.apache.org/guides/mini/guide-multiple-repositories.html
