Browse Prior Art Database

A configurable and dynamic artifact installer

IP.com Disclosure Number: IPCOM000243565D
Publication Date: 2015-Oct-01
Document File: 4 page(s) / 138K

Publishing Venue

The IP.com Prior Art Database

Abstract

The proposal is a metadata driven installer that is capable of building the installable on need basis. The proposed invention can be directly consumed and configured by the development teams and thereby reduce the dependency on the release team.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 4

A configurable and dynamic artifact installer


This article addresses the problem of generating and building an artifact installer dynamically based on the solution requirements. The current issue is when a team generates artifacts / contents they are dependent on the release team to get them integrated within the installer and then get it out for validation. This limitation imposes challenges around solution delivery mechanism and the ease at which solutions can be customized and shipped to end customers.

There is a need to provide a guided interface to get the artifact content integrated to the installer build.

To address the above challenges, the BA Growth Initiatives team built a framework described below:

This proposes a metadata driven installer that is capable of building the installable on need basis. The proposed invention can be directly consumed and configured by the development teams and thereby reduce the dependency on the release team.

The development / implementation team can update the installer meta-data file (or via a guided UI) with the information related to the content / artifacts. This information may include the details of the content, file type etc. For example, Reports, Models, database, Configuration files and other parameters like node details.

The framework enables an association between an artifact type and a container that hosts the artifact. For e.g. Reports get mapped to the Cognos Report deployment mapping and will deploy it within Cognos. Similarly the database file type can get mapped to the type of database that will be used.

Each file type and sub type listed in the file internally gets consumed by the framework and mapped to the right functional set that needs to be executed.

All this information can be provided in a simple guided mechanism in the

1


Page 02 of 4

metadata / configuration file and...