The configuration config-smartics-alias for the Alias Maven Plugin has been released with version 1.1.0.
The new configuration allows to talk to a JBoss AS via the JBoss AS7 Deployment Plugin via aliases. This speeds up deploying and undeploying artifacts to the application server from the command line.
This is the new section of aliases:
--- 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]
Here is the link to the homepage of version 1.1.0 of this configuration project.
Happy asd'ing and asu'ing! :-)
Please note
The links above directs you to the currently released version of today. As time goes by, new versions of this software will be released. The versioned sites will still be available to provide you with the documentation for the version of the software you are actually using.
For each project there is a link that will always point to the homepage of the latest released version.
Today we hit a stack trace as we pushed a project from Hudson to SonarQube. It complained about a problem injecting the CoberturaReportMojo. We were using the latest version (2.6) of the Cobertura Maven Plugin and encountered no problems, when creating a cobertura report within our Maven site.
This article shows a solution to workaround this problem.
The Problem
We were able to reproduce the issue by calling
mvn cobertura:cobertura
The full stack trace is:
[INFO] <<< cobertura-maven-plugin:2.6:cobertura (default-cli) @ cobertura-test <<<
[INFO]
[INFO] --- cobertura-maven-plugin:2.6:cobertura (default-cli) @ cobertura-test ---
org.sonatype.guice.bean.reflect.Logs$JULSink warn
WARNUNG: Error injecting: org.codehaus.mojo.cobertura.CoberturaReportMojo
java.lang.TypeNotPresentException: Type org.codehaus.mojo.cobertura.CoberturaReportMojo not present
at org.sonatype.guice.bean.reflect.URLClassSpace.loadClass(URLClassSpace.java:109)
at org.sonatype.guice.bean.reflect.NamedClass.load(NamedClass.java:45)
at org.sonatype.guice.bean.reflect.AbstractDeferredClass.get(AbstractDeferredClass.java:45)
at com.google.inject.internal.ProviderInternalFactory.provision(ProviderInternalFactory.java:84)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.provision(InternalFactoryToInitializableAdapter.java:52)
at com.google.inject.internal.ProviderInternalFactory$1.call(ProviderInternalFactory.java:70)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:100)
at org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:138)
at com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
at com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
at com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
at com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
at com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
at com.google.inject.Scopes$1$1.get(Scopes.java:59)
at org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
at org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:253)
at org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:245)
at org.apache.maven.plugin.internal.DefaultMavenPluginManager.getConfiguredMojo(DefaultMavenPluginManager.java:455)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:92)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: java.lang.NoClassDefFoundError: org/apache/maven/reporting/MavenReport
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(ClassRealm.java:386)
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:42)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
at org.sonatype.guice.bean.reflect.URLClassSpace.loadClass(URLClassSpace.java:101)
... 41 more
Caused by: java.lang.ClassNotFoundException: org.apache.maven.reporting.MavenReport
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230)
... 68 more
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
Looking at the dependencies of the Cobertura Maven Plugin it was obvious that the referenced class org.apache.maven.reporting.MavenReport is part of this artifact:
<dependency> <groupId>org.apache.maven.reporting</groupId> <artifactId>maven-reporting-api</artifactId> <version>2.0.8</version> </dependency>
So we tried to replace the artifact by a newer version. The next micro release already fixed the issue.
The Solution
So here is the fix for the configuration of the cobertura plugin:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>cobertura-maven-plugin</artifactId>
<version>2.6</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.reporting</groupId>
<artifactId>maven-reporting-api</artifactId>
<version>2.0.9</version>
</dependency>
</dependencies>
</plugin>
Conclusion
The solution was not that obvious to us from the start. Searching the internet slowly revealed the root cause of the issue.
This information here may help anyone to save time looking for a solution. 
The smartics-jboss-modules-maven-plugin is a tool to generate JBoss Modules based on the information found in a POM and applies additional information found in modules descriptors. To make reuse of these modules descriptors possible, they are developed in an independent configuration project and attached to the plugin as a dependency.
This short article shows how to do it.
For more information about about generating JBoss modules, please refer to smartics-jboss-modules.
The Configuration Project
To create a configuration project just create a Maven project with a packaging type of jar.
<?xml version='1.0'?>
<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>com.mycorp.config</groupId>
<artifactId>config-mycorb-jboss-modules</artifactId>
<version>1.0.0-SNAPSHOT</version>
<packaging>jar</packaging>
<!--
... excluded infrastructure (SCM, deployment, ...) configuration here ...
... you'll probably also want to fix the version numbers of the
used plugins, Maven will tell you that ...
-->
</project>
These are only a few constraints to follow to add modules descriptors:
- The modules descriptor files have to be stored in a folder named
jboss-moduleswithin the JAR artifact. Place it in your project atsrc/main/resources/jboss-modules, so that this folder is automatically included. - The modules descriptor XML files contained in this folder
- require the name extension
.xml. - have to follow the smartics JBoss Modules Descriptor schema.
- require the name extension
The project layout looks like this:
You see that we split the modules descriptors semantically in different files. Per convention the name of the file is the name of the module or a semantic name, if there are several modules descriptors in a file. Putting all descriptors in just one file would be ok, too.
Since the src/main/resources folder is automatically included in a JAR, the POM has not to be adjusted. The project’s artifact can be build, installed and deployed as any other project containing resources.
For a real-life example, please refer to config-smartics-jboss-modules. This is a configuration we use in our projects and add information that is common to all. So the contents of this project certainly changes in the future.
Modules Descriptors
We already gave an introduction to the modules descriptors in our article Modules Descriptor for smartics-jboss-modules-maven-plugin. Nonetheless here is an example of the contents of the XML file, just to get you the complete picture:
<?xml version="1.0"?>
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module name="com.mysql">
<match>
<includes>
<include>
<artifactId>mysql-connector-java</artifactId>
</include>
</includes>
</match>
<apply-to-module>
<dependencies>
<module name="javax.api" />
</dependencies>
</apply-to-module>
</module>
</modules>
The example shows the descriptor of the MySQL JDBC Driver as a module. It defines the main artifact as a resource and adds a dependency to the standard javax.api provided by JBoss AS. The plugin generates a module.xml from this descriptor.
For details on syntax and semantics, please refer to the article Modules Descriptor for smartics-jboss-modules-maven-plugin already mentioned above.
The Configuration of the Plugin
To add configurations to the plugin add a dependency to the artifact. For instance, to include the modules descriptors of config-smartics-jboss-modules, configure the plugin as follows:
<plugin>
<groupId>de.smartics.maven.plugin</groupId>
<artifactId>smartics-jboss-modules-maven-plugin</artifactId>
<version>0.2.0</version>
<executions>
<execution>
<id>create-modules-archive</id>
<goals>
<goal>create-modules-archive</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>de.smartics.config</groupId>
<artifactId>config-smartics-jboss-modules</artifactId>
<version>2.0.1</version>
</dependency>
</dependencies>
</plugin>
Conclusion
In this short example we have shown that there is absolutely no magic in providing module descriptor files for the smartics JBoss Modules Maven Plugin. Add the configuration artifact to the classpath of your plugin and you are done.
For more articles on this topic, please refer to the project's blog.
Robert. (October 30, 2013 at 9:20 pm)Hi Eric,
thank you for your comment!
I don’t know, if I understand your problem exactly. I have added a test case that reflects my understanding at http://www.smartics.eu/svn/public/maven/smartics-jboss-modules-maven-plugin/trunk/src/it/apply-dependency-excludes. And the result is correct, I think.
May I ask you to check, if my assumptions are correct?
- modules.xml
- validate.groovy – a comment contains the resulting module.xml
Maybe you would like to show me the part of your configuration that does not work as expected? Maybe we could discuss this by email (we are currently
working to install a mailing list)? We could post the summary of our results here later, for the benefit of others …
Cheers,
Robert
Robert. (November 1, 2013 at 12:14 pm)I have added an article that may clarify the exclusion topics to our blog: Exclude with smartics-jboss-modules.
The smartics JBoss Modules Maven Plugin allows to create a JBoss modules folder for a project defined by a Maven POM. This articles shows alternatives to this approach and tries to give guidelines on when to use which option.
Option 1: The manual Approach
If you follow the documentation on Extending JBoss AS 7 you encounter a Maven archetype that allows to create an extension project. This project contains a generated module.xml file.
The module.xml looks like this:
<module xmlns="urn:jboss:module:1.0" name="com.acme.corp.tracker">
<resources>
<resource-root path="acme-subsystem.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="org.jboss.staxmapper"/>
<module name="org.jboss.as.controller"/>
<module name="org.jboss.as.server"/>
<module name="org.jboss.modules"/>
<module name="org.jboss.msc"/>
<module name="org.jboss.logging"/>
<module name="org.jboss.vfs"/>
</dependencies>
</module>
Source: acme-subsystem.zip
If you have further dependencies, you will add them as resources or dependencies manually.
The archetype also creates a configuration for the Maven Antrun Plugin that helps to generate the final module.xml for the distribution package:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<inherited>false</inherited>
<version>1.6</version>
<executions>
<execution>
<id>build-dist</id>
<goals>
<goal>run</goal>
</goals>
<phase>package</phase>
<configuration>
<target>
<!-- Replace the '.' in ${module.name} with '/' to get its path -->
<tempfile property="temp.file" />
<echo message="${module.name}" file="${temp.file}" />
<replace file="${temp.file}" token="." value="/" />
<loadfile srcfile="${temp.file}" property="module.path" />
<delete file="${temp.file}" />
<delete dir="target/module" />
<property name="module.dir" value="target/module/${module.path}/main" />
<copy file="src/main/resources/module/main/module.xml" tofile="${module.dir}/module.xml" />
<copy file="target/${project.artifactId}.jar" todir="${module.dir}" />
<echo>Module ${module.name} has been created in the target/module directory. Copy to your JBoss AS 7 installation.</echo>
</target>
</configuration>
</execution>
</executions>
</plugin>
The positive aspect of this approach is that it comes for free. For small projects with no or just a few dependencies, this may all you need.
Any additional resources or artifacts may be deployed with the JBoss AS7 Deployment Plugin via the JBoss CLI. This is out of scope for this article, please refer to Complex Deployment and Resource Examples for more information on this topic.
Option 2: The imperative Approach
If you have to add more dependencies to your project you probably want to synchronize the information in your POM with that of the module.xml. On Stackoverflow Ryan Stewart shows how to do this with a couple of Groovy lines of code:
<plugin>
<groupId>org.codehaus.gmaven</groupId>
<artifactId>gmaven-plugin</artifactId>
<version>1.3</version>
<configuration>
<source>
def sw = new StringWriter()
def xml = new groovy.xml.MarkupBuilder(sw)
xml.module(xmlns:'urn:jboss:module:1.0', name:'ats.platform') {
resources {
project.runtimeClasspathElements.each {
def path = it.find(".*?([\\w\\.-]*\\.jar)") { it[1] }
!path?:'resource-root'(path:path)
}
}
}
println sw
</source>
</configuration>
</plugin>
Source: Generate an xml file with all dependencies with maven
Please refer to the author’s article on information on how to integrate this into your build process or go to his example POM directly.
This is a quick and smart solution to create a module.xml upon the dependencies declared in the POM. Due to its imperative way you may also extend this build script to configure additional information into it.
Option 3: The declarative Approach
To be honest, I have not tried the imperative approach. I’m a fan of declaring what I want to accomplish and have the build system figure out for me how to do it. Therefore I like the Maven way, where the imperative code can be outsourced to a plugin that can be reused in different builds. So this is the plugin configuration to create a complete modules folder:
<plugin>
<groupId>de.smartics.maven.plugin</groupId>
<artifactId>smartics-jboss-modules-maven-plugin</artifactId>
<version>0.2.0</version>
<executions>
<execution>
<id>create-modules-archive</id>
<goals>
<goal>create-modules-archive</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
And this is the modules declarations file that controls the creation of the modules:
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module name="$g1">
<match>
<includes>
<include>
<groupId>(de.smartics.exceptions)</groupId>
</include>
</includes>
</match>
</module>
</modules>
This is just a simple example. Real modules descriptors usually get larger the more control you impose on the generation process (e.g. export or service directives).
By externalizing the modules declarations, they can be easily reused (since writing the whole matching and applying rules over and over again is ridiculous and dissatisfying).
<plugin>
<groupId>de.smartics.maven.plugin</groupId>
<artifactId>smartics-jboss-modules-maven-plugin</artifactId>
<version>0.2.0</version>
<executions>
<execution>
<id>create-modules-archive</id>
<goals>
<goal>create-modules-archive</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>de.smartics.config</groupId>
<artifactId>config-smartics-jboss-modules</artifactId>
<version>2.0.1</version>
</dependency>
</dependencies>
</plugin>
The example above shows how to add external modules descriptors from config-smartics-jboss-modules to your build.
So the positive side effects are reuse of code and declarations. This has the implied benefits that you do not have to test the configuration that builds your code (since this is the responsibility of the developers of the plugin). This approach also allows to have common dependencies as individual modules. This is because they are not necessarily added as resource root, but as dependencies. If you have a larger library, especially if it provided types that are used by other modules in their interfaces, it is useful to have this library as a separate module. This use case can be handled easily with the plugin.
The drawback compared to the imperative approach is, that you have to learn another DSL – here is the XSD for the modules descriptors. This is in situation quite cumbersome, where you use this language only occasionally. A multi-purpose approach with a script may come handier.
Conclusion
On small projects with no or very few dependencies you might use approach one. But usually things get bigger so that an automated approach that syncs the module.xml with the POM information is mandatory. If you want to use the imperative or the declarative approach is merely a matter of taste. The first may be easier and most pragmatic (in the best sense of the word), while the latter may be easier to distribute to cope with larger projects.
Please refer to the articles on JBoss modules on this blog or to the smartics JBoss Modules Maven Plugin’s homepage for more information on this topic.
This is a short introduction to the JBoss modules descriptors file which controls the generation of the JBoss modules folder with the smartics JBoss Modules Maven Plugin.
This plugin is useful for developers using Maven, who want to add their libraries or frameworks as modules or extensions to a JBoss AS 7 server.
For a general introduction to the smartics JBoss Modules Maven Plugin, please refer to Maven Plugin to generate a Modules Directory for JBoss AS 7 or to articles about JBoss modules on this blog.
Side note: If you edit the XML files you may want to benefit from the XSD for the modules descriptor that is a useful tool within you IDE. Add it to your XML catalog and open the files with your XML editor!
Outline: modules
The basic structure of the smartics JBoss modules descriptors XML file is this:
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1"> <module name="..."> </module> <module name="..."> </module> ... <module name="..."> </module> </modules>
You see a list of module descriptors, for each of them a JBoss module folder will be created, if a dependency referenced from the Maven POM matches. For each dependency that is not matched by a module descriptor, a default module will be created.
For a full outline, please refer to The smartics JBoss Modules XSD on the plugin’s site.
Outline: module
The module element, with mandatory name and optional slot attributes, has four major sections:
<module
name=""
slot="">
<directives>
...
</directives>
<match>
...
</match>
<apply-to-dependencies>
...
</apply-to-dependencies>
<apply-to-module>
...
</apply-to-module>
</module>
Directives
The directives control the generation of the modules folder.
Match
The match element selects Maven dependencies by the groupId and/or artifactId. All matching artifacts are added as resource roots (i.e. resource-root elements) to the generated module.xml.
Apply-tos
So there are basically two generated types of entities within the generated JBoss module descriptor (module.xml):
- module – in form of a
module.xml - dependencies – in form of
dependencies/moduleelements within amodule.xml
Not all relevant information for the JBoss module descriptor can be derived from information in the Maven POM. To apply additional information to these generated entities use apply-to-module and apply-to-dependencies respectively. apply-to-module applies (i.e. adds or corrects) information in the generated module.xml. apply-to-dependencies applies (adds or corrects) information in matched dependency modules.
The following sections give some examples on these elements.
Directives by Example
A simple directive is to skip the generation of a module. The use case it as follows: You have a dependency to an artifact, but the artifact is already provided by another JBoss modules folder (e.g. is part of the public API delivered by the JBoss AS itself).
<directives> <skip>true</skip> </directives>
For detailed information on the allowed elements, please refer to the XSD for the modules descriptor.
Match by Example
As mentioned above, this allows to catch Maven dependencies by their artifact coordinates. Only group and artifact ID are supported.
<match>
<includes>
<include>
<groupId>commons-.*</groupId>
<artifactId>commons-(.*)</artifactId>
</include>
</includes>
</match>
It is allowed to use regular expressions in either of the matching elements, but they should be given only on one include. You may also add excludes to filter on the inclusions.
For detailed information on the allowed elements, please refer to the XSD for the modules descriptor.
Apply-to-Dependencies by Example
If you want to modify a generated dependency, e.g. if you want to set the export property to true, use this:
<apply-to-dependencies>
<dependencies>
<match>
<includes>
<include>de.my.module..+</include>
</includes>
</match>
<apply>
<export>true</export>
</apply>
</dependencies>
</apply-to-dependencies>
Within a dependencies element there is a match element that matches modules by their name to have the information in the apply element applied.
There are other elements like services, optional, or imports/exports. For details please refer to Module descriptors.
For detailed information on the allowed elements, please refer to the XSD for the modules descriptor.
Apply-to-Module by Example
If you want to add additional dependencies, use the apply-to-module element. For instance you may want to add a dependency to the public API javax.api provided by the JBoss AS:
<apply-to-module>
<dependencies>
<module name="javax.api" />
</dependencies>
</apply-to-module>
There are other elements like exports, main-class, or properties. For details please refer to Module descriptors.
For detailed information on the allowed elements, please refer to the XSD for the modules descriptor.
Conclusion
This has been a short introduction on the smartics JBoss modules descriptors XML. In this overview we presented the building blocks of this descriptor and short examples to get you started in using the smartics JBoss Modules Maven Plugin.
We plan to add use case centric articles in the future to give you a deeper understanding on the generation task.
The smartics JBoss Modules Maven Plugin, a plugin for Maven, has been released with version 0.2.0.
This plugin allows to generate a modules folder according to JBoss Modules. The dependencies from a Maven POM are used together with module descriptors to generate the target directory structure together with the module.xml files. This is useful if you want to provide libraries as modules or if you are writing an extension for the JBoss AS 7.
This version of the plugin moves the module declaration from the POM to external files. This will make it easier to create the module declarations. An XSD is now also provided!
The new basic structure is this:
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module name="" slot="">
<directives>
...
</directives>
<match>
...
</match>
<apply-to-dependencies>
...
</apply-to-dependencies>
<apply-to-module>
...
</apply-to-module>
</module>
<module>
...
</module>
</modules>
To get started, have a look at Usage Modules.
For details on this version of the plugin please visit the project's homepage.
Please note
The links above directs you to the currently released version of today. As time goes by, new versions of this software will be released. The versioned sites will still be available to provide you with the documentation for the version of the software you are actually using.
For each project there is a link that will always point to the homepage of the latest released version.
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.
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.
POM or BOM?
A POM defines the object model for a project. That is its coordinates for identification, metadata (description, developers, …), URLs to sources, artifact servers, and other information systems and finally the plugins to build the project’s artifacts and the projects dependencies. A BOM, as bill-of-materials is a POM with the intention of defining a set of dependencies to be imported by client projects. Instead of manually selecting appropriate versions of a set of artifacts that work together, the developers of a framework or library provide such a BOM.
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:
<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>
So we would like to generate a modules folder with these dependencies and its transitive closure. Therefore we add our plugin to the BOM like this:
<plugin>
<groupId>de.smartics.maven.plugin</groupId>
<artifactId>smartics-jboss-modules-maven-plugin</artifactId>
<version>0.2.0</version>
<executions>
<execution>
<id>create-modules-archive</id>
<goals>
<goal>create-modules-archive</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
</plugin>
And this modules descriptor to src/etc/jboss-modules (the name of the file is actually irrelevant – all XML files in this folder are expected to be modules descriptors for our plugin):
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module name="$g1">
<match>
<includes>
<include>
<groupId>(de.smartics.exceptions)</groupId>
</include>
</includes>
</match>
</module>
</modules>
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.
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.
Run Maven:
mvn package
And we are done! This is the generated JBoss module descriptor of the main artifacts:
<module xmlns="urn:jboss:module:1.1" name="de.smartics.exceptions">
<resources>
<resource-root path="smart-exceptions-core-0.12.3-SNAPSHOT.jar" />
<resource-root path="smart-exceptions-i18n-0.12.3-SNAPSHOT.jar" />
<resource-root path="smart-exceptions-report-0.12.3-SNAPSHOT.jar" />
</resources>
<dependencies>
<module name="com.google.code.findbugs.jsr305" />
<module name="com.google.guava" />
<module name="com.ibm.icu.icu4j" />
<module name="com.thoughtworks.qdox" />
<module name="commons-configuration" />
<module name="commons-io" />
<module name="commons-lang" />
<module name="commons-logging" />
<module name="de.smartics.messages.smart-messages-core" />
<module name="de.smartics.properties.smart-properties-core" />
<module name="de.smartics.util.smartics-commons" />
<module name="ognl" />
<module name="org.apache.ant" />
<module name="org.javassist" />
</dependencies>
</module>
And this a view on the generated directory:
All transitive dependencies are automatically added.
Nice, but not convincing. The modules of the dependencies are not aligned to the naming scheme found in JBoss. That is because the standard naming scheme uses the Maven group and artifact identifiers to construct the module name.
Finetuning – Mapping Dependencies to Modules
We could add something like this to our modules descriptors file to map the dom4j artifact:
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module name="org.dom4j">
<match>
<includes>
<include>
<artifactId>dom4j</artifactId>
</include>
</includes>
</match>
</module>
</modules>
Just catch the dom4j dependency by its artifact identifier and map it to the name org.dom4j.
And here a bunch of Apache Commons artifacts:
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module name="org.apache.commons.$1">
<match>
<includes>
<include>
<groupId>commons-.*</groupId>
<artifactId>commons-(.*)</artifactId>
</include>
</includes>
</match>
</module>
</modules>
We have shown regular expressions for the matcher already. To refer to the first artifact regular expression group, simply use $1.
We catch some artifacts this way, but this seems to be quite cumbersome. Good news: We have already done this for you! To be honest: For a couple of artifacts, but we will expanding the descriptor set over time (and it is very easy for you to do this for artifacts of your company, too – please have a look at config-smartics-jboss-modules for an example).
So let’s include these standard modules descriptors as dependencies to the plugin to get it fixed:
<plugin>
<groupId>de.smartics.maven.plugin</groupId>
<artifactId>smartics-jboss-modules-maven-plugin</artifactId>
<version>0.2.0</version>
<executions>
<execution>
<id>create-modules-archive</id>
<goals>
<goal>create-modules-archive</goal>
</goals>
<phase>package</phase>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>de.smartics.config</groupId>
<artifactId>config-smartics-jboss-modules</artifactId>
<version>2.0.1</version>
</dependency>
</dependencies>
</plugin>
Ah! Much better:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="de.smartics.exceptions">
<resources>
<resource-root path="smart-exceptions-core-0.12.3-SNAPSHOT.jar" />
<resource-root path="smart-exceptions-i18n-0.12.3-SNAPSHOT.jar" />
<resource-root path="smart-exceptions-report-0.12.3-SNAPSHOT.jar" />
</resources>
<dependencies>
<module name="com.google.code.findbugs.jsr305" />
<module name="com.google.guava" />
<module name="com.ibm.icu.icu4j" />
<module name="com.thoughtworks.qdox" />
<module name="de.smartics.messages.smart-messages-core" />
<module name="de.smartics.properties.smart-properties-core" />
<module name="de.smartics.util.smartics-commons" />
<module name="org.apache.ant" />
<module name="org.apache.commons.configuration" />
<module name="org.apache.commons.io" />
<module name="org.apache.commons.lang" />
<module name="org.apache.commons.logging" />
<module name="org.javassist" />
<module name="org.ognl" />
</dependencies>
</module>
Ok, it is just cosmetics, but we adhere to the conventions defined by the JBoss team. Here is the directory with commons-* moved to org.apache.commons.*:
Moving to our own Slot
Every module is per default written to the main slot. This is nice but will usually collide with what is already provided by the JBoss server. But we can easily move this whole stuff to our own slot.
Here we go:
<plugin>
<groupId>de.smartics.maven.plugin</groupId>
<artifactId>smartics-jboss-modules-maven-plugin</artifactId>
<version>0.2.0</version>
<executions>
<execution>
<id>create-modules-archive</id>
<goals>
<goal>create-modules-archive</goal>
</goals>
<phase>package</phase>
<configuration>
<defaultSlot>smartics-exceptions0</defaultSlot>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>de.smartics.config</groupId>
<artifactId>config-smartics-jboss-modules</artifactId>
<version>2.0.1</version>
</dependency>
</dependencies>
</plugin>
By setting the defaultSlot property of the plugin, we direct the modules to a slot named smartics-exceptions0.
But not all Modules to the default Slot?
In case you want to direct some dependency modules to the main slot? Add a modules descriptor for those files like this:
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module
name="$g1"
slot="smartics-exceptions-0">
<match>
<includes>
<include>
<groupId>(de.smartics.exceptions)</groupId>
</include>
</includes>
</match>
</module>
<module name="org.apache.commons.$1" slot="main">
<match>
<includes>
<include>
<groupId>commons-.*</groupId>
<artifactId>commons-(.*)</artifactId>
</include>
</includes>
</match>
</module>
</modules>
The modules.xml:
<module xmlns="urn:jboss:module:1.1"
name="de.smartics.exceptions"
slot="smartics-exceptions0">
<resources>
<resource-root path="smart-exceptions-core-0.12.3-SNAPSHOT.jar" />
<resource-root path="smart-exceptions-i18n-0.12.3-SNAPSHOT.jar" />
<resource-root path="smart-exceptions-report-0.12.3-SNAPSHOT.jar" />
</resources>
<dependencies>
<module name="com.google.code.findbugs.jsr305" slot="smartics-exceptions0" />
<module name="com.google.guava" slot="smartics-exceptions0" />
<module name="com.ibm.icu.icu4j" slot="smartics-exceptions0" />
<module name="com.thoughtworks.qdox" slot="smartics-exceptions0" />
<module name="de.smartics.messages.smart-messages-core" slot="smartics-exceptions0" />
<module name="de.smartics.properties.smart-properties-core" slot="smartics-exceptions0" />
<module name="de.smartics.util.smartics-commons" slot="smartics-exceptions0" />
<module name="org.apache.ant" slot="smartics-exceptions0" />
<module name="org.apache.commons.configuration" />
<module name="org.apache.commons.io" />
<module name="org.apache.commons.lang" />
<module name="org.apache.commons.logging" />
<module name="org.javassist" slot="smartics-exceptions0" />
<module name="org.ognl" slot="smartics-exceptions0" />
</dependencies>
</module>
The generated modules folder:
Skip Module Generation
One use case for modules in the main slot would be that the main folders are not generated and that modules are used that are already provided by the JBoss server in that slot. Simply add the skip directive to those modules you want to reference as dependencies, but not create a modules folder:
<modules xmlns="http://smartics.de/ns/jboss-modules-descriptor/1">
<module
name="$g1">
<match>
<includes>
<include>
<groupId>(de.smartics.exceptions)</groupId>
</include>
</includes>
</match>
</module>
<module name="org.apache.commons.$1" slot="main">
<directives>
<skip>true</skip>
</directives>
<match>
<includes>
<include>
<groupId>commons-.*</groupId>
<artifactId>commons-(.*)</artifactId>
</include>
</includes>
</match>
</module>
</modules>
As you can see, the dependencies are still there:
<module xmlns="urn:jboss:module:1.1"
name="de.smartics.exceptions"
slot="smartics-exceptions0">
<resources>
<resource-root path="smart-exceptions-core-0.12.3-SNAPSHOT.jar" />
<resource-root path="smart-exceptions-i18n-0.12.3-SNAPSHOT.jar" />
<resource-root path="smart-exceptions-report-0.12.3-SNAPSHOT.jar" />
</resources>
<dependencies>
<module name="com.google.code.findbugs.jsr305" slot="smartics-exceptions0" />
<module name="com.google.guava" slot="smartics-exceptions0" />
<module name="com.ibm.icu.icu4j" slot="smartics-exceptions0" />
<module name="com.thoughtworks.qdox" slot="smartics-exceptions0" />
<module name="de.smartics.messages.smart-messages-core" slot="smartics-exceptions0" />
<module name="de.smartics.properties.smart-properties-core" slot="smartics-exceptions0" />
<module name="de.smartics.util.smartics-commons" slot="smartics-exceptions0" />
<module name="org.apache.ant" slot="smartics-exceptions0" />
<module name="org.apache.commons.configuration" />
<module name="org.apache.commons.io" />
<module name="org.apache.commons.lang" />
<module name="org.apache.commons.logging" />
<module name="org.javassist" slot="smartics-exceptions0" />
<module name="org.ognl" slot="smartics-exceptions0" />
</dependencies>
</module>
Moving the Modules to JBoss
During development you will probably simply want to add the generated folder to the list of JBOSS_MODULEPATH:
set "JBOSS_MODULEPATH=/path/to/my/modules;%JBOSS_HOME%\modules"
Per default a JAR file with all the modules is attached. This archive may be moved to the target folder and unzipped. During development you may set the plugin property attach to false to skip the generation of the JAR. You may also want to move your plugin configuration to a profile like this:
<profiles>
<profile>
<id>modules</id>
<properties>
<attach.archive>true</attach.archive>
</properties>
<build>
<plugins>
<plugin>
<groupId>de.smartics.maven.plugin</groupId>
<artifactId>smartics-jboss-modules-maven-plugin</artifactId>
<version>0.2.0-SNAPSHOT</version>
<executions>
<execution>
<id>create-modules-archive</id>
<goals>
<goal>create-modules-archive</goal>
</goals>
<phase>package</phase>
<configuration>
<attach>${attach.archive}</attach>
<defaultSlot>smartics-exceptions0</defaultSlot>
</configuration>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>de.smartics.config</groupId>
<artifactId>config-smartics-jboss-modules</artifactId>
<version>2.0.1</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</profile>
</profiles>
Conclusion
JBoss modules help to keep the deployables smaller (in our case the exception library with all its dependencies weights more than 15 MB!) by adding the library to the application server’s platform services.
What we have seen is a tool to generate JBoss modules from a Maven POM. For sure no rocket science, but a handy tool to get a project’s artifacts into a JBoss modules folder easily.
In the next article we will show an example for a JBoss extension.
Frank Seidinger. (February 14, 2014 at 12:36 pm)Dear Robert,
Great idea and work. From what I’ve guessed by the description and compared to alternatives (plugins as well as manual procedures) your plugin seems to be the most mature solution currently available.
Therefore I really would really to use your plugin in own open source projects. As you already mentioned your artefacts are not published to the maven central repository although It seems that you meet the necessary requirements.
I therefore would like to encourage you to do so. This seems to me the only way of expressing reliability to your users.
Kind regards,
Frank.
Robert. (February 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
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
Jan. (May 26, 2014 at 2:40 pm)
The testdoc-tools have been released with version 0.4.1.
This release cleans-up two dependencies.
The first clean-up is that of smartics-commons. The old version had some test dependencies on the compile classpath. This has been fixed with version 0.5.2 to which we updated.
The second one is more interesting: Due to a ICU4J 2.6 dependency in the classpath, the Maven Plugin Plugin raises the following exception:
[INFO] Generating "Plugin Documentation" report -— maven-plugin-plugin:3.2 [INFO] Applying mojo extractor for language: java-annotations mojoFailed org.apache.maven.plugins:maven-site-plugin:3.3(default-site) [HUDSON] Archiving site from /home/sw/.hudson/jobs/smartics-jboss-modules-maven-plugin-site/workspace/trunk/target/site to /home/sw/.hudson/jobs/smartics-jboss-modules-maven-plugin-site/site projectFailed de.smartics.maven.plugin:smartics-jboss-modules-maven-plugin:0.1.1-SNAPSHOT sessionEnded [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1:57.108s [INFO] Finished at: Fri Oct 04 13:47:14 CEST 2013 [INFO] Final Memory: 89M/530M [INFO] ------------------------------------------------------------------------ mavenExecutionResult exceptions not empty org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.3:site (default-site) on project smartics-jboss-modules-maven-plugin: Execution default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site failed: 48188 at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:146) at hudson.maven.Maven3Builder.call(Maven3Builder.java:124) at hudson.maven.Maven3Builder.call(Maven3Builder.java:71) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:283) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-site of goal org.apache.maven.plugins:maven-site-plugin:3.3:site failed: 48188 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 27 more Caused by: java.lang.ArrayIndexOutOfBoundsException: 48188 at org.objectweb.asm.ClassReader.readClass(Unknown Source) at org.objectweb.asm.ClassReader.accept(Unknown Source) at org.objectweb.asm.ClassReader.accept(Unknown Source) at org.apache.maven.tools.plugin.annotations.scanner.DefaultMojoAnnotationsScanner.scanFile(DefaultMojoAnnotationsScanner.java:139) at org.apache.maven.tools.plugin.annotations.scanner.DefaultMojoAnnotationsScanner.scan(DefaultMojoAnnotationsScanner.java:85) at org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.scanAnnotations(JavaAnnotationsMojoDescriptorExtractor.java:125) at org.apache.maven.tools.plugin.annotations.JavaAnnotationsMojoDescriptorExtractor.execute(JavaAnnotationsMojoDescriptorExtractor.java:104) at org.apache.maven.tools.plugin.scanner.DefaultMojoScanner.populatePluginDescriptor(DefaultMojoScanner.java:108) at org.apache.maven.plugin.plugin.PluginReport.executeReport(PluginReport.java:271) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:190) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:219) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:319) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:135) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:175) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:138) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) ... 28 more
The problem is known and documented to be fixed with version 2.8 of the library:
DefaultMojoAnnotationsScanner fails to scan some dependencies
There is no release for this version in the Maven repositories (although available through the ICU website). Since the ICU team also recommends to update to newer versions, we updated the dependency to version 3.8 of ICU4J (the dependency is transitive due to jaxen/xom and therefore we stick to this older version).
<dependency>
<groupId>jaxen</groupId>
<artifactId>jaxen</artifactId>
<version>1.1.4</version>
<exclusions>
<exclusion>
<!-- icu4j exchanged: Parsing problem in this lib -->
<groupId>com.ibm.icu</groupId>
<artifactId>icu4j</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<!-- icu4j exchanged: No parsing problem in this lib -->
<groupId>com.ibm.icu</groupId>
<artifactId>icu4j</artifactId>
<version>3.8</version>
</dependency>
For details on this version of the tool set please visit the project's homepage, for changes since the last version, please consult the release report.
The Maven plugin buildmetadata-maven-plugin has been released with version 1.2.0.
This version of the plugin will make it easier to replace the build.properties with its XML counterpart buildmetadata.xml. There are also fixes that prevented the inclusion of certain build metadata into one of its reports.
We also cleaned up some dependencies. Especially the dependencies to various SCM implementations have been removed. The only supported SCM provider is still SVN.
For details on this version of the library please visit the project's homepage, for changes since the last version, please consult the release report.
When will this version be in the Maven repo? I’m trying to use V1.1.5 to get the SVN version but no SCM data appears in the build.properties file so I was hoping the new version would provide that info.
J. Norris. (October 24, 2013 at 7:49 pm)
J. Norris. (October 24, 2013 at 7:56 pm)I found that the reason I wasn’t seeing SCM information was because it is executing a command line and my SVN credentials are not saved.
Still would like to know when 1.2.0 is available in the maven repo.
Robert. (October 25, 2013 at 10:09 am)Currently we have no plans to add our artifacts to Maven Central due to the additional work required. We have a couple of plugins, tools and libraries and we have to handle them all equally. Our projects usually depend on a number of other libraries, configurations, plugins, and POM files that are also not available in the Maven repository. So this is not a “deploy one artifact” effort. Due to our limited time resources, releasing them to our smartics repository is our preferred way.
As long as adding our artifact repository to our user’s repository configuration adds no significant burden or is otherwise not an option, we would continue with our current process of releasing our projects. You probably know the Accessing Artifacts information on our site. In the last years only very few users requested the availability in the Maven repository.
But we are reconsidering our strategy regularly …
BTW: The latest version of the buildmetadata plugin is available at http://www.smartics.eu/buildmetadata-maven-plugin.
J. Norris. (October 25, 2013 at 1:39 pm)Hi Robert,
Thanks for the reply. It is the smartics repository I was referring to. The latest version I saw there was 1.1.6-SNAPSHOT.
Jim
Robert. (October 25, 2013 at 2:08 pm)Hi Jim,
thank you for your comment!
This is a problem due to the Maven conventions we now adhere to, but haven’t been followed from the start. The naming scheme maven-xyz-plugin is reserved for plugins provided by Maven. Therefore we had to rename the maven-buildmetadata-plugin (latest release 1.1.5) to buildmetadata-maven-plugin (latest release as of today 1.3.0).
So here are the versions of maven-buildmetadata-plugin (up to version 1.1.6-SNAPSHOT as you reported) and here are the versions of buildmetadata-maven-plugin (version 1.1.6 and up).
We recognized the problem and are working on a solution to make our users aware of the renaming issue. I’m sorry for the lack of transparency and the mess it entails.
Robert
J. Norris. (October 25, 2013 at 2:09 pm)Hi Robert,
I saw the blog about the renaming and it didn’t register in my brain. Thanks for the update. I’ll make the change.
Jim
I think the apply-to-dependencies / dependencies / match / excludes is not working with resolved dependencies. At least in version 0.2.0
I believe its because ModuleXmlBuilder line 337 adds the dependency via the addContent method regardless of whether it matched or not from the ApplyToDependencies.getDescriptorThatMatches.
I could of course be completely wrong too.
Thanks,
Eric