Child pages
  • Sling module descriptor
Skip to end of metadata
Go to start of metadata


We have a number of automated processes which make use of the Git repositories as a source of truth:

  • generating a default.xml manifest for repo checkout
  • generating Jenkins jobs

However, we often have the need to override some of the logic on a per-module basis:

  • building a project with multiple JDKs
  • including certain modules in repo groups or creating special profiles for them

In the future, we may look into other automation, such as:

  • generating a Jenkinsfile per each module
  • automatically maintaining a which points to documentation URLs or the build Job

Therefore it is proposed to allow the existence of a Sling module descriptor file in the root of each Git repository. If no descriptor exists, the module is processed by various tools in the default manner. If it exists, the tools must inspect it for custom settings and apply them.


The module file will be named .sling-module.xml . It is a "dotfile" as it is not usually touched during regular development. The XML format easy consumption from various tools and , compared to JSON, allows defining comments.

Rather than listing a specification, a full example is provided below:

sling-module.xml example
	<jenkins> <!-- settings inspected by Jenkins -->
		<jdks> <!-- replaces the default jdks when present -->
		<downstreamProjects> <!-- adds more downstream projects when present -->
		<archivePatterns> <!-- adds more archive patterns when present -->
		<!-- overrides the default goal when set -->
		<!-- Additional parameters to pass to the Maven invocation -->
		<!-- rebuilds the job periodically when defined -->
	    <!-- when set to true, xvfb support is enabled -->
		<!-- No Jenkins job generated when set to false -->
	<aggregator> <!-- setting inspected by sling-aggregator tooling -->
		<groups> <!-- generates repo "groups" settings and separate Maven profile in the global reactor pom, when present -->
  • No labels