Giter Club home page Giter Club logo

pm's Introduction

Provisioning Manager Tool

Project Modules

Module pm-parent

Defines main version and common dependencies of the project.

Module feature-pack-api

General provisioning and feature-pack API. Which allows to provision the desired installation specification at a specified location, install additional and/or uninstall existing feature-packs, export the currently provisioned specification to a file with the purpose to reproduce it at a different location.

Module wildfly-provisioning-plugin

WildFly-specific provisioning plug-in which takes care of assembling the configuration of the provisioned WildFly-based installation.

Module feature-pack-build-maven-plugin

Maven Mojo implementations (i.e. goals in Maven plugins) to install feature-packs to the maven repo and to provision the target installation.

Module wildfly-feature-pack-maven-plugin

WildFly-specific Maven Mojo implementation that builds WildFly feature-packs. The plugin has to be included into the WildFly feature-pack build modules as

<plugin>
    <groupId>org.jboss.pm</groupId>
    <artifactId>wildfly-feature-pack-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>feature-pack-build</id>
            <goals>
                <goal>wf-build</goal>
            </goals>
            <phase>compile</phase>
        </execution>
    </executions>
</plugin>

Module tool

Command line interface which allows to:

  • Build feature-packs and install them into the Maven repository;

  • Provision an installation by pulling the feature-packs from the Maven repository and installing them at the specified location.;

  • View the currently provisioned installation specification;

  • Export the currently provisioned installation specification to a file with goal to reproduce the installation later.

The Maven assembly plug-in is configured to create a single executable JAR file which contains all the dependencies.

CLI Commands

FileSystem commands

The following filesystem commands are available:

  • cd - change current work directory

  • pwd - print current work directory

  • mkdir - create a new directory if it does not already exist

  • ls - list the content of a directory

  • less - display the content of a file

  • rm - remove a file

provision-spec

[workdir]$ provision-spec <spec-file-path> [--dir=<installation-dir>]

(Re-)Provisions the installation according to installation specification provided in an XML file.

Arguments:

<path>        - filesystem path to the XML file describing the desired
                installation specification.

--dir         - optional, target installation directory. If the argument is
                missing, the current work directory is assumed as the target.

install

[workdir]$ install <feature-pack-gav> [--dir=<installation-dir>]

Adds the feature-pack to the installation specification (or creates a new spec if one does not exist yet) and (re-)provisions the target installation.

Arguments:

<feature-pack-gav>  - groupId:artifactId:version of the feature-pack to install.

--dir         - optional, target installation directory. If the argument is
                missing, the current work directory is assumed as the target.

uninstall

[workdir]$ uninstall <feature-pack-gav> [--dir=<installation-dir>]

Removes the feature-pack from the installation specification and (re-)provisions the target installation.

Arguments:

<feature-pack-gav>  - groupId:artifactId:version of the feature-pack to
                      uninstall.

--dir         - optional, target installation directory. If the argument is
                missing, the current work directory is assumed as the target.

provisioned-spec

provisioned-spec display

[workdir]$ provisioned-spec display [--verbose] [--dir=<installation-dir>]

Displays the currently provisioned installation specification.

Arguments:

--verbose(-v) - whether to include feature-packs not explicitly chosen by
                the user but installed as dependencies of other feature-packs.

--dir         - optional, target installation directory. If the argument is
                missing, the current work directory is assumed as the target.

provisioned-spec export

[workdir]$ provisioned-spec export <file-path>

Exports the currently provisioned installation specification to the specified file in the XML format. The resulting file can be used as an argument to provision-spec command.

Arguments:

<file-path>   - file path to store the provisioned specification to.

Building and launching the tool

The tool can be built by executing the following Maven command:

mvn clean install

The executable JAR will be built in pm/tool/target/pm-tool.jar

There is also a convenience do.sh script in the root directory of the project. If executed w/o arguments, it’ll build and launch the tool.

./do.sh package will only build the tool. ./do.sh run will only launch the already built tool.

Building WildFly feature-packs

To be able to build WildFly (core, servlet and full) feature-packs the WildFly Maven plugin from this project has to be included into the target WildFly Maven build configuration.

The following branches can be used as examples:

WildFly feature-pack build configuration

WildFly feature-pack building Maven plugin expects an XML file named wildfly-feature-pack-build.xml which contains information about the feature-pack dependencies on other feature-packs, what additional content to include into the feature-pack, configuration assembly instructions and post provisioning tasks.

WildFly post provisioning/install tasks configuration

When the target installation has been provisioned content-wise, there still tasks remain to perform to make the just provisioned installation usable. One of the essential ones is to assemble/adjust the configuration to what the user has selected. Other tasks include setting file permissions, correcting line endings for certain files, create expected directories.

These tasks are described in wildfly-tasks.xml file which is included into the resources of the WildFly feature-pack. The file is created by the WildFly feature-pack building Maven plugin based on the wildfly-feature-pack-build.xml.

pm's People

Contributors

aloubyansky avatar dmlloyd avatar ehsavoie avatar jamezp avatar jfdenise avatar ppalaga avatar spyrkob avatar tomashofman avatar

