This is a short note on developing extensions for the JBoss AS 7 server. It took me quite some time to pinpoint the problem

JBAS014775: New missing/unsatisfied dependencies

to be actually a problem with my extension parser.

Here are the details ...

The Problem

When I installed my extension for JBoss AS 7 for the first time, the system answered with the following message:

JBAS014775:    New missing/unsatisfied dependencies:
      service jboss.binding.http (missing) dependents: [service jboss.web.connector.http]
      service jboss.binding.management-http (missing) dependents: [service jboss.serverManagement.controller.management.http]
      service jboss.binding.management-native (missing) dependents: [service jboss.remoting.server.management]
      service jboss.binding.osgi-http (missing) dependents: [service jboss.osgi.as.framework.bootstrap]
      service jboss.binding.remoting (missing) dependents: [service jboss.remoting.server.remoting-connector]
      service jboss.binding.txn-recovery-environment (missing) dependents: [service jboss.txn.ArjunaRecoveryManager]
      service jboss.binding.txn-status-manager (missing) dependents: [service jboss.txn.ArjunaRecoveryManager]
      service jboss.outbound-socket-binding.mail-smtp (missing) dependents: [service jboss.mail-session.java:jboss/mail/Default]
      service jboss.socket-binding-manager (missing) dependents: [service jboss.serverManagement.controller.management.http,
                                     service jboss.remoting.server.management, service jboss.remoting.server.remoting-connector]

After stopping the server I saw this:

JBAS014776:    Newly corrected services:
      service jboss.binding.http (new available)
      service jboss.binding.management-http (new available)
      service jboss.binding.management-native (new available)
      service jboss.binding.osgi-http (new available)
      service jboss.binding.remoting (new available)
      service jboss.binding.txn-recovery-environment (new available)
      service jboss.binding.txn-status-manager (new available)
      service jboss.outbound-socket-binding.mail-smtp (new available)
      service jboss.socket-binding-manager (new available)

I search for quite a while, trying to figure out, what caused the dependency problem. I even posted a question to the JBoss Community: Newbie to extensions: JBAS014775: New missing/unsatisfied dependencies.

As I - quite accidentally - moved the subsystem declaration within the standalone.xml some positions up, I found out, that the extension configuration parser did not read all XML passed to it properly. The dangling end element of my configuration seemed to confused the whole parsing process. So the parser skipped the rest of the configuration file, including the socket bindings. Hence the error message. :-)

If I would not have registered my extension as the last subsystem, I might have found the problem much earlier. The error message is much more obvious in this case.

Conclusion

If you happen to encounter JBAS014775 and/or JBAS014776, while you are installing your own extension, check your extension configuration parser.

Tip: During development, you may want to add your subsystem not at the very end.

I hope this shot helps saving someone's time ... ;-)

The smartics Maven Enforcer Rules have been released with version 0.2.0.

This version provides a new rule called NoSnapshotsInDependencyManagementRule, which - you might already have guessed - checks that there are no snapshot dependencies in the dependency management block of a Maven POM.

The Problem

If you are building with Maven, it is easy to make a release of project with snapshot dependencies. Not in the dependencies block, the Maven Release Plugin takes care of that, but in the dependency management block (and unfortunately in some other places, like the skin artifact for building the Maven site).

The Solution

This rule for the Maven Enforcer Plugin checks that no dependencies listed in the management block are snapshots. So, especially for BOMs, you will never again have a release that fails to have set the dependency management information to proper releases.

The Maven plugin Bugzilla Maven Plugin has been released with version 0.7.0.

This release allows to explicitly state the extension that is derived from the packaging information of the POM. The extension information is used on a sync with the Bugzilla server after the release of a product. It is sent to the Nexus server as part of the coordinates to retrieve the latest version.

A fix dealing with the packaging type ejb is also included in this release. And it provides special handling of JBoss packaging information used by the JBoss Packaging Maven Plugin. That is jboss-sar is mapped to the extension sar.

Please refer to the release notes for more information on the changes.

This article gives an overview over open source build tools created by smartics. It shows how we use them to automate our build process, reducing manual steps as much as possible.

It will also give hints on how to use these tools in corporation projects to handle versioned sites of in-house projects.

Why automate?

