I'm new to developing plugins for Confluence. Starting the server with atlas-run worked out of the box. But when I tried to reload a Confluence plugin with FastDev, I got the following error message on the console:

[INFO] [talledLocalContainer] [INFO] --- maven-amps-dispatcher-plugin:4.2.10:cli 
                                         (default-cli) @ simplebp ---
[INFO] [talledLocalContainer] [INFO] Opening port 4330 for socket cli access
[INFO] [talledLocalContainer] [INFO] Waiting for commands...
[INFO] [talledLocalContainer] maven2>2013-12-21 18:40:00,116 WARN [http-1990-6] 
  [atlassian.seraph.auth.DefaultAuthenticator] login login : 'admin' 
  tried to login but they do not have USE permission or weren't found. 
  Deleting remember me cookie.

Searching on the internet, I only found references to configuration problems concerning Jira and Crowd. This was definitely not my problem. It took me quite some time to figure out (thanks to Michael Griffel's answer to atlas-cli, pi execution gets stuck at "upload plugin to server http://localhost:2990/jira"), that the problem could be solved by setting the following properties:

set ATLAS_OPTS=-Dusername=admin -Dpassword=admin

Now the hot deployment works like a charm!

Comments copied from our old blog server:

Thanks a lot, helped me a lot. For a direct Maven call: -DATLAS_OPTS=-Dusername=admin -Dpassword=admin

Adrian. (March 24, 2014 at 9:10 am)

When I first started to learn about JBoss Modules and JBoss Extensions, I looked for Version 7.1 of the JBoss Application Server and began to read Extending JBoss AS 7. Unfortunately I had only a short glance at the adviced prerequisite Admin Guide and therefore missed the invaluable information about basic concepts. The Version 7.2 of Extending JBoss AS 7 makes the relevant parts more clear.

Nonetheless the information about getting started with writing JBoss Extensions is scattered so this little guided tour might help those who feel somewhat lost (as I have felt in some parts of my journey).

Overview over the Tour

Since modules are the foundation of JBoss Extensions, this tour will first introduce you to documentation that deals with JBoss Modules. The second section will then concentrate on the extension concepts and will guide you towards the central document for all extension programmers.

JBoss Modules

The modules concept is quiet easy to grasp. There is a certain directory layout with a given number of artifacts (module.xml, JARs, index files) in it. There are means to reference modules from dynamic deployables (META-INF or deployment descriptor). Some class loading knowledge comes handy in case of trouble shootings. That's it.

Here is the list of recommended readings:

1. JBoss Modules - provides information about modules, but unfortunately the information given is not complete. The best covered part is Module descriptors.
2. Define dependencies, two options:
   
   1. As part of META-INF/Manifest.mf as shown in Manifest module information.
   2. With a WEB-INF/jboss-deployment-structure.xml as shown in Class Loading in AS7 documentation.
3. JBoss Modules Maven Plugin - helper to create the module structure for a Maven project. Note that we are the authors of this plugin, so we may be biased concerning the usefulness of the tool ;.).

JBoss Extensions

Dealing with extensions is just a bit more complicated. The basic concept is indeed not that difficult. But if you plan to actually write an extensions, going into details might not be that obvious at first. Therefore we recommend the following readings:

1. Extending AS7 - provides an overview over the basic concepts ofextensions/subsystems and deployments. It discusses when to use which approach or when to combine the two. It also provides information about patching and the differences patching modules or non-modules (like XML files or deployables).
2. General configuration concepts - provides more information on extensions and subsystems. It also provides information about the concepts of profiles and logical resources like paths, interfaces, socket bindings and system properties.
3. Management resources - provides information about the concepts address, operation, and attribute. The mapping of the configuration (e.g. standalone.xml to the runtime model is done by constructing and executing operations. Therefore this information is very relevant. The document also discusses the differences to JMX. You may want to not follow references to the basic Java types of DMR, since they are covered in the next step.
4. Detyped management and the jboss-dmr library - provides an overview of the JBoss Dynamic Model Representation (DMR)
   1. ModelNode
   2. ModelValue
      1. ListModelValue
      2. PropertyModelValue
      3. ObjectModelValue
   3. ModelType
   Understanding these basic building blocks is the basis for the construction and desconstruction of operations and parameters
5. The native management API - provides information about the construction of operations in Java.
6. Extending JBoss AS 7 - provides information about writing extensions for JBoss AS 7. I find it easier to first get the concepts and then get my hands dirty. Therefore I recommend this sequence:
   
   1. Key Interfaces and Classes Relevant to Extension Developers
   2. Example subsystem

The last document shows quite detailed how to develop an extension. The next step would be to learn how JBoss extensions have been implemented JBoss developers. Download and have a look at the source code of JBoss AS 7! Expect to find a couple of different approaches for implementing extensions.

Here are two projects we developed that may also serve as examples. But keep in mind: We just started with JBoss 7 and these topics. ;-)