Watchers

 avatar  avatar  avatar  avatar

pm's Issues

package xsd

package.xml is a file which describes a package inside a feature-pack which includes package name and its dependencies on other packages (in the same feature-pack).
Java class that represents package.xml is org.jboss.provisioning.descr.PackageDescription. There is also an XML parser org.jboss.provisioning.xml.PackageXMLParser and XML writer org.jboss.provisioning.xml.PackageXMLWriter.

The actual XSD file is currently missing.

feature-pack.xml parsing tests

There is an XML parser org.jboss.provisioning.xml.FeaturePackXMLParser which reads feature-pack.xml and builds an instance of org.jboss.provisioning.descr.FeaturePackDescription that represents it.

This needs to be covered by the tests.

feature-pack.xml marshalling tests

org.jboss.provisioning.xml.FeaturePackXMLWriter takes an instance of org.jboss.provisioning.descr.FeaturePackDescription and produces a corresponding XML file.

This needs to be covered with the tests.

provisioning.xsd and parsing tests

provisioning.xml is a file which is used by the provisioning tool to produce the target installation which is fully described in the provisioning.xml in terms of feature-packs.

Java class that represents provisioning.xml is org.jboss.provisioning.xml.ProvisioningMetaData. There is also an XML parser for it org.jboss.provisioning.xml.ProvisioningXmlParser.

The actual XSD and the parsing tests are currently missing.

Simplify the pm-provisioning XML schema

The present pm-provisioning XML schema prescribes a structure like this:

<installation xmlns="urn:wildfly:pm-provisioning:1.0">
  <universe name="org.jboss.group1">
    <feature-pack name="fp1" version="0.0.1" />
    <feature-pack name="fp2" version="0.0.2" />
  </universe>
  <universe name="org.jboss.group2">
    <feature-pack name="fp3" version="0.0.3" />
  </universe>
</installation>

I do not find the universe element useful in any way and I propose to change the schema so that the structure looks like this:

<installation xmlns="urn:wildfly:pm-provisioning:1.0">
    <feature-pack groupId="org.jboss.group1" artifactId="fp1" version="0.0.1" />
    <feature-pack groupId="org.jboss.group1" artifactId="fp2" version="0.0.2" />
    <feature-pack groupId="org.jboss.group2" artifactId="fp3" version="0.0.3" />
</installation>

Why:

  • Such a flat structure is easier to work with: copy&paste among XML files
  • groupId and artifactId depict better, what those values are
  • Neither there is any universe grouping in ProvisionedInstallationDescription.
  • The server-provisioning.xml files of wildfly-server-provisioning-maven-plugin used exactly this <feature-pack groupId="org.jboss.group1" artifactId="fp1" version="0.0.1" /> structure. Let's say that we could stay backwards compatible here.

I am ready to perform the necessary changes.

@aloubyansky could you please comment?

package.xml marshalling tests

org.jboss.provisioning.xml.PackageXMLWriter takes an instance of org.jboss.provisioning.descr.PackageDescription and produces a corresponding XML file.

This needs to covered with the tests.

basic feature-pack installation tests

Basic provisioning tests include:

  • installing a feature-pack with all its packages to a specific location;
  • installing a feature-pack excluding some of its packages;
  • installing a feature-pack including some of its packages;
  • installing a feature-pack which depends on another feature-pack;
  • installing a feature-pack which depends on another feature-pack excluding/including some of the packages of the feature-pack specified as a dependency;
  • installing a few independent feature-packs at the same time.

feature-pack xsd

feature-pack.xml is a file which describes a feature-pack including its GAV, packages, dependencies and, possibly, custom provisioning plugins.
Java class that represents feature-pack.xml is org.jboss.provisioning.descr.FeaturePackDescription.
There is also an XML parser org.jboss.provisioning.xml.FeaturePackXMLParser and XML writer org.jboss.provisioning.xml.FeaturePackXMLWriter.

The actual feature-pack.xsd is currently missing.

package.xml parsing tests

org.jboss.provisioning.xml.PackageXMLParser reads package.xml and builds an instance of org.jboss.provisioning.descr.PackageDescription which represents the XML file.

This needs to be covered with the tests.

CLI: uninstall completion should suggest things that are actually installed

At the moment, uninstall completion is basically identical to the install command completion, i.e. it is suggesting the candidates querying the artifact repository. It'll be more reasonable to suggest artifacts that are actually installed.
uninstall can target the current directory (when the --dir arg is missing) or a dir specified in the --dir argument.
The first thing to do will be to identify whether the current or the specified dir is a valid home dir containing the provisioned state. So the completion of the uninstall should start with the home dir.
Once the home dir has been confirmed, the command can use the ProvisioningManager.getProvisioningConfig() to get the list of the artifacts installed.
NOTE: it might not be obvious from which stream those artifacts were installed. We'll probably need some more data in the provisioned state for that. But the feature-pack GAVs at least are there.

provisioned-state.xml marshalling tests

org.jboss.provisioning.xml.ProvisionedStateXmlWriter takes an instance of org.jboss.provisioning.state.FeaturePackSet<?> and produces an XML representation of the object.

This needs to be covered with the tests.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.