Before we delve into the details of automation, I want to give you the reasons why we are putting much effort in writing build tools.

Save Resources

As a tiny company we are constantly low on one particular resource: time. Therefore we push automation as far as possible.

Repeatability

Having only very limited resources we have to do releases in a small amount of time. Often late in the night, where releases have to be a no-brain-involved task.

Easy to Use

Since we do not want to have something in our way, launching our tools should be as easy as possible.

Traceablility

If something went wrong, we have to access information that helps us to pin down the root cause of the problem. This allows us to fix it and get better with time.

Reuse

We want to enable other companies, which includes our customers, to use our tools to be more efficient in their effort to produce high quality software.

We also hope to get into a discussion with our users to improve our tools for the benefit of everyone.

Project Creation

Continuous Integration

On the first check-in of a new project, we want our integration server to build the project continuously. Therefore we create a job on our Hudson server by launching

chj

on the project’s configuration. This uses the Alias Maven Plugin and launches Maven to use our POM to create that job on the server, using the Hudson Maven Plugin. chj is an alias for create hudson job.

Issue Tracking

To further traceability we want to assign new features, change requests, improvements, and bugs to the versions of our products to fix them. This allows to generate release reports automatically, which we will later show. Therefore we have to create a product on our Bugzilla issues server by running

bi

This will again launch Maven, using the Bugzilla Maven Plugin, to create the Bugzilla product upon information found in the POM. bi is an alias for bugzilla initialize project.

h

 --- mvn
 t    = mvn -T 4 clean test [args]
 p    = mvn -T 4 clean package [args]
 i    = mvn -T 4 clean install [args]
 s    = mvn -T 4 initialize site [args]
 sd   = mvn -T 4 clean deploy site-deploy [args]
 l    = mvn initialize license:format [args]
 --- jboss
 asd  = mvn jboss-as:deploy [args]
 asr  = mvn jboss-as:redeploy [args]
 asu  = mvn jboss-as:undeploy [args]
 iasd = mvn clean install jboss-as:deploy [args]
 iasr = mvn clean install jboss-as:redeploy [args]
 --- project-sync
 b    = mvn bugzilla:sync [args]
 bi   = mvn bugzilla:init [args]
 chj  = mvn hudson:createJobs [args]
 dhj  = mvn hudson:deleteJobs [args]
 --- project-analysis
 a    = mvn dependency:analyze [args]
 dpu  = mvn versions:display-plugin-updates [args]
 ddu  = mvn versions:display-dependency-updates [args]
 --- project-release
 r    = mvn -T 4 release:prepare release:perform [args]
 rpr  = mvn -T 4 release:prepare [args]
 rpe  = mvn -T 4 release:perform [args]
 rr   = mvn release:rollback [args]
 rc   = mvn release:clean [args]
 --- java
 j5   = set JAVA_HOME="JAVA_HOME_5";; set PATH=JAVA_HOME_5\bin;PATH
 j6   = set JAVA_HOME="JAVA_HOME_6";; set PATH=JAVA_HOME_6\bin;PATH
 j7   = set JAVA_HOME="JAVA_HOME_7";; set PATH=JAVA_HOME_7\bin;PATH
 --- ALIAS EXTENSIONS
 ...aq (... and quit!): taq paq iaq saq sdaq laq raq rpraq rpeaq rraq rcaq
 --- help
 h    = This help.
For additional information please refer to:
  https://www.smartics.eu/de.smartics.config/config-smartics-alias/1.1.0/alias-report.html

Project Release

Releasing

The act of releasing a software version is already automated by the Maven Release Plugin. This command can be launched via the integration server, which is – for reproducible builds – highly recommended. Alternatively it can be launched from any developer machine using the alias-maven-plugin by typing

r

After the release we often want to update the product information in the Bugzilla server. Typing

b

will add the new released version and milestones for the project.

Static Project Site

Using the Maven Site Plugin we create project sites with Maven that provide essential documentation on a specific version of a product. The site will be automatically pushed to our sites server using the Maven groupId, artifactId, and version.

This creates some long and ugly URLs, not easily to remember by a standard human brain. For smartics-commons, a small library for Java that contains utilities we often use in our projects, the URL for version 0.5.2 is

 http://www.smartics.eu/de.smartics.util/smartics-commons/0.5.2