1. smartics-exceptions-bom (SVN)
2. smartics-properties-jboss-extension (SVN)

Both projects use our JBoss Modules Maven Plugin for integration into a JBoss AS 7.

Summary

This has been a short tour through the documentation on JBoss Modules and Extensions. It lists the relevant documents to get an easy start into these technologies.

If you happen to encounter a broken relocation in your local Maven repository, the module generation process with JBoss Modules Maven Plugin will produce an unexpected result with two generated modules instead of one.

For this example we assume that the project references the relocated commons-io in Version 1.3.2. This artifact is broken in the local repository as shown below.

Broken relocated Artifact

The relocated but broken artifact in org/apache/commons/commons-io/1.3.2 looks like this:

commons-io-1.3.2-javadoc-resources.jar.lastUpdated
commons-io-1.3.2-javadoc.jar
commons-io-1.3.2-javadoc.jar.sha1
commons-io-1.3.2-sources.jar
commons-io-1.3.2-sources.jar.sha1
commons-io-1.3.2-test-javadoc-resources.jar.lastUpdated
commons-io-1.3.2.jar
commons-io-1.3.2.jar.sha1
commons-io-1.3.2.pom
commons-io-1.3.2.pom.sha1

The contents of the POM shows the following:

<project>
  ...
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <version>1.3.2</version>
  ...
</project>

Why is it broken? The groupId does not match the location within the repository. It is a fault that the folder contains artifacts instead of the relocation POM.

Correct relocated Artifact

This is the correct contents of org/apache/commons/commons-io/1.3.2 as a relocated artifact:

commons-io-1.3.2.pom
commons-io-1.3.2.pom.sha1
_maven.repositories

This is the correct POM of the relocated artifact:

<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>org.apache.commons</groupId>
 <artifactId>commons-io</artifactId>
 <version>1.3.2</version>
 <distributionManagement>
   <relocation>
     <groupId>commons-io</groupId>
     <artifactId>commons-io</artifactId>
     <message>https://issues.sonatype.org/browse/MVNCENTRAL-244</message>
   </relocation>
 </distributionManagement>
</project>

The unexpected Result

The unexpected result created from the broken relocation is that the created modules folder contains two modules for commons-io. This is because the resolvement of the broken relocated project results in two artifacts instead of one.

These are the modules for the artifact:

• org.apache.commons.commons-io
• org.apache.commons.io

Solving the Issue

To solve this issue, remove the broken artifact from the local repository. The next build will restore the correct form. The resolved artifact will create only one module, as expected.

So if you encounter a seemingly unaccountable duplication of modules, please check if it is caused by a relocated relocated artifact, whose folder in the local repository is broken.

The JBoss Modules Maven Plugin, a plugin for Maven, has been released with version 0.3.1.

The new version now supports, besides BOM and non-POM project, multi-module projects.

The following example shows how to use the new property excludeDependencyManagementDependenciesInPomProject to control the export of management dependencies in case of projects of type pom.

<project
  xmlns="http://maven.apache.org/POM/4.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
 
  <groupId>de.smartics.sandbox</groupId>
  <artifactId>multimodule-project</artifactId>
  <version>1.0.0</version>
  <packaging>pom</packaging>
 
  <dependencyManagement>
    <dependencies>
      <!-- These dependencies will NOT be exported -->
    </dependencies>
  </dependencyManagement>
 
  <dependencies>
    <!-- These dependencies will be exported -->
  </dependencies>
 
  <build>
    <plugins>
      <plugin>
        <groupId>de.smartics.maven.plugin</groupId>
        <artifactId>smartics-jboss-modules-maven-plugin</artifactId>
        <version>0.3.1</version>
        <executions>
          <execution>
            <id>create-modules-archive</id>
            <goals>
              <goal>create-modules-archive</goal>
            </goals>
            <phase>package</phase>
          </execution>
        </executions>
        <configuration>
          <excludeDependencyManagementDependenciesInPomProject>true</excludeDependencyManagementDependenciesInPomProject>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

For details on BOM, POM and non-POM projects, please refer to Project Types.

For details on this version of the plugin please visit the project’s homepage.