Skip to content




API Explorer

Package properties

Sometimes you may find it useful to store certain values for later use in your services. One way to achieve this is through the use of package properties.

Martini has two types of properties, those that are global to the instance, or local to a certain package. You'll want to use package properties if you want values to be persisted and used within a package only. A common use case would be for storing API access keys; you'd typically use the same set of credentials when invoking third-party services under the same API.

Packages declare their properties under conf/properties:

├── conf
│   ├── properties
│   │   └──
│   |...

The naming convention may be changed by configuring the application property. So a package prefix of develop dictates the application to look for instead of This is useful for storing package properties for multiple environments or developers in the same place - all you need to do is configure your various installations with their own

Like instance properties, changes to your package properties will be visible as soon as you save the properties file (assuming the application property is set to always-check).

Might have to manually create the files

Your .properties files are not automatically generated when you create a package or when you re-specify the value of If your .properties files are missing, simply create them under the conf/properties folder.

Property merging

Properties are merged according to package hierarchy. Consider the following example:

  • Package petclinic-demo depends on petclinic.
  • Package petclinic declares the following property:


When accessing the property petclinic.petstore-url from the petclinic-demo package, the value is resolved. This is possible because it depends on the petclinic package. If the dependency is removed, the property resolves to null.

The child package may declare a property of the same name, essentially overriding the parent property. For instance, if the petclinic-demo declares the following property:


The resolved value for petclinic.petstore-url when accessing it from the petclinic-demo package is http://localhost:5000.

Application properties inheritance

Aside from explicit package dependencies, packages also inherit properties from the system-wide application properties. If a property is not available in the package hierarchy, the system application properties is ultimately queried for a value.

Modifying package properties via Martini

To add new properties via user interface, follow the steps below:

  1. Go to the Navigator view.
  2. Look for your package and expand its contents by clicking on its node. Look for the conf directory,
  3. Double click the .properties file to open it.
  4. Add, edit, and remove key-value pairs as needed.

    Opening the `` file

    Opening the `` file

Quick search for files

In Martini Desktop, you can do to search for your .properties file(s) instead using the Open Resource dialog. With this, you can open all of your .properties files all at once.

Searching for `.properties` files via the Open Resource dialog

Modifying and using package properties programmatically

The instance-wide classloader ships with a Groovy extension module packed with utility methods. This means that you can use the functions defined in that extension module in all of your Groovy or Gloop code.

When working with package properties, most, if not all, of the methods you'll be needing are present in the GroovyMethods class.

You can add or modify package properties in Groovy code using some of the methods provided by the extension module mentioned. For example:


Array values

If you want to save an array of values, simply create a string of all the values separated by commas. Martini has utility methods that'll parse and split those values for you and return them in an array.

To remove a package property, do:


To fetch the value of a package property, you can do any of the following:

'key'.getPackagePropertyArray(['default-value-one', 'default-value-two'])

The methods for managing package properties are context-aware. If you call any of the methods above in a certain script and that script is contained in a package called foo, then only foo's package properties will be fetched, added, modified, or removed.

The one-liner will follow the rules below on retrieving the property from your properties file:

  1. From the file
  2. Iteratively from each parent package, until found
  3. From your application properties

Gloop and Flux is fully supported too

Most of the one-liner methods in the GroovyMethods class also appear in the Navigator, and can be used in Gloop and Flux services.

When updating properties, only the local package properties file is updated.