What would be nicer is this:

 http://www.smartics.eu/smartics-commons/0.5.2

And even, if we want to refer to the latest version of the project

http://www.smartics.eu/smartics-commons

While a particular version is actually deployed to the location mentioned first, our smartics Softlink Tool, running on our server as a background process, will automatically generate the missing links.

Metadata

The following metadata about our products is automatically released as part of the generated project sites.

Release Reports

Adding release notes manually is cumbersome and sometimes error-prone. It is easy to forget some details. Therefore we add issues to our Bugzilla server and extract release reports for our projects automatically with the help of our Issues Maven Plugin.

Build Metadata

To help our users and ourselves to check how a version has been built, we add a build report using our Buildmetadata Maven Plugin.

Project Metadata

For all project metadata we do not want to attach to the main artifact, our Projectmetadata Maven Plugin will create an attached artifact. This artifact is stored side-by-side with the main, sources, and javadoc artifact.

Test Stories

Our testdoc-tools allow to add metadata to tests. With this metadata, reports can be generated that allow to read tests like stories about the software. There is also a plugin for Eclipse that helps navigating between code and its test cases.

Library Reports

The following reports of projects, using the mentioned smartics libraries, are automatically released in the generated project site. Keeping codes or constants documentation in sync with its code is difficult. Therefore we use the libraries to let the build machine controls this issue for us.

Exception Codes Report

smartics Exceptions is a library for Java that helps handling exception codes. Central are exception codes that identify error conditions. A report on these codes is generated by the exceptioncodes-maven-plugin.

Properties Report

We are currently developing a library that makes handling configurations with Java easier. The project is called smartics Properties. Part of this project is the Properties Maven Plugin that generates reports about properties, using the metadata and Javadoc comments provided in the code.

Recommendations for Projects

If you are using Hudson or Bugzilla you may consider to use the Hudson Maven Plugin or the Bugzilla Maven Plugin to create the project’s representation on the servers. Creating a product or updating the version information on the Bugzilla server as well as creating or deleting a Hudson job may always be effortless.

If you already use Maven sites and their reports as part of your project documentation, creating easy to remember links automatically with the smartics Softlink Tool may be an easy-to-install option.

Creating release reports with the Issues Maven Plugin depends on your requirements. It is easy to include, but over time, as more and more issues will be analyzed on each release, the creation of the report may get time consuming. If your issues server already manages those reports, you may safely skip this plugin.

Metadata for your projects may proof invaluable, but for some they are just an additional burden with its benefits never be used. If it happens that SNAPSHOT versions get passed around within your team – or even worse – between different teams, you may welcome metadata within the archive to track the artifact to its sources in your SVN version control system. So the Buildmetadata Maven Plugin may be a tool to use. Before you employ the Projectmetadata Maven Plugin, check if you have use cases for the data preserved. Otherwise you build process will only be slowed down without any gain.

The same is true for using the testdoc-tools. Although the Eclipse plugin will help in navigation despite the reports are of no use for your team.

Using the libraries in your project is a question on another level. Due to the nature of exception design in Java, the smartics Exceptions library will leak transitively into your API. This may or may not be a problem, but it should be discussed.

smartics Properties is a relatively new project where you are on the bleeding edge. We are currently working on tighter integration into the JBoss application server and this might make it easier for some teams to integrate this tool. We will inform our users about changes on the project’s website.

Conclusion

As Mike Clark puts it:

Automation will give you back something you don’t have enough of: time.- Mike Clark

That is not that every project needs to use all of them. It depends on the qualities required by the project. But many of them may make the developer’s life easier, without being costly or heavily invasive. Saving time on everyday tasks helps teams to put time and mind at problems worth the effort.

We are happy to inform you about a fork of our Buildmetadata Maven Plugin created by Salim Badakhchani at Red Hat!

Salim is working for Release and Configuration Management (Middleware) and has evaluated our plugin for supporting some 300 software projects to collect build metadata.

Reason for the Fork

This is the reason for Salim giving our buildmetadata plugin a try:

We essentially support some 300 software projects which make up the JBoss Community and we help them productize their software for general release. A lot of the work we do focuses on ironing out problems with their builds which largely utilise Maven. To that end we had requests, from the community, to have better build meta data information, about the builds, so as to improve transparency of process and assist with the trouble-shooting effort.

