Blog

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

We started with the idea to add some of our project dependencies as modules with the JBoss AS 7. Soon we found out that we also wanted to provide an extension to the JBoss server. But the method of creating the directory of modules proofs to be quite cumbersome – especially if your libraries have a larger number of direct and transitive dependencies.

 

Then we were looking for a tool to generate the modules directory for us. We found some Ant scripts provided by JBoss, but these where not overwhelmingly documented – and Ant build scripts was not what we were looking for.

We are using Maven and it seem that some of the module information is already available from the project object model (POM). So we began to create our own tool – a pluging for Maven: smartics-jboss-modules-maven-plugin.

Info Box

For more information about about generating JBoss modules, please refer to smartics-jboss-modules.

The Idea

What is the basic idea? The Maven plugin is usually applied to a BOM or a JBoss extension POM. It traverses the dependency tree and generated a module for each dependency. Since you do not want every dependency as a module, usually because a version of the module is already provided in a slot within the JBoss server or several artifacts should be placed in one module, you may add rules on which modules to skip, how to name modules, how to apply additional information – all dependent on the name of the Maven dependency.

...

Example with smartics-exceptions

Here is an example: smartics - exceptions is a library for Java that helps to implement exceptions with unique identifiers, error codes, message text construction (I18N), exceptions metadata and reporting. This was our first candidate we want to provide as a module.

So here is the essential part of the smartics - exceptions BOM:

Code Block
languagexml
 <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>de.smartics.exceptions</groupId>
        <artifactId>smart-exceptions-core</artifactId>
        <version>${project.version}</version>
      </dependency>
      <dependency>
        <groupId>de.smartics.exceptions</groupId>
        <artifactId>smart-exceptions-i18n</artifactId>
        <version>${project.version}</version>
      </dependency>
      <dependency>
        <groupId>de.smartics.exceptions</groupId>
        <artifactId>smart-exceptions-report</artifactId>
        <version>${project.version}</version>
      </dependency>
    </dependencies>
  </dependencyManagement>

...

It just states that every dependency matching the given groupId should be added to the module named de.smartics.exceptions (the text inside the groupId is a regular expression with a group – therefore the brackets – and the ${g1} signals that the matched group identifier is also the name of the module). One the plugin’s website you’ll find the XSD for the modules descriptor.

Note Box

It may be confusing that we call our modules descriptors ‘modules descriptors’ since JBoss named their module descriptors also ‘module descriptors’, but the two are not the same. Our modules descriptor should be called ‘jboss module descriptor descriptors’ (JMDD). Or – since we are not JBoss: ‘smartics descriptors for jboss modules’. But this term is quite unwieldly so we hope that context will make the meaning. Where unsure we will use the term ‘JBoss module descriptor’ (singular) to refer to the module.xml defined by JBoss and simply ‘modules descriptor’ (plural) to refer to the descriptors to create the folder with JBoss module descriptors and artifacts.

...

 
Quote External
authorRobert
source-dateFebruary 14, 2014 at 1:01 pm

Hi Frank,

thank you for your feedback!

We are continuing to consider putting our artifacts to Maven Central. Unfortunately we are extremely time constrained, so this will probably not happen very soon.

Maybe you could explain why providing our artifacts via Maven Central would be more reliable than providing them via our own server? If we would quit the support for the plugin (and we are not considering that in any way), I think users would more appreciate to have access to the sources than to artifacts according to reliability. Are we overlooking facts here?

But we count your vote on our list of supporters for Maven Central publishing.

Kind regards,

Robert

 

...

Quote External
authorJan
source-dateMay 26, 2014 at 2:40 pm

Hi Robert. We work with JBoss modules a lot and your solution looks very promising, I will give it a try. But I will also add a vote to the pro-central team: We have a very strict governance. All builds must run on the company jenkins machine and this machine is configured to accept only the companies own artifactory repo. So when we want to use additional 3rd party libs that are not in central, we will have to apply for a new “remote repo” entry in the artifactory. Things are much easier when we just can get them via the already configured repos. My 2-c

Jan