Tuesday, September 9, 2014

Preview/Alpha Release of Overlord API Management

The Overlord team has been working on a new project ( https://github.com/Governance/apiman ) that provides rich API Management functionality.  The project is still in its early days, so any thoughts/feedback is even more appreciated than normal.

The project site is here:


The quickstart (linked from the web site) can be run straight from the maven source and ultimately runs in WildFly 8.1.

If you're interested in runtime API Management governance capabilities, give us a look and join us in the conversation!

New website launch!

We're excited to announce the launch of the Overlord project's new website: http://www.projectoverlord.io  We'd sincerely appreciate your feedback or ideas!

Wednesday, July 2, 2014

Overlord 1.1.0.Beta1 Released

The Overlord team is pleased to announce the release of Overlord 1.1.0.Beta1, comprised of SRAMP 0.5.0.Beta1, DTGov 1.5.0.Beta1 and RTGov 2.0.0.Beta1. We will also be launching our new website shortly (http://governance.github.io/). Please take a look and let us know what you think.

The common features across the components are:
  • Support for EAP 6.3 and Fuse 6.1 (Fabric support to follow shortly)
  • Numerous bug fixes



  • Maven facade (early preview)
  • Many doc improvements
  • Moved from jline to aesh
More details: http://red.ht/TBjjAl



  • Jetty 8 Support
  • New Admin UI to manage Workflow Triggers
  • Notification Service email templates can now come from S-RAMP
More details: http://red.ht/1lyY0pF



  • New UI to replace previous Gadget Server approach
  • Integration with Elasticsearch and Kibana for analytics
More details: http://red.ht/1iVa0r6

Speak thanks to Ivan McKinley for Elasticsearch contributions, Michael Clay for work on the new RTGov UI, and help from the SwitchYard, ModeShape and Fuse teams.

Friday, March 14, 2014

DTGov Release: Version 1.2.0.Final

We are very pleased to announce the release of version 1.2.0.Final of Overlord DTGov.  This latest version contains a number of bug fixes along with support for Tomcat 7!

Please download it and give it a try!  We welcome all ideas and feedback.

S-RAMP Release: Version 0.4.0.Final

We are happy to announce the release of version 0.4.0.Final of the Overlord S-RAMP project.  This new version contains a number of a bug fixes, but most importantly we now have support for all of the following runtime platforms:

  • JBoss EAP 6.1
  • JBoss Fuse 6.1
  • Tomcat 7

Additionally, the S-RAMP User Interface now includes an Ontology Manager, which is long overdue.  It's pretty hard to manage ontologies without an editor, due to the format (RDF + OWL Lite) of the file.  To help with that, version 0.4.0.Final includes a user interface that will allow users to create, upload, and edit their ontologies.

It is of course recommended that users finalize (as much as possible) their ontologies prior to using them to classify artifacts.  Once an ontology is heavily used to classify artifacts, it becomes much more difficult to make significant (read non-addition) changes to it!

Monday, February 10, 2014

S-RAMP specification 1.0 is public!

We are proud to announce that OASIS just officially published the S-RAMP 1.0 specification:


The Overlord project had two members on the TC (Eric and yours truly), while Randall Hauch joined from the ModeShape project. The Overlord S-RAMP implementation is an Apache 2.0 licensed Open Source implementation of the specification, and it has already found adoption as the Enterprise repository of choice; one repository for all enterprise artifacts. You can download the complete spec bundle from http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/cs01/s-ramp-v1.0-cs01.zip. For our implementation see: https://www.jboss.org/overlord.



Thursday, December 12, 2013

DTGov release workflow using 'Domain Deployment'


DTGov ships with workflows which can help you with deploying releases to runtime environments. At the moment the deployment service supports 4 ways to deploy an application:
  • copy, file copy to a directory
  • rhq, using the RHQ REST API to deploy an application to a resource managed by RHQ.
  • as_cli, using the JBoss AS Client to deploy to a JBoss Domain.
  • mvn, deploy the application to a maven repository.
In this blog post we demonstrate how to deploy an application using the JBoss AS Client.

DTGov configuration

To use the JBoss AS Client we need to configure a target in the dtgov.properties file referencing the as_cli protocol. For example to deploy to a domain on server we'd use

governance.targets=   qa|http://www.jboss.org/overlord/deployment-status.owl#InQa|as_cli|admin::admin123!::

Where admin/admin123! are the credentials to log into the remote domain.

JBoss Domain Setup

The DTGov deployment service can deploy to a JBoss Domain. Look here if you need more information on how set one up.

1. Open the domain/configuration/domain.xml file for editing, and make sure you have a 'qa' group, which is name of the target mentioned above. You should end up with something like
        <server-group name="qa" profile="full">
2. Open the domain/configuration/host.xml file for editing, and assign servers to this group. In this example we add 'server-one' to the 'qa' domain group. You want to add more then one server.
        <server name="server-one" group="qa">


3. Now you can start your domain using something like
   bin/domain.sh -b -bmanagement=

You can test your credentials (admin/admin123!) by logging into the management console, which in this case would run on, and/or using the client: bin/jboss-cli.sh. You may have to add an admin user using the bin/add-user.sh script. Also verify that you see the 'qa' domain group in the management console.

Deployment of your application

At this point the release workflow is ready to deploy an application to the 'qa' domain group. Once you've approved the 'dev' task, you should see the dtgov deployment REST API logging on the dtgov server:

Calling POST TO: http://localhost:8080/dtgov/rest/deploy/qa/0e7a209c-f298-433c-b9a6-3d40d4ac2f5c

This means that the dtgov is invoked the jboss client on the 'qa' domain to deploy the application, where '0e7a209c-f298-433c-b9a6-3d40d4ac2f5c' is the UUID of the application artifact that will get deployed. If something is wrong at this point you can use your favorite REST client tool and perform POST's to this url until things work. 

 Figure 1. Screenshot of the management console after the requirements jar was deployed (probably a bad choice to deploy the requirements!!)

 I hope this worked for you too, and that you picked a better artifact then I did as deploying the requirements from the dtgov-demos-project doesn't really make a whole lot of sense! Well other then demonstrating that it works :).