Never one to reinvent the wheel I did some searches and found the smartics buildmetadata-maven-plugin. I quickly set up a project to evaluate the plugin and it produced the information we were looking for, so it seemed logical to productize it for general consumption in the community.

The Fork

You can access Salim's work on GitHub at

He is planning to enhance the documentation and make the plugin as easy to use as possible. If you want to see what's on his list, please refer to the issues page.

The plugin can be accessed via

and may soon be made available via Maven Central. For some corporation development departments accessing this repository may proof easier than that provided by smartics.

smartics' View

The Buildmetadata Maven Plugin is one of our most requested open source projects. So we were happy to hear that Salim also considered the plugin useful to invest into it. We are eager to learn how it performs within the realm of 300+ projects! - And we hope that a large number of committers and contributors get even more productive by the use of this plugin.

But isn't a fork a bad thing? We think not! The fork enables Salim to be in full control of the further development at Red Hat. On the other side at smartics we are also able to try new features without delay. We think that both projects can help and inspire one another.

The Future

At smartics we will continue supporting our own version of the plugin. But we have no immediate plans for new features (like the support of git which is sadly on our list for quite a while :-( ). So having an eye on Salim and his work is highly recommended. ;-)

We wish Salim good luck and hope to have a chance to continue supporting him in his effort!

Have you ever tried to edit a WordPress page offline in an editor of your choice with HTML syntaxhighlighting or even tag completition?
And have you too recognized that pasting the edited text from the editor to your WordPress textarea did result in strange looking pages / blog entries?

Even if you are using the “Text”-view of WordPress, it tries to support you while typing your blog in inserting e.g. line breaks (<br>). This also happens when you are pasting html code from your external editor to WordPress which results to code like the following:

Pasting the following block for example

After editing the html code you would like to paste to WordPress just replace all CR LF (\n\r) in the external editor with the empty string (with nothing). This results to one single line containing your complete blog post. And paste this to the WordPress editor being in the Text-view. Then switch to the Visual-view and back to the Text-view.

Voilà now your blog post is perfectly fine formated for WordPress.

But – caveat – when your blog post contains <pre>some preformated text</pre>tags these are messed up when switching back and forth from Text-view to Visual-view. You have to rewrite these manually.

The smartics JBoss Modules Maven Plugin creates Modules for the JBoss Application Server. This includes the directory structure, the JAR artifacts and – of course – the module.xml.

This article provides information about exclusion mechanisms in modules descriptors used by the Maven plugin. It shows how to exclude Maven artifacts, skip module generation for already existing modules, and explains the meaning of the include/exclude tags.

Introduction

Everything starts with a Maven project object model (POM). The POM is either a bill of materials (BOM) or a regular project POM. Within this model a developer defines the dependencies of the project. These dependencies are used by the smartics JBoss Modules Maven Plugin to create a folder containing the modules for the transitive dependency chains.

Now let’s have a look at how to control the generation process to exclude artifacts from being turned into modules.

The Modules Descriptors

Since the JBoss module descriptors contain information that cannot be derived from a POM, the plugin defines modules descriptors files.

The Maven plugin traverses the dependencies and tries to match each dependency with a modules descriptor. If no matching modules descriptor has been found, a default module will be generated.

What is important to note:

1. Modules descriptors that do not match a Maven artifact, have no influence on the generation process. This implies that you may add any number of standard descriptors to the configuration to ease the pain of specifying the usual suspects. Please refer to External Modules Descriptors for the smartics-jboss-modules-maven-plugin for more information to this topic
2. Modules descriptors files contain information on modules and do not allow to exclude specific artifacts from the generation process. Global configurations for exclusions are found the the plugin’s configuration.

Let’s delve into the exclusion stuff …

Exclude an Artifact

If you have an artifact in the transitive closure of your project you want to exclude from the generation process, you have to specify the artifact in the dependencyExcludes within the plugin’s configuration section. Here is an example:

<plugin>
  <groupId>de.smartics.maven.plugin</groupId>
  <artifactId>smartics-jboss-modules-maven-plugin</artifactId>
  <version>0.2.0</version>
        ...
  <configuration>
    <dependencyExcludes>
      <exclude>
        <groupId>org.something</groupId>
        <artifactId>exclude-me</artifactId> 
      </exclude>
    </dependencyExcludes>
  </configuration>
</plugin>

This tells the generation process that the artifact, once encountered, will be dropped. The artifact will neither occur as a module in itself nor as a dependency of another module.

Here is an example configuration as part of our integration tests.

Skip the Generation of a Module

If you want to include the dependency in the module.xml, but you do not want to create a module for a given artifact, you may use the skip directive.

<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
  <module name="org.something.exclude-me">
    <directives>
      <skip>true</skip>
    </directives>
    ...
  </module>
  ...
</modules>

This approach is useful if you want to depend on modules generated elsewhere. Either by other projects or the JBoss server itself.

Here is a modules.xml as part of our integration tests, that may serve as an example.

Exlusions

There are a couple of locations within the modules descriptor where you encounter an exclude tag. The following sections help you to distinguish them since they have mostly nothing to do with the exclusion of an artifact from the module generation process.

Exclude from Module Resources

Everything you match within the match element within the module descriptor is added as a resource to this module. Often there is a one-to-one relationship between the module and a resource, but this is not necessarily so. Here is the outline of the descriptor:

<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
  <module name="org.something.my-module">
    ...
    <match>
      <includes>
        <include>
          <groupId></groupId>
          <artifactId></artifactId>
        </include>
        ...
        <include>
          <groupId></groupId>
          <artifactId></artifactId>
        </include>
      </includes>
      <excludes>
        <exclude>
          <groupId></groupId>
          <artifactId></artifactId>
        </exclude>
        ...
        <exclude>
          <groupId></groupId>
          <artifactId></artifactId>
        </exclude>
      </excludes>
    </match>
    ...
  </module>
  ...
</modules>

The exclude elements specify artifacts that are not to be added to the module as resources, although they match the includes. This allows to group a number of artifacts within one module. For each matching artifact no additional module will be generated.

Exclude from Applying Information to Dependency

We already mentioned that not all information of a JBoss module descriptor can be derived from a POM. The apply-to-dependencies allows to match modules (not artifacts as in the previous match element!) by their names and apply additional dependency information.

<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
  <module name="org.something.my-module">
    ...
    <apply-to-dependencies>
      <dependencies>
        <match>
          <includes>
            <include></include>
            ...
            <include></include>
          </includes>
 
          <excludes>
            <exclude></exclude>
            ...
            <exclude></exclude>
          </excludes>
        </match>
        <apply>
          ... 
          <!-- 
            Add here information to be applied to 
            dependencies in the generated 
            module.xml 
            -->
         ...
        </apply>
      </dependencies>
      ...
    </apply-to-dependencies>
  </module>
  ...
</modules>

The exclude elements in the match section exclude the modules from having the information given in the apply element applied. It does not mean that the specified module is excluded from the dependency list of from the module generation.

There are examples as part of our integration tests that show you complete configurations.

  <apply>
    <slot></slot>
    <export></export>
    <services></services>
    <optional></optional>
    <imports>
      <include path="" />
      <include-set>
        <path name="" />
          ...
      </include-set>
      <exclude-set>
        <path name="org/jboss/example/tests2" />
          ...
      </exclude-set>
    </imports>
    <exports>
      <exclude path="" />
      <include-set>
        <path name="" />
          ...
      </include-set>
      <exclude-set>
        <path name="org/jboss/example/tests" />
        ...
      </exclude-set>
    </exports>
  </apply>

Exclude a Dependency?

There is currently (version 0.2.0) no way to simply drop an artifact dependency from being translated to the list of module dependencies.

As shown above:

1. you may use the exclusion of the artifact from the generation process. This will neither add a module for this artifact nor add the artifact as a dependency of any of the generated modules.
2. or, if you want the dependency, but not the module generated, use the skip directive.

If you have a use case that matches none of these approaches, please let us know!

Conclusion

We have summarized the semantics of the exclusion elements found in the smartics’ modules descriptor.

1. dependencyExcludes in the POM.
2. skip directive in a modules descriptor
3. exclusion elements in a modules descriptor

Hopefully this helps you to get fine grained control over your JBoss modules generation process.

For more information please refer to

• The jboss-modules articles in this blog.
• or to the smartics JBoss Modules Maven Plugin’